We moved into our new office in Collingwood last week and we’ve been settling into the new space. We’ve had to deal with all kinds of things such as a brilliant coffee machine, a bit too much sunlight, and everyone having to work out how exactly to get to work.
The new space is great. We have a lot more room to move and it’s closer to home for most of us (except for Sam… sorry Sam) and it’s right near Melbourne’s funky Smith St. Maybe we need to start being more funky so that we all fit in?
Levels! A whole bank of levels!
We’ve been making a lot of levels for our next game. So many in fact that just managing all of them has become quite a chore (hundreds and hundreds of designs that could make their way into the final game).
To deal with these numbers, Agent Sam has made a really nifty tool that allows us to easily sort and structure our levels, give them ratings, and easily view information about each level. This was all done using Google Spreadsheets and some nifty Google Apps Script. We’ll have to write a full feature-blog post describing how great Google Apps Script is for making simple tools as it’s proven to be a very versatile weapon we can use in our quest for making better games.
Another cool thing we’ve made by hacking Google Spreadsheets is to create nice reports about who is actually playing our games and how long they are sticking around. This info is great because it helps us make our games a lot more fun, but it can sometimes be hard to really read the graphs that Flurry make. So we made our own graphs!
Even more awesomely, we were able to use Google Sites to automatically pull these graphs from the Spreadsheet, and display everything in a somewhat nicer format.
Leveraging Google’s services has proven to be a really great way for us to rapidly create useful tools that enhance our ability to make games. More on this in a future blog post feature.
We made some really hard levels, couldn’t solve them, and so made the computer do it for us
When designing levels, it’s often very difficult for the level designer to be able to keep all the variables and permutations of the level in their mind at once. It’s possible for us to make much higher quality levels if we have an automated “solver” that can solve our levels for us, as well as providing very useful information about a level (such as the number of possible solutions). We’re also kind of lazy.
So we made a “solver”. This has actually been a work in progress for quite some time, but it only just recently became awesome.
This tool was made by extending Unity through it’s great editor features. We really strongly recommend that other Unity developers get in on this and start making wicked tools by extending Unity.
And then we made it even more awesome
The next step, of course, was to make it automatically show us the possible solutions in a way that was highly readable to a level designer. Agent Sam is doing a more detailed write up about this, but basically we can learn so much about how our levels are structured through this tool and it makes it much easier to make great content.
We quietly started a beta test
Agent Henrik began work on a beta test for our new game. It’s a closed beta at the moment and I am sorry but it is now closed.
Sorry about that.
On the bright side this means that our new game is getting close. We still don’t have a definite launch date but it will definitely will be released sometime.
We also started thinking: “What’s Next?”
The new project is in it’s final stages so we’ve started thinking about our next project. We have some new IP that we want to develop further into a new game, and so we’ll definitely start work on that.
But we also see a lot of potential to improve Train Conductor, so we’re going to explore that. It’s still early days so we don’t have totally concrete plans at the moment, but we’re thinking of making the newer “Challenge Mode” the focus of the game since that style of play seems to be much more the kind of play we were trying to create with the original Train Conductor.
Agile Development is a well known production methodology for software development. It has been used for around two decades to give structure and organisation to the iterative development process. It has many benefits, but is difficult to successfully apply, especially to a small games studio such as The Voxel Agents. The major difficulty we’ve faced while using the Scrum methodology is the ability to write effective stories.
Scrum provides many rules about what an effective story can contain, but scrum is also about personalising the process to suit your own development requirements. Over the past year, we’ve gradually improved the way we write stories so that what we are writing is appropriate for us. I’ll describe our rules for story creation here.
What is a story?
A “story” is a small chunk of development that brings benefit to the user. For example, “As a player I want helpful hints to appear in the early levels to help me understand the rules“.
This short story tells me quite a lot about what the required outcome is. It tells me who the feature benefits (“as a player“), it tells me what the benefit is (“I want helpful hints to appear in the early levels“), and it tells me why that benefit is important (“to help me understand the rules“). I know that simple debug text isn’t suitable in this situation because that only benefits me, the developer, and not the player. I know that the ability to view the “helpful hints” should occur while playing a level, and I know that the helpful hints should be relevant to the rules that the player is learning.
This story does not tell me how to make this feature. It does not say “Place some red text in the bottom left corner that says ‘Slide a block to interact with the game’ “. It simply describes the required outcome which leaves the implementation of the feature up to the developers – who are, after all, the experts at making this game (one would hope).
Now that have our story which describes a specific benefit to a specific person for a specific reason, we now need to communicate to the team what the minimum requirements of this story are. The minimum requirements are known as “acceptance tests”. They are a list of criteria that must be met for the story to be considered complete. An example of an acceptance test is “when the player is playing an early tutorial level, a legible message that explains the rules to the player must be displayed“. Another could be “the hints must be set on a level-specific basis“.
Ideal acceptance tests are more specific than the general story, but they still don’t tell me to use a specific implementation. Acceptance tests assume that I am smart enough to determine the best implementation in the given situation.
What the acceptance tests should do is constrain the possible outcomes to what is desired by whoever requested the story. For example, it is clear from these acceptance tests that it would be unacceptable to show a randomly selected message during the loading screen. These acceptance tests make it clear that the hint should be relevant to the level that the user is playing and should be displayed while the user is playing the level.
Acceptance tests are important because they describe what the done state of the story is. A story is done when, and only when, all of the acceptance tests have been met. If I do anything more than what the acceptance tests require, then I’m probably just gold-plating this feature and I should instead request a new feature rather than adding functionality that is not yet necessary.
Acceptance tests and Stories are quite standard in scrum. One of the innovations we’ve added to improve the process for ourselves is to write a “Spirit” for each story. The spirit is kind of like an acceptance test but it isn’t binding. A story’s spirit is used to add colour to the acceptance test and to suggest possible implementations that better illustrate the desired outcome.
An example spirit is: “We want to show a helpful hint at the start of each tutorial level that explicitly explains the rule being taught in that level to the player. This will assist the player to understand what they are learning and hopefully speed up the learning curve. For example, we want to show some text at the bottom of each screen that prompts the player to do an action such as ‘don’t be afraid to use undo’“.
This spirit has suggested an implementation to me, the developer. The suggested implementation is what the requester of the story had in mind when they wrote the story. I don’t have to use this implementation, but it helps me to understand the intention so that if I think of a better way of doing it, I can be sure that it still fits the original requirements.
We invented the spirit because we quickly noticed that when we wrote stories we had a misleadingly clear idea of what we wanted. We’d write terrible stories like “At the end of a level show a heap of particles to make the player feel good!”, but then after implementing that feature we realised, for example, that it made levels take too long to finish up so another way of making the player feel good was required. Writing the spirit of each story down allows us to give a quite specific example of what is desired, but still gives us sufficient flexibility to iterate on an idea further during development.
Level Of Done
In typical scrum, each story is brought to a potentially releasable state. Ideally, at the end of each sprint, a release candidate is produced that is just that little bit more feature packed than the last release candidate. This is great for typical software development (release early, release often), but doesn’t necessarily work for games development.
Quite often, we only want to test an idea out in the cheapest way possible. We don’t care if there are red blocks on the screen or if there is debug text all over the place, we just want to see how an idea plays without needing to polish off the edges to make it nice and neat for the players. For this reason, we often don’t want our increments to be release worthy. If we’re just prototyping, it would be a complete waste of resources to make it good enough for a player.
To get around this problem, we specify a Level Of Done for each story. The level of done lets us know how much effort to put into polishing up the feature.
For example, if we’re just making a rough prototype of a half-baked idea, we describe the level of done as “first working“. First working means that it doesn’t matter really matter if it crashes a lot, or if you need to hold down the shift key for some weird reason, we just want to see it up and running as fast as possible. It also means that we don’t want it taken any further than that until another story has been made. This prevents a small prototype from being gold-plated before we know if we actually want it. Therefore if a story requests a “first working” prototype and the developer delivers something beautiful that is ready for the App Store, then that developer has done the wrong thing and loses brownie points.
If we want to take an idea a bit further and see how it plays with the rest of the game, we would say it has to reach “prototype” state. The difference between prototype and first working is fairly subjective, but generally speaking a prototype should be good enough for us to put in front of other people for play testing (i.e. no crashes, no arbitrary keys or insider knowledge). A prototype is not release worthy though. Again this Level Of Done means we only want so much effort put into a story, and any additional effort is potentially a waste of resources.
On the other hand, if we really do want a feature to be good enough for users, we say that it must be “releasable“. Releasable means that we’d be happy selling this bit of functionality. It doesn’t imply that the game is ready to release since other features might not have reached a releasable state yet, but it does mean that if the whole game was of a similar level of quality, then the game is ready. Releasable is a very high standard for us, so we use it sparingly.
We were doing QA in the office, and we needed a way to record some of the particularly hard to reproduce bugs.
Solution: masking tape of course.
The result? Well we still can’t work out what was causing the bug, but now I can capture me beating Agent Simon’s high scores on video which is ultimately much more satisfying.
Last weekend, we competed in the #fab48hr game making competition in Brisbane, Australia… and what a wild weekend! We won! That was great, but more importantly I was absolutely blown away by the quality of games made by the other teams. I was particularly impressed with the level of quality and polish that was developed in “indie” / student room. There is an enormous amount of talent in Australia and I’m sure we’re going to see more from those awesome young developers.
In the #fab48hr competition, each team must concept, design, and create a game based on three keywords that are provided at the beginning of the competition. This year, those words were “suit”, “key”, and “badger”, provided by Yug, Hex, and Jinx.
We made this:
How to Play: Without giving too much away, if you have a couple of XBox controllers, plug them in for the best experience, using “A” as your action button. If you have to use a keyboard, you can use the arrow keys for player 1 and WASD for player 2, with “shift” as the action button. Also be aware the the glowing yellow floor (which totally looks like lava) will kill player 1 and the swirling blue circles (evidently poisonous gas…) will kill player 2. That’s all you really need to know… oh yeah one more thing: the badgers aren’t nice and they will eat your face.
The Badgers of Fury 161 was developed by the Alliance of Indie. This team was composed of developers from a number of Australia’s top Indie studios including yours truly Agent Tom (The Voxel Agents), Liam Hill (Defiant Development, 3 Blokes Studios), Cratesmith (Cratesmith,Defiant, Strange Loop), Matt Ditton (Queensland College of Art, Defiant), and the incredibly talented Milenko (Strange Loop,Defiant).
But really, kudos where kudos is due:
As proud as we are of the game we managed to make in 48 Hours, the real winners of the competition were the indie team Rockin Moses (read about them here: http://making-games.net/48/?p=2916) who made a really fun game called The Fifth Suit.
This game was great fun to play. For me, their game evoked “Smash Brothers Brawl”. While playing, I was less concerned about winning and more concerned about trying to make life difficult for my opponents. It was a strong social experience and quite a polished product for just 48 hours of work! You can grab a PC version of their game here [WIN] but it’s best played with XBox controllers. If you’re lucky enough to have some XBox controllers then I strongly suggest you get this version [WIN – XBox Controllers].
Last years winners, Cratewerks, which included Matt Ditton and Cratesmith, are combining forces with one of 2007 and 2008 winners, Agent Tom Killen, of the teams sif90 (2007, 2008) and The Voxel Agents (2010). They will be joined by the exceptionally talented Liam Hill, Mark Filippelli, and Milenko.
The 2010 event saw close competition between both Cratewerks and The Voxel Agents. Both teams made great games and in the final community voting round, Cratewerks won by a crucial single vote.
About The Alliance of Indie
The Alliance of Indie are Liam Hill (Defiant Development, 3 Blokes Studios), Cratesmith (Cratesmith,Defiant, Strange Loop), Matt Ditton (Queensland College of Art, Defiant), Milenko (Strange Loop,Defiant), Mark Filippelli (Strange Loop), and Agent Tom (The Voxel Agents).
We spend a lot of time being all creative and fuzzy and nice here at The Voxel Agents, but often we need to stand back and have a good hard think about what’s actually happening out there in the mobile games space.
To make sure we are all still on top of everything, I spent all of last week researching the mobile market space. I forgot everything I knew about iPhone and Android and had a good hard look at the information that is out there. Some of my findings certainly will be old news to you, and some might change what you thought you knew. So, if you’re interested in the business (pronounced “biz-niz”) side of being an indie game developer, check this stuff out:
You may think the iPad is a mobile device, but you’d be wrong.
- 43% of iPad owners use their iPad more than their desktop computer
- 28% say it’s their primary computer
- 34% use it more than their TV
- 83% use it primarily while at home. Only 11% use it on the go.
Developers are flocking back to the iOS platform
Even though iOS has more Apps, Android has more free Apps
iOS has served 15 Billion downloads compared to Androids 4.5 Billion
Android App installs per day may be reaching parity with iOS installs
500,000 Android devices are activated every single day
and most importantly of all…
So we’ve done it again. We’ve purchased 25 tonnes of CO2 offsets to negate the environmental impact of our business over the past year. Two years in business, and zero carbon impact with the bonus that there are now more trees in the world!
If you want to support Greenfleet, head on over to http://www.greenfleet.com.au/ and find out how much carbon your business or lifestyle produces and consider purchasing carbon offsets. It’s a good thing to do.
So now that 2011 has rolled around, we decided the time was right to grow our team. We’re very, very, happy and proud to announce Henrik Pettersson and Yangtian Li as the latest additions to our secret service / games development studio.
We’re loud and proud of the fact that it was the 2008 48 Hour Game Competition that inspired us to start our own games studio, and so it is with a sense of purpose and trepidation that we are preparing for the 2010 challenge. Over the next 48 hours we’re going to laugh, we’re going to cry, we certainly aren’t going to sleep very much, and we’re going to make a game.
We have a lot of respect for everyone entering the competition. It’s not a small undertaking to start with nothing but a blank canvas and the need to turn three obscure words into a workable game concept.
Indeed coming up with an initial concept is one of the hardest parts of the competition (second only to the stamina that is required) so we thought we’d share the process we employ to turn those three keywords into a set of game mechanics.
To begin with, we get away from the computer. The core game mechanics are vital. We need to get our core concept worked out. So we resist the urge to fire up Photoshop and instead welcome pen and paper as our first set of tools.
For our 2008 entry, Melonauts, we had a big piece of butcher’s paper and on this we drew three columns. At the top of each column we wrote one of the keywords. In each column we extracted any verbs (action words) related to the keyword that we could think of.
For example, in 2008 the keywords were “watermelon”, “astronaut”, and “summertime”. Beneath summertime we wrote dozens of keywords including “seasons, summer, cycle, heat, sun”. Beneath “watermelon”, there were “smashing, growing, planting, harvesting, juicy”. Astronaut had concepts of “gravity, spacesuit, planets, and travel”.
We then started combining the keywords. There is an obvious link between “planting, growing, harvesting” and “seasons, cycle”. This link immediately suggests a game mechanic based on growing a watermelon crop.
Another potential concept was to combine astronaut with planets and sun. These concepts are related in a thematic way in that a game could be about an astronaut exploring different planets with different suns that affect the way plants grow.
So we had two concepts. One was a highly mechanic based game of growing and harvesting crops in cycle with the seasons, the other involved an astronaut going on a journey and exploring how watermelons would grow on different planets.
To decide between these concepts we looked to our strengths as a team. We were able to rapidly create game mechanics and we had experience in developing mechanic’s based games, but no one in the team had experience or significant ability in creating story driven exploration games.
We also considered what we were making the game for. It was the 48 Hour Game Comp and so the judges had a bunch of games they had to play. They would only have a few minutes to play each game so whatever we created had to be instantly pick up and play, and needed to express its concept within the first two minutes to be effective.
For those reasons, we chose to play to our strengths and we developed the concept where watermelons needed to be planted and harvested in cycle with the seasons. At this point astronaut was doing little more than contribute a theme to the game, and the planting and harvesting needed a purpose, and so we took the inevitable decision to make our astronauts space marines who needed to fight and needed watermelons to do so.
And so Melonauts was born. The words “summertime”, “astronaut”, and “watermelon” became distilled into a set of game mechanics based on planting and harvesting, watermelon fuelled space combat, and a relentless cycle of seasons.
To summarise our process, it is focused on producing actions words and verbs. It is the actions that translate directly to gameplay and game mechanics. We avoid exploration or story driven gameplay because that isn’t our strength and because it’s very difficult to make a story driven game compelling within just two minutes of gameplay.
There are different approaches to take. “My Mechanical Romance” by Curious Bear won in 2009 and that was largely a story driven game where they elegantly expressed a complex concept through simple game interactions. It was a beautiful game and so we don’t mean to say that being exceptionally focused on mechanics and action words is the only or the best way to approach the keywords.
We follow our mechanics driven approach because it suits our strengths. If you have a team that is great at producing concept or narrative driven gameplay, make that type of game. If you have a brilliant artist who can produce content rapidly, make a content heavy game. Play to your strengths, and us that means producing a set of simple mechanics and refining those mechanics into a short sharp game that is instantly understood and endlessly replayable.
Massive props to the SIF90 team. Simon, myself, and Matt (the three on the back right) owe a debt of gratitude to Joe Gatling (back left), Jon McEwan (front left), and Michael Szewczyk (front right) for working with us to create Melonauts. It’s a game we can all be proud off.
Our number #1 fan, 4 year old Andrew of the U.S., has been waiting MONTHS for the chance to play Train Conductor USA.
He is a massive fan of the original Train Conductor Australia, and back in March we got an email from him wanting to know when he’d have more levels to play.
Well, after the release of Train Conductor USA today, Andrew got his chance and he was kind enough to record himself playing. Andrew, I have to say that you made my day.
Click here to listen (Warning! Incredibly cute!): Andrew Plays Train Conductor 2
We’re glad you love the game Andrew and we’ll get some more levels made for you to play soon.