Wednesday, March 21, 2012

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. :)

Tuesday, March 13, 2012

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. 

Friday, March 09, 2012

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!)