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