Prototyping Experiments

I'm sure most of you are familiar with the concept of prototyping. Often it's the only way to determine whether a game will pan out (in terms of gameplay ideas).

For Creatures & Castles, the only prototype was in my head. The game was written without any extensive testing of ideas - I already knew what I wanted to do. Not so for "Shattered"...

I know what the basic storyline is, and I know I have some interesting and original game mechanic ideas that lend themselves well to that story line. What I don't know is how well they will work in practice.

With that in mind, I'm planning on implementing a quick prototype of some of the ideas in Monkey. It's  a fun little programming language, and (despite not having a debugger), it's a pretty good fit for what I want to do. Of particular interest to me is the ability to target multiple platforms (currently HTML5, OsX, Windows, XNA (and hence Windows Phone and XBOX 360) as well as iOS and Android. That's a whole lot of platforms. Of course, that doesn't mean I intend to test my prototype on all of those platforms, but if you have a simple 2D game idea in mind, there are certainly worse programming languages to use to target all those platforms at once.

In my case, the choice of prototyping language is due to a golden rule I always intend to follow when prototyping but never quite manage to do so; that is all prototype code should be thrown away at the end of the prototype. It will have been munged and hacked, and probably stinks to high heaven. If I wrote it in the target language to start with, it would be tempting to just use it as is instead of rewrite it properly. By using a different language, I have no choice.

Another issue with prototyping is the use of test art. I'm not really an artist - I dabble, but that's about it... Ian, on the other hand, is an excellent artist, but I'm not about to ask him to produce a load of throwaway art so I can use it in a prototype.

With that in mind, I searched for some stick-art walk and run cycle animations on the web. I was unable to find any suitable (although I was amazed to find that there are websites devoted to stick-art animation). I did find a fairly decent tool called Stykz designed for animating stick art characters and - after about an hour of playing around managed to put together a reasonably decent walk and run cycle.

run cycle

walk cycle 

Now admittedly they are not perfect, but they will do for my prototyping purposes (and you are welcome to them for you own use if you think they'd be useful).

Hopefully, I'll be able to get some prototype screenshots up and running in a few days - although I have a sneaking suspicion that this prototype may be strong enough to stand up as a game in its own right. We shall see... 

If so, it will certainly be an interesting detour before returning to Shattered, and will give Ian even more time to produce artwork.

ADDENDUM: Monkey is, so far, proving to be a total pain in the arse. There is no debugger! Apparently one is in the works. I shall persist for a little while more to see if the pain eases. Failing that, I'll put it to one side until the promised debugger appears!


ADDENDUM 2: I'm starting to grok it a little bit. The lack of a debugger is painful, but with careful programming (and judicious use of logging) it's possible to get stuff working. After a day, I have this (as well as a reasonable understanding of the framework).

Exciting Stuff! (It's a prototype, dammit!!!)

ADDENDUM 3: A few days later and I'm getting a feel for it. The lack of a debugger is an unholy pain, but it has the advantage of making you think about the code more before you run it. Additionally, it's possible to load the XNA target into Visual Studio and debug it there - the code mapping is remarkably one-to-one.

I see shiny things.