After listening, scribing and finally implementing some of Matthew Wiggins’ various nuggets of wisdom, I decided to throw the net wider and talk to a few other ex-Lionheaders who have made the move to indie development. It’s perhaps worth noting that I was briefly a slum-landlord to two of these fine fellows before their successful launches into indie games, so I’m hoping that something about living in the same abode in Aldershot will be the nudge I need for certain success. I can almost taste the future millions.
First up is the other founder of Wonderland Software, Mr Mark Rose. I’ll not repeat the suggestions he made that reiterate Matthews’ views, as he had plenty to say otherwise when we met up at Guildford Starbucks.
“A start-up is not a small version of a big business, it’s a search method” – with a start-up I should be trying to find or create a niche that I can create a business in. I’m not an established company with a business plan set in stone. I’m a small, agile, proto-company that shouldn’t be wasting its time trying to fight for market share from a large company doing the same exact thing. If I fail to find a niche to exploit in the area I started looking in, I should search elsewhere or close without wasting too much time, effort and money. This rings true with the sort of game I’m trying to make initially, to some extent at least. I’ve been told of a few other games that fall into the same niche, which on the one hand makes for competition, but on the other hand shows me there’s an ecology and an interest in that niche. However if I can’t find the unique selling point, I should be moving on. This can just be doing something better than others, but I better be doing it a lot better, as otherwise I’ll be ignored as just another clone of X.
“Utilise what already exists” – I shouldn’t be reinventing the wheel, especially not when the wheels out there will do the job I need them to do. I certainly want to use other people’s libraries or code where possible and only build what’s unique to my game. However if something is reasonably simple to build and I’ll need it to do exactly what I want, then writing from scratch could well be faster in the medium term. I’m going to have to find myself a level editor that will allow me to create levels with basic objects, in 2D, with position and orientation, which can have meta-data attached. Nothing complex required and if I can’t find something suitable in short order then writing something myself that does exactly what I want makes a lot of sense.
“Keep interfaces simple” – I think I’m going to have to be brutally honest with myself when it comes to user interfaces. If my mum can’t use it from the get go, without having to be told how to do some interaction, where the first attempt she takes to do what she wants isn’t the method I’ve implemented, then I’m going to have to re-write the user interface until she can. That’s one of the things I find Apple get so right. My iPhone almost always acts in the way I expect. If there’s something I want to do, then it normally does it the way I expect the first time I try. I should always aim for that with my own GUI.
“Don’t over plan” – paying the price of being multi-platform now, just to be future proof, costs me planning and implementation time now for potential time savings later. This is rarely a good trade-off. I’ll be keeping things flexible now, but only in the most cursory ways necessary to not completely trip myself up later. This balance is going to be hard to keep.
“Keep the game design simple” – Mark was definitely of the mind that keeping the game design as simple as possible made the most sense and that however simple you have it, you can almost always take some level of complexity away to improve the game. Keeping it simple also means that later you can still add to it a layer at a time without much difficulty, but removing a feature that’s entwined with the whole game design can be very difficult (and a huge, risky unknown) once the game is in production. The game should also be something you can play straight away without having to work through tutorials. I want a game that makes sense the second you look at it. Not a mish-mash of nonsensical buttons that you gradually learn how not to fear. I have no problem with games that slowly increase in complexity as you play through levels, introducing it (and the appropriate interfaces) as you progress, but starting there will only scare the players.
“Don’t overanalyse the design, go with your gut feeling” – this is definitely a piece of advice I could use. I keep sitting and imagining the design and interactions, wasting time trying to perfect it in my head before I code it. If I implement the simplest feature first and play that, then I think I’ll have much more success as the next feature to implement will be much more obvious. So long as my gut is telling me that the first feature seems like a good one.
“Give the player some reason to shout about your game” – Get them to want to post their new high score on Facebook, either for its own sake or for a few coins of in-game currency. Whilst I generally ignore all the Facebook games that shout for attention, many others won’t and free advertising is an important way to bootstrap your game sales.
That was most of Mark’s advice, as I can best remember it and extended from my scribbled notes. I suppose I could record these conversations but I wouldn’t want to write anything I or the advice giver couldn’t later plausibly deny. Just in case, like.
Next I moved to the Drummond to meet up with Kostas Zarifis and hear of his experiences trying to get Kung Fu Superstar funded…