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.
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, “tobioriya.zip”.
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.
Previous Journal Entries: #01
New Features and Enhancements
Monday, April 30th, 2012 was the second day I was able to get more work done on the prototype. I decided to transform the prototype into a score-based game where the player aims to score as many points in a 60 second timeframe (as suggested by Agent Simon). (See Figure 1) The player must shoot from node to node using the controlled node to score points. More nodes appear when the player reaches the last remaining node on screen.
Figure 1. A screenshot of Sling (16 hours in)
I did another pass over the input system. The player is now able to drag out from any position on the screen without having to start the drag from the controlled node.
I’ve managed to address existing vulnerabilities outlined in my previous journal entry. The iterated prototype gave the player a goal and a challenge of scoring as many points as possible. Movement issues were resolved by allowing the player to shoot to locations where nodes spawned on screen. The size of each node now represents the hit area for triggering shots.
After making further additions and enhancements, I spent some time playing the game to find further issues with it.
The list of issues is as follows:
Lack of excitement
If the score and timer are entirely ignored the game gets boring quite quickly. As a player I ask, why do I have to sling to the next node? Why can’t I just let the controlled node sit still? There’s really nothing else driving me to progress.
Lack of variation
I begin to ask if the lack of excitement is due to the lack of variation in the game. Will pinball style collision on some nodes add more variation to the game? Would new node types like bombs or nodes that blink on and off make the game more varied?
Issues with input
On a touch device the player’s hand covers the controlled node when firing it downwards. Should I replace the touch-drag-release input with tapping (or click-drag-release with clicking on desktops)? Would that take away the challenge in the game? Would it make playing the game less satisfying?
Return On Investment
I gathered together my thoughts and ideas as to which directions this game could be taken in. I did a rough estimate as to the cost and benefit of making each change to the existing prototype, which allowed me to group them based on their Return on Investment (ROI). (See Figure 2)
- Pinball style collision
- Ordered shooting with sequences based on node size or sequence of numbers
- Tap to shoot input
- Add different types of nodes
- Different shooting speeds based on masses
- New node types
Figure 2. The Cost/Value Curve (adapted from the Beyond Scrum Gamasutra Article)
As a developer, I aimed to make changes to the prototype that are within or close to the sweet spot first (ie. the greatest benefit for the least cost).
On Friday, April 27th, 2012, I started work on a new exciting prototype for a game. The vision for this game wasn’t yet clear, but I had a vague idea that I wanted the gameplay to be on a graph (see Figure 1) and to be 2D, rather than 3D, to keep the project relatively small by avoiding z-depth as much as possible.
On the 2D graph, the player would be able to move between nodes and create new connections. As each node is visited, resources are collected and the player would have to spend these resources to gain energy to connect to the next node they are about to visit. The goal that I envisioned for the player was to continually grow the graph by adding more and more nodes and edges. The challenge would develop over time as nodes die out, just like stars in our universe, and the player will eventually run out of nodes to connect to.
The vision of the game has purposely been kept abstract and general to avoid placing early restrictions on where the game could be taken next. In my mind I’m thinking it could end up a puzzle game, a strategy game or even an action arcade game, but I’m not locking in what the game will be too early. Development is much more exciting this way because you feel free and unbound to do whatever you like, it allows you to go with the flow and discover where the fun is and allows the game to evolve organically. However, it does come with the risk of becoming demotivated or lost early on in the project if the game doesn’t lend itself to new ideas or it overwhelms you with too many ideas, respectively.
At first I was using Unity, but then decided to restart the project in Flash as I felt that I needed tools that I’m much more familiar with to speed-up my designer-programmer iteration loop. (See Figure 2)
Design – Decide on what to change.
Implement – Execute the change.
Playtest – Verify the effect of the change by playing the game or observing someone else play.
The above loop occurs frequently as new changes are made to the game. The time saved by implementing new changes in Flash can be invested in focusing more on designing and playtesting the game.
The very first thing I did in Flash was to create a node spawning system. I next create a node that the player is able to control. As the player pulls back from the controlled node and subsequently releases, the node would shoot forward in an opposite direction of the drag.
I then focused my attention on experimenting with the feedback that is provided to the player when the controlled node is interacted with (See Figure 3). I fell into my own trap of making this interaction as satisfying as possible because I felt that this is what the player will be doing most of the time and I needed to make this feel good for them. In hindsight, I should have worked on some other part of the game.Figure 3. A screenshot of the prototype (8 hours in)
I spent some time playing with the prototype in its toy-ish state while imagining that the nodes had collision and the ability to disappear or reappear. I attempted to find out what was fun about the game and what issues it had. I found the following issues and noted down what I could do to resolve them.
Lack of goal(s)
As it was a toy and not a game it lacked a goal. Should the player clear the nodes? Should the player connect the nodes in the least number of shots? Should the player bounce the nodes off the screen? Should the player get huge by consuming the other nodes? As a player, these were some questions the game was screaming out at me.
Lack of challenge
As a player I didn’t feel challenged. To provide more challenge for the player, I could assign an order to each node and the player could be rewarded based on how well they followed the sequence. I could pose a challenge to the player to line up multiple nodes in a single shot and reward them based on how many they are able to shoot at once. I could challenge the player to not cross over their trail which exists for their last few shots or exists based on the distance they’ve travelled.
Issues with movement
I could foresee that there would be an issue with trying to move from one node to the next since not every node would be possible to reach. There were a few possible solutions I came up with to resolve this issue, I could rig the spawning system so that there will always be at least one reachable node destination. I could move the controlled node to the closest node’s position in its line of fire. I could enable border collision or wrap the borders to increase the chance of moving to the next node successfully.
Arbitrary use of sizes
The size of nodes didn’t really have any effect apart from providing feedback for the player. Size wasn’t being utilised in any interesting ways. The order in which the player has to visit each node could be based on node size (ie. from smallest to largest or vice-versa) to add more challenge. Node sizes could represent mass or life and could add to or subtract from the controlling node’s size as it visits the other nodes, I’m very unlikely to go with this though as it has already been done in Osmos. The game could turn into a hoarding game, where the player just continually grows and at a certain size the camera would zoom out Katamari Damacy style and more nodes would appear from the sides of the game screen.
I’ll post another journal entry next week about the next set of changes I’ve made and the steps I’ve taken to overcome the above vulnerabilities.
Hi, how’s it going?
I’m Sam TC Wong, the latest addition to The Full-Time Voxel Agent’s Dev Team and one of Melbourne’s Resident Game Jammers. I’m also a recent Computer Science and Multimedia Graduate from Swinburne University of Technology. During my studies I made a bunch of games in my own spare time, outside of work.
So…Hey! I was thinking, I’d share about them, but FIRST…
…here’s my personal experience with games in a highly paraphrased format!
The first ever video-game I played as a kid was a Tetris variant, titled ‘The Blocks Game’. In primary school, my Dad and I would always fight over whose turn it was. To this date, Tetris is still one of my favorite classic games. *THUMBS UP!!*
Before jumping onto my first console, my Mum used to bring home games from work off of Floppy Disks that her colleagues lent to her. I played them on my first ever PC, which I won in a shopping centre raffle when I was in Primary School.
I played a lot of Paganitzu, and it was another favorite childhood game!
My first ever console was the PSX during my Late Primary School Years.
It currently sits inside of its home (a cardboard box next to my bed).
In Secondary School I moved back to the PC. I joined an online community of players in Starsiege: Tribes and quickly started making maps. I got a really big kick out of interacting with players as a level designer. My parents weren’t too happy about this huge distraction from my studies, but for me it was heaps of fun.
Here’s a Tribes Legacy video for those who may be slightly interested…
During High School, I was always thinking in the back of my mind,
“Oh Hey! Imagine how cool it would be to make levels or even games as a day job!”
I always enjoyed programming in VB 3.0, VB 6.0 and played around a lot with animating in Flash. At this stage in my life I was looking to head down the web design/development, software programming career path…
BUT THEN…The penny dropped and in late High School, I found out that there were Universities offering courses in Games Development.
I decided on doing University to better my programming, design and art skills. Eventually meeting a fork in the road where I had to decide which discipline(s) I would try to focus my attention on. In the end, I picked programming because I always enjoyed it the most and I always wanted to build my own games without having to rely totally on other programmers. Previously in High School, I always looked up to the cool kids that included scripts in their Tribes maps.
University did have an impact on my tastes as a gamer; I eventually switched from being a hard-core gamer to a more casual/indie gamer…
I’m now more inclined to consume games in the video above than the typical AAA content.
In 2009, I attended my second Freeplay Independent Games Festival and I met Tom Killen at the After Party, we exchanged emails and the rest is pretty much history. Between that time and today I’ve made a heap of games outside of work, here are some I can share with you.
Attributed to Sam TC Wong
This game is a love-child between a SH’M'UP and Air Hockey!
Reason for Occasion: Games Programming in C++ at University
Cooking Utensils: C++ with SDL, x2 PS2 Controllers, x1 Controller Compatibility Adapter
Cooking Time: 1 Month
Attributed to Sam TC Wong
A SkiFree-inspired game where the player attempts to delay their impending doom for as long as possible!
Reason for Occasion: Just another distraction from University.
Cooking Utensils: AS3 with Flex, x1 Optional XBOX 360 Controller
Cooking Time: 24 hours
Attributed to Team Sideways
A 2-Player survival game between two genders (Male and Female). Each player takes control of forces of attraction between males and females. The winner is the gender who out-lives their opponent.
Reason for Occasion: Global Game Jam 2011
Cooking Utensils: AS3 + Flex, x2 XBOX 360 Controller
Brew Time: 48 hours
Attributed to Sam TC Wong
A 2D Hex-Puzzle inspired by 3D Logic Puzzle Flash Game.
Reason for Occasion: Holidays overseas in Singapore!
Cooking Utensils: C++ with SDL
Cooking Time: 1 month
Attributed to Wanderlands
A 2D connect-the-dots action game, based on the theme, ‘Rout.’
Reason for Occasion: The first-ever #squidprobro Game Jam
Cooking Utensils: AS3 with Flex
Cooking Time: 24 hours
Attributed to Wanderlands
A variation of sokoban with magnets, based around the theme, ‘Counterpart‘.
Reason for Occasion: The Last Jam of 2011!
Cooking Utensils: AS3 with Flash IDE
Cooking Time: 48 hours
We actually went to the beach for a day to brainstorm and found this very dead-looking blow-fish that washed up…
Leave Me Alone
Attributed to Sam TC Wong
A 2-Player Top-Down-Face-Off-Poke-Em-Out game based around the theme, ‘Alone‘.
Reason for Occasion: Ludum Dare #22
Cooking Utensils: AS3 with Flash IDE
Cooking Time: 24 hours