CAT | Voxelites

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

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

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

 

No tags Hide

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

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.

Vulnerabilities

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)

Low ROI:

  • Pinball style collision

Medium ROI:

  • Ordered shooting with sequences based on node size or sequence of numbers
  • Tap to shoot input

High ROI:

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

Read the next development journal entry.

Hide

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

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


Figure 1. Clarification of which graphs I’m referring to.

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.

Getting Started
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)

Figure 2. A highly generalised designer-programmer iteration loop
 

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)
 

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

—- Continue to Journal Entry #02 —-

Hide