Experimental Development Pt.4: Room rework, Visual/Audio elements, Game loop and playtest

Posted byJacky Cheong Leave a comment on Experimental Development Pt.4: Room rework, Visual/Audio elements, Game loop and playtest

A large number of changes have been made to the game, these changes were done to better integrate our chosen theme for the game. This being a traditional FPS game like Quake and Doom. Part of these changes were also done to integrate with Tom’s procedurally generated text.

Changes made

Variables

Figure 1: Public string values to be used for PCG for text

Here the string variables and others were made available as discussed with Tom. The idea behind this was to help generate the text and giving more context. Because I had produced the level PCG first, the text PCG system needed to be adapted to it. This would be an interesting workflow to further investigate as we are making two similar functioning systems (Procedural Generation) that need to interact in a meaningful way. This also affected how the rooms were designed as they needed descriptors too.

Rooms

  • Figure 2
  • Figure 3
Figure 2 is the previous, Figure 3 is after.

The changes for rooms are that the walls also have low-resolution textures built in. Walls were also elevated to a taller height. This was a consequence of implementing FPS movement for the player (more on that later). There are also some new variations on rooms, so if the PCG needs a room going from right to left it will have two or more rooms to choose from. The goal of this change is to add more visual variety to the structure of a level.

Another change was that the rooms were made larger, the exits and entrances have a larger width too. This another effort to adapt towards our chosen theme.

Empty room instantiation

  • Figure 4
  • Figure 5
Figure 4 shows empty tiles, Figure 5 shows the new empty room instantiation.

The empty rooms before as shown in Figure 4, allowed the player to access large empty spaces that were antithetical to the level design conventions found in the case study,as such the PCG was adapted to detect such empty rooms and fill them with a room.

However upon reflection and discussion we found that this felt unnatural and disruptive towards our target theme because the there were too many instances of the same type. In Procedural Generation for Everyone, Compton (2017) explains the 10,000 bowls of oatmeal problem where mathematically unique generations are not distinguishable from the other. In combination with the rest of the rooms, these empty rooms would make the differences less distinct. Then instead of the empty rooms, I decided to use rooms with walls on every side. This way works well with the larger room designs, the level still feels large enough and yet not too similar.

Killbox and verticality

  • Figure 6
  • Figure 7
Stairs and paltforms are built into the killbox arena

Here the PCG had to be adapted to create killboxes in the middle of the level. The killbox is composed of several different rooms. The killbox can vary in size between 2-by-2 and 3-by-3 cells.

  • Figure 6
  • Figure 7

This larger area allows for some experimentation with verticality as well as level design, currently the killbox rooms have vertical access but not much thought has been put into these designs. In that case this may warrant a revisit to Quake map design, especially concerning killboxes.

Audio and Visual elements

The visual elements implemented are:

  • FPS gun with shooting VFX inc. Muzzleflash and bullet impacts (this has no gameplay impliactions, only an FPS convention).
  • Lighting has been added.
  • Low resolution textures.
  • Playstation shader (dSoft20, 2016) implemented.

Audio elements are:

  • Footstep sound effect for the player character.
  • Droning ambience sound.
  • Teleportation sound.

The sounds are produced with Audacity. The PSX shader, again is part of the theme, the implementation of this shader has affected the manner of textures and how they are used, that is the textures have a warping effect. This undesirable and needs to be remedied. The textures themselves need to be of a smaller resolution to. The gun has been implemented to better reinforce the theme, this gun however has no gameplay implications right now. However this could be revisited in the future so that a gameplay purpose could be added, for example in Quake (aside from shooting enemies), the shootign can press switches that open doors.

Before playtesting there is one additional element that needs to be implemented, this being the gameplay loop.

Gameplay loop

The original gameplay loop in initial concept was as follows:

  • Player starts in starting room, in front of the entrance.
  • Player navigates the level to find a key.
  • Player navigates level to find exit.
  • Upon contacting the exit, a new level is generated.
  • The player is placed in the new level’s starting room.
  • Repeat from top.

However, upon discussion and reflection with Tom, this has changed. The main change is that we decided on removing the key. The reason for this is that the context for the game is that the player has entered an empty multiplayer game. While the key is a staple of FPS games like Doom and Quake, it is not part of their multiplayer equivalent. The multiplayer FPS games feature many different modes (Rhee, H. et al., 2019) that have a competitive element and focus on objectives and confrontation. The project would not have such competitive elements as such multiplayer modes do not usually feature the use of a key to unlock a door.

Now the gameplay loop is simplified:

  • Player starts in starting room, in front of the entrance.
  • Player navigates level to find exit.
  • Upon contacting the exit, a new level is generated.
  • The player is placed in the new level’s starting room.
  • Repeat from top.

The discussion and new gameplay loop resulted in the following:

My approach is to now implement five levels, each level generates itself upon the player reaching the end of each maze. The player is then placed into the next level and repeats until the player reaches the last exit. Upon reaching this exit, the player is placed on top of the stack again and begins the play through again. This time with additional changes, however these changes have not been decided. This was raised with our tutors, to take advantage of the cyclical nature of the game. However there are already a lot of changes made, these changes need to playtested.

Playtesting first prototype

For this playtest we want to test the controls and mechanics, this would be the movement, mouse look any early bugs. The playtest below was conducted with the least amount of disruption, the player was not given any initial instructions apart from expressing any thoughts they had about the game and has not tested any previous build of the game.

The main issues identified were:

  • Textures had a warping bug when the player was too close.
  • Player found the camera sensitivity frustrating, it was too slow.
  • The objective was not clear and player asked what they had to do.

Solutions:

  • The textures warping has been identified as an issue with the PSX shader that was used, the meshes that the textures are on are cubes. In the examples supplied with the shader, all textures need to be on planes that have a high polygon count. Then planes need to replace the walls instead.
  • Sensitivity could be fixed by simply adjusting the sensitivity, however this is most likely an issue with the size of the viewport. That is a smaller screen size will result in a more sensitive camera look and vice versa. As such a possible solution would be to implement a custom sensitivity setting for players.
  • This would be resolved with the text pop-ups that will be implemented in a future build. However, for this game I do not believe it would be beneficial if the player was given an objective. Instead they would be signposted towards the exit, upon regenerating they perhaps understand they could have an effect on the space and wish to keep going.

Unfortunately I could not assess whether the desired effects were achieved with the game, this being my second aim of the project: “Learn how to evoke feelings of unease and tension through the use of spaces and sound”. This was because the player could only express discomfort towards the sensitivity and nausea from the warping textures. Then fixes for these issues take priority.

Next steps

Apart from the playtest issues there is one other element that would need to be implemented, this being the changes on the playthrough of each game. How this may be expressed is something worth investigating or coming up with additional designs. This can certainly be used to explore my two aims, that is because these changes between playthroughs can be expressed by changing the maze or elements dedicated to enforcing a particular mood of atmosphere. This would require furhter study into items of media that would evoke feelings of tension and unease, to be more specific the weird and eerie.

  • Address issues found in playtest.
  • Implement playthrough changes.
  • Study additional methods to evoke feelings of tension and unease for the changes between playthroughs.

Bibliography

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.