Killing Time...

Well, I suppose it's about time I wrote a blog post. It's been a while... Since I last wrote a post, Hiive has brought on two part-time employees - both of whom (after a couple of early hiccups) are working out pretty well so far.

The initial plan was that they would free up more time for me, and I guess they have - but not as much as I'd hoped for... Part of that is ramp up and training, which is to be expected, so hopefully once they are fully up to speed on my idiosyncratic ways of running a company I'll have more time for the things I want to do rather than the boring management stuff. I clearly wasn't cut out to be a manager so my employees effectively have to manage themselves...

Anyway. That's boring. Onto some interesting stuff... We're currently performing a grand experiment with the Monkey programming language. You've probably read about me alternately complaining and/or praising it since I started experimenting with it. In fact, even in the short time I've been using it in earnest, the quality of the product has improved leaps and bounds... It's very good, if a little rough around the edges. For quickly getting up and running it excels. However, I'm not convinced that it will be a good fit for me to take a product from conception through to release. It will get me close, but when it comes to matters of polish, the 'one size fits all' targetting method isn't ideal. It gets me 90% of the way there, but doesn't really feel right for the last 10%. For example, if I want to add in custom shaders to make the game look more impressive, then there is a mechanism for doing so - but it's target specific and relies on getting your hands dirty with the target language to implement correctly. This is all fine, of course, but if I'm going to go to the trouble of writing in target-specific languages, I'm wondering why I didn't start out in the target language to start with.

There are other things I don't particularly like about Monkey as well... The main one being that class inheritance isn't as fine grained as I would like. You can have private and public members of a class, but there is no concept of protected. (Note that the previously mentioned lack of a debugger is still an issue - but there are workarounds for that).

So, I've been mulling over a plan of action for how to proceed with the platform game, and I think I've decided on making the gameplay 'feature complete' within Monkey and then mothballing the monkey code. Further development will be continued using a heavily refactored (Thank $deity for ReSharper!) version of the XNA target.

This still allows me to target multiple platforms (thanks to Monogame) and gives me the advantages of being able to have very fine-grained control over the graphics pipeline. I have some great ideas to up the presentation that require the use of shaders. Of course, this means that Josh will have to learn a new language (as he is currently familiar with Monkey) but I think that the extra productivity boost from being able to use a mature development environment and world-class debugger will outweigh any slow-down from having to learn C#.

As an aside, I noticed that GameMaker is now available on Steam. I may well be looking into that at some point. (Although who knows when that will be... I still have Unity installed on my computer from a couple of months ago, and I think I've only fired it up for a quick look once in that time period. I guess I'm just not that excited by 3D for the sake of it.)

Hmm. So what else have I been up to? Well, I've actually managed to find some time to play a few games. My current addiction is Subset Games' FTL. It didn't grab me at first, but I persisted for a few plays and quickly became hooked. And this actually brings up a wider point. As I've grown older (I turned the big 4-uh-oh about a month ago) I find that I have less and less time (or inclination) to play games that require a substantial time investment. Instead I find myself looking for games that I can delve into for twenty to forty minutes at a time. Now, I know there are a whole slew of casual games that fit that bill, but I've never really been into casual gaming. What I tend to look for are the more 'hardcore' style of game that feel deep and involving and yet only require small amounts of time. Up until now, boardgaming has been scratching that itch fairly well, but I can't always rustle up a group of friends to play a quick boardgame. FTL, on the other hand, is almost perfect for a quick hardcore play session. Note that I said almost perfect... It's not quite the game I want to play. It's very close, but not quite... I'm hoping that they come up with a sequel that goes more in the direction I want, but if not, then I know what Hiive's next game is going to be!

Another game that's captured my attention just recently (if only to make me weep at how much my reaction time has diminished over the years) is Terry Cavanagh's Super Hexagon. It's a beautiful piece of minimalist design, and extremely addictive to boot. It could use a couple of playability tweaks with the movement of the player, but I'm also perfectly prepared to accept that I may just suck at it. The music is also absolutely fantastic. In fact, it's the only game soundtrack I've ever bought (mainly because I don't survive long enough to hear the tunes in their entirety and they surely deserve a listen). I'd even go as far to say that it's better than the VVVVVV soundtrack. (Note: It's no secret that the current platform game we're working on is inspired by the latter!)

Okay. That's enough random blathering from me. Hopefully we'll have some more exciting posts about the platform game coming up in the next few weeks and then we'll start working in earnest on our Rogue-like. Watch this space (if you're so inclined!)

More Prototyping Fun...

The platform prototype has nearly become a game in itself. When I started working for Hiive it had the basic mechanics functioning in a test level. The player can run, jump, change color, and perform an impressively athletic wall-jump.  Since I started working on it I have taken it from a cool concept to a promising game in the works.

The Prototype when I started

My primary project has been to take the raw prototype level format and expand it to  create a functioning editor screen, and I am happy to say it has been going well. It's is still far from finished, however it is getting closer and closer. Once the serializer (to save levels) has been finished the floodgates will open for new levels and the prototype will be in its final stages of creation.

Edit screen as of now

Within the editor screen, you can place and remove any block, reassign the start and finish position, place any color of horizontal or vertical robot and set waypoints for them to travel between, and remove those robots when you decide they weren't in the best position.

Current game screen

Even incomplete, the game is both fun to play and to create levels for. Once the game is further along, the finish point, which is currently a tesseract, will be a wormhole, and collectible items that unlock your colors will be required to reach the wormhole to the next level.

For example, in this level, good luck reaching the finish point without using green, either to run along the top platform or to wall jump from wall to wall. The robot's are immortal, the player currently has no way of defeating them, though there have been a few ideas tossed around for their possible demise.

Future plans include attaching the tesseract graphic to collectibles, adding a third robot that either moves in a set multidirectional path or chases the player, finishing the serializer so new levels can be added, and making the editor screen more user friendly.

Monkey Game Development: A Beginner's Guide

 Having just opened Monkey for the first time simultaneously with this book, I must say this is a very well done book. I had learned Java through school so it was not my first programming language, but as far as monkey goes it was a completely fresh start. Monkey Game Development walks you through the creation of eight different games over ten chapters, one per chapter with the first chapter as an introduction and the last as guidelines for getting games published.

 Starting from the first game, a remake of Pong in the form of "Pongo," I could tell this book would do well with me. It explained the basic methods that would recur throughout every game I made with the book, and even explained why those methods belonged in every game. For every new piece of information it made sure I knew not only how to type it in, but also why it worked the way it did and why it was either necessary, or why it saved time. On the subject of saving time, the book comes with a host of graphics, sounds, fonts, and a particularly useful library called fantomEngine. It was introduced in chapter four and used with every game created from that point onwards. fantomEngine was created specifically for this book and is a library to help speed up the creation of your games by providing useful functions such as loading images, fonts, and sounds, creating images from sprite sheets, creating transitions and timers, and much more.

 My biggest complaint about Monkey Game Development is the lack of instruction on compiling to the various destinations. In chapter one, it mentions it will guide you through the installation of the various SDKs and how to set them up for Monkey, yet it never does. For example, in chapter five you create a game called Chain Reaction and it is the first game you are able to upload to an android device. In the beginning of the chapter it says it will show you how to set up Android, yet by the end of the chapter it only tells you how to change the name of your game and the icons for it once it is already on Android. I flailed trying to upload this game to android for hours.

 My only other complaint about Monkey Game Development is the rampant typos. After going through the entire book I am truly unsure whether they were on purpose or not. Admittedly, they did help me learn the code much better then if they were not there, but it would still be a good idea to at least mention to expect those landmines in the code in the intro chapter. The typos included everything from misspellings of method headers, forgetting to type in the parenthesis after calling a method, alternate spellings of fields from the initialization to the implementation, and much more. Again, the typos helped more then they detracted, but I'm still not entirely sure they were supposed to be there, or an accident by the editor. 

 
I highly recommend this book to all people looking to learn the Monkey programming language, particularly for game creation as the name suggests. The book has several faults, but the benefits far outweigh those faults. I read through the book and did all of the games in a week, and am now making a game of my own to prove I know Monkey.

It's going well.

[Note from Andrew: Josh is my new trainee programmer minion.]

Rogue Games: Can I have a little more plot with that?

Rogue Games: Can I have a little more plot with that?

Since its advent, gaming has made a profound impact on the lives of those who’ve enjoyed it.  As the technology improved and the variety increased, gamer culture began to grow exponentially. In fact, it’s grown so much that it has been, irreversibly, intertwined with the mainstream. Proof and point: my very non-gaming parents bought a Wii two years back.

I didn’t grow up a gamer.  At least not like many of my generation did.  I didn’t own my first console until 2002 (I was in college)—and that was a N64, which I bought for Mario Kart. I added four more consoles soon after that, and then, of course, now I have my go-to's: Wii, PS3, and 3DS. My PSP no longer makes this list as it had a rather crushing accident with my foot.

Now, it’s not that I didn’t play on consoles as a kid. I have an aunt and uncle with nine kids; they have literally owned every console to come to America, and a lot of the rip-offs. However, in my house, kids were expected to go outside to play, not be in front of a TV. So after babysitting, swimming, fishing, exploring and general crazy kid stuff, I would spend hours on the computer at night.

For that reason, I got into PC games first. Granted, the ones I played were almost all educational. I remember playing the crap out of Oregon Trail, the Carmen Sandiego series, and Mavis Beacon Teaches Typing. What? This was the MSDOS age and I wasn’t even in double digits yet for my age.

Speaking of that, does anyone else remember Freddy’s Rescue Roundup? You had to go around rescuing chickens on platforms while trying not to be caught by whom I can only think are the farmers who own the chickens.

And like any good Family Guy episode, here’s a jump to something only slightly related from the set up:

The first time I played a rogue-like game was last month.

Eventually, once I was able to play the less than educational games, I gravitated to J-RPGs. Zelda: A Link to the Past (I love puns!) was actually the first in this genre I every played, and I loved it. What I enjoy about RPGs are the stories, so jumping into rogue-like games was a big shock for me.

I played two games on recommendation from Andrew, as a means of getting to know the genre: Hack, Slash, Loot and Legends of Yore. Both of which are fun games, in their own right; however, I kept craving that overarching story line. Because, while the exploring, questing, and desecrating tombs are all fun, the general lack of depth to the plot that jogs me the most.  It leaves a gap for the players, like myself, who became attached to other genres first.

And certainly, this isn't saying that rogue-like games aren't good games; it's quite the opposite. While I didn't have the connect I would with some games, Hack, Slash, Loot highly amused me. I couldn't sit there for hours playing it, but it was enough entertainment, even in just short bursts, to show that it was a good game and well constructed. I also enjoyed some of the game mechanics of Legends of Yore too.

When it comes down to it, rogue-like games probably aren’t for me, or at least pure ones. However, games are rarely fully one genre or another anymore, and I would be greatly interested in seeing a rogue game mixed in with other genres; then you can get all the fun of questing, with the added bonus of a plot to explain why we’ve decided that all those tombs just had to be vandalized.

Fresh Meat

Hey, this is ella fae, the “new face” mentioned previously, and I just wanted to drop by and give you a quick introduction.

I’m just your average girl with a B.A. in English, a dream of becoming a professional author, and a passion for all things nerdy. And in case you’re wondering the validity of that last statement, I was the president of my university’s anime club and am still the only girl to ever win a tournament at the gamer’s club bi-annual LAN party. I am also very proud of my book, manga, and comic book collection, which exceeds 3,000 (though I ran out of room for them all a long time ago). Of course this all pales in comparison to my almost complete collection of Mystery Science Theater 3000, my absolute favorite TV show.

I am currently working on a couple of novel ideas to publish, on top of writing in fandom for my own amusement.  

As for my roles in hiive, I’ll mostly be the behind-the-scene girl doing the administrative work; however, I’m also going to help out with the research and story development for various games. I’m really excited to be part of the team, and I look forward to all the fun to come. 

Ja ne!

Time. The lack thereof.

Time is in short supply here at hiive HQ.

Although I'd love to be devoting my time to prototyping our new game the real world - unfortunately - has a habit of getting in the way.

The platform game prototype is working pretty well, but it's lacking a certain... something that makes me think it would be a great game. I have some ideas to develop it further, but until I've fleshed them out a little bit more, it's going on the back-burner.

So for the meantime, we're going to focus on prototyping another couple of ideas.
The first is the brain-child of my artist, Ian. He's been pestering me for a while to do a take on a Rogue-like. However, I wasn't keen unless we could think of something worthwhile to differentiate it from all of the other Rogue-likes out there.

Well, it turns out that an idea I had for another game allowed us to circle back round and take another look at the Rogue-like idea. The other game (which I'm not ready to mention yet) is nice and unique, and may well be a great deal of fun if I can pull it off, but will require a significant investment of time and money to do justice, whereas a Rogue-like... Well it's a Rogue-like. And by definition it will be easier and cheaper to produce.

I've been working on some Dungeon generation and path-finding code this weekend and hopefully will be able to get something up and running pretty quickly to test gameplay ideas. I'd like it to be recognizable as a member of its genre, but still be able to add something unique to the mix. We shall see how it transpires.

In the meantime, here are a couple of mockup screenshots using the graphics that Ian has thrown together thus far. (He seems to be under the impression that if he throws enough graphics at me I'll feel guilty about the effort he's been putting in, and consequently break down and start working on it. He's right.)

Mock-up 1

Mock-up 2

Bear in mind that these graphics are not indicative of the final game. This is purely a prototype. It may not pan out. We shall see.

In other news, there will be a new face on this blog soon. Hiive has enlisted the services of a talented young lady who will be responsible for a lot of the administrative work involved in running Hiive. I've been doing it myself for the past seven years and it's becoming a total pain in the posterior. I've been thinking about hiring an assistant for some time, but I finally pulled the trigger this weekend. So Yay! That means more time for me to work on games and less on boring paperwork!

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.

Gentlemen of Leisure

Some days I swear I have ADD; I seem to be able to come up with the idea for a new game at the drop of a hat, inspired sometimes by the most unlikely sources. Other times, I see a new game I like and I think "Hey, wouldn't it be cool to do something like that." Now to be fair, most of these ideas are fleeting (and crap) but sometimes I come up with a gem. In fact, I come up with far too many so that it's difficult to decide which one to start working on next.

I have a document titled "Game Ideas 2012" that I use to keep track of game ideas that I have had so far this year as well as those of my artist, Ian Maclean. There are far more good ideas in that document that I can possibly work on, and I always want to start on two or three, with the current favorite depending on such factors as what mood I am in on a particular day. I only wish I had the time and resources to work on multiple projects.

This kind of analysis paralysis, as many of you will know, is extremely counterproductive. By prevaricating and procrastinating on which game to work on next, no work gets done at all.

So. In order not to just spin my wheels indefinitely I had to come up with a concrete plan. My last blog post actually provided some of the seeds for this plan, which I shall detail below.

The first part of the grand plan is to pick one of the game designs and flesh it out into a full plan. The second part of the plan is to start working on better PR. From my observations it seems that a game being good (or at least not terrible) isn't enough. I've seen good games fall by the wayside and not so good games go on to great success and all combinations thereof, examples being VVVVV, Hack Slash Loot, Cthulhu Saves the World, Magnetic Billiards, They Must Be Fed and Cave Story. I'll leave it as an exercise to the reader as to which game fits into which category.

So, without further ado, it's time to make a decision. Our next game is going to be an old school flick-screen platform adventure games along the lines of the old ZX Spectrum game Universal Hero.

Universal Hero (ZX Spectrum)

The new game (with the working title of "Shattered") is in the early planning stages right now. Obviously we don't just want to regurgitate a standard platform adventure without attempting to bring something new to the genre. We won't go into great detail as to what we will be bringing, simply because it's still in flux. In the meantime, we do have an early work-in-progress screenshot of one of the earlier screens in the game. Bear in mind that this is a work-in-progress. The final game should look much better. However, there is some benefit to documenting our progress both for the benefit of ourselves and others.

"Shattered" WIP 

Sure, it might not look like much yet, but remember it's only a very early shot. Hell, we don't even have the game engine in place yet. Right now we're mainly fleshing out the story and working on the look and feel we want for the game. It may well change radically before long. And if and when it does, you'll be able to read about it here.

So - other news? Ian, the artist, liked my last blog post ranting about us describing ourselves as Gentlemen Game Developers(TM), that he ran with it, coming up with this awesome logo.

"We're not indies, we're gentlemen game developers"

It still needs a few tweaks here and there, but it's pretty close to being done. I'm really happy with it. It will make a fine public image for this and future projects. In the meantime, I thoroughly recommend taking a look at Ian's website for other examples of his fine artwork - especially if you need a versatile and very reasonably priced artist to work on your project.

You got your Hipster in my Indie...

Probably one of the most embarrassing things that happened to me in the last year was to be called a Hipster. At that point, I wasn't even sure what a hipster was, but I was pretty annoyed when I found out. For a start, I'm well North of thirty years old, and I don't think I've ever worn an item of clothing ironically in my life. (Not to mention the fact that my glasses aren't the big chunky kind).

I'm definitely more of the 'is this item of clothing practical' rather than the 'will this look good on me' school of thought - much to the annoyance of my wife.

Anyway, this is a mere prologue to my rant, which today concerns the level of snobbery I've (personally) seen and heard about amongst "Indie" developers...

Seriously guys, you're not superstars, you're not the saviours of gaming, you are not the freakin' Messiah. So get off that high horse and stop acting like you're 'better' than everyone else.
And while you're at it, take off those stupid glasses and ironic thrift-store clothes and wear something that isn't a pathetic statement about how cool you are in rejecting the mainstream concept of cool, man...

Ha. Actually that was very therapeutic. I feel much better now.

The point is I think that the label of "Indie" is slowly being taken over by a bunch of poseurs and wannabes... and as such, I'm not comfortable with that label.

From henceforth, I shall be a "Gentleman Game Developer".


(*For the humor-impaired. This post is not entirely serious. Relax; Have a snack made from locally-sourced, shade-grown granola, washed down with an ironically warm PBR. Enjoy.)

Oh, and Zynga can still go take a long walk off a short pier. :)

Pathfinding with Sticky Fingers

One of the biggest flaws (and complaints from players) with the iOS version of Creatures & Castles was that the path-tracing tended to be a little flakey - particularly on the smaller devices, where navigating around corners would prove to be a problem as the cursor tended to get stuck behind an obstacle.

It was a valid complaint, mainly because corner navigation was something I hacked in at the last moment and did not have the time to implement a proper solution (such as A*). Luckily, if I don't know how to do something properly then I have no problem in enlisting the help of someone who can. The genius in question for this particular endeavour is Eddie Edwards, a genius of the certifiably annoying damn-why-can't-I-do-the-stuff-that-he-does-effortlessly kind who I was fortunate enough to work with many years ago when I was fresh out of university.

The decision to ask Eddie to help was purely because I knew that in a couple of hours he'd be able to casually implement what probably would have taken me days or weeks of frustration and head-scratching, and sadly I don't have the time to be able to do that. Getting his help saved me time (and by definition money). 

So - after a brief explanation of the problem and the provision of some sample data, a C++ program duly arrived in my inbox with the path-finding code implemented and a nice little sample program that demonstrated how the library worked.

The arrows indicate the direction to travel to reach the target square. 

Converting the code across to C# (because I didn't want to have to go to the effort of packaging it as a library with an Objective-C wrapper, and then having to write a C# export layer for Monotouch) took no more than two or three hours spread out over a couple of days (I do have a day job you know :) ) and the results are as shown below:

The magenta circles show the rough path to the destination point.

It's a bit rough around the edges and will require some massaging to integrate fully to produce nice paths, but the hard part is done - the determination of the optimal route from a start point to a destination point when the way is blocked by one or more walls.

Basic path optimization - removal of intermediate points revealing the most efficient path (magenta line).

The code as it stands provides a complete path between any two point routed though the center of any intervening tile. It's not particularly memory efficient, as it generates a large lookup table for each level. Currently, my integration of the library provides for this to be generated as each level is loaded. However, this may well be too slow on iOS devices (Eddie himself recommended that I should pre-generate the lookup data and store it to be loaded as required). What I'll probably end up doing is generating it on first play and then cacheing it in the temporary application cache. Data stored in there is only removed when the system runs low on space.

Even though the full path between two target points is generated, it only uses the eight cardinal directions, leading to some sub-optimal paths in wide open spaces. This isn't necessarily a problem. The code already does the hard part of finding a route; in order to avoid some of the pitfalls of the cell-based approach to navigation I can simply post-process the generated path to remove redundant points (as in the image below). That is, I can remove any point along the path that can be connected via a straight line with any other point, provided there is no intervening obstacle. With this, and a couple of other minor tweaks (including increasing the granularity of the route finder so it doesn't aim smack-dab for the center of each cell, but instead tries to find the shortest distance to the next cell) the generated paths should be a lot more realistic and - crucially - our long national nightmare of tricky controls should be over and done with.

A more complicated route-finding example.

If I'm feeling particularly clever I may even implement a little path smoothing based on the Catmull-Rom formula, but that's a topic for another day. 

Ideas, iPads and Thieving Bastards

Ask any game designer and/or developer and they will tell you that ideas are cheap and plentiful. Pretty much anyone can have an idea for a game or application and most people have more than one that they are only too happy to tell you about ("I'll come up with the ideas and you do the coding. It'll make a fortune and we'll split the profit 50/50").

Well, no. Ideas are easy and are only 1% of the effort involved in making a game. In fact, until I worked closely with my artist, Ian Maclean, who hails from the Frozen North, I had assumed that programming takes up the bulk of a game. Not so; depending on the game type, the graphics can involve as much - if not more - effort than the game engine itself!

Anyway; enough of that whining from me. My initial plan with this blog post was to talk about some of the new game designs I have planned for hiive. Being essentially a one-man outfit with a full-time commitment to non-game work, I only have limited time to work on my games. This, of course, means that I generate far more ideas than I can possibly work on. And my artist is no slouch in that area either.

Now, some of these game ideas are ruled out immediately (for now!) due to complexity and lack of development funds. In other cases (and this has just happened) I'll have a nice idea fleshed out only to see a very similar game appear in the app store a couple of weeks later.

But there's a more specific reason I won't be going into any details of upcoming games, and that is Zynga.  Zynga's entire business model appears to be to watch for a popular game in the app store and then brazenly clone it. And to be fair, it's a very successful business model. However, I hope the people responsible meet their karmic fate sooner rather than later. It's disgusting; it's cynical; and it makes me want to get all stabby with the people concerned. I used to have a lot of respect for Brian Reynolds (Zynga's chief "game designer") who designed the superlative Alpha Centauri and Alien Crossfire for Firaxis. But no longer. And I'm sure he'll be crying himself to sleep on his bed of shredded $100 bills tonight over that.

Still, in itself, that may not be much of a problem for much longer. Indie games, by definition, are generally fairly low budget. Low budget games tend to be far more suitable for feature-constrained platforms such as the iPhone and iPad. Low budget can also mean a greater tendency to take risks, leading to some brilliant gameplay innovations (at least, until Zynga steal them).

With the new iPad (it's the iPad 3, dammit), the graphical and processing power has greatly increased. This is not good for indie developers. More power correlates to more cost, and that leads to two things. The first is that some indie developers will no longer be able to afford to compete (at least on the iPad platform). The second is that with increased budget comes more risk averseness. Simply put, if you are spending more to develop your game, you're not likely to want to take many risks with the gameplay. Witness the glut of first-person shooters on the PC for prima facia evidence of this. (I'm looking at you, XCOM and Syndicate).

I'm hoping this will not necessarily affect me too much. I deliberately design simple games that would have been at home on the Amiga or Atari ST, and try to focus more on gameplay than graphical effects. I don't always get this right, and in fact with Creatures & Castles I almost certainly didn't. However, the principle still applies. Gameplay is King.

In this spirit, I've been slowly working on some major upgrades to Creatures & Castles. There is a new gameplay mode (Time Attack) that relies more on twitch reflexes than careful pre-planning of a path. Along with that is a bunch of additional graphical polish (that probably should have been in there from the start) as well as a new control method that should fix some of the flaws in the previous implementation. On top of this, I'm planning to put the Egyptian levels into the game as an in-app purchase.

Now, due to the way Apple's app store works this will go largely unnoticed as an upgrade for an existing app, so I intend to take advantage of the coverage provided for new apps. Creatures & Castles will be rebranded as Creatures & Castles DX and released for free. If I can think of any logical (and optional) in-app purchases that will improve the game without affecting those who choose not to purchase them, I will probably include those too.

Once Creatures & Castles DX is out of the way, the next three projects (not in any particular order) are the sequel and as yet unannounced games (thanks Zynga) involving cheese, cats and chewing gum (each in their own game), as well as some others that, at this stage, are little more than a couple of jotted notes in a Google Document.

I hope to be able to blog about these new projects soon, at least as soon as I've finished the Creatures & Castles DX updates and got some way into them (and figured out how to get the anti-Zynga plugin to work!)