TAG | prototype
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.
In 2011 we made loads of prototype games; some small, some funny, some that sucked, almost all ugly (except the lucky few that receive Tian’s touch :D). Here’s a visual tour of 20 of the 24 games that we made in five months. Together they paint the picture of what Voxel Agent games look like when they’re born – a mish-mash of squares, circles and terrible colour schemes!
Last weekend, we competed in the #fab48hr game making competition in Brisbane, Australia… and what a wild weekend! We won! That was great, but more importantly I was absolutely blown away by the quality of games made by the other teams. I was particularly impressed with the level of quality and polish that was developed in “indie” / student room. There is an enormous amount of talent in Australia and I’m sure we’re going to see more from those awesome young developers.
In the #fab48hr competition, each team must concept, design, and create a game based on three keywords that are provided at the beginning of the competition. This year, those words were “suit”, “key”, and “badger”, provided by Yug, Hex, and Jinx.
We made this:
How to Play: Without giving too much away, if you have a couple of XBox controllers, plug them in for the best experience, using “A” as your action button. If you have to use a keyboard, you can use the arrow keys for player 1 and WASD for player 2, with “shift” as the action button. Also be aware the the glowing yellow floor (which totally looks like lava) will kill player 1 and the swirling blue circles (evidently poisonous gas…) will kill player 2. That’s all you really need to know… oh yeah one more thing: the badgers aren’t nice and they will eat your face.
The Badgers of Fury 161 was developed by the Alliance of Indie. This team was composed of developers from a number of Australia’s top Indie studios including yours truly Agent Tom (The Voxel Agents), Liam Hill (Defiant Development, 3 Blokes Studios), Cratesmith (Cratesmith,Defiant, Strange Loop), Matt Ditton (Queensland College of Art, Defiant), and the incredibly talented Milenko (Strange Loop,Defiant).
But really, kudos where kudos is due:
As proud as we are of the game we managed to make in 48 Hours, the real winners of the competition were the indie team Rockin Moses (read about them here: http://making-games.net/48/?p=2916) who made a really fun game called The Fifth Suit.
This game was great fun to play. For me, their game evoked “Smash Brothers Brawl”. While playing, I was less concerned about winning and more concerned about trying to make life difficult for my opponents. It was a strong social experience and quite a polished product for just 48 hours of work! You can grab a PC version of their game here [WIN] but it’s best played with XBox controllers. If you’re lucky enough to have some XBox controllers then I strongly suggest you get this version [WIN – XBox Controllers].
This prototype is one in a series of time mechanic puzzles we’ve been exploring recently. Tian and I created this prototype and with some additional coding help from the other Voxels. It progressed from concept to prototype in just three days. While this concept as it stands will probably not be something we develop further, it has spawned some very interesting derivative ideas and creations.
I particularly believe in the navigation controls and we’ve been developing some quite special with them. Hopefully we’ll be able to show you this in the near future.
Time-Travel Treasure Hunt is a an observation-puzzle game where the players goal is to locate stars which are hidden in a scene. The scene changes over time, playing back a simple story, and the player can follow the events from start to finish or can reverse and scrub time however they please. As the scene unfolds, objects and patterns will collide and overlay each other to form a star-shape. The player must observe these shapes, and click them at the right moment to identify where they are hidden.
Here’s an example of 3 animated shapes dancing and having an absolute blast in the snow. Can you see when they align to form a star?
Click the link below to play the game! Rules:
- Locate the stars in the animation and click on them when you spot them. We don’t mean the obvious stars in the night sky, but the hidden stars formed by shapes and patterns, as well as pink stars.
- Use the scrubber to scrub time backwards and forwards, and use the arrow keys to jump a single frame at a time.
- Pink stars will briefly appear for just a split second and it’s only possible to click them when they are visible.
- Other stars have been cleverly hidden in the environment and take shape when objects align.
There a total of 10 stars. See if you can find them all. Click here to play: Time-Travel Treasure Hunt [35 MB]
‘Slingshot’ is a game concept that I worked on myself and it has not been made into a playable prototype (yet). With Slingshot I set out making a concept with complete focus on player input. The idea is to start designing something that feels good to play, where the motions makes sense and are designed for a touch device.
The first draft of this game idea was done on paper, trying to draw interesting puzzles and patterns to trace lines around – When the paper-prototype seemed interesting, I proceeded to put together a video to explain the idea to the other Voxels (you can see the video below). The next step is to build a playable prototype, and then from there come-up with an interesting theme and mood for the game. This is just one type of development process we’re trying, in another project it might go in the reverse order (Theme -> Gameplay vs. Gameplay -> Theme). One of the great benefits in working at The Voxel Agents is that we get to find these things out as we go. I am given a lot of freedom and leeway in how I approach game design and prototyping.
Here is the pitch-video for Slingshot. Keep in mind that this NOT our next game but one of many concept we’re working on: