Menus

23 October 2019

So the essential engine bit looks to be successful so far. I can move the blob about the screen one keypress at a time using WSAD. The ‘calculation’ such as it is is done on a background thread. When the user resizes the screen, the screen redraws, and of course, it also redraws on a timer - all very nice.

Lessons

I did discover a couple of somewhat unexpected things during the previous step, probably worth noting those now.

Focus

Initially, nothing I hooked up would do anything. It turned out to be a question of Input Focus. I hadn’t appreciated there are two steps to getting the focus at application startup. The first is that the control to which the focus is going must have Focusable = true. The second is that when the main window loads it doesn’t just focus the first available control, you have to tell it which control to focus. It’s a simple one-liner in the code behind, so no big deal once it works :)

Logging

Big projects always have some Logging. I thought this project was small enough to get away without it, but tracking down the focus issue showed me that that is not so. For now, I’m using simple Debug.WriteLines to get the effect, but clearly, a proper logging solution is needed soon.

Next steps

But what next? There are so many directions in which I could take this to still get to my ultimate end goal. I could do any of the following (and probably more):

• logging
• improve the threading code (cancelability etc.)
• separate the viewport from the game area
• draw an actual rocket instead of a blob
• handle edge collisions
• have a win condition
• hook up the mouse

I think, however, what I’m going to do first is to add a simple Menu to the game. I know for sure I’ll need this and I’ll want to explore a bit how to hook it all up nicely in Wpf.

Menus

I’m sure there will be lots of menus to come for this project. First, though, I want to get the basic structure in place. So the starting menu will be simple:

• Start New Game
• Resume Game (if applicable)
• Quit to Desktop That should do it :) Although, there needs to be a way to get the Menu up once the game is running. I’m thinking simply pressing the ‘Escape’ key will work nicely for this.

It doesn’t seem like much, but this little Menu implies much for the structure of the application.

• The startup should go to the Menu instead of jumping directly into the game.
• It must be possible to toggle between Menu and active gameplay with Escape/Resume.
• Showing the Menu should pause the game.
• There are now multiple ways to exit - the windows ways, and the Menu way.
• What happens if the app loses focus to another window? It should undoubtedly pause, but should it show the Menu? I think the simplest here will be to show the Menu. At least then there is only one paused state.
• The Resume option can be unavailable if no game is currently in progress.

Now we know what is needed, it’s time to code again.