Times, trials, and turbulence.
For those of you unaware, I’m currently on my four-month co-op term from the university, working at the Ministry of Education here in Ontario. The commute down to (and back from) Toronto pulls a lot out of me each day, so developing Skirmish on the side has been a difficult talk. Still, during the week I manage to fit in two hours overall during my to-and-fro train rides, and sometimes a little in the evening too. The weekend is where progress tends to shine the most, however, and this weekend hasn’t been an exception.
In terms of development status, Skirmish Online is still in the very early stages. The core engine is the primary area of development, so the focus is on the foundation systems like graphics routines, data structures, implementing the map system, starting the particle engine, and so forth. The only traces of actual ‘gameplay material’ is insofar that the basic Player physics are implemented (ie. moving, animation, and collisions with the map). I’m very eager to get started on the gameplay, but there’s plenty of work ahead before I get to that.
All of that said, this weekend saw three items meet implementation:
- The ResPak resource package format, with runtime loading and image definitions.
- Bitmap fonts; including (semi-)optimized rendering, nifty colour gradients, and outlines.
- The basics of the logging system, including toggleable info-channels and file ouput in coloured HTML format.
Okay, what does all of this mean?
First of all, a “ResPak” is a fancy name for a big honkin’ ZIP archive full of resource data (images, sounds, music tracks). Thanks to Java’s Zip-Stream classes, this wasn’t too hard to implement. Inside each ResPak is a definitions file containing information about each resource inside the ResPak, so the game knows more about how the (currently only images) items work. For images, it defines the in-game handle for the image, the frame width/height (for spritesheets), and the transparency colour to use. A simplified system — which was the goal to avoid the need to write unnecessary editors and the like. Simple, but totally functional. There’s very little in terms of security in it, but it’s just not needed since modifying the resources won’t give any players an unfair advantage. Heck, call it “moddability” instead. 😉
Next up, the bitmap fonts are exactly what they sound like. I’m currently taking advantage of the wonderful AngelCode Bitmap Font Generator, which defines a nice easy-to-parse file format and PNG images for me to read in and use. The idea is that each glyph (or letter, rather) is defined as a piece of the overall ‘alphabet texture’ mapped onto a square ‘billboard’. So when a desired string is to be outputted, the billboards are just strung together and drawn to the screen. Of course, I couldn’t resist the temptation to add some extra glitz, such as some nice colour gradients and custom-colour outlines to spazz things up. I think it’ll go a long way in getting that ‘extra polish’ feel by the end:
(Click to enlarge)
Finally, the logging system, which isn’t really too much to speak about. It’s just a simple static class that lets you make calls like:
Log.write("File not found!", LOGCHAN_ERROR);
The idea is that the log data that is stored will be used to save logs to disk, write out data to the in-game chat console (chat messages, game events, etc), or output to System.out for the console-based dedicated server, in a reasonably flexible manner so that each output form can have its own set of channels it wishes to subscribe to.
And alas, tomorrow is Monday. It will certainly be a long one, but hopefully I’ll be awake enough to move forward with the next steps of development. Until next time!