Luna Academia

Summary

Luna Academia is a first person shooter game heavily based off the gameplay mechanics of Quake. The player has to eliminate enemies and open doors in each level in order to make progress.


The doors can be opened using keys found throughout the map, and the enemies can be killed by either of the three weapons the player has at their disposal.

Specifications

  • First Person Shooter Game
  • Created in 10 weeks half-time
  • Created by three level designers, five programmers and three artists

My Contributions

  • Level Design
  • Created one level
  • Created a first person shooter prototype using Unity
  • Created various scripts for exporting scenes in Unity into a readable XML-document
  • Created several design documents based on various reference games

The Team

This Time, We Need a Unified Vision

Since the vast majority of the team agreed that having multiple reference games in mind while making a Game Assembly project was a bad idea, we decided to only have one reference game this time around. This turned out to be a great idea work-wise, but many problems still arose during the later stages of development. But more on that later.


In order to decide which game to pick, I came up with an idea and a task for the level designers to do early on during the pre-production phase. The idea was that we would analyze a couple of games that had been of interest to members of the group and write down all of the features and gameplay mechanics that were used frequently in the game. After that was done, we would mark the features that our teachers wanted us to implement in yellow and the ones we considered to be essential for the game in green. Usually they were one and the same, but sometimes they were different things.


With these design documents in hand, we presented the different games to the group and we let them choose which one they wanted to use as a reference point. As it turns out, we were all passionate about the first person shooter genre and therefore a lot of heated discussions were present during the first week of the project. Efter the end of the second week however, the majority of the group voted for Quake as the better choice for a reference game.

An early mockup of the game created by Victor Petersson and Marie Flood

Roughly Interpreting John Romero

Once we had established Quake as our reference point for the project, us level designers used the knowledge gained from creating the design documents to start working on some top down layouts. We found that Quake maps were often created as individual rooms before they were connected to each other in various ways. Things like foreshadowing future rooms and revisiting old rooms were in our opinion very prominent in Quake, so we kept this in mind when we designed our maps.


We also noticed that Quake featured a lot of vertical gameplay as well as many open spaces with pickups and monsters. This was mainly what we had in mind when we created the first drafts of our layouts and we tried to keep it as basic and simple as possible since we knew we only had ten weeks to complete the levels.

What the library looked like in Unity during the white boxing stage

The second top down draft of the level

Creating a Library

The graphical artists created a bunch of untextured props early on so that the level designers could use them for white boxing the level layouts. Once we had created a representative layout using those props, all three of the level designers were teamed up with a graphical artist from the group who would look at the layout and visualize a unique environment based on the white boxing. I worked most closely with Marie Flood and we decided to make my map library-themed.


We traded ideas with each other and within a couple of weeks I had created a blocked out map with relatively good flow and pacing. During the remainder of the development process I mainly focused on iteration and decoration of the level.

"HELP, I'M LOST!"

While most of the playtesters agreed that the map was visually pleasing during late development, many were also frustrated with the layout since they repeatedly got lost while playing my level. The first thing we as a team did to try to fix this problem was to place out pipes in the rooms and corridors, hoping that they would subtly guide the player through the level. This was a technique we had seen being used in Mirror’s Edge and we thought “If it worked there, why not in our game?”. Turns out, the guiding pipes helped somewhat for a few people, but a vast majority of the players were still lost.


I figured the reason that this solution didn’t work in our game was that in Mirror’s Edge, the main threat arguably comes from miscalculating an environmental hint, which will cause you to either fall off a building or get shot by enemies. In our game however, the main threat comes in the form of enemies, and pickups help you defeat them. So, naturally, the focus of the player in our game should be directed towards the enemies, not the environment, since the environment poses no real threat.

An old version of the room where most of the playtesters got lost

The pipes that were supposed to guide the player

The Pipe Thing Didn't Work, What's Next?

Since the Mirror's Edge level design approach didn't work in our game, my next solution to the problem was to place out enemies and potions in almost every room and corridor in the map. I believed that this way, the player would more easily be able to get a sense of progression and hopefully also recognize a room based on the number of enemies or pickups in that room.


This did help somewhat, but it wasn’t enough. It especially didn't help the players that were stuck running in circles throughout the level, as they never encountered any new pickups. Many players still felt the underlying structure of the level was the problem and that the different rooms looked too much alike one another.

Away With the Old, In With the New

The final solution to the problem of players getting lost was to restructure the level layout and replace the walls and lights in many of the rooms. To start off, I removed a lot of mid-room props and walls in favor of bigger and more open surfaces in the different rooms. This gave the player an overview of each room as he or she stepped into the room for the first time, which I hoped would subtly imprint the layout of the room into that person's memory.


Secondly, I changed the position of most of the keys in my level so that the player would see the door that opened itself while the key was being picked up. I did this because my level was the first level in the game and therefore I needed a way to teach the player the game mechanics of picking up keys and unlocking doors. I felt this was a great way to do just that using only the level layout, while making it easier for the player to navigate through the level.

The key is right in front of the door

After I had restructured the level layout the graphical artists provided us with new wall textures. We used those to create a unique feel in each room that the player entered. I also placed out bright colored lights in front of keys and doors so that the player would, for example, see green lights nearby a green door and a green key. These lights may not always have been pretty, but they undeniably helped players get through the levels.


After these changes, the playtesters had no trouble navigating through the level and the players who were previously frustrated were now enjoying what I had done with it. This was a truly rewarding experience for me.

An example of one room before the changes...

...and after the changes

At this point, we still needed a lot of core features

Conflicts and Misunderstandings

I believed focusing on creating the core features first was necessary seeing as we were still unable to play the game as intended during the later development stages. The time constraints and the fact that the reference game issue was brought up a few weeks before the deadline were also part of the reason why I believed so.


However, a few team members felt that focusing too much on core features is demoralizing and damages the product since, to them, none of those core features would be a result of passionate work. They wanted to be able to work on things besides the core in order to stay motivated, while we wanted to work on the core first in order to create a playable game.


Unfortunately, despite us trying our best to solve the conflict through multiple meetings and talks with the teachers, the conflict was never fully solved.

Back To The Reference Game Issue

A couple of weeks before we were supposed to wrap up the game, a portion of our group expressed their concern regarding the reference game. They felt Quake was a game they didn’t feel motivated to use as a reference point and they also felt like switching reference games early on in the development process was a bad move. Even though some of them had expressed the importance of aiming low in terms of scope early on, they now felt like Quake as a reference point was setting the bar far too low.


At that point in time, we still didn’t have all of the features we deemed essential to create a first person shooter implemented into the game. Therefore I personally felt like changing the reference game again at this point in time would damage the final product rather than help it. However, I also emphasized the fact that Quake was just a reference point, meaning that once we had all of the core features that we needed, we could make whatever we wanted from there.

A screenshot of the final product

Closing Thoughts

Out of all the games I helped create during my time at The Game Assembly, this was the one with the most conflicts and frustrations. I think that this was the case largely because the first person shooter genre is a genre which we all feel really passionate about as a team, and we like different things. I also feel like a lot of the conflicts that arose later in the project could have been resolved much earlier on if we had openly discussed the problems we faced. However, I think the main reason why the conflicts were never fully solved was because we simply didn't have time to solve them. With more time, we might have been able to understand each others point of view better.


Despite all of those things mentioned above, it was also the game project that taught me the most about teamwork, iterative level design and understanding other people’s point of view. Once the feedback started rolling in from playtesters and I was challenged to meet player demands I truly felt like I could adapt to the needs and produce really cool content as a result. I walk away from this project a little more experienced than before and therefore I am happy with the result.

Screenshots


contact@erikleiram.com