Sprint 2 was originally going to be a continuation of the work we had started last sprint and our procedural generation system was going to be started in Sprint 3.
After feedback from our client/supervisor it was suggested we push the procedural generation system forward to this sprint due to its large basis around the entire work.
One of our team came up with this simple system to spawn rooms allowing different types and sizes of rooms. This was a great basis for the start of the system and we then discusses how we could create a rules system to generate the level based on this idea.
Something else that needed refining was the art style and the playable character. One of our team had hand drawn the character style, and this model was created based on this design.
The design of the artwork has always been a thought on the cartoon based styling rather than the normal survival horror genre which is dark and gloomy. The idea is to use the darkness and the atmosphere to cause the horror feeling over jump scares and gore.
In continuation of this, our artist has come up with a variety of items that suit this cuter theme than what is usually associated with survival horror.
Not all of these were created in week 1, but over the majority of sprint 2.
This week had the team working further on the procedural level generation system with two team members really focusing their time on this major feature. One team member was assigned the role of creating the random level system, while the other was working on the random room system. Both features will work in tandem to create levels that are unique everytime whilst also having some variations.
During the development of the procedural generation, another of our members was working on the navigation system for our “despair” enemy character.
The first example was showing how the enemy would chase the player based on a navigation mesh. This mesh will be used to allow the despair to chase the player while also stopping it when there are no paths to the player.
All assets here are place holders.
The next step was implementing a cone of vision that the despair would use to look for the player. This allows the player to sneak around the despair without it noticing unless it looks at the player directly.
You can see when the despair is chasing the player when it turns a red colour. Again all of this is placeholder to test the features over what will be finally implemented.
Week 3 has the team continuing work on the random generation system, as well as finding a set of art assets that worked as place holder to allow us to continue on our development journey while not being held back by delays in modelling.
Our initial system though was not placing the items as expected, even though the layouts were coming through and, as you can see, there were places for rooms. The doors and walls were not aligning as expected.
After some major modifications to the layout system, the walls started spawning the correct way and our levels have started taking shape.
This was a major leap forward in our development and meant that the game could continue.
Also the despair character system continued to be fleshed out and we finally get to see the player character asset being chased by our temporary despair within a game level. The despair has all of the systems required:
- patrol the world
- look for the player
- chase the player
This week we had some visual changes including the model for the despair finally in play as well as a spawning animation and a sneak animation for the player.
There was also some major changes to the despair system including its speed and the ability for the player to hide behind obstacles by crouching. The despair is also hurt by light now and will flee when it gets too hurt.
This wrapped up our second sprint and at this point we made a demonstration of the games current state for our supervisor. Following feedback from this sprint, our next sprints focus will be more on getting the game as a whole rather than waiting until the final sprint to finalise the game.