Technical Dev Blog #7: The Top 5 Tools at Flat Earth Games
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…
5) Google Docs
Yeah, I know. It’s an easy one and will surprise nobody, but every single character of our internal documentation – from the original design document to the technical design specifications to the milestone lists for our artists to the programmer’s documentation to the crafting/resource bible Leigh currently maintains… it’s all on google docs, and we wouldn’t have it any other way.
The combination of a simple interface, elegant default font styles and – most importantly – the chat/comment features has made the process much easier than ever.
Once or twice we’ve deviated and had a .doc or .txt file for some reason, and each time it’s caused us a headache. Now? Everything of substance is in a virtual folder on Google Docs (or Drive, or whatever the smeg they’re callit now…)
It almost goes without saying that spritesheets are a requirement for sanely dealing with large numbers of animations these days, and TexturePacker is the best thing we’ve found for that task.
When a new frame or animation sequence comes in from one of our artists, just opening up the texturepacker file automatically re-packs the textures, keeps the old settings, and with a few clicks spits out all three versions of the art asset we need – for phones, retina phones / tablets or bleeding-edge high-DPI tablets.
When testing a game built for a touch interface, one of the most useful and underrated things when doing the initial prototyping or testing of new interfaces or game concepts is tactile feedback.
The problem is, it’s a touch device – there IS no tactile feedback. Just visual… and sound.
When we added the ability for the player to chop down trees, we had an axe-swinging animation and the tree sure as hell vanished, but we knew it’d be months before we had the particle system in place to add the satisfying visual representaiton of the tree exploding in a blast of virtual woodchips.
So to Freesound (the creative commons sound library) we went, and within minutes had found a nice, meaty wood-splosion sound effect, had cropped and normalised it in Audacity (the free and relatively powerful open-source audio editing tool).
It may not seem like much, but the 2 minutes it took to have a temporary sound effect in there, long before our audio engineer began work on the game’s soundscape, meant that we got a good idea of how people would enjoy or dislike the experience of deforestation in our game.
None of the sounds we have in game are final, but with Freesound, many are good enough that most people probably would’t realise it!
It’s worth noting, too, that I have a background which includes film post-production, and I am in this case choosing Audacity despite being quite familiar and comfortable with other, more powerful audio editing tools. In many cases, the most “powerful” tool is not always the best for a job – and this is a perfect example of that proving to be the case. Something tiny and fast like Audacity was the better choice for us.
2) Apple Automator
Not all our sprites are set in spritesheets, believe it or not. For a variety of technical reasons, quite a number of our game’s sprites sit loose, and we *still* have to take the higher res art from the artists and recompress a few versions for each size of device.
Before beginning this project, I hadn’t used Automator before. Want something automated? I’d break out Python. Because it’s what I knew. But there are limits. Resizing images is relatively easy in python… but not tht easy.
At least, not compared to Automator. Drag in our images, drag in a ‘scale’ event to the workflow and the program automatically asks if you’d like to add a ‘copy files’ event first, so you don’t overwrite the old ones.
After that? Rename the files with the appropriate suffixes. Save our the workflow, and just open it up and re-run it every time you want to re-create the art.
Total elapsed time: 25 seconds to create the workflow, one click and 2-3 seconds to execute.
And did I mention Automator is a built-in feature of OS X?
Automator has made a huge difference to our workflow, being used in numerous places when managing files with our projects – and I suspect we’ll only use it more as we progress further towards release.
As I’ve pointed out several times above, speed and efficiency are the most important thing when rapidly adding new features in a game and testing how well they work.
Part of the reason for this is that we want to always be a step ahead of our artists. Why? Because they’re producing polished art, have a finite amount of time to spent on the project, and we don’t want them wasting their time.
Now, ProCreate is a particularly awesome iPad painting application. It’s one people have used to draw some truly mind-blowingly gorgeous pieces.
But us? We use it to draw some of the worst programmer art you’ve ever seen – and draw it fast. Multiple layers, ease of switching between brushes and colours, and we can turn out a few sample icons, UI Screens or inventory items in as many minutes.
In our case, this is hugely important, as much of our time now is spent balancing our crafting system, and the very last thing we’d want is our artists drawing, say, a gorgeous image of a Loom or Traction Engine only to discover that we no longer want to include Looms or 19th century steam motors in our game.
So for us? ProCreate is the ultimate prototyping and drawing tool, responsible for aproximately 95% of the “art” you’d see in our game’s inventory system if you had a copy of our game in front of you right now.
Oh, and did we mention it’s made by Aussies? No? Well, it’s made by Aussies.