Author Archives: rohan
This is a developer blog by Rohan originally posted on Gamasutra, titled “METROCIDE, or, How I Rolled My Own Cyberpunk Dystopia“.
In early April, a collection of us at Flat Earth Games, fresh off a family-friendly crafting/city-building game, decided to kill a lot of people. Virtually, of course. I suppose partly it was a reflex reaction from a year or more of making a game where it was literally impossible to die. But it was also prompted by the question of “what kind of Cyberpunk game would we want to play?”
See, it was a game jam. A ten day one – the 2014 Cyberpunk game jam. And to us, used to 48-72 hour jams, 10 days felt like a life-time. So why not really go to town? We could surely do an action game in that time. What if we did a full-on cyberpunk action game where you played as a contract killer? We were thinking a real-time, action version of the kind of game we imagined we were playing with the 1994 Genesis “Shadowrun” game.
Of course, that’s insane – but slightly less so if you cut down your scope a great deal. So it’d be totally top-down, pixel-art, and permadeath. The art could be turned out by all of us, I could build the city out of tiles so a map editor would be easy to create, and by focusing on a death-at-every-turn permadeath style, we’d limit the need for save formats AND give a nice, bleak feel to the gameplay.
“Kill the bugs!”, or, “How to do QA without a QA team.”
I am, of course, lying. It’s not like my brother and I were the only people who ever played TownCraft before it was out. We had some incredibly diligent testers along the way, including one who gave up his time for a pittance, for a days at a stretch if we needed him.
But it’s still not a QA department. When you’re an indie developer, it may not be too difficult to find a few friends & family members to play your game – especially once you hit that magical point where it starts being fun – but that’s not what QA is, really.
Seriously, good QA means repeating the same thing over and over to find obscure bugs. It means not just playing the game while munching popcorn, but getting people who are not only good at testing every little facet of your user interface and game, but also good at writing technical descriptions of the problem – and how to re-create it. They have to stress testing your AI and scenarios for all manner of discrepancies and woes. In the case of an action game with a linear path, it may mean repeatedly doing the same section until you’re so tired of it you just want to jump in front of the nearest Shambler while crying for mummy.
So, without a team of paid, professional game-breakers at your disposal, how the heck do you get your game to a playably stable state? Well, after much thought and putting together all the things I think we did right and wrong on TownCraft, here’s my list of things I would do again for our next game.
We are mad. Completely and totally mad. If I’ve got one take-away from what we’ve done over the last few years and what we’re in the process of releasing now, that’d be it.
Let me explain…
Want to play TownCraft, but don’t have an iPad? Well, we’d like to know what platforms you do want to see it on.
So, to assist us in this we’ve created a mailing list. When you sign up, you can indicate your preferred platform (and more detail, if you’d like) so we can gauge interest.
Once you’re on our mailing list, you’ll also find out when major TownCraft updates are released, or any other big news. We won’t spam you, though – promise! Only big news will be sent to you, and only on the platforms you select.
To sign up, follow the link in the menu or just click here.
So, TownCraft is out now in Australia for iPad. If you’re one of the people who’s bought it already, or you’re thinking about buying it either now or when it comes out for your platform/region, this blog post is for you.
TownCraft is a game which contains:
- 95 different types of objects you can place in the world
- 210 different resources you can have in your inventory
- 216 different recipes which can be used to create those resources
- 33 different subtly distinct types of biome which are used to create each world
What does this mean? Frankly, it means we need your feedback. After months of play-testing (years if you include early alpha versions) there’s still a slight chance we may have missed something. And while we may have been largely inspired by 1990s-style video games, unlike games of the DOS era, we are not washing our hands of it – it is a continually evolving game, and we’ll support it as long as you guys keep playing it and giving us feedback!
Do you like parts of it, but think that turnips are slightly overpriced? Or grow too fast? Finished a scenario in a specific time and want to brag about it? (Our lead tester’s current record is about 2 and a half hours for the first scenario!) Found a bug (either the crawling on your cabbage plantation kind or the digital kind)? Think we should add a certain feature? Let us know! We’ve created an email account just for you – firstname.lastname@example.org – and we’ll be checking it every day, and we don’t just value your thoughts – we rely on them!
We’ve already submitted an update to the app store with a myriad of small fixes, tweaks and even a few new features to make the tutorial a bit more elegant for first-time players, and you can expect many more after that, including new maps coming very soon.
This is your game now, not just ours. Tell us what you think!
But what about the near future?
Our next steps are game balancing based on feedback, localisation for other languages and regions, iPhone support (Yes, it’ll be a universal app – if you own it on iPad, you’ll already own it on iPhone!), a few new surprises & features – and, of course, working to fix any niggling issues or problems we (and you) have discovered over the last few days.
And the features? Well, here’s a hint: if you’ve managed to plough through the three (huge) scenarios the initial release shipped with, you’re in luck: we’re working right now on challenge scenarios to stump even veterans like our testers!
Games aren’t really ever finished these days, and TownCraft will be no exception. We want to thank you for buying our game (or having an interest in it!) and we promise to keep working on it.
So, Leigh posted his thoughts recently on the fact that our game, despite being primarily targeted at iPad, is not really an ‘iPad game’. It is in the sense that was it was built from the ground up for this platform – the interface went through three careful major iterations to make it as elegant, seamless and transparently simple as possible on a touch interface.
But it also *isn’t* in the sense that is is a full, solid premium game. These are my thoughts on that – consider it a friendly rebuttal, if you like, or at the very least an alternate perspective – why I feel he’s right… but why I feel that’s not a problem.
It wasn’t designed for in-app microtransactions, and even the budget/scale of the game is more like a mid-level indie game than a little iPad twitch-fest. This we’ve known from the start – but it wasn’t something that bothered me. Far from it – I considered it an opportunity – and a challenge. To illustrate this, I’ll tell a story.
There is an uncomfortable similarity between making a movie and making a video game.
Not really in any of the practice (unless you’re doing a heavily CG movie), but the similarity is there.
When you start a film, you’re writing the script and planning how it will be shot. You’re putting stuff in. Same at the beginning of a game. When we were penning our design document, we were dreaming up features, some only vaguely defined, but features and gameplay elements nonetheless.
As the engine begins to take form and you start to be able to, y’know… *play* the game… you start to dream up more ideas. The fortnightly (sort of) meetings or random coffee breaks would often result in a handful of ideas, one or two of which might end up in the melting pot – especially if one of those ideas is very easy to code and could, say, be knocked together in a few minutes while the shine of the idea was still there.
It’s a really great way for a game to evolve organically – not right for every type of game, but one that’s basically a sandbox with some fun toys in it? It’s really worked for us.
Well, it’s Christmas/Solstice/Festivus/etc, and I don’t mind admitting I’ve had a few convivial beverages, so it’s time to talk about the editing tools we’ve developed for Township.
Picture, if you will, a perfect game development world. One in which tools are enormous, powerful, database-driven, and quickly export everything from an advanced GUI into the game data required to procedurally generate an isometric world. Are you imagining that? Great.
Well, we don’t have one of those. In fact we’ve been so busy making the game engine that trying to make any tools to edit the dozen odd XML files that drive our game wasn’t much of an option. At least, not making a serious GUI editor.
I had originally intended to write an article describing our workflow. It seemed like a good idea at the time – maybe some people might get some use out of seeing the workflow we’ve settled on for the technical side of our development.
However, over the last few weeks, I noticed (as we had a few folks passing through the office and seeing what we’re doing) that the biggest question became some of the more abnormal tools we use.
And so, instead of dryly going through every step of the process, what follows are the 5 most useful tools for the development of our game – in terms of efficiency, importance, total hours and yeah, even ‘cool’ factor.
This isn’t just software on our laptops or desktops, either – this includes anything that could conceivably be called a ‘tool’ or ‘resource’ for our sprite-based, OpenGL-driven exploration/creation title.
And so, without further ado…
This post by Rohan originally appeared on Kotaku…
It’s T plus a fortnight-odd now, and we’ve had time to put the iPhone 5 through its paces – both as a gaming platform for our enjoyment, and as something to build our own games on. Can anything be said that wasn’t said on launch day by the myriad of developers putting in their two cents? Well, two things popped into my head…
I was always going to buy an iPhone 5. Not because I’m some frothing-at-the-mouth Apple fanboy with a turtleneck and a shrine to Steve Jobs mind you (The turtleneck IS the shrine to Steve Jobs – Leigh) – but because I’m a mobile developer, and a game nut.
Being an indie developer at a fledgling company, without the benefit of a well-staffed QA department or team, my house resembles a “Museum of Modern Mobile History”. Between old devices of mine and hand-me-downs from people answering the call for debug devices, I have almost every iOS device Apple have released, two android devices, one laughable Symbian phone and a few other obscure bits of tablet hardware.
But the iPhone 5 was something special – something I knew I was going to have to buy if I wanted us to be able to make a good show of being up to date with our current project, a mobile title designed to take advantage of the ultra-high res devices the average mobile gamer carries in his or her pocket these days. The first thing made the iPhone 5 special wasn’t so much the A6 chip (a chip so fast it can belt out 1080p 3D graphics to your TV which look better than almost any Xbox 360 title I’ve seen) or the myriad of smaller features which Apple advertises – it was the screen.