My aim in entering
the competition was to learn more about game dev, and the purpose of this
postmortem will be to try and make the lessons learnt explicit. My entry is
available for download on itch, and the source code is available at github.
There are many things one could focus to talk about in a postmortem - the number
of choices made in making a game is staggering. So I want to make a number of
posts, which otherwise would have been notes to myself, about the most important
lessons I've learnt from this project. In this post I'll talk about the
graphics.
Graphics
If you had told me I would be pleased with the graphics of my Ludum Dare entry
when I started I don't think I would have believed you - I am no artist!
However, after the
competition, I think the graphics are perfectly acceptable. They are very basic,
but are functional, have a consistent style and a consistent colour scheme. In
particular, I think the conscious choice to keep to a restricted colour scheme
was a very simple way to drastically increase the quality of what was produced,
and something that can easily be replicated in future.
Beyond that, I encountered some issues and suggestions with the graphics which
should be addressed in future. The first of these was handling edge cases. In an
interactive medium like games it is inevitable that the game will produce some
edge cases that were originally unaccounted for. In the case of my game, there
are two edge cases which I've noticed crop up that I am unhappy with the
handling of. Here is a screenshot showing both:

On the left are two overlapping bullets moving in opposite directions.
Unforunately here the shape of the bullets does not work well and it is awkward
to visually parse this information. On the right in this image is a gun with a
timer which really just means "this gun always shoots", which could be more
simply shown by having only one stage in the timer (in general, timers can have
repeating patterns, which ought to be removed to simplify the player's
information).
Unforeseen edge cases like this are by definition not something one can account
for beforehand, however, whilst making my entry I did not pay attention to
details like this at an earlier stage in development. Instead, I didn't take the
time to test for things other than "does this code work", which was a mistake.
The second problem I had with the graphics was how good a job the graphics do of
drawing the attention of the player to the important things happening in the
game. Here is an example screenshot:

The most important thing in the game is probably the player themself, who is
located in the top left here. I think that the robot is sufficiently visually
distinct, so this is not a problem. However, the next most important thing the
player probably ought to be aware of is the location of the goal, which in this
screenshot is two squares down from the player. Unfortunately, I chose to draw
the goal in a dark purple colour rather than a light purple, and the goal does
not draw the eye well. In addition, a bullet may be located over the goal to
further obscure it (this is not really avoidable, but is something I ought to
have been aware of).
Other things in the scene of importance are the timers of each of the guns.
I think these are quite visually distinct and self explanatory (I've not had
anyone leave a comment saying they didn't understand when a gun would fire, or
when it would rotate). However, I relied on the timers to give all information
about when the guns fire, but neglected that this means there isn't a big visual
cue about which guns are firing next turn. This means a common error whilst
playing is to move into a square believing it is safe but find out you have
overlooked a gun which was going to fire into that square next turn. This could
be addressed by the guns changing colour to be brighter when they are going to
fire next turn.
Finally, here is a better screenshot to demonstrate the problem of locating the
most important information in the game. As it stands, the first part of the game
is a mini-game of where's Waldo to locate the robot and the goal!

Finally, there are no sprite animations in the game, but this would have added a
lot. Below is an example of the animations:

I think in light of how much it would add, I ought to look into learning to
animate the robot (and perhaps upgrading the explosion animations from particle
effects). We shall see about this in the future!
To summarise the lessons learnt for the future are:
- Use a colour scheme as an easy way of increasing graphics quality;
- Make notes on what important information the graphics need to convey;
- Try hand making animations.