Hi folks, today I'll be talking about new gameplay elements we added and some art stuff.

Since we were missing kind of a "Gameplay" element in our game we thought alot about new gameplay elements. We had some suggestions we should add a "Naughty" element to our game, so we had a few brainstorming sessions and after some discussions we came up with a list of ideas.

We all voted on what ideas we thought were best.

Number 2 & 8.

8: Bad guy that runs around setting fires. To win catch him and save victims.

2: Victims running near fire, they catch fire and you have to extinguish them.

So we developed number 8 into a kid that runs around and setting fires 'randomly', having a high chance to set victims on fire. This changes the gameplay drastically, creating a more surprising gameplay element. After this we also thought about pushing objects into fire, creating more of a "naughty" atmosphere, giving the player chances to misbehave. 

Furthermore we added machines from the actual Heim museum, and letting the players interact with them so they can enable/disable them, and sometimes overheat.

Here some pictures of machines and pushable objects.

We adjusted a few particle systems, and smoke particles and safe spot particles

were also added.

UI was worked on thouroughly, because some were still placeholders and some we found out to be unclear after feedback from playtest sessions. 

Animation wise we also progressed alot, all animations were finished.

Museum Framework Uncertainty

We are reaching the deadline for the project and we have finally gotten to implementing the connection to the Heim/Oyfo museum framework.

In order to stop our engineers from doing stupid things and "accidentally" DDOSing the museum's database, we have updated the base code the teachers provided to us to make it "Stupid-Proof".

Firstly, to coincide with the coding conventions in our group, we have adjusted all the arguments the game receives from the player to be accessible via properties instead of getter methods.
Then, since the Arguments are simply data received from the player, we have changed them to be a simpe C# class.
Furthermore, we have added an Initialized property to the Arguments to let our engineers know whether there is a connection to the museum's database or not.



Next, we created an exposed method that starts a request as a coroutine in order to take control of how many times the coroutine is started. This way, users of the API are unable to start millions of requests to the database, crashing it.
Moreover, we have added an optional System.Action parameter that allows the engineers to take specific actions after the request is processed. In our case, we are using it to proceed to the next level once the score has been uploaded.



This framework allows us to take the players score and upload it to the museum's database. However, the problem is that there is no way currently to get the score from the server. In other words, this renders this entire system useless and makes us unable to create a high score system, unless we store the high scores locally on the computer where the game is run.

Mecanim Without Animations?

With the release of Unity 5, the Unity team introduced their new mecanim system to the world. Mecanim is a system that allows users to create put together animations, create transitions and build complex and sophisticated animation state machines.
Although mecanim is aimed at animations, under the hood it is but a finite state machine with conditional transitions between states. We took advantage of this and create an animation controller without any animations!

In our game, our victims can have multiple behaviours:
- None
- Following the player
- Going to safety on their own and returning or panicking when they get lost
- On Fire
- Rogue

At first, the victims only had the first 3 behaviours, so it was fairly simple to manage within 1 Victim script using an enum and a switch statement. However, once we started expanding the behaviours victims could have, the codebase grew large and no one wanted to approach it anymore.

Mecanim to the rescue!

We took the AI of the victims, separated it into different StateMachineBehaviours, which are special components, extending from ScriptableObject, that Unity allows users to put on different states inside their mecanim system, and created a controller for the victims.

And every state in this state machine has a behaviour attached to it determining how the Victim behaves in that state



Afterwards, instead of a huge mess inside the original Victim script, all that is left in there is one method that sets the Behaviour parameter in the state machine that determines to which state the victim transitions to.



Moving to this system and utilizing the power of Unity's mecanim allowed us to easily extend and modify the functionality of the victims, making the game much more fun and enjoyable!