Hi I am Jim, the Level Designer for STARSTRUCK, and this is a summary of one day on the production floor: November 5th, 2013. The level design problem I am addressing today is a severe dip in the intensity of gameplay after our second encounter. Our game, STARSTRUCK, is a 3D twin-stick beat-em-up which demands high intensity encounters throughout the gameplay experience. The player controls Dr. Box, and he has just fought the final boss for the first time before watching him escape. The downhill interlude is immediately after this first major challenge of the game, and the beat chart shows that a slight dip in intensity is desired. However, the intensity dips too much right now, and playtesters complain that this section “feels too long,” which is the polite way of saying that it is boring.
For each of the levels in the beat chart below, the following scale is used to describe intensity:
0: Dr. Box walks and dashes, but there are no enemies for 15 seconds
1: Dr. Box encounters up to 5 enemies every 15 seconds
2: Dr. Box encounters more than 5 enemies
3: Dr. Box encounters more than 10 enemies
4: Dr. Box encounters more than 15 enemies
5: Dr. Box encounters more than 5 enemies in traffic
6: Dr. Box encounters more than 10 enemies in traffic
7: Dr. Box encounters more than 10 enemies with the boss
8: Dr. Box encounters more than 15 enemies with the boss
9: Dr. Box encounters more than 20 enemies with the boss
The Downhill Interlude has several unique considerations that must be taken into account:
- The player must interact with the control stick in a new way to fight a new enemy type
- Tight corridors make the gameplay space feel more claustrophic than other parts of the game
- Trucks drive up the hill and create environmental hazards
- The player often has reduced health from the previous encounter
My first step is to improve the player’s visual feedback for spawning enemies. I really want to make a quick change and see the result before starting the more complicated work for the day. With Unity3D, it is easy to click and drag the Enemy Spawners (shown with red tags above) one house further down the hill. This means the player will have a better opportunity to see the enemy coming at them instead of running past it before it comes into the gameplay area.
This is definitely a step in the right direction. I find the enemies spawn and stay on screen until their first attack, even when I ignore them and dash through the whole section. After this change, I realize I need to add a mesh collider to another house, or the last Dirt Devil will quite obviously fly through it. After I add the mesh, I have to reposition the spawn point so that the enemy flies out in front of the house and does not hide behind it. A few iterations later, I have a result I am happy with. This took 20 minutes with about five minutes interruption for a group discussion about a design change to our core mechanics.
The next alteration is to double the amount of enemies spawned from each spawner. The testing for this change will be ongoing, and already I can feel that these enemies are taking a lot more of my attention. Now on to some larger alterations – but first a surprise playtest for ten minutes. Our playtester, Enrique, felt that the section could use more trucks so that is what I will focus on next. To all the students in the first half of your year at VFS Game Design, I recommend that you do what Enrique did and just show up on the second floor and ask to play games. It helps the teams in production a lot and you never know what benefits will come from these interactions.
Trucks are currently using Wheel Collider code that Marcus (from Sweet Escape) generously shared with us. They are awesome, fully capable of some pretty amazing jumps, and were easily modified to seem goofy enough to fit in our world. One drawback is that I have to manually place a new set of path nodes, aka empty game objects, for each truck that runs through the level and cannot copy and paste them. The best way to do this is to take advantage of Unity’s icon system. These only show up in the editor and make level design much easier because you do not have to find invisible objects in the hierarchy. Best practices for icons include using diamonds or circles to mark all path nodes, using labels for trigger volumes and spawners, and colour-coding everything to make your life easier. You can add icons to any object in the Inspector tab by clicking the shape with a downward arrow that is just left of the enable/disable checkmark box.
I used tags to mark my first set of path nodes, so placing these next ones should not take too long because I can place the new sets in the same general location. My workflow is to place nodes for one truck, test that truck to make sure it is triggered and goes to the end of its path, and then move on to the next truck. This task ends up taking 35 minutes, and ends just in time for the staff to test our game as part of our afternoon Project Development lab. The gameplay “feels less empty” than last week, which is a sign I am doing something right. My main goals for the rest of the day are to create a mini-encounter at the bottom of the hill and smooth the transitions before and after this section.
After a complete playthrough of the game, I notice various gameplay elements that need to be tightened up in other sections of the game. After 20 minutes of adjusting those elements, I commit all my changes for the day so that my teammates can test the new changes and provide feedback.
It is now almost 2pm, and I still have a lot to do today. Now that I am sure no enemies are chasing me from previous sections of the level, I feel like it is time to add another enemy into the mix at the bottom of the hill. This will create an encounter that has enemies coming at you from high in the sky and low to the ground, one of the key moments our team envisioned from the very beginning of the STARSTRUCK project.
After 20 minutes of setting up the encounter, it feels good enough to let playtesters offer their opinion. First, I am going to tweak this section a bit more. Playtesting can wait. I decide to make devils spawn and fly out of the spiral door directly behind the doghouse.
The time has come for me to remove the invisible walls at the end of this section. I am confident in the quality of all the gameplay up to this point, so the only major task left for level design is to set up a better boss battle arena and tweak the AI values to reflect the new changes. These tasks probably warrant a full day. I am starting to get into some scripting for this next task, as I have to remove both the walls and the logic that triggers them. One of the issues is that I have, a trigger volume that collides with the player only after they exit, so they cannot go backwards. Right now, the player can enter the trigger volume and exit the same way they came in, which prevents them from re-entering the street that takes them to the final boss. I added what I call a toggle volume to create a threshold at the beginning of this trigger volume. The toggle volume has one value that returns true when the player is inside it and returns false when the player is outside of it. I am able to prevent the trigger volume from adding collision when the player backs up by checking to see if this value is true when I call OnCollisionExit() in the trigger volume script. Now the bug is fixed. Once again this task takes 20 minutes to complete.
The new boundary is a collection of trucks spawned offscreen that move by gravity to seal off the narrow opening in the picture above. It is not sealing the player 100% of the time, so I must add more trucks. A visit from the Steve, the audio mentor, alerts me that the ambient sounds are not working correctly so I diverted from my original task. I had forgotten to use layers to limit collision with the sound trigger volume to the player, meaning that ambient sounds were triggered by other objects in the scene. Steve and the team listened to new assets from our audio collaborators for almost half an hour and then I got back to placing the trucks into a satisfactory barrier. I know how to break the formation of the boundary, but I doubt many players will ever put themselves in the position to find out. Especially now that they will be hurrying forward to destroy the doghouse!
There was a critical bug during the playthrough with Steve, and in this case it was one that I created earlier today. Apparently I broke the trigger for the boss fight while removing the invisible walls. Thankfully, it is just a syntax error in the code and takes less than 30 minutes to solve – bringing me to 5pm. Only one hour left in core hours and the Downhill Interlude already feels much different that it did the day before. I spend 20 minutes removing a bug that allows the player to leave the gameplay area in this area. Then I quickly adjust the path nodes I placed earlier today to help the trucks avoid getting caught up in the narrow section of the hill.
I got one final playtest in after adjusting the path nodes, and core hours are done. This is one of the few days I have spent entirely on level design, but I feel that sharing this experience has revealed some tips for anyone who wants to get ready for the second floor.
LEVEL DESIGN TIPS
First of all, playing the level is the only way to know everything that has been adjusted is actually working. Therefore, the best practice is to make small changes that result in a visible difference, then test them, and make sure they work as intended before moving on. Also try to break tasks into small, manageable pieces that are estimated to take twenty minutes or less. Other responsibilities are constantly taking time from your day, so large-scale complete world passes will be interrupted – especially when working in a small team environment. Keep moving through tasks and don’t seek perfection, optimize your work towards making players enjoy your game. Don’t assume anything about how other players will judge it, get people to playtest it instead; then ask them specific questions to confirm your hypothesis. The way players perceive challenges is one of the most important parts of level design, so make sure you are reinforcing your design decisions with observation, and constantly iterating to give players the experience that you want them to have.
Jim Dodge is a student in term 6 of Game Design at VFS