2018-01-27

A Puzzle Game

If you’re stuck on an aeroplane with nothing to do, what better way to pass the time than to write a new game? I’d written versions of this particular game in Flash and SQL before so creating a new version in C would be more of an exercise in dredging up old memories rather than creating something new (especially as the basics are so trivial to implement), making it an ideal project for a plane flight. I got the game logic working in the air, the rest of the game written over the next few days, and I’ve been mucking around with presentation and fluff for the last few weeks.

Here’s a slightly cropped video of the DS version:

Most of the game works the same way as the monochrome Game Boy version. Personally I think that everything added to the game since the Game Boy version - with the exception of color - has made the game worse, so this version intentionally sticks fairly closely to its minimalistic inspiration. Some of the graphics I redrew from scratch, using the Game Boy Color version as a reference, whilst some started out as screenshots of the GB version. The music came from The Mod Archive; after having no success in using large WAV files of the original audio I was happy to find some great versions of the original music on that site in XM format.

The only aspect of the game I intentionally changed was the responsiveness of the controls. Neither of the Game Boy versions of the game managed to get the controls right. The controls in the GB version of the game were sluggish and unresponsive. The controls in the GBC version grossly overcorrected the problem and made everything move far too quickly. This version finds a happy medium between the two.

I dug out the source code for the Flash version as a reference to see how I’d implemented that, opening it with a hex editor as I haven’t owned a copy of Flash XM or a computer capable of running it for years, but surprisingly there was barely any code in it. Thinking back, the two trickiest parts of the Flash remake were coming up with a function to rotate multidimensional arrays by 90 degrees (in order to rotate the shapes) and trying to increase the automatic drop speed by a constant amount in each level. The Flash version tried to solve the drop speed by using an ugly system in which, instead of regularly dropping the shape every n frames, drops were triggered by a repeating pattern of frames - eg a drop after one frame, then after two frames, then after one frame, etc - in order to simulate fractional frames. Rotating the shapes was tricky because each shape was contained within an array just large enough to accommodate the shape (the box was stored as a 2x2 array while the line was a 1x4 array, for example), so the rotation algorithm had to work with multidimensional arrays whose dimensions changed size as they rotated. Worse, each shape has a rotation point that can fall outside the bounds of its array making it difficult to reposition correctly in the grid once rotated.

For the DS version I avoided the rotation problem entirely by storing all possible rotations of the shapes as pre-canned data in the game, and solved the repositioning problem by representing all shapes using 4x4 arrays. There’s no need to reposition the shapes following a rotation because the arrays are large enough to contain the correct position of each rotation. I solved the drop speed problem by using the frame counts from the Game Boy version as listed over at HardDrop.

Of course, creating a new game led to a number of improvements and enhancements to the underlying libraries, which is the fun but time-consuming part. I wanted to support graphics that were 50% larger on the PSP and 3DS, which meant changing my PNG-to-C tool so that it could convert two PNG files into one C file with #ifdefs to switch automatically between small or large graphics depending on the target platform. I was already embedding two copies of the bitmap data - one for the DS and other platforms and one for the Dreamcast - so I first had to implement real fixes for the hacky system that handled the color space conversions for that platform and get rid of the unnecessary bitmap data.

Once I had support for multiple bitmap sizes I realized I’d also need to be able to support multiple font sizes. I finished off my objc tool for creating fonts from PNGs and added large font support to it.

Supporting XM mod files meant adding mod support to the sound system. That was straight-forward enough: SDL’s mixer library uses libmodplug for mod playback; the DS uses MaxMod; and I’m using MikMod for the PSP. I haven’t figured out mod support for the Dreamcast or any kind of sound for the 3DS yet. Hanky Alien, Chuckie Egg and this game all had their own sound implementations, so I divided the class into two pieces (a data provider and a sound server) and moved the server out into the shared hardware abstraction library. Chuckie Egg and this game now use the server code; Hanky Alien will use it eventually.

Finally, I’ve been adding macros for reducing the amount of boilerplate necessary when creating classes. I’ve also created a tool that will generate new source and header files for classes.

There’s still a bunch of tedious presentation work to do to finish this off. I wrote a hierarchical menu system for Amy Zing that I’d hoped would be the only menu system I’d ever need to write, but naturally the menu system I need here uses a different structure. It’s more like a graph of screens than a hierarchy, in which the decision about which node to visit next depends on logic in whatever object owns the menu instance rather than the option that the user just selected. I’m hoping that the high score system I wrote for Chuckie Egg will just drop in to this game, though I’ll need to write a new view to present it. I need a title screen, a “game over” screen, a “game complete” screen (for the B-type game), some alternative background graphics, launcher assets for the PSP, a two-player mode (on the same device) and music/sound on platforms that currently don’t have it.

2009-11-15

Woopsi 0.40 Alpha Released

A new release! There are quite a few changes bundled up in this release, all of which have been described in detail over the last month or so of blog posts. In brief, the important changes are:

  • Woopsi is out of pre-alpha and into alpha release;
  • It now ships as a library that can be installed into the devkitPro folder;
  • PALib support has been removed;
  • Improvements to the graphics API;
  • New test and example projects;
  • Lots of bugfixes.

Get it from the usual place:

SourceForge

Here’s a video of one of the new example projects. It demonstrates most the drawing functionality that’s available when drawing directly to a Woopsi gadget:

For anyone with a browser that can’t show H.264-format video tags, here’s a link instead:

WoopsiGadgetDrawing

2009-10-04

Networked PacMan and Embedding Video

Adding video to a blog not hosted on one of the main blog providers is a real pain. WordPress has about a dozen plugins that handle video, most of which haven’t been updated in a while and are tricky to configure. The worst offenders are the plugins that handle anything other than FLV format videos or streamed videos hosted on sites like YouTube. That’s a shame, because actually creating FLV videos is itself far more work than it should be. A simple plugin that played MOV or AVI files would be greatly appreciated.

I eventually decided upon the FLV Embed plugin. It seems to be reasonably up-to-date and is very easy to use. Unlike the YouTube streaming plugins, it lets me keep the video files hosted on my own server.

Once I’d installed the plugin I needed to get my video into FLV format. This, as previously mentioned, is a huge pain. My version of Flash is PPC-only and I don’t want to have to install Rosetta on my nice clean Snow Leopard install, so using Flash is out. FFmpegX depends on a binary that is also PPC-only (and hasn’t been updated in over a year) so that’s out too. All of the other FLV converters for both the Mac and Windows are either crap shareware applications, look like they contain malware, or both.

(As a side note, why is it that all of these crappy shareware programs insist on creating skinned UIs? They all look like the kind of shovelware that gets installed on new PCs that anyone with any sense uninstalls before they even attempt to use the computer.)

Anyway, the only FLV converter I found that was remotely useful was iVideoConverter. It is a shareware app, but it’s got a good UI and it actually works, which is more than I can say for the rest. As it’s just a front-end for ffmpeg, you’d expect nothing less from it. I nearly resorted to using the HTML5 video tag, but since the browser manufacturers refuse to agree on a video standard, it’s rather pointless. (EDIT: After some testing, it seems that Safari will play Ogg Theora - though that may be because I’ve got all sorts of video players installed, including Perian - whilst Firefox refuses to play anything at all, despite me having configured the appropriate MIME types.)

Anyway, the whole purpose of this waste of a weekend was to post a video of a project I wrote a while ago. I created a networked version of PacMan as part of a five week group project for my master’s degree. The project as it was submitted was rather larger - it had a second game and a database behind it. I’ve stripped out just about everything that I didn’t personally write (barring the XML config file stuff) and the database (simply to make it easier to distribute).

In this version, the first player to connect to the server plays as PacMan; the other players control the ghosts. By default, it supports 2, 4, 6 or 8-player games, but the code itself will support any number of players. Here’s the video of it in action; it shows two networked clients running on the same host:

The game can be downloaded here:

PacMan

This includes the NetBeans project with full sourcecode, plus Java binaries and instructions on how to run them. Note that in order to play the game you need to have the JVM 1.5 (at least) installed.