Cloud city

21 November 2019

That was both easier and harder than I expected. It took longer than I had initially planned, but I also got further.

Using GitHub Actions, I set up an automatic build and test process for every push. This would have been especially easy for a .Net Core application, but unfortunately, I’m just using vanilla Wpf. I ended up building a Powershell script to call MsBuild and NUnit executables. The biggest challenge was getting the NuGet packages to Restore. Luckily, someone has already created an Action to provide the NuGet executable, so it wasn’t especially hard. It even sends me a mail when a build fails (an unexpected but impressive built-in feature).

The annoying thing with all CI systems is having to keep pushing to the remote repo to see what happens. This really hampers the learning process, but since they all have the same issue, I was expecting it.

Next, when a release is created in GitHub, the script goes ahead and publishes the binary with the same tag. Thanks to the ability to link to the ‘latest’ release, this is always downloadable via a button on the website.

Of course, I also wanted to stamp a version number into the binary so that I can more easily trace issues in the future. I found all sorts of neat plugins for generating version numbers, but the version number was already part of the Release details, so I didn’t need those. Ultimately I just factored out a single file containing the version numbers and the script overwrites that before the build commences. It feels a little crude, but it definitely gets the job done. It also allows me to run the build scripts locally for testing, which really cuts back on the number of pointless commits.

I also ran into an issue with multiple builds being triggered for each release, turns out that GitHub’s ‘release’ event is fired multiple times. Each triggering has a different action property set. Once I filtered those down to just the last one, I got a realistic number of build events.

So with that behind me, I can get back to more exciting work, and if you feel like it, you can download the latest version and follow along with the progress.

And now…

Anyone following along will know I’m trying to hit the biggest unknowns first, and that leads me nicely into the next area I’m going to tackle. Sound effects. Not hearing the engine roar is unsatisfying and I’d like to address that. It was a toss-up between animations and sounds. Ultimately animation is just more of the same, whereas sound is an entirely new area.

Sound can be seen as a whole new medium of feedback between the game logic and the user. As such, I think it will be reasonable to push sound processing into its own thread. Possibly even multiple threads for simultaneous sound effects (e.g. rocket thrust and blob pulsing). Then the question becomes - how many simultaneous sound effects should be supported (indeed, how many can WPF support?). Also, do I start playing sounds on an event, or play them as long as some state exists? Playing on an event and forgetting is probably most straightforward, but playing on state would likely be most immersive. What about spatial awareness? Should close sounds be louder and more distant sounds be quieter? If so, at what point is an object too distant to play its sound? Sound is, apparently, a complex issue.

I think I need first to build a SoundTest app to explore what is possible, independent of the game itself. A test app worked well for the visuals, and when something works well I like to do more of it :)

So without too much of a plan, I’m off to play about and see what I can do :)