In the hole

19 November 2019

Success. It’s officially a game :) There is an objective, a mechanic, a win condition, and a lose condition. There is even a menu and pause functionality as a bonus. Phew!

(showing a play to victory)

Of course, it’s not ‘done’, not by a long shot. But I’m happy to have some real progress. Probably it’s enough to create the first release version too - it is, after all, essential to know how the deployment system works. I guess that is, in fact, the next step.

The journey

Let me tell you about some of the issues and challenges I experienced since the last post.

Most critically, after implementing gravitational pull for the black hole at the centre of the world, I discovered that it was possible to get the ship in to orbit. No, not just possible but darn right easy. And that totally sucked the fun out of the experience, because the action slowed right down. So, despite the grand back story, that mechanic had to go. On a whim I tried inverting the force so that it pushed away from the centre, surprisingly that was a lot better. So I had to update the backstory to shoehorn the new mechanic into it. Thinking about how to do that I concluded the most straightforward approach would be if the player were somehow now inside the event horizon, so I added a second circle around the outside of the play area and made that deadly.

Then I had a bug in the mouse input that was dropping some of the movements. Fixing that made the ship behave a lot more smoothly, a huge relief.

There were some WPF issues along the way too. First was line drawing, I was sure there must be a way to draw inset/outset lines, but it seems not; the solution is to manually adjust the location of the line by its thickness. Next up was the issue of bounding boxes. Calculating an accurate bounding box for a given path geometry turns out to be complicated. The Path object has a method for it built-in, but it does not provide particularly accurate results, which is awkward when it comes to hit testing - the user can see when it is wrong very quickly! For now, I’ve added some fudge factors here and there, not ideal but straightforward and it works.

In figuring all the above out, I extended and improved the Visual Test application. Building that was one of my best decisions, it has helped tremendously with nailing the details.

And then we come back to our friend the viewport. The code there was getting overly complicated and hard to follow, so I refactored it into lots of smaller classes. Doing that simplified so many parts that a major refactoring pass followed. Now the actual game logic is readable from the code - major score :) But that’s not all. Whilst testing the event horizon, I made the game-area much larger than the playable space, effectively meaning that the cursor always stayed fixed in the middle of the screen. And you know what? It is way more predictable. So, I think it is time to follow the herd and have a centrally fixed cursor. It’s not urgent; I can fudge it with a large game-area for now.

Screen size also made itself an issue. Playing in a window is substantially harder than playing full screen for two reasons. First, there is a lot less time to react to approaching edges. And second, with the game windowed it is possible to see much less of the environment at any given time, which makes it easy to get lost. The obvious solution would be to zoom out when windowed so that the visible play area was always the same. Problem with that is that it will make the UI elements really small, probably unplayably small. This is another one of those situations with no clear answer, and I’m going to punt on this too - full screen is my goal for now, and the user can always make the window bigger.

Can I play?

To let my readers (numbering, definitely, in the low digits) try playing what I have so far, I need to make a downloadable version. So next up is a quick detour into building and releasing - time to investigate GitHub Actions.