PROJECT PURPOSE AND DESIGN GOALS
-
I wanted to explore how Non-Euclidean games affected the design of levels and it's impact on the player.
-
I hoped to gain a better understanding of level design theory and how it can aid in designing Non-Euclidean spaces.
-
I hoped to create a gameplay / level prototype in Unity/Unreal.
(Can be either a single large level that the player explores like the witness or multiple smaller levels like a puzzle game, where a game mechanic makes use of the non-Euclidean spaces)
INTRODUCTION
My project is going to be about exploring how Non-Euclidean geometry could be applied to level design theory in games. By creating a game prototype, I hope to investigate and research this idea through active development. I want my prototype to break away from convention Euclidean geometry and it will try and break one of the established Euclidean postulates.
WHY THIS PROJECT?
I want to work on this project for both personal and professional reasons:
-
For personal reasons, I want to work on my level design skills and hope to improve my understanding and application of designing video game levels
-
For professional reasons I can hope to provide more information to my field as a whole. It’s meant to be a research paper that explores and does a deep dive on level design theory and how much of it can applicable to Non-Euclidean spaces to justify if level design rules are universal and can be applicable to any space.
AIM OF PROJECT
The aim of my research is to explore how non-Euclidean geometry combined with level design theory can inform and impact how we design the spaces of games.
With that information I want to gain a better understanding of level design theory and how level design theory can aid in designing Non-Euclidean spaces.
I then deep dived into the research for my project, dividing it based on level design theory, Non-Euclidean games and Non-Euclidean Geometry research. I compiled all of my research and resources into a large mind map which I can reference at any time.
As I was researching I created small connections that led me to more questions. These connections created my research questions that I could explore during the course of my project.
I started by doing a deep dive into level design theory and what it encompasses. Level design was defined as a huge component of overall game design. From the spaces to the player plays in, to the challenges and objectives they had to solve. Level designers are responsible for creating the environments the player interacts with and guides them through it with a fun and interesting challenges.
For the simplicity of my research, I broke down all of my level design research into two categories:
-
Environment or space design. This is all about physically designing 2D or 3D spaces and actively creating environments for players to explore. Other points to mention would be composition, lighting and architecture.
-
Guiding, pacing and player flow. These include enemies, quests and challenges. Effectively filling the environments with gameplay elements or mechanics.
I then deep dived into how architecture could be used as a framework for level design. How environments and spaces are fundamentally designed has a lot of importance importance . Architecture makes use of the space the player maneuverers and creates an atmosphere that invokes emotion and guides the player. It can also be used for story telling and help build a narrative.
Further research also brought inspiration from art techniques specifically composition. Composing your scene to not only be appealing but also to convey all the information to the player is an important skill. By using composition techniques, it’ll be easier to control the focus of the scene and to guide the player to the main focal point
Next was to do research Non-Euclidean games and see what was common in them that defined them as Non-Euclidean games. • I wanted to identify any techniques or mechanics that were used to make them Non-Euclidean. Those games were:
-
Antichamber
-
Superliminal
-
Hyperbolica
Non-Euclidean research was the last thing I did. I did a surface level amount of research to get an understanding of what defines Non-Euclidean Geometry and to understand the theory behind it. • The main theory that constitutes Non-Euclidean geometry is by breaking one of the five Euclidean postulates. So I will try to focus on making a game that distorts one of the postulates to create a Non-Euclidean effect.
EARLY PROTOTYPING
DESIGN OF GAME
The game’s design was intended to be like “The Witness”. An open ended puzzle game where the player would have to use the Non-Euclidean aspect of the world to navigate and solve different puzzles.
By having a more puzzle focused game, I could do research on both how Non-Euclidean geometry affected the space and the game design during development.
DIFFERENT PROJECT IMPLEMENTATIONS
To try and attempt to figure out my core game’s experience I made different projects with different features and attempts to try and hone in on the game’s feeling.
I had three different projects when experimenting:
-
World bending shaders
-
This was my first testing phase to try and implement an effect that closely reflected a Non-Euclidean world. • This was also my first time trying to make shaders from scratch in Unity and played around with my own brand new shaders and with plug ins.
-
-
Portal implementation
-
The portal test was about making smooth portals into different areas by using stencil buffers. This test was to explore how I would be able to integrate this with my game
-
-
Forced perspective
-
This mechanic was inspired from Superliminal.
-
It’s a forced perspective mechanic where you can pick up an object and it’ll stay the same size based on how close or far you move it, but the object’s size will change to create the same perspective.
-
RESEARCH
CORE GAMEPLAY AND PLANNING
PLANNING
I decided on the direction of the project after my experimentation. I decided to go with my portal implementation. The world-bending shader wasn’t quite what I wanted. The forced perspective mechanic was too close to Superliminal and would be difficult to experiment with from a level design perspective.
The portal implementation is simple, but it allows for a lot of flexibility regarding level design. Mechanics can also be stacked on top of it to create interesting gameplay and allows for more creative game design.
I started by creating a simple game overview document. This had the basic design principles, gameplay loops and the over arching goal for the game. This helped me stay on track with the game vision and to narrow down what I wanted to accomplish with my project.
I started to fill in my notion homepage for the project. This is where I planned and kept track of my entire project.
It included last semester’s feedback, tracking supervisor meetings, play testing data and a calendar to mark my progress and goals.
Finally, I did a ton of project backend work such as source control with GitHub and doing any research for plugins that I might need for the project going forward. I specifically implemented ProBuilder and ProGrids which is a Unity plugin that’s great for prototyping levels and gray boxing. The plugin was meant to help me save time and be more precise when designing my levels.
CORE GAMEPLAY
When planning out the core gameplay, I was adamant to not want to create something like Portal or Antichamber. Both games used portals as well but in very different ways and I wanted to achieve the same effect.
I wanted physics-based puzzles to an extent, but I still wanted the feeling of impossible geometry so that way I could explore designing non-Euclidean spaces.
With that in mind I decided to have portals but to keep it different, I wanted to have my portals be attached to ceilings and walls. This would change the player’s orientation and gravity, but it would be a seamless change. This way I could create physic-based puzzles with gravity, but I could keep the impression of the world having impossible geometry.
From there I created the core gameplay by building a player controller, tweaking portals to be seamless and other gameplay elements (puzzle cube and door system) to create the components for the core gameplay.
LEVEL DESIGN
PLANNING AND DESIGN
I first started out by planning out the full scope of the game. This included things such as time to complete areas, how long the game might take and the absolute minimum game content wise. This was in case I needed to cut down on areas if the project got too large.
After deciding on the scope of the game I got around to planning the full tutorial level. This included the number of rooms, diagrams, level flow and pacing.
After the tutorial I had envisioned the level as the player entering a hub area where they could then access any puzzle. After completing those puzzles, they would reach the end.
Puzzle 1 which is called “efficiency” was meant to test the player’s resourcefulness. The idea was to solve the puzzle room using only one cube.
Puzzle 2 which is called “innovation” is about the player thinking outside the box when using the cubes.
(All of the planning and conceptualization can be found on my itch dev logs)
IMPLEMENTATION
After figuring out the design of the project I got to work on creating a block mesh of the tutorial area. I fleshed out a basic block mesh with the tutorial prefabs and by the end of the month I had a working, playable tutorial area. From there I started implementing block meshes for the Hub area, puzzle 1 and puzzle 2 zones.
One pieces of design feedback that I received which I took to heart was, people found it very difficult to identify the space around them because it looked very similar.
Even with landmarks and differentiating geometry the textures made the environment blend and it felt alienating to the player. It also made the space feel far bigger than it was because everything merged.
A solution was to color all the walls and floors so that way the environment would be more striking and easier for players to orient themselves
POLISHING
GAMEPLAY ELEMENTS
I added in some gameplay polish features that provides feedback to the player for certain actions.
For example, players had difficulty understanding when the cube had been picked up, so animations were added to give more feedback.
Another piece of gameplay feedback was creating pipes to the door and button to create a very clear trail. It helps identify what button is to what door and makes the world more alive.
ART ASSETS
The first stage of polish was placing the uncolored art assets. It helped give a better aesthetic of the world.
Additionally, since the art assets were modular, it helped in building interesting environments.
With the aesthetic being a sci-fi industrial zone, I couldn't just color the floors, walls and ceilings like in the previous versions.
To make it everything look consistent, Instead of coloring the whole environment I colored props and décor items in the room. It felt more subtle and was more appealing to the eye. It also served the gameplay function of using color to represent an object's gravity.
LIGHTING, POST PROCESSING AND AUDIO
The next element of polish was the lighting of the scene
In the previous image the level looks extremely dull, and while it serves gameplay functoriality it’s not visually appealing. It’s also because directional lighting is used and that’s what outdoor scenes.
To fix things I added in colored lighting to accent the scene. It helps with identifying the gravity a lot better. I also used indoor lighting techniques to make the environment more realistic.
Implemented post processing like bloom to make objects glow and stand out. I couldn’t add too much due to how portals are coded.
The last stage of polish was implementing the audio. I needed to add music and sound effects for all the in-game actions. I built an audio manager and sound class which would easily allow me to play sound and music at any point in time.
POST MORTEM
WHAT WENT RIGHT?
-
•The project was good in terms of development. From a level design and gameplay perspective the game came out well and can instill a non-Euclidean effect.
-
This is my first time making a 3D game solo, however having knowledge of Unity from previous projects have helped in speeding up my development greatly and allowed me to have a clear plan during the development cycle.
-
From a design and research perspective I was able to focus on what I wanted to complete. I’ve gained insight into the level design process and will be able to use this knowledge in the future.
-
WHAT WENT WRONG?
-
The project was over scoped. I wanted to add two more puzzle areas, an ending zone and cutscene. The content was massive, and I had put myself under a lot of pressure to create and polish all of it.
-
There was a hiccup during development as I ran into a render pipeline bug that made it difficult for me to add in post processing or the shaders I had made. As a result, I ended up working on my level design and pushing polish to the back of the project.
-
Finally, during the early stages of the project I had contracted Covid which put me out of commission for two weeks and took a massive hit to my motivation slowing down the project.
WHAT I LEARNT
-
I learnt an incredible amount during the project. I learnt about 3D game design and development. Developing for 3D environments and asset placement is a completely different experience to 2D games.
-
I learnt a lot during the research phase of the project. I gained a much stronger understanding of level design, Non-Euclidean geometry and got to play around with different ways to implement my concepts.
-
It’s also the first time I’ve done such a huge amount of research before starting a game project which really helps in brain storming and coming up with game ideas.
-
I learnt an incredible amount during the project. I learnt about 3D game design and development. Developing for 3D environments and asset placement is a completely different experience to 2D games.
-
•I also learnt a large amount of 3D level design skills and have developed better methodology skills that I can use in the future.
HOW I OVERCAME THEM
-
Regarding over scoping I spoke to my Supervisor and had asked for their opinion on the matter. Thankfully after speaking to my supervisor and re-considering I was able to res-scope accordingly and focus on polish rather than content. This kept me more focused and took off a lot of pressure I was feeling.
-
There was no real way to overcome the render pipeline problem other than tackle it head on. It was very problematic as my core mechanic the portals was causing the problem. However, since it was a plugin, I wasn’t sure how to convert it to the new pipeline. After weeks, I finally just asked the creator of the plugin for help to which I got a simple and prompt reply. That showed me I should have just asked for help earlier.
-
Finally, for the Covid issue I couldn’t do much but refocus my project planning. I went back to my notion and re-structured the project to fit the new timeline after Covid.