Category Archives: techblog
Rohan has posted a new dev blog over on objectsgame.com outlining the jump from 2D to 3D.
For those unaware, Objects in Space was originally going to be an entirely 2D game, using pixel art graphics on everything from the main bridge to space stations and NPCs. What we discovered, however, was that the level of functionality we intended for the game simply wouldn’t work on an entirely 2D plane.
We wanted to switch to 3D, but knew we didn’t have the resources to compete with high-end space trading games like Elite: Dangerous, so we agreed to keep the low-fi look of the game even as we went 3D.
The poly counts and texture resolutions were kept very low to evoke that pixel-art feel. Each monitor would become its own interactive texture, and the player could zoom in and out with a simple left-click/right-click interface.
Check out the dev blog from Rohan here!
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…
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…
So, last month I blogged about how we were building the UI for our game. One of the things we’d decided to do was keep our options open for porting to other platforms by making our UI scale to whatever sized screen we cared to throw at it.
When we first got the game building fine on the iPhone 5, this made me smile – having the UI just smile and quietly use more space for the inventory screen when given more screen real estate was pretty good.
And yet this week, I find myself blogging about how we’ve nuked that feature entirely. How I’m now no longer using a Scale9 system for our in-game UI objects. The code is still there, for now, but we’ve just stopped using it.
For a bit of context, before developing our game, I developed (and still develop, at least until we magically stumble onto this mythical ‘income’ and ‘success’ stuff I keep hearing about at the IGDA Sydney events) helpdesk and financial systems, mostly database-driven web apps.
After years learning my trade at a tech-shop, I began to work on my own, and for the past few years have built helpdesk systems internally for a mob with the money to do so. Thing is, that while I had it beaten into me savagely that documentation and in-line comments were the most important things about what we did at the tech-shop (proven every time someone failed and profanity-laced verbiage took to the air come deadline-time) years of working as the sole programmer in the wild west that is my current place of employment… I began to worry that I was getting lax.
At the end of the last tech blog, I said I was going to write next about the problems we’ve had with our choice of framework. I’ve decided to postpone that a post or two and instead discuss something which has dominated much of my brain over the past few manic weeks: user interfaces in mobile games.
So, as of the milestone we hit a couple of weeks ago, we have a character who walks about a world in which plants grow, rocks can be decimated, trees chopped down and all manner of mayhem ensues (there’s even wildlife flying overhead). You can move your little character about, and you can interact with the world.
There’s a full functional inventory system, and it can be filled up with any number of tasty little items from [redacted] to [redacted] all the way up to the popular crowd-pleaser [redacted]. (Although we can and have confirmed TURNIPS! – Leigh)
Which meant it was time to take our design document’s user interface section and… well, implement it. There’s one small problem with that: our game is aimed at mobile phones and tablets, and while they use the same kind of APIs and languages, and are even binary compatible with each other in many cases, the difference in screen size between a typical smartphone and a typical tablet is nothing to be sneezed at.
There’s an old saying that no battle plan survives first contact with the enemy. In this case, mobile phones were the enemy… sneaky little buggers.
So, after we had our technical and design documents laid out and the contracts with our friends at Epiphany signed, we had to make a few decisions: what engines, frameworks and languages were we going to use?
Initially, we’d pitched the game as an iOS-exclusive title, and so that meant we’d most likely be working with Objective-C, most likely – that being the native language of the platform – but it’s always good to think carefully about your options.
Rather than attempting to make a game as efficiently, quickly and cheaply as possible, we made goals which were slightly more long-term.
Our project is not small, and the engine required to do it is actually quite complex (…as we found out later – Leigh). An isometric engine with large, interesting worlds that you can explore and build in is nothing to sneeze at, especially compared to the kind of thing we could have ended up making – say, a level-based endless runner or platformer.
One of the decisions we made based on this was that the engine should be re-usable. In fact, we very quickly ended up figuring out a few other potential titles we could use the engine (and even re-use some of the assets) for after we’re done. This way, we could plan around our game not selling particularly well, and leverage our first title to make our future titles that much easier to do in the event that it doesn’t earn us enough money to fund our next title.