Wednesday, April 27, 2011

On Game Design

As you may or may not know, Creatures & Castles was originally designed for the iPhone.1
As a platform iOS interested me because it seemed like the perfect platform to support a small development. It has the advantage over PC game development in that unless (like Notch's Minecraft) you happen to be very lucky, a PC game stands little to no chance of garnering any significant attention without a significant spend on marketing and development, as well as a fairly large team of programmers, artists and musicians to produce a game acceptable to the market at large.

Similarly, although they are of a comparable form factor and power to the iOS devices, hand-held consoles such as the Nintendo DS (and variants) have too high a barrier of entry for the casual developer2 due to the ridiculous cost of their development kits, the stringent 'chicken-and-egg'3 developer program entry requirements and bone-headed refusal to support homebrew development - presumably due to a misplaced fear of piracy (which would happen anyway - homebrew support or not). It's a shame. I would have liked to have seen Creatures & Castles on the DS range of hardware. I think it would have worked pretty well.

In any case, back to iOS. With iOS, we have a powerful device (but not so powerful that a single developer can't develop a quality game), a consistent programming interface and a cost of entry for developers of less that $100. Couple that with a vast installed user-base and a well-established storefront, and it's fairly clear to see why the world and his dog is developing apps for iOS (and to a lesser extent Android and WP7).

The most interesting part of the challenge with developing a game for iOS is that the form factor and user interface is virtually unlike any other platform. Attempting to produce a game with 'standard' (e.g. joypad-based) controls is, to me, an unimaginative and intellectually barren exercise. Games such as  Flight Control, Cut the Rope, UFO on Tape and Doodle Jump have successfully married unique and innovative use of the iPhone hardware with simple and compelling games - and as such, have gone on to great and deserved financial success.

With this in mind I tried to make best use of the hardware when I came up with the design for Creatures & Castles. The high concept was "Flight Control in a maze". Possibly not the best high concept ever, but it was good for a start. The aim of the game was for the player to use their finger to trace a path of magical footprints for the hero to follow safely to the exit, using timing and skill to get there in the minimum number of steps. The best score is obtained by reaching the exit in one go; it is possible to break the path up into multiple segments, but a 10 footprint penalty is assessed for each segment. This last point is particularly important.  I did not want the player to get stuck on ANY level. It always annoys me when I buy a game and cannot access all of the content I paid for because I can't get past a particular point. As such, in Creatures & Castles, it's easy to get past any of the levels by using multiple path segments. The catch is that your score will suck.

So the control system as designed is remarkably simple:

  • Drag from the hero to create a path.
  • Touch the hero to set him/her moving along that path.
  • Touch the undo button to undo a path.
  • Touch a collected object to use it.

It's not perfect - particularly when it comes to tracing paths through the maze on the iPhone screen. It can be a bit small and fiddly, so I added the ability to use a two-finger pinch to zoom. Not the best possible solution, I'm sure, but by no means the worst.

1Actually, it was originally designed as an online multiplayer game similar to the current rash of Facebook societal games, but that's another story. I gutted my original design to come up with a simple iPhone game instead.)
2 This may well be something that Nintendo and Sony come to regret with time unless they have a change of heart.
3 With few exceptions, they will not even consider applications from 'first-time' developers without a significant track record.

Sunday, April 10, 2011

Revisiting tinting

So, if you look closely at my screenshot from the post before last, you'll notice that I was talking about tinting images on-the-fly. I did a bunch of research on the web to see how other people were tinting their images. After some time, I discovered that the standard tinting algorithm used was as follows:

- where c is the color component (r, g, or b).

Applying various tints gives the following results. The original is on the left, and the tinted version is on the right:

Note that the colored text is supposed to have a black outline. Clearly, this will not do - no matter how brightly it is tinted, it should still retain internal details.

I spent some time playing around with various different blending schemes using different color spaces until I came up with the following modification:

This modification is the same as the previous, except that the tint alpha value is multiplied by the luminance of the source pixel. Thus, the darker the pixel the less it is tinted. This produced results as follows:

Now, this looks pretty good on the letters. The black outline can clearly be seen. However, if you look very closely at the red lettering, there is a faint grey outline visible between the black and the red. This is because the luminance is too low at that point to allow any significant tinting. However, it is still light enough such that the lack of tint can clearly be seen. In general, it seems that luminance alone isn't enough to get us an interesting tint.

It turns out that this has a fairly simple solution. The problem is that the luminance isn't increasing quickly enough for us - the linear relationship between how much we tint and how bright the source pixel is is not quite suitable. What we need instead is a tint level that increases much faster as the luminance increases. To fix this, I chose to multiply by the square root of the luminance. ("Wait," I hear you say, "Square root? Surely that will be smaller?" Well in this case no. The square root of a number between 0 and 1 is larger than the number itself. E.g. the square root of 0.25 is actually 0.5.) 

The adjusted equation now looks like this:

Anyway. Enough mathematics. The result looks like this:

And the full-screen tint looks like this:
Which looks just about right. Now, the big question is, why was this information not easy for me to find online? Was I just searching for the wrong stuff, or is it something that everybody already knew apart from me?

The updated javascript ImpactJS plugin can be downloaded here

Sunday, April 03, 2011

Staying in touch - Or Not, As The Case May Be

This week I've been working on getting the basic game control framework in place. If you've played Creatures & Castles on the iPhone or iPad (and if not, why not - go and buy it immediately!) you'll have noticed that the character is controlled by tracing the character's route using the player's finger to lay a path of magical footprints.

Touching and dragging is a natural operation on the touch-sensitive screen of the iDevices. The most direct way to translate this across to the HTML5 version would be to have the player click and drag the path. However in practice it's a colossal pain in the ass, so I decided to implement a different system for controlling the main character. I'm in the process of prototyping a simple system where left-clicking will create a path between the character and the position of the cursor - as long as there isn't an intervening wall. Holding down the right mouse button undoes the path, which removes the need for a separate undo button as in the iDevice version.

It's not quite perfect, and I still have some tweaks and experimentation to perform before I'm 100% happy with it, and after that the core game will be in place. Then it will be time to start fleshing out some of the in-game enemies and the scoring system. From there, I'll work my way out to the supporting features such as the title screen, level select screens and other ancillary features. In fact, the reasons behind my choices to develop the game from the inside out would make a good topic for my next post.