Last week we finished the playable prototype, and during the weekend we gave it to our friends to test it. Now it’s time to throw everything out and start to build it up once again. No. I’m not joking, and I’ll explain it in a moment, but first, let’s talk about what we learned from the playtesting.
Playtest result of the prototype
One of our testers took her time and captured how she is playing our game. Watching this gameplay was fun, and very informative at the same time.
If you are working weeks on a game, you become less aware of the gameplay problems. You don’t make mistakes, because you know how it works. This video pointed out some issues that we couldn’t figure out. These were gameplay and level design problems that I explain later in this article.
We discovered two obvious problems just by talking with our testers:
First Milestone: The Vertical Slice
With finishing the playable prototype, we closed down the prototype phase of the development. This also means we have to throw out our current work and start it again from scratch. A hard but necessary step since the prototype is some kind of sketch, where we drop in everything that seemed to be fit.
We spent most of our week to set up a new project, importing the assets we want to use, rebuilding the scene and writing the codes we’ll need for the game.
We made some changes on the level layout since the one in the prototype didn’t guide the player well enough. They didn’t find the shadow gate, because the level leads them right into the camp.
Three Levels of Communication
During the prototyping, I combined the 3D Game Kit event system, with my own game architecture that is based on scriptable objects. This architecture follows the idea of Ryan Hipple, he is a principal engineer at Schell Games. He made a Unite Talk about the architecture they are using.
It’s quite genius, and I was inspired to make my own version. I used this for plenty of projects since then, and it was very convenient and quick to work with. I’ll publish it in the Unity Asset Store soon, but that’s a different story.
Since we were satisfied with the workflow in the prototype, I started to build up better this combination. The core principle of this is compartmentalization: separating the parts of the system to prevent malfunctions from spreading between or among them.
You might be thinking, this is the core principle of the object-oriented programming too. You are right, but since we are using component-based architecture, where a single component contains a small code, OOP wouldn’t be appropriate here in my terms. I like to call it Three Layers of Communication.
1st Layer: Prefab
Most of our prefab functions are made with simple components that utilize UnityEvents. Our rule of thumb is that we are only using UnityEvents within the prefabs. We have the Burning Crate prefab, where UnityEvent turns on the particle, the interest target for the AI, and the audio.
2nd Layer: Scene
Every communication between prefabs on the scene works with Game Command System from the 3D Game Kit. This a great system, it’s easy to see which game object calls whom, due to the gizmos.
Currently, it supports only one to one connection type. Where we needed many to one connection, we made child objects for the prefab each with a single Game Command Sender, and call each of them with a UnityEvent.
Important: we only allow this type of communication between game objects that are connected to the scene.
3rd Layer: Game or Global
We are using scriptable object events and listener components, similar to the ones that are presented in the video above. I use Game Communication and Global Communication as synonyms.
Understanding the difference between scene communication and global communication might be difficult sometimes. Our rule of thumb is this: global is when the result of the event should be the same regardless the scene is currently loaded, otherwise it’s scene communication.
Scene Communication Example: a trigger activates the burning crates. Both of them could be used differently in other scenes, so they are communicating on the scene layer instead of global.
For narrative dialogues, we have multiple actors on this scene: the character, the guards and the obelisks. We want to show an avatar image and the name of the actor with the text.
The first question you could ask here: why wouldn’t we use the Dialogue System I made for the Asset Store? It’s hard to admit, but it lacks an important feature that required for this project.
We could use the Runemark Dialogue System for this project, and it would work fine. The asset is made with conversations in my mind, and not with a narrative. For every box of text, we should make a new dialogue graph, which is not an optimal workflow.
I’m working on an update of the Asset to support narratives much better, once it’s done, we will put that into Shadowdancer too. Until that time, we will use this solution, because it was faster to make.
In-Game Pause Menu
It would be useful for the test to have the possibility to restart the level or load the last checkpoint when the player is got stuck somewhere. Now we have a pause menu with these options!
That’s it for this week, hope you enjoyed this article. Next week we continue working on this project and getting closer to the Vertical Slice.
We’ll see you all next time!
One thought to “Shadowdancer Devblog
Week 6 – Throwing out the project”