CAT | making games

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.

, , , , , , , , Hide

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!

, , , Hide

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.

The Pitch

Yangtian Li pitches an idea for a game

Lumberjacks cut wood.

Carpenters make things.

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.

The first concept, and it starts with a forest of trees!

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

Icons avoid the problem of tall trees


No tags Hide

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.

Agent Matt showing the rest of the team how one of the variations could work

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.

Pen and paper prototypes in notebook form
was another alternative to cardboard and chipery!

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 Legacy Flash Level Editor,
it was pweeeeetty and initially helped us get the levels 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.

 Our first working Unity Level Editor, we previously supported in-editor revisions!

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.

A reenactment of the really clever poltergeists hard at work!  

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.

Our Unity Level Editor, functionality over form.

If you found this blog post informative, please visit our Puzzle Retreat Facebook Page to Like or Comment.


Settling In!

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.



It’s finally official. Time Trackers is now available on the App Store, and on our Voxelites page!

Here is a video showing the whole 14 hours that we took to make the game:

Play Time Trackers in your browser

Read more about the development here: Live blogging from the 14 Hour Game Making Challenge!

No tags Hide

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!

first build of the game

second build of the game – some art and programmer “animations” ;P

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


and this one!

Here’s one of my favourite audience made art works!

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!

final build of the game!





No tags Hide

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.

In a parabolic antenna, incoming parallel radio waves (Q1 – Q3) are reflected to a point at the dish’s focus (F), where they are received by a small feed antenna.

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.

Screenshot of the first playable build.

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.

Rough draft UI design.
Upgrade menu up the top.
Big Grab button down the bottom.

I sat down with Agent Simon to discuss the problems the game had, and these were the major things we outlined.

  1. The game doesn’t explain what to do or how to play.
  2. There is still too much to catch – it’s distracting
  3. Why will a player return to the game?
  4. The game is kind-of ugly! (I’m a programmer – what did you expect?)
  5. 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)

Screenshot of the final game!

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!


No tags Hide

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).

Acceptance Tests

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.

No tags Hide

Where can I play An Archer’s Dream? Play the latest version!

Previous Journal Entries: #01 #02

After taking a 3-week break from working on the game, I returned back to it on May 18th, 2012. The break allowed the game to sit in the back of my mind for a while and gave me more time outside of work to ponder over what the game was lacking and new ways to overcome these issues.

The relationship between the controlled node and other nodes wasn’t obvious to players when I handed the game over to friends to playtest. I had to explain how to interact with these game elements. I felt implementing a less abstract theme could give the player more direction without the need for an experienced player to explain what to do.

I decided on a new name for the game and to dress it with an archery theme. The new theme was inspired by Ikiki’s game (See Figure 1), Tobioriya (とびおり屋), which I played a few years ago. You can download and play it, search for “date 08/01/21”, and the filename, “”.

Figure 1. A gameplay video of two rounds of Tobioriya (とびおり屋)

I spent the day improving input, adding enemy AI, and replacing placeholder art and target animations (See Figure 3). The target animations were inspired by Agent Henrik’s awesome art experiments.

Enter The Balrog
After in the archery graphics were added, I decided to add a new game element called the Balrog, which ran continually towards the player. This nasty creature ended the game prematurely if it got too close to a stationary archer. The purpose of the Balrog was to add more challenge by preventing the player from camping on a node’s position for too long. The Balrog gave a new dynamic to game space; the value of each node varied based on how far away the Balrog was from it.

Figure 2. An Archer’s Dream (24 hours in)

Inspiration to implement the Balrog came from two games, the Yeti from SkiFree (See Figure 3), which kept the duration of the game very short.

Figure 3. A gameplay video of SkiFree

The other game was the Balrog from Small World: Underground, which made players carefully consider its position when taking their turn. A few friends introduced me to Small World after watching an episode of Table Top (See Figure 4).

Figure 4. The 30 minute episode of Table Top that made a mate go out and purchase Small World: Underground.


No tags Hide

« Previous Entries

Next Page »