By Tooth & Tail
this was my second game project at my education at Futuregames.
- Role: Systems designer/project lead
- Time: 4 weeks
- 19 people
- Made in Unity
- Theme: Dagger Blade
I was the project lead for this project. And this project is for me the project I probably learned the most from. In terms of how to communicate effectively. How to work with a game vision. And how to scope properly (or rather how not to in this case).
Trailer
Ambitions
We had a lot of people in our team with a lot of experience. So when we where brainstorming on what we wanted to do we decided to go bold: Make something that would be a challenge from both a design as well as a coding perspective.
We considered the strengths of the group would be around sound and environment. This is why we decided on making a horror game, as in that genre sound and environment are particularly important.
Second, we decided to be experimental: Combining horror with tactical grid based movement. None of us knew any games like this so we where interested to see if we could create a fun game in this way.
Prototyping
for this game we needed both enemy pathfinding and tiles with different functions. Therefor a lot of programming work needed to be done before we could prototype in Engine.
in order to increase the efficiency we gave the programmers a quick draft of what we knew would be in the game. in the mean time as designers, were prototyping and testing the game on paper. Something that works really well for turn and grid based games.
the paper prototype ended up working really well for the sake of both designing the game as well as communication what we where thinking the the UX designer in the group and QA as we quite quickly found a fun game loop.
Vision of the game
A problem arose thou when communicating this game vision to the programmers. At this point in time my impression of how you should communicate with programmers was that the Game Design Document was a Game rules document (like in a board game) that the designers would write and the programmers would then use to make the game. Rather then a reference page to align the vision of the game. A lot of mistakes where made because the rules i wrote where my interpretation of the rules of the prototype that we made that then got re interpreted by the programmers. Meaning a lots of ineffective communications and small misunderstanding that build up and really slowed down the programmers work. in hindsight a recording of a play through we did on paper. or a playthroug of one of the levels using any Virtual table top would have been way more helpful than the game design document i spent upwards of 30 hours writing.
My First takeaway here being that there is no such thing as cheating when it comes to communicating having everyone reach a intuitive understanding of what we are working towards is top priority.
Coding
My second take away was over estemating my coding capabilities being how important it is to have a base level understanding of programming as just being able to write and communicate is really important. As i noticed that my capacity to work on C# scripts is inversely proportional to how tired i was. this has set my ambition to become better at coding to not end up here again.
Environment
as this game was a horror game the environment and sound where some of the most important parts of the game. one of the most powerful tools in making a horror game is the fear of the unknown. Which does not match well with a tile game as tiles in general make thing predictable. When Designing the game we hoped that trough mechanics such as a fog of war. And good environmental story telling and sound design this would still work out
Sound
this game had basically two types of modes it could be in either the enemies where patrolling or they where chasing you. I wanted one of these to be slow while building tension where as the chasing track would be an intense your doom is approaching kind of track.
I do want to note that all sound editing and the soundtrack were done by other people