A little Devblog on Prototyping
What is this post about?
This post is less technical and more of a little story on how the main mechanic for one of my university projects was found. The project in question is The Wuseling. Wuseling is a four player local 2.5D brawler about bearded mages that battle it out in an arena.
The game was written in Unity and my part in this project was mainly Gameplay-Programming and a bit of Game Design. At the start of the project we had to find our main mechanic so we created a few prototypes, which I often ended up programming.
Storytime! So what was our process?
In hindsight we actually somewhat followed the double/triple diamond design model.
The Diamond Model
I first got into contact with this when I was reading The Design of Everyday Things by Don Norman (highly recommend that book by the way).
Basically the design model describes the process of designing solutions for problems. Firstly one needs to define the problem itself. For this, one broadens their view to find possible causes for the problem to then converge back to find a concrete definition for the problem. Afterwards the same is done for finding a solution. Many possible solutions are found to converge back to a concrete solution again.
Besides the double diamond model there also exists the triple diamonds model:
This graphic is by Karl T. Ulrich, who also has a lovely explanation on the triple diamond model here. But in short, it is quite similar to the double diamond model. It however adds another diamond in the middle, which focuses on understanding the needs of the customer/user.
As a little sidenote: personally I always tend to call it the tennis-ball-snake model, as it looks like a snake that has swallowed a few tennis balls.
Just now I was once again wondering why my google search for “tennis-ball-snake design model” didn’t get me any good results ^^’
Human-Centered Design Process
Don Norman also describes the Human-Centered Design Process. This is an iterative approach on constantly improve a design/prototype. I think the following grafic describes it nicely.
This is also often called the spiral method (even though it is depicted as a circle here). So basically one makes observations on the intended target population, generate ideas, produce prototypes and tests them. This can be repeated until satisfied.
Back to Wuseling!
Enough about the theory behind it! Let’s see how we applied this to our project. Basically we did not follow this concrete design process, we just did things our way. That however ended up with certain similarities. Let’s wander through our process with some nice pictures!
Definition of what we want
At the beginning we started with establishing the approximate range within which our mechanic should operate. To do this, we sketched out some rough guidelines:
- it should be physics based
- it should be somewhat chaotic (it was a bit tough to find the correct balance of chaos)
- it should include some pulling or pushing of players
Prototype Ideas: Lots of them!
With this we started to write down some possible ideas that fit the theme. Let’s just look at some sketches so I don’t have to explain every single one:
After we decided on our favourites we actually made quick and dirty prototypes on the mechanics and decided on the one we liked most:
The winner was Rubber-Links!
We decided on focusing on the Rubber-Links mechanic. Basically players can shoot two ends of a rubber band and activate the rubber band in order to pull any connected things together. This also allows players to only shoot one end of the Link and activate the rubber band whilst it is still connected to oneself to dash forward! In combination with environmental elements such as boom-barrels this mechanic was promising.
With this we started into further iterations and improvements of the mechanics:
Over time the mechanic was further improved by adding some aim assist, less wobbly ropes as well as better player models.
Conclusion on our Prototyping Process
We somewhat applied the “tennis-ball-snake” model. We first started with defining what we wanted. Then wrote down some possible mechanics, narrowed it down to our favourites. Then we created some small and dirty prototypes of these to actually tested them. Then we decided on a favourite again. Then we scrapped the dirty prototype code (yay to dirty prototyping!). Finally we coded it clean again and started the spiral model of constantly improving on the mechanic.
I have to say however, in this specific example we never found a satisfying end for the mechanic. The cycle continued on and on. In the end Wuseling was scrapped due to many reasons which I won’t go into detail here. Though I think if we would have kept on it, at some point we would have ended up with the perfect mechanic that just 100% clicks :)
That’s it,
Thanks for reading,
Cheers, David :)