Skip to main content

Understanding Game Design for the Development of a Game Environment

Part of the Communications in Computer and Information Science book series (CCIS,volume 713)

Abstract

In this paper, we will show the importance of understanding game design concepts when creating a game level. In this case, we are using the creation of a game level that has being made as a final project of an undergraduate student, to show the results of this paper. We used three methodologies to help them in this process, coming from these sources: the paper “It’s Only a Game”, the book “The Art of Game Design: A Book of Lenses”, and the paper called “MDA: A Formal Approach to Game Design and Game Research”.

Keywords

  • Game design
  • Game level
  • MDA

1 Introduction

The system implemented at the design course for undergraduate students of our university starts with students having multiple classes with a great variety in ideas and approaches with the intention of acquiring knowledge as broad as possible in regard to overall design. After two semesters of introduction, all students move into a more general group of mandatory classes alongside the important part of the course which is the work on projects, where the students start to focus more on practical activities than on learning theories.

The projects are designed to give an introduction of basic concepts and theory behind them and quickly moving into making the student learn and work with the tools used in the market like Autodesk 3Ds Max, Autodesk Motion Builder, Mudbox, Unreal Engine 4 and others and then moving on to actual designing and creating their own projects.

Taking this approach allows the students to become good at learning how to model and texture in those programs, how to operate between them in the required workflow and learn how to work in groups of usually two to four people, and the dynamics behind it.

The consequences behind this is that, even though some of the results became really good projects, some of them were not of great quality or were even left unfinished. So we looked at the reasons behind it, and most of the times, it was the lack of a better knowledge in the theory behind the process of designing and creating a project, which didn’t allow the student to execute the project from scratch. One of the problems the students would encounter was getting stuck in some area and not knowing how to proceed accordantly. Another was not taking into account how other areas of the project could influence the decision on its overall design, creating problems late in development that could not be solved easily. The final result was a project which, although not a failure, would not offer the target audience the emotional experience that we were looking for.

The conclusion was that we had great students that knew how to properly use the tools available to them and, eventually when working as a professional, they would be able to follow orders to achieve whatever was asked from them. However, when asked to design projects and ideas, the lack of theory and knowledge in other areas such as, cinematography, communication, creative writing, visual arts, among others, have caused problems to some students. Although we know that it is hard for the undergraduate student to master all these elements, the challenge is to make them understand, because the lack of understanding on how they all work together and influence each other was the problem to be solved to create an emotional experience for the player.

That’s the main issue we had with undergraduate students, we still want them to learn how to work on the required tools and the process of how to work in group, but, most important, we needed them to be able to design ideas and projects of their own. To reach the goals proposed in this paper, we needed the students to know how to make proper decisions in the process of developing a game asset while taking into account how all those different areas influence the design and execution of the project. To do this, we looked into theories that we could apply to improve our projects, and the result was an adaptation of different methodologies.

This adaptation was then first applied into a student under graduation final project. The result of this project is being presented and used as an example of this paper and the main reference of a project for future undergraduate students.

2 Methodology

We began our process looking first at MDA: A Formal Approach to Game Design and Game Research [1]. We used this methodology to clarify and reinforce the interactive process of developers, making it easier to decompose the study and design behind games in general by showing the difference in views between the players and developers and how important is the relationship of both, since one change in either side will influence the way the other sees things and affect the overall design of the game. It uses three categories to demonstrate this relationship: Mechanics, Dynamics and Aesthetics, the former being what developers see more clearly and the latter being what the player experience in the game. We can also look at this process through what is referred to as lens. These will give us insights and questions to be answered necessarily in all these areas when designing a game.

So to help us out with this part of the process we used the book The Art of Game Design: a Book of Lenses [2]. The idea behind it was to not only give a checklist of questions that the students should mark, but to improve the “quality” of the questioning made by the students during the development cycle. So instead of keep wondering why something “feels” off, or “doesn’t look right” and in the end, going around in circles and taking actions that end up being based on feelings, now they have a clear direction on how and with what to question their work, when trying to solve a problem and to proceed properly.

Alongside the idea of looking through lens, the author also decomposes the game design further than what we’ve seen before in MDA by separating it in four categories: Mechanics, Technology, Story and Aesthetics. The interaction process between the player and developer is still the same as MDA, but this further breaking down of elements made it easier to visualize things for the undergraduate students. After working with these four elements, we decided that it would be more helpful to add another element that the author called “Theme”. This helps the assets being created to be something important because it gives the student a centralized element to their work, since now every choice made must reinforce the main theme of the game and consequently that affects every element being designed in the project.

The importance here was to show to the undergraduate student, when designing a game, that all the elements do not sustain by themselves; they are always being influenced by others and the coherence between all of them is one element that distinguishes a great design from a bad one.

We found out that only these two mixed together wasn’t enough. We had a clear way on how to decompose the student’s projects and a clear way to question it and have supportive content for the students to look out for, but we still did not have a clear process of workflow to fit in our schedule, to help out the students to organize during a semester.

In order to solve this issue, we took Jim Wallman’s article It’s Only A Game [3] as a reference for a design cycle with the Formal Loop idea from Jesse Schell [2] so that we could implement it in our process to give the students a pipeline of production. The basic idea of this pipeline was to create a process and loops inside of it, the basic guide line of it worked like this:

  • Decide objectives and problems

  • Brainstorm it

  • Define one idea

  • Examine the idea with design elements

  • Test the design

  • Prototype the idea if approved

  • Get feedback and restart the cycle

Using this we gave to the students a cycle of progression while creating feedbacks necessary at each step made, enabling the possibility of showing to the student the results of their own decision, no matter good or bad [3]. This will also allow the process to become dynamic and give the students time to go back and forth to adapt the design choices. This process gives a better support for the choices made by the student mitigating the risk of problems during late progress in the development cycle.

With these ideas mixed together and adapted to your university system, we expect to improve the environment of our classes and increase the chances of a good project being designed and executed by our students.

3 The Project

3.1 Idea Behind the Project

The focus of this project has always been to learn the process behind designing a brand new 3D game level, and the purpose of doing that was to leave it as a reference for future undergraduate students who are considering going into the game industry and want to learn from it. We have learned and documented as much knowledge and theory as possible regarding game design in order to develop this project.

To be able to do so, we knew we would need to theorize a brand new game, inspired by others, sure, and also use it to restrain and set limitations to the level in 3D for the game we were actually creating inside Unreal Engine 4 so that the final product could be a good emotional and fun experience to the players.

3.2 The Project Itself

When this project was at its beginning, the ideas and concepts behind the methodology weren’t fully integrated with the entire process. It was something that was incorporated and learned throughout the entire project, which explains why we had so much going back and forth in relation to the idea, and also multiple versions of it until coming up with one to move forward.

In the beginning there were two clear ideas, the first one was the creation of a dungeon for a MMORPG inspired in the likes of World of Warcraft and Final Fantasy XIV. At first this idea came up simply because it was “an amazing idea” or it would “look amazing in Unreal Engine 4” and other very/simple motives. When actually trying to apply the methodology to that idea, it became clear that this project would require a really high complex study behind story, visual and audio design that would influence directly upon the layout and design of the dungeon while also having to take in account the mechanics. In the end, this idea was too complex to be carried out by one person in a period of 4–5 months, at least in the way we were proposing to do it made.

The second idea was the creation of an alternative level for a game called Rocket League. With that idea however, one problems came up: the game was created and is supported by Unreal Engine in version 3. It’s outdated since version 4 was released with a complete rewrite with major updates. Since we want our students to use the latest technologies, there were no reason to go back to an old version. Despite this problem, there were still good arguments in favor of that idea as it is a not complex situation story-wise. Another is that the level itself isn’t as big as an entire dungeon, the aesthetics behind it is also less problematic because of the natural less complex situation. All of that would make it easier to see and apply the methodology.

So, the first cycle of this idea was an adaptation for a new sport mode which became a beach arena with volley as its game, with a location inspired by the volley arena on the beach of Rio de Janeiro but replacing the players by cars. Here we had the pillars of the methodology, technology would always be Unreal Engine 4 and dictated by that, there would be a simple story behind it, the aesthetics would be more towards a cartoon with reality tendencies, and the mechanics would be set by the rules of volley itself and adapted as feedback given.

We designed the layout of this arena in 2D and went after some feedback and the results were mixed about the idea. But the overall feelings were that it was a gimmick experience for them and with little interest from people to play volley since it’s not a popular sport like soccer is, and also that it was still too much like Rocket League as a game and not just an inspiration from it.

So we took the idea back to the drawing board and started to work on it again. And then, we changed it to being undersea, with the possibility to go above sea-level walking through the walls of the arena, which would create a very dynamic level design. This idea was quickly discarded for the risk of not being able to accomplish it in the Unreal Engine 4 for hardware limitation and because the studio of Rocket League announced a similar map was being worked on for the game itself. In the meantime, the sport as a mechanic idea was becoming more of a problem than a solution to our design of an arena level. Most of the times we were put in a situation where soccer would be the only fun experience according to the feedback we were receiving. If we followed that idea, we would just be a recreation of Rocket League in Unreal Engine 4 or could even be interpreted as a pure copy of the game, but with a different aesthetics and with lower budget. So we had to change the fundamentals of our game’s the mechanics of our game so that it would create different possibilities to design our assets for the game.

We remembered an alternative game mode from Monster Truck Madness 2. It created a small arena for the players to fight to maintain themselves on the platform centralized in the level which had a ramp and the idea was to survive the longest time on top of it, while trying to push other players away from the platform. The player with highest score would win.

Now we had the aesthetics of an arena from Rocket League with the extra platform added as a mechanic alongside the game mode rules into the things we should account for when creating the assets required for the level. And here is where we realized that the theme had to play a higher role in the project. To centralized the ideas, we had to set in stone that everything from now on had to reinforce the simple theme of “King of The Hill”, which was the fight between the players to maintain themselves in the highest position possible during the game.

Now we needed to answer a simple question “What’s the best location that will help to increase the experience of the game while reinforcing the now main theme of King of The Hill?”

A beach didn’t make sense, a random place in the jungle was kind of pointless and had no purpose in increasing the experience of the player. That’s when the story played a role in the creation of the level. After going back and forth with questioning and receiving feedback, we came across the idea of why not make the match between the players some sort of a television event that people are watching inside the game universe?

Now we had decided on all the parameters proposed by [2], as follow:

  • Mechanics: Destroy and push people away from the platform using cars in the arena.

  • Technology: Unreal Engine 4 would be the limitation of how far we could go.

  • Story: The match was a TV show for the universe created.

  • Aesthetics: Tendencies close to reality but with a cartoon touch.

  • Theme: Fight for the King of the Hill Title.

Once the parameters for our game level were established, we began to brainstorm the new place we would create. So for a television show, it was decided that the best was an isolated place, with viability for cameras and lights everywhere. We didn’t want public around the location, given the limitation that this would create upon Unreal Engine 4, taking resources from other places just to have a public, didn’t seem worth it. And because the idea was of an exclusive television show, we decided not to have public.

The first idea agreed upon was a game level of an isolated island where you could see silhouette of mountains and cities in the far background and the vast ocean, with cameras around the arena and huge posts of lights source to give the fight more of a spectacular show vibe. It would be a small island, but with heights so players could see the ocean, and in it there was the arena similar to the basic one from Rocket League, but instead of having goals on both sides, it would just be a platform in the middle of it, and spread around the maps, there would be boosters you could gather, just like in Rocket League, to give you a boost in speed making it easier to push/destroy enemy players off the platform. We gave this idea another cycle of feedback and it was received positively and we moved on to prototyping the assets so we could test it out as soon as possible.

So we created the island with the tools Unreal Engine 4, and during this process, we tested it out multiple different layouts for the island, really high heights, very low one close to the waters, shape of the island, we even tested it out a couple of height maps that were originated from islands in the real world. Together with creating the island’s level design, we had created a small group of sample placeholder’s objects, that were used as a reference for the actual arena inside the said island, so at the same time we could have an idea of how the arena would look like on those islands.

After multiples islands and arena combination were tested, we encountered a fairly problematic situation, every time we tested the prototype, it always gave the player a Rocket League’s different mode vibe, instead of a game inspired by it. We went back to looking at the fundamentals applied to the idea to question ourselves why that was happening, and we found out that it was not actual a gameplay mechanic that was giving this experience to the player; it was actually the limits imposed by the arena and its shape and form that were too similar to Rocket League. As a consequence, we had to do something to the arena and adapt the game level to that change in order to change this experience.

First we tried out just removing the arena walls and giving the player free reign on the island, but then the same limitation the walls had, would happen again on the border of the island, to avoid people from falling off. It worked a bit better, but it wasn’t ideal to have invisible walls doing this job. Another problem was that the island was created to be a plain field inside the arena, and outside of it, the field was irregular, with ups and downs in the terrain so as not to give the island a plain surface. And when we tried to play with that irregular terrain, a whole new dynamic of gameplay and consequences showed up for us to deal with in order to be able to move on with the island idea.

Second, and what worked best, was actually removing the island of the game, and expanding the actual platform that the players were supposed to fight for, and creating a smaller one in the middle of it, in a slightly higher position. And while testing, we liked the idea of adding the danger of falling off experience to the player. So, in this new level, the player could actually fall off, and the consequences of it are still up to debate because of how balanced the game has to be, but the possibility is now there and now we have a design that doesn’t give the player a rocket league feel and experience. The mechanics and aesthetics of the game have changed.

That’s why we needed to create cycles of test and later prototypes for feedback, so we could change and adapt as early as possible, since this amount of changing would not be possible if the entire island and arena were already fully modeled and texturized inside Unreal Engine 4. That would have been almost an entire work discarded or even worse, we would have to accept that reality where very few things would be changeable.

With the methodology applied, we were able to move on and produce the game level by following the procedures of modeling, texturing and changing the environment accordantly, making small aesthetics adjustment along the way until the assets and aesthetics were completed and the project itself was able to receive actual gameplay mechanics.

4 Conclusion

This project showcases the reasons why we need to encourage the project to be based on methodologies and studies of game design, otherwise the project would not have developed the way it did, and without it, we would only have developed a good looking arena, with close resemblance to Rocket League, and people might have looked at it and considered it just a good looking game level.

Following this method, we ended up with an arena that is, based upon given theory, ready to be implemented in the rest of the development process of an actual complete game if we wanted to do so.

With this result, we agreed inside the university that this methodology is an improvement upon projects done before this one, and that as the first project being done under this supervision, we still need to learn more to continue improving the quality of the work being done, including this one, it always has some room to improve and grow a little more using this methodology, and that’s what we will continue to work with.

References

  1. Hunicke, R., LeBlanc, M., Zubek, R.: MDA: a formal approach to game design and game research. In: Game Design and Tuning Workshop at Game Developers Conference 2001–2004

    Google Scholar 

  2. Schell, J.: The Art of Game Design a Book of Lenses, 2nd edn. CRC Press Taylor & Francis Group, Boca Raton (2008)

    Google Scholar 

  3. Wallman, J.: It’s only a game. In: Chestnut Lodge Wargames Group Fourth Annual Conference, October 1995

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to André Salomão .

Editor information

Editors and Affiliations

Rights and permissions

Reprints and Permissions

Copyright information

© 2017 Springer International Publishing AG

About this paper

Cite this paper

Salomão, A., Andaló, F., Horn Vieira, M.L. (2017). Understanding Game Design for the Development of a Game Environment. In: Stephanidis, C. (eds) HCI International 2017 – Posters' Extended Abstracts. HCI 2017. Communications in Computer and Information Science, vol 713. Springer, Cham. https://doi.org/10.1007/978-3-319-58750-9_10

Download citation

  • DOI: https://doi.org/10.1007/978-3-319-58750-9_10

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-319-58749-3

  • Online ISBN: 978-3-319-58750-9

  • eBook Packages: Computer ScienceComputer Science (R0)