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