Post Mortem – Legacy of Erina: Shattered World

(Sir Flauschig – Lead Programmer)

This will not be a pure post mortem documentation, but it will be a summary of the goals and the results. It will also show the points which went well or badly from my point of view. (Other team members could present some points differently).

Most parts of the following text is translated with deepl. (Because lacking of time.)

Goals:

My goals within this GamesJam were:

• To analyze the use of state machines as a basis for different objects and to learn about the advantages and disadvantages, where the limits are and what the solution for possible problems and limitations is to consider if I would like to continue using this in other projects.
• Another goal was to get to know the generation of meshes via script better. To get to know the problems with more complex structures and to implement the automatic generation of the UV map itself.
• I had already tried to implement a wayfinding with the A*-Search, but after a short introduction to the included Nav Meshs and Nav Mesh Agents (Unity) I wanted to use them in practice and learn about the advantages and disadvantages.
• The last point was to get to know the use of GIT within such a project better and to learn about the limits/problems.

Results:

State Machines:

The advantage of handling via individual states is that only those aspects that are necessary are handled in the respective state. If there are aspects, which must be present in each state, this can be solved very easily by inheritance.

To implement the behaviour over states has the advantage, that the behaviour can be extended fast and easy over further states. If every behaviour is an own object, this can be done with relatively clear code.

Another advantage is that single states like falling, rolls or attacks do not need a large amount of code. At the start the suitable animation (if necessary with suitable animation events) can be played and at the end of the animation the state can be changed back to the normal state.

If in certain states the control should be restricted by e.g. the player, this can be handled easier in different states instead of disabling the control in certain cases under certain conditions.

With more complex objects/behaviours a state machine reaches its limits more easily. A solution for this could be several state machines, which under certain circumstances also communicate with each other.

In this game the player has been given additional internal states, which reflect the inputs. This is based on two integer values, which are changed bit based. (Flags) If the actual state differs from the state before, this is reported to the state (small internal interrupt system at the player). If something is done with the information in the current state or not, can be decided then. (So single inputs could theoretically be lost if it is not stored and passed on between.

All state machines have as a condition the possibility to be addressed by more general interrupts. This is useful for trigger (boss) or interaction with chests.

Mesh Generation:

The mesh generation was used for the bridges. Mainly because attaching assets to each other would have been more difficult and problematic. Generating the meshes for the bridges during level generation was the way to make them look better.

In the first iteration of the implementation, there was only one vertex for each corner and thus each side. So at that time either 16 or 12 vertexes were needed per row of the mesh. But this was a less good implementation because all edges were rounded and the UV generation did not work properly.

In the second generation, a separate vertex point was generated for each visible page and only the respective pages were connected. This would have increased the number of vertexes per row to 20 or 36 vertexes.

As an inexperienced person, I had spent 2 days on the whole setup and I personally felt the generation of the mesh as a cramp. But now I know that this is also a bit more complex from the internal structure. (I partly had to work with up to 2 internal offsets in my built up structure to be able to build the vertex correctly with the correct index).

Nav Mesh (Agent):

Using Nav Mesh / Nav Mesh Agents in Unity is basically simple and easy. You have to generate the Nav Mesh and place the agents on it.

But since the islands were randomly selected and placed at runtime, they had to be generated either at runtime (performance problem) or generated before and attached afterwards.

I decided to go for step 2. I generated the Nav-Mesheshes in advance. But you have to consider that this prefab has to be in the neutral rotation. (y = 0), otherwise the agents may behave strangely later, because the rotation from the nav mesh to the islands will have the previous rotation as offset. This would cause the agents to pass through objects or change to positions that are not intended. Another possibility is to look for hidden paths, because the player is at a point which is not or only differently reachable.

Using of GIT:

Git is a powerful tool and needs proper instruction. However, this proper briefing was missing from my side, so one team member had massive problems using it.

It should also not be used to synchronize all files. Especially text based files are useful. (No binary files). 

Also the Unity project should be well prepared and unimportant files for other users should be added to .gitignore as an exception. Especially files generated by Unity fall into this category, because otherwise they would produce an enormous overhead.

Successfull:

I regularly worked on the project for a few hours every day. Most of the problems that occurred and were treatable within the deadline I was able to either fix or reduce.

I was able to complete the first analysis of state machines for myself. I was able to see the clear advantages and I was already thinking about how to handle the limits.

The mesh generation had also worked. Sometimes there are still problems due to external factors of the mesh generation, but I could understand the basis better. However, this had not been a very pleasant aspect for me. Nevertheless, this will probably still be a possibility for generated aspects.

The Nav Mesh Agents worked well so far.

I had the time management under control. I could fulfill all my goals and a usable prototype of the game came out. Unfortunately, the quality of the code had to suffer a little over time.

We held regular meetings to discuss the current status and the next steps. (2 times in a week.)

Unsuccessfull:

Especially at the beginning, the meetings were quickly and extremely submerged in offtopics. The focus of the meeting was hardly present during the time.

One team member had extreme problems with GIT and the synchronization of the island prefabs above. With better briefings and a better understanding in general this could have been better counteracted.

The structures of the Unity project had quickly got out of hand. Also the naming of the files. (Except for the subdirectory of the C# files.) This would have to be better addressed in the future and then followed. Especially the uniform naming in English. (And a uniform naming of the files like CamelCase)

I had not been aware that a post-mortem documentation was desired. This had only really become known to our team towards the end of the deadline for submission. Because of the deadline extension I decided to write this document.

I hope that this will give some people helpful aspects to think about and may get better ways to handle some problems.