At the 2013 Game Developers Awards hosted by the GDAA, Puzzle Retreat was awarded with the Accessibility Award. Not only is it an awesome and prestigious award that we like showing off in our office, but it marks a very important milestone when it comes to game development. Film Victoria and Screen Australia now consider accessibility when it comes to providing funding and are now rewarding companies that excel in developing games that are accessible to a wide audience.’
We think this is pretty swell.
Accessibility in gaming has always been a topic of contention. How does one make a game that caters towards people with motor, cognitive, hearing, speech or vision impairments? Mainstream games usually shy away from this demographic in favour of the masses.
In terms of our games, we aim to make them accessible to those living with impairments. We believe everyone should experience the joy of gaming!
Puzzle Retreat was designed from the ground up with that philosophy in mind.
Sometimes games (particularly puzzle games) rely too heavily on language, small icons or graphics that are make it difficult for players with certain types of vision impairment or difficulties with language to be able to understand and follow. We’ve attempted to alleviate the problem by using large and bold icons that can easily be differentiated. Furthermore we tried to make the game playable without understanding any written text.
There is an definitive association between time limits and penalties with puzzle games. I’m sure you’ve all felt the frustration of nearly completing a level, only to have the timer run out on you. We decided to take a different route when it comes to unforgiving scenarios.
We eliminated them entirely.
Puzzle Retreat allows players to take as much time on an individual puzzle as they’d like, reset it as many times as they want and even skip the puzzle entirely. Puzzle Retreat was designed to be a relaxing puzzle game, so it only felt right to dispose of time limits and penalties.
We’ve also tweaked the detection radius of the blocks so that its extremely forgiving when a player misses a block by a small margin. This feature, plus the removal of the timer allows players who don’t have a range of fine motor skills to be able to enjoy Puzzle Retreat.
We at The Voxel Agents are extremely excited when it comes to the future of gaming in Australia. With so many awesome studios producing games of such high quality and Film Victoria and Screen Australia providing consideration for funding to those who place emphasis on accessibility, we can’t wait to see what gets released in the future.
This is Agent Aiden, signing out.
That’s right. We’re excited to announce that we have moved into a new office! It is part of the a new game developer shared office called the Melbourne Arcade (@TheArcadeMelb) in Southbank. Thank you very much to GDAA for making this collaborative environment a reality. It’s proving to be awesome already!
Here are some photos of our new pad!
Walk up the stairs and turn right to find the ‘Voxel Agents’ plaque on our fabulous door. Through said door you might see a few agents at work.
Working hard or hardly working? I’ll leave that up to you to decide.
Across the room you will find a board full of Voxel Agent secrets and shelves full of miscellaneous gadgets. If you look really closely, you might see a protoss zealot hiding behind a firebat. Weird, huh?
Next to the board of secrets is the lounge area. Also known as my desk.
If you look right outside of our beautiful windows you can see the Eureka tower. Such a great location! Sometimes we feel a bit sorry for the passing by passengers, because City Rd happens to be on the route to the docks :C
Down the corridor are the offices of Surprise Attack, Many Monkeys Development, Tin Man Games and many more to come. We’re ecstatic to be sharing a space with so many other awesome studios – plenty of creativity in air, and when we walk past a board room full of people playing a multiplayer game together for “work” we remember how great game development is ;P
It’s nice being in Southbank. It’s a gorgeous area, and Simon has told me stories of how it is a historical site for The Voxel Agents. The first press photo of the original co-founders, Simon, Tom and Matt (left-to-right), was taken on the bank of the Yarra River in 2009, complete with amazing hair cuts!
Together they started the studio in an small office on the top floor of the HWT Tower (pictured) which is literally across the road from our new place. However, the story goes that all they could afford was the converted fire escape, with no windows next to the mens toilets! However, once the first artist arrived to join the team they couldn’t possibly fit a fourth in a one person office (!) and moved to Richmond.
Accordingly, the original concept of Train Conductor was dreamed up on the side of the Yarra River while looking across to Flinders St Station. And hence the station features in the Melbourne level of Train Conductor, from a view not too dissimilar from the foyer of the top floor of the HWT Tower!
The arcade is The Voxel Agents fifth office in five years, and from the sounds of it, the best yet! We’re really happy with the location, the office space and we love being so close with other awesome Melbourne game devs! Exciting times ahead 😀
PAX was such a great event and I loved meeting our players, especially those of you who have been supporting us for so long! You fill me with pride and excitement that we are making something worth making. Events like these get me so inspired, and they remind me why I make the games I do.
I got the chance to be part of the panel ‘Getting out of the Garage’ with a fellow devs from our oz industry. We spoke about what inspired us to get started, and what mental illness we had to let us do so. During the talk I mentioned that our inception was partially inspired by a manifesto for making iPhone games. We weren’t always the fearsome, bearded developers you know us all to be and at the time of creating the studio, it wasn’t obvious that starting a mobile games studio making original IP was such a good idea. Certainly at the time there were zero prominent examples of it working in Australia!
Matt, Tom and I (and our other friends too) had always talked about starting a studio . It wasn’t until our team won the 48 hour game making competition twice in a row, and when Pandemic closed down and I had quit Halfbrick that it just all fit together. We knew it was time to start a studio. The manifesto isn’t the reason we started, it just formed a part of the conversation. But it’s interesting to look at it in retrospect, and see that where we were coming from.
The “Manifesto for iPhone Game Development” was actually a tongue-in-cheek title to a thread I posted into a private forum my uni friends and I frequented. The “manifesto” bit was the joke. At the time the title seemed stupid. iPhone’s weren’t “gaming” devices. But I can’t take credit for thinking otherwise. I’m an unashamed Apple fanboy for almost a decade now. I was reading Roughly Drafted regularly and Daniel Eran Dilger’s ideas convinced me that there was huge economic potential in the App Store, and that the iPhone’s success seemed highly certain. Daniel Cook’s game design blog was my significant designer inspiration – especially the articles about innovation and creating new genres. The iPhone seemed to be the perfect mix of the circumstances Cook talked about for great innovation to occur.
Without further ado, here is the Manifesto as it was written back in November 2008.
The Manifesto for iPhone Game Development in 2008
There is no first party developer to compete with. Apple has no interest in making games. Yeah they have a Poker app, but that feels more like proof that games can exist as apps, rather than any significant attempt to become a game developer.
Big companies aren’t that interested yet. All the massive developers and publishers are either ignoring the market entirely, or giving it extremely little focus. The attitude is generally that the iPhone is not a serious gaming device.
Game developers are generally avoiding Apple products, regardless of opportunity.
Quality standards are easy to beat.
The platform lacks a defining title, and the opportunity is there for an innovative title to fill that role. Gameboy = Tetris. Famicon = Mario Brothers and Zelda. Playstation = Wipeout (to me at least). iPhone = Trism? Really? Good idea, but surely we will progress from here.
The iPhone is at a very early stage and innovation on the platform has barely begun – it is an exciting time to be designing iPhone games! Think of all the possibilities with a multi-touch screen, an accelerometer, an always connected internet device, a device you ALWAYS have with you, GPS, bluetooth! Each offers huge potential for new experiences!
Consumers expectation are at a comfortable level for indie studios; $1 – $10
Units sales are already considerable and sales growth is huge. Consider that the iPod sells hundreds of millions a year… well where are those iPod users likely upgrade to?
The approval process is relatively easy for indie developers to satisfy. Certainly better than current handhelds, and forget consoles!
When we started the company, we focused in on the multi-touch screen as our key differentiator. Ultimately though I think the always-on internet connection and “always with you” device have been the single most important aspects for innovation for game design, and even the games business. So much innovation has occurred by exploring these aspects.
In 2013 I’d it’s not so clear cut that the iPhone is the best platform for an indie studio to get started with… But that is a whole other discussion!
Puzzle Retreat as we know it today is a far cry from where it began in May 2011. It started as a third-person game about felling trees, and it finished as a relaxing minimal board game about sliding ice blocks. In between, it ventured into a massive variety of themes and styles, including one where you were responsible for unfurling dragons by the pool so they could sunbake. It’s had explosions, bad guys, tractors, floating islands and even storylines. The game you play today was only possible with eighteen months of refinement, simplification and a whole lot of love from a creative team striving to make the ultimate logical puzzler for mobile. This is Puzzle Retreat’s game dev story.
Yangtian Li, our in-house artist at the time, pitched to the team an elaborate design for a lumberjack-come-carpenter game. You fell trees in the forest, bring them home and make furniture. You can then unlock, sell and buy different design schematics, paints, flourishing details, and then trade what you make with other players online.
Add a Splash of Puzzle
Henrik Pettersson was immediately inspired by the puzzle potential of felling trees in a forest. His first design was a puzzle game where the trees fall into each other and knock each successive tree down dominoes style. The second design, and eventual winner, focused on your player character who stands behind each tree to push it over. You must have enough space to stand behind the tree to push and there must be space for the tree to fall onto. This puzzle design requires you to find the right order to knock all the trees down whilst keeping the appropriate spaces free, and not locking yourself in.
We really liked the potential depth of puzzles this mechanic presented, and the simplicity of the interaction. Playtesters were scratching their heads and smiling, and we could feel the potential of this game really standing out – it’s a brain scratcher that can fit into a few minutes a day on a mobile.
Save the Ozone
Over the past year our studio has continued development on our
TOP SECRET grid-based puzzle game.
One of the major and on-going challenges that our team has faced during development was the creation of high-quality handcrafted puzzles.
Initially, we experimented with new puzzle variations with cardboard and a set of poker chips. It empowered designers to prototype rules earlier with no upfront code investment (while code was spent on building the actual game). We also couldn’t deny that it came with super cheap “save features” with the use of a handheld camera or pen and paper. However, there were downsides to creating puzzles with cardboard and chips. It took a great amount of time to test puzzles with oneself, within the studio and with playtesters on the streets of Melbourne City.
Designers had to make sure that each move made on cardboard was legal and because a computer wasn’t dictating how the moves were made, it was prone to human error and caused creation of unsolvable puzzles and puzzles with unintended solutions. Playtesting within the studio was also a lengthy process, it involved designers restarting the board manually by hand after each play. Since a computer wasn’t dictating the original layout of pieces, this process was also prone to human error and sometimes caused awkward moments when it was realised that a puzzle being tested was unsolvable. Getting our designs in game on a portable device to take to the Melbourne City streets for playtesting wasn’t easy either. We had to use one of our Legacy Flash Level Editors, which we were no longer supporting, to paint out our cardboard prototyped level and then export it, which took about 5 steps before being able to play it in game.
Our first working Unity Level Editor, had paint, erase, load and save features (similar to our Legacy Flash Level Editor). It also saved puzzles in XML (a format that our Legacy Flash Level Editor supported). The Unity Level Editor had a first working solver, which made Unity crash a lot and our designers refused to use the Level Editor until it was fixed. We did see potential in it and persisted to shove in and rip out new features, one of the most significant features was the Solver.
Like a Phoenix, the Solver died temporarily (ie. removed), but soon after it was reborn (ie. reimplemented), but instead of turning into the same Phoenix it once was, it was reborn into this insanely powerful tool that changed the way designers now go about creating puzzles in our studio to date. The Solver had the ability to tell us how many solutions existed to solve the puzzle and if there were any solutions that were unintended, which we call illegal. A puzzle that was found to be illegal would never make it into the game. Designers were able to create super difficult puzzles that would have taken a day each to make and now they were being made in less than a hour. If a designer didn’t know how to solve the puzzle that they created themselves, they could request for the solution to be played out in Unity’s play-mode by the Solver.
The Solver was then made to play the game for us on device, it was an amusing sight to sit back admiring it’s beauty. It looked as if our studio was haunted by really clever poltergeists that have possessed a bunch of our iPads and was playing and solving each puzzle within a matter of seconds without making any incorrect moves.
After a couple weeks of non-stop puzzle creation our designers got really accustomed to the Unity Level Editor and following this we had a discussion about our puzzle creation process and where to take it next. From this meeting, we decided to optimise the process further by adding a list of solutions to the puzzle being edited within the Level Editor itself without designers having to go into Unity’s play-mode. It allowed designers to tweak their puzzles and to see the effect of their changes on the final solutions far more rapidly. Previously designers had to wait a whole minute each time they needed to test out a change that would have affected the solutions to a puzzle. Also the newly added visual representation of a solution communicates itself more quickly and clearly as to where each piece in the puzzle fits on the grid to the designer in comparison with how it was previously in play-mode.
If you found this blog post informative, please visit our Puzzle Retreat Facebook Page to Like or Comment.
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.
Here is a video showing the whole 14 hours that we took to make the game:
Read more about the development here: Live blogging from the 14 Hour Game Making Challenge!
Hey there, we’re making a game at ACMI at Federation Square. We’re going to take an earlier prototype we made in 2011 called Time Travel Treasure Hunt, and make it into a fully fledged app fit for the App Store in just 14 hours! (Meanwhile we’ve spent a year working on our upcoming title… shh). So this is going to be EXTREME GAME DEVELOPMENT. 1 year? who needs that? 48 hours? Who needs that? 14 hours? Just perfect ;P
Come say hi at ACMI and pitch in your ideas. We just had a communal brainstorming with some luverly audience members, and we’re setting up two machines for you to make art for the game and make sound effects for the game. We’re here all weekend and I’ll be live blogging as often as possible. Supposedly I’m meant to be “spruiking” the audience, but I think ACMI forgets I’m a computer nerd LOL so we’ll see how that goes.
Ok so we’ve got the stations setup, people are recording explosion sounds. We’ve got people suggesting names for the game and we’ve got a drawing station with people filling in the lines for chickens, cows and houses!
I’ve uploaded our first build of the game: Play it here. The basic mechanics are up and running and from the first brainstorming session we are working our way through the list of todos.
The second build includes the first audience made art ; the trees and cows (?).
But Tian doesn’t like having people watch over her shoulder. Especially when she has to make art that fits the same style as what the audience can draw… haha oh Tian, it’s ok we know you’re AWESOME.
Day 1 – Hour 5 – 2:01pm
People recording chicken sounds has got to be the best part of this whole shenanigan! It always gets a laff. BEGGGEEERRRRRRKKKK
Day 1 – Hour 6 – 3:31pm
Just had a quick team meeting. We’re dividing up the workload and putting champions in charge of certain areas. Matt, Tian and Henrik are building the first major scene and getting the flow happening in the core gameplay. Sam is getting sounds into the game and the audience user made content flow flowing. Tom is on the star collection crusade and I’m tackling the introduction to the game.
Day 2 – Hour 14 – 4:31pm
We’ve had no internet all day! Sorry for the lack of updating…
But on the plus side we’ve been better at ignoring people today and desperately rushing to have the game ready for shipping. 26 minutes to go…
The final game!
Ever since I dropped a ping-pong ball into a satellite dish as a child I’ve always been somewhat fascinated by the parabolic dish. It doesn’t matter which part of the dish the ball hits, it will always bounce back up to hit the focus point. Allow me to steal an image from wikipedia to explain my point.
As you can see in the above image, a ball dropped from any point above the dish (Q1, etc) will always bounce in such a way that it hits the focus point. This is the same way satellite dishes receive incoming data (and why you need to make sure you point the dish in the right direction!).
I was trying to work out if I could use this concept to make a game. Being a satellite dish is no fun. Nor is being the focus point (you just stay in one spot right?). What if it was up to you to catch the data on the correct angle to make it hit the focus point? Now we’re getting somewhere! …and so ‘Ping’ was born.
In the first version, there was a veritable wall of data raining down from the sky. You were the little panel you can see on the right-hand side of the image, and whatever hit you bounced off. It was made extra difficult by the fact that the panel was straight (i.e. not a parabola). So data wouldn’t bounce back to the right place unless you caught the data right in the center of the panel.
When I passed this build around the office, the other Voxels didn’t quite share my joy for the game. This is understandable, given that even the best player in the world could never catch more than 20% of the falling data – there was just so much of it! My solution was to add power-ups to the game. (Because power-ups solve everything right?) And that resulted in Version 2. It was definitely better, but it still had a ridiculous rain of data that you had to catch, and it lacked a strong reason to return to the game.
I sat down with Agent Simon to discuss the problems the game had, and these were the major things we outlined.
- The game doesn’t explain what to do or how to play.
- There is still too much to catch – it’s distracting
- Why will a player return to the game?
- The game is kind-of ugly! (I’m a programmer – what did you expect?)
- What actually IS the player? Some kind of rectangle?
Making the game self-explanatory was all about encouraging the player to put their finger on the screen and start moving it about. So we added a big GRAB area on the screen. Reducing the amount of data to catch was easy – just remove the fluff data (And add in some scary RED packets that hurt the player and need to be avoided)
Getting the player to return to the game was a bigger problem. The solution was to create an upgrade system where you can earn bigger satellite dishes, faster movement, etc. The idea is that you can’t get ALL the upgrades at the same time. So if you want to get a high-score, you need to find out which combination of upgrades works best for you. This means you have to play through the complete progression several times before you can be truly high-score competitive.
Solving the art was a much easier problem for me. I just got Simon to do it all! Thanks Simon 😉
Play ALL the versions here!
- Version 3 (Current Live Version) – http://www.thevoxelagents.com/voxelites/ping/
- Version 2 (Added powerups) – http://www.thevoxelagents.com/prototype/Ping/v2/Ping.html
- Version 1 (Lots of data!) – http://www.thevoxelagents.com/prototype/Ping/v1/Ping.html
- Version 0 (First playable) – http://www.thevoxelagents.com/prototype/Ping/v0/
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.