An Archer’s Dream: Game Development Journal Entry #02
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).