Don't sleep in your classes, or else...
- Introduction
Hello, I'm Victor, Deadalu's Programmer and Game Designer, on this page you will find in detail about my job in the development of the game and my experiences on doing so.
- What is Deadalus?
Deadalus is a first-person psychological horror game set in a university. The player must deal with the pressure of waking up alone in the middle of the night, dealing with an unknown enemy and looking for a way out of the maze that the university has turned into.
Pre Production
- Motivation
Deadalus was a college project in which the whole class and teachers worked together, its purpose was to serve as the course completion project for all students, in addition to serving as experience of what it would be like to work in a large-scale game on the market, it was also planned that the game would be presented to all university students at the end of the semester, where it would also be seen by the sponsors who helped with development costs. The project started in the last semester of the Digital Games course at Estácio de Sá in 2018.
- Concept
The concept of Deadalus is: "Would it be possible to sleep in class and wake up in another plane being pursued by an unknown being?". This idea stuck because the class wanted a game that would take place in an environment similar to our university, and it was also decided by everyone that it would be a horror game.
The name Deadalus came from the combination of the Greek mythology character Daedalus and the word 'dead', to give the idea of a labyrinth of death.
Game Design
- Planning
As soon as the production started I worked as one of the game designers of the project, my main function was to document the game design document and the wiki, in addition to planning and balacing mechanics and features for the game.
Initially I chose the role of game designer because I had a lot of interest in exercising it in a team project, as previously I had only worked as a programmer or a 2D artist.
- Change of roles
After a few months of production, I ended up changing roles for several reasons and started to work as a programmer. The main reason was the fact that the programming team was having several problems to the point that the game didn't work, and I offered to help, and with that our teacher and producer thought it would be better to change my role and become a game designer for the project himself, so that we could have a complete game at the end of the semester. Another reason was that I did not like the role of game designer and feel that my decisions did not have a real impact on the project, as I realized that a large part of the team was guided by the script for the production and not by the design documentation that I created.
Despite being a negative experience at the time, it didn't make me lose the desire to continue working as a designer on other projects.
Documentation example.
Wiki used during development.
Programming.
- Replanning
At some point during development, the game wasn't running properly and it was incomplete, it was then that I suggested recreating the code from scratch to avoid future problems and guarantee a functional result, this was a somewhat risky decision and it required a redesign of the schedule of production.
Today I can say that it was the correct decision and that it yielded good results, since the game was completed on time and is playable from start to finish.
- Progressions / Shifting Rooms
One of my roles was to implement the game's progression. How will the player go from the beginning of the game to the end? He must find keys, tapes and solve puzzles to progress. The biggest challenge facing the implementation of the game progression was the implementation of the shifting rooms, the first time the player listen to each of the tapes, when leaving the radio room he will find himself in a mysterious and completely different place from the corridor he came from, giving the impression that the scenario is constantly changing. To create the shifting rooms it was necessary to activate, deactivate and move certain parts of the scene without the player noticing.
- Cutscenes
Deadalus cutscenes are not particularly complex, just a sequence of actions that the enemy (Janitor) does while the player watches, an example can be seen at the beginning of the game where the Janitor stops sweeping the floor, looks back and disappears when the lights go out. Creating these cutscenes in technical terms is nothing more than instantiating the Janitor without artificial intelligence and giving a sequence of timed actions so he moves, animates and the scene reacts accordingly, all within a coroutine.
- Janitor
Undoubtedly the biggest challenge I faced was the creation of the Janitor and his artificial intelligence, this includes: Instantiating the Janitor when he is supposed to be present, creating a NavMesh and code that makes him detect and chase the player under set conditions and make him work on cutscenes.
The way the Janitor works is very simple, he is blind and because of this he is not affected by field of vision or lighting, but by sounds (for example the player running) and heat (for example fire created by the player). Therefore, all objects that can emit some sound or heat have a script with a numerical value that represents an order of priority to be detected. If the player is running and has a detection value of 5, but a window was recently broken nearby and has a value of 10, then the Caretaker will be attracted by the sound of the glass until it stops and then start looking for the player again or anything with a high value.
Working with artificial intelligence was something new and challenging, especially when it came to integrating other mechanics with the Janitor, for example opening doors and real-time changes to the scenario. Fortunately I was able to learn a lot and I would certainly be able to create something better next time.
Shifting Room example.
Script of a Shifting Room.
Cutscene example.
Script of a cutscene.
Pathfinding example.
NavMesh example.
Conclusion
Deadalus was a successful project in general, it fulfilled the goal of being a complete game made by the whole class in a professional way, it was presented by the students and had a good overall reception by the sponsors.
I can say that what I learned the most with this project was time management and teamwork, and despite several problems and frustrations during the course of the project I had a great enjoyment and I could have the experience I would have working in a professional game project.