It is common advice to test your game as early as possible and keep testing it constantly throughout development, with as many fresh eyes as possible. I’m sure it’s very good advice, but it’s hard to follow when starting from zero in terms of following and budget, especially the fresh eyes part. I’ve gotten a few friends to test earlier versions of Atomic Space Race some time ago, but it’s time to cast that net again. If you want to be involved I’ve set up a signup form here. I’d prefer to coordinate tests by means of a Discord server, but if that doesn’t work for some interested potential testers I’m open to other ideas, and the form has a place to suggest. The comments section here works for suggestions and discussion too.
Currently I’m building versions for Mac OSX and Linux as well as windows, but don’t have enviroments to test them myself.
One of the challenges with testing is drawing the line on when enough has been implemented to push it out the door. There’s always one more thing you want to do before it’s ready, especially when there are large parts unfinished.
Many things have been advanced a little, but only a few item have come to fruition since the last posting. One is a basic options menu, presently just a color option and some volume controls. The other is sound and music for those options to control. Sound design and music production are areas I have no expertise in, but there’s some good resources out there. In particular I’d like to highlight Gravity Sound who has produced several tracks I’m using in the current build, and has plenty of other good work I’m not using.
Another challenge is minimizing the amount of repeated work every time you need to release a version. I’ve got a build-and-package script from when I made the Atomic Space Tools builds, but that was at least one computer and several adjustments of the file structure ago. My ideas about proper package structuring and naming conventions have also evolved, so I’m revising all that before getting myself locked into anything.
Lastly I’ve moved the project from Unity 5.x to Unity 2017. Constantly moving up versions isn’t a great idea for an ongoing project, but there’s a few behind the scenes features of newer versions that I’d like to have on hand, and 2017 is the basis for Unity’s current Long-Term Support version that promises to get stability and compatability updates for a while without the major feature changes of the ongoing verison, so I made the decision to make the jump to that rather than Unity 2017. This time at least it was a rather painless update.
Again, if you are interested in participating in testing, check out the signup form. First testers will probably get given links within the next week.