Econauts

Marine Exploration Game

Role:

Lead Designer (Team of 13)

Assignment:

Prototype for Client

Programs:

Crest Water System, Unity 5 & Visual Studio

Group Project

When it comes to creating a client requested video game in a group of 13 people, with the added pressure as a student, no project could have been more fitting than Econauts!

The stakes were increased, I was to lead the design team and we were going to be operating an entirely new system called the Crest Water System in Unity as well.

The team thoroughly enjoyed the experience and managed to deliver the project on time and to spec.

Surprisingly, the easiest part of the entire project was implementing the sounds we created, without breaking any of the systems – Phew!

Please feel free to download and play Econauts here:

Econauts

Econauts Game Trailer

Take a look at the gameplay trailer below! And then walk through the process from pre-production all the way into post-production

Pre-Production

The process of creating ‘Econauts’ started with three group presentations pitched to the client: KD Marine, with ideas of game look, feel, mechanics, systems, and much more all aimed at delivering the vision to get players engaged with Ocean Conservation.

After the presentations, the team was tasked with implementing and iterating on the feedback of the stakeholders that was understood to best suit the vision.
- This meant needing to take ideas, systems, and features from all three groups, and adding them into a game design document with heavy explanation for the impact on each one.
- The main thing was making sure the game flow would be able to work without breaking and while still fitting into the vision.

In this instance, I was tasked with creating workflow charts of the features and systems needed for the core gameplay loops, and to link these game flows to each other with a clear vision on how these would fit into the title fluidly.

Full System Map

The decision was made to incorporate a free-roaming sandbox of a catamaran into a marine wilderness with mini-game elements layered out throughout the world to earn progression through the title.
Taking inspiration from well-known games would give our title the feeling that the younger generation enjoys to get them hooked using mechanics they are already familiar with.
In this case, we were heavily inspired by GTA's mission system, as well as Bioshock's narrative story system of radio communication to drive the linear direction for the player.

We knew we could only get a low poly idea of the look for the title with the time we had, but felt we could make it colourful and eye-catching enough to keep players engaged.

The system map starts at the main menu and flows into the rest of the game features, systems, and mechanics.
The team also required some help in creating wireframes for the UI design.

Below are a few screenshots of the GDD with additions from the different groups, which were split into coders, designers, 3D graphics, and UI/UX design.

Game Design Document Screenshots

Wireframe of the Pause Menu

Production

The main areas we overlooked that led to a lot of pressure were scope, UI/UX, and implementing design systems to code efficiently. These are big problems to go over, so I'll try break it down a little easier below:

As expected, we experienced a few problems as a team ranging from scripts overwriting each other, struggling to implement game builds together, UI breaking game flow, and getting the mini-games to work independently from the free roam, but still having the consistency to flow between the two features without errors occurring.

Mini-Games

Mini-Games were 50% the main mechanic to ‘Econauts’ meaning they were ultimately a big part of the holistic game.
The issues we found most difficult was integrating the mini-games into the main build or the free roam. Seamlessly moving from boat to mini-games was not always, well… seamless. Creating the mini-games amongst three coders was relatively simple but once we began adding them to the game, a lot of functions had to be adjusted to compensate for the other function requirements.
We added elements such as points for completing the mini-games or events. Doing poorly at the mini-games meant a lot of cross script referencing was required. Sometimes getting the flow or transition into mini-games would break both mechanics entirely! Arrhhh!

After a week and a half, we managed to get everything implemented and working but bugs still pursued… There were issues such as points being doubled due to quests being replayed (Ooops! Didn’t think of that!). This seemed to have a domino effect as we'd code the quest to be unavailable after completion, only for that to impact the rest of the mini-games and make them unplayable.

As we worked through the problems one by one, we slowly started to develop a lot of polish to the game overall. At the stage of hand in, we still found that we had a variety of issues, such as UI panels being activated when they weren’t requested by the player. The remaining issues came into free roam aspects and the decisions the player would make which at times would cause a glitch in the game. One of the most pressing issues we found was a mini-game breaking the free roam. The only real way to fix a lot of these issues was to sit down and work through the code meticulously, using ‘for loops’ and ‘booleans’ to overcome the issues when two situations like this would coincide to create a game bug.

Drone Mode Problems

Although there is no glitch here, it provides as an example of how confusing the transition could be for programmers to get right. In this mini-game, the player uses the E key to trigger the mini-game but we found that this wouldn’t interact with the free roam drone which could be activated by pressing Q. This would often create an overlap of the same function in the game and thus have an ever-looping effect of a fading screen.

Eventually, we took a unified approach of only working on one build of the game at a time meaning a lot of files being passed around the coders, which eventually turned into an implementation team of myself and the lead developer (winning!)
- Although, this was only a small win; we had other issues to fix as well

The design served well when going back to the system map to see which areas we needed to work on and where they needed to connect to one another
- However, one area we had overlooked during documentation is how several systems would work when all activated at the same time even though we had never intended for that to be possible.

Free Roam

Free roam was an amazing playable mechanic to have in ‘Econauts’ but often it seemed to counter act the workability of the mini-games.

For example, in playing the game, players would encounter fadeaway screens that lead to the mini-game. At times, this would be our worst problem as the fadeaway would either ruin the timing of the transition or play twice and sometimes bug the game. Coding this in took a lot of time and pressure. Luckily, we found work arounds where we could separate the timing of the fadeaway only into the action of the fadeaway screen taking place, instead of it effecting each mini-game individually. Often, mini-games were able to be triggered more than and it took a lot of boolean variables and checks to make sure the transition was smooth. Free roam would especially become difficult when mini-games were having to be played a few times due to the player triggering the event often.
Overall we hoped to make an impactful game where the player was able to witness wild life in its natural habitat. At times, the sea life would act poorly depending on the players actions. Raycasts became fairly useful for detecting objects in front of moving animals and eventually the beauty of the animations from wildlife would work fairly well according to the environment.
The free roam aspect is one of the best features I've had the pleasure of working on in a game and I look forward to the next time I'll be able to work on this mechanic.

Audio Glitch

At points it would be the audio that would lead to a poor gaming experience.
Two audio files overlapping, causing one to restart every frame after completion of the mini game. We found the issue was the audio file was only supposed to play after the transition back into free roam, however because it plays before that period, it is consistently in a loop of trying to play at the first iteration of where it was instantiated - a jarring bug.

Due to the issues we experienced on the programming side, we were unable to reiterate design we had intended on as we didn't have a lot of time left and the roadmap had not been adapted for any sort of QA testing as we were just delivering a prototype within three weeks.
Looking back, I would have got the design team together to start looking at the system map and looking at areas where we were seeing faults so we could look for common areas to focus on, address, and reiterate into the system map with updated information.

The game feel came out very well with focus on character and control working the best, however the camera had limited range of motion and the player found themselves fighting with the camera often leading to frustration.
- This needed to be reworked to give the player more ability to feel and observe the world around them with character control being entirely separate all together.
- We made the mistake of having the camera feel too static.

Certain areas of UI within the title were also too prevalent and "in the face" of the player making the audio cues somewhat redundant but it also broke the flow of gameplay up too much during the onboarding section of the game
Due to the UI team being a different group, we failed to incorporate their work into the system map which meant our biggest failure where the design fell apart was the flow between UI and normal gameplay.

Main Menu

There are no earlier iterations of the main menu but there were impactful issues with getting the main menu to work as requested.

As you can see from the video, the menu works in a way where each button moves the camera on a track and settles at a specific part of the interior of the boat. This took a while to get right due to the usage of Cinemachine and the Dolly Track system. The UI Team coding this process was complex and coincided often with the ideas that were put together from the team leader. This became a worry to implement into the main build of the game in the final 48 hours before hand in. Luckily, we managed to create what was needed with relative ease by using the game engine inspector options. However we had limited time to include working audio sliders and added buttons that directly related to the main game. This threw off the flow of the system map that had been created for the GDD. Regardless, the main menu was a phenomenal learning process and was entirely a different sort of menu style than we had undertaken before.

The biggest problem with programming we seemed to face was that fixing one problem with the logic we had, would ultimately lead to more problems because we were constantly referencing different functions from other scripts
- This would usually impact negatively on the purpose those scripts seemed to serve.
- It made implementing design a little more difficult when looking at the scope we had set within the three weeks

Post-Production

The project, in the long run, was largely successful despite struggling with strict timelines, but we aren't here to go over the successes, and rather what could have worked better and what decisions I would have made during production that I only realised during the post-mortem.

Video Documentation of the Game Creation

In the end, the Game Design Document needed to be heavily adjusted to include a variety of different changes to the features and systems through development.
Knowing this, a discussion could have happened to add less mechanics and features in the mini-game area to accomadate for this or taken them out as a whole during the production cycle.

The game ended up having a lot of bugs which were easy to find through destructive testing
- Mashing buttons, for example, was a great way to destroy the flow between gameplay and UI.
A discussion on a candidate build would have been good to have with a focus of a few days to test for bugs, issues, and any other areas of concern which in this case was definitely the flow of UI to gameplay and vice versa.

Some code overlapped, wrote over each other, and caused problems like fade-outs from certain mini-games to happen twice leading to a progression blocker or an exploit for the economy system.
- Due to this, we had to go back into the programming a few times to fix these game-breaking issues but little did we know how much time we were going to lose as a whole.
We should have looked at simplifying the systems for the programmers to work on and then build up the complexity if we had more time.
- Constant communication needed to occur between designers and programmers with the potential to even partner up designers to specific coders working on their mechanics.

At times it was something small like certain triggers not working correctly and failing to start certain events either due to miscommunication with the system map or broken code.
- We were fortunate that none of these were blockers and were easy enough to fix after hand-in date.

Communication was great overall for the project however the UI/UX team definitely needed to be part of the design team discussions to avoid the biggest issues occurring.
On top of this, the development team had a lot of input for some of the designs as well which ended up causing a small disparity in terms of scope.
- A designer should be as open to hearing out the 21st piece of feedback as the first and we made errors of brushing this off and putting the coders under pressure.

End

And that's it for the making of Econauts! I was happy with the final product but I learned more from what it could have been in the end. The short comings were big lessons and showed how vitally important teamwork and communication is to the success of any game project!

Thank you for going through it and if you'd like to try out the build, consider getting it from the button at the top of the page.