During our first month, the team focused on porting over our demo from Unity to the Open 3D Engine (O3DE). As we close out the month of June, everything except for one or two minor polish pieces (such as VFX) has been ported over to O3DE. While we certainly had our roadblocks—learning a brand-new engine on the fly while porting your work into it isn’t the easiest thing to do—we’re now at a point where we’re familiar with the engine and about to hit the ground running on developing more levels.

Team Highlights

Transitioning to a new engine can be quite challenging, but lead programmer AJ led the charge and created helpful tutorial documentation so that all members could have a guide for installing from source. If any member had an issue with their installation, AJ went above and beyond to help them resolve it.

Development Updates

Gameplay Development

This month, we implemented all existing gameplay features. These include:

• Combat mechanics for all three states
• Puzzle and environmental mechanics for the gas state
• Puzzle tools (levers, pressure plates)
• Enemy pathfinding, albeit still a little finicky

Art and Design

State of Matter is a low-poly, first-person puzzler, set in a dystopian sci-fi setting. The main events of the game occur on an asteroid that a group of scientists has established a mining facility on. The player’s journey will take them through the different areas of this facility, including its mines, research stations, and power generators. Aesthetically, the facility’s advanced technology contrasts with the seemingly barren asteroid. The abandoned nature of the facility, however, is eerily complementary to the void of space that surrounds it.

• We created several new crates, a ship, character head, freight elevator. We also begun work on skeleton, and several different ice models.

• We iterated on Walls & Terrain.

• We created new skybox for opening level
• Fuel cells were given different considerations for the opening level. They will now be introduced in a small way to the player, and later puzzles will utilize them with more depth.

Programming

• This month for programming, we implemented:
  • Player movement and controls
  • HUD/UI integration
  • Gun mechanics and firing
  • Enemy pathfinding and attacking
  • Environmental and puzzle tool interaction

• A lot of work towards the start of the month was focused on figuring out the different ways to program in the engine. Most of our programming has been done using C++, and there were some hurdles at first getting used to writing code in a different language and engine than we were previously. However, we quickly overcame these hurdles. Once we were able to do a couple deep dives into the engine and documentation, we were able to figure out how to do things like writing our own EBuses and reflecting nodes to the script canvas for quick and simple UI and audio implementations.
• Our code architecture went through a couple changes throughout the month. As we became more familiar with the engine, we optimized a lot of our code in order to more efficiently handle linking and decrease the number of components necessary. Where we may have had 3 or 4 scripts in the Unity demo, we’ve condensed these down to one component that can handle all logic and different buses that handle all communication between different entities and their components. It wasn’t all just porting. As we ported, we took opportunities to refactor algorithms and drastically increase flexibility of various components we had. To be honest, all our code, in general, feels more reliable now, especially with EBuses, as compared to their Unity counterparts.

Sound and Music

• Most of this month was educational, as progress was greatly halted by initial audio system integration through WWise. Initially learning the following took up a majority of the time following engine functionality:
  • The audio system is currently done through WWise Sound Banks alongside O3DE’s Audio Triggers and Script Canvas.
• Time was also spent figuring out the best system for attaching specific audio to prefabs and such, which was concluded to be through Nodes grabbable from the Script Canvas.

The end of the month has been adding some basic audio and the music from the Unity project including the Main theme, Main Menu soundtrack, Level 1 soundtrack, movement sounds, and various weapon functions.

• On the side of the creation of the audio assets themselves, more music is currently in the works, as we have The Descent soundtrack done and awaiting implementation. Other sound effects are also being created and altered as the team continues to provide feedback on them.
• The goal of the music in level 1 is to introduce the feel of the game to the player, giving them the sense of having arrived at a deserted place shrouded in mystery and secrets. Sound effects also have a focus on having sci-fi feelings to them to effectively immerse the player into the world of this game.

Challenges & Solutions

Primary technical challenges we faced throughout the month include:

• Engine onboarding difficulties
  • Learning how to program with O3DE took the most amount of time by a large margin; understanding its component system and different APIs, a little bit of refamiliarization with C++ for those of us who had not used the language in a while, and most importantly, understanding the EBus system.
  • At first, we began implementing features using a similar method to how we’d do so in Unity: using FindComponent and keeping pointers to other entities and components. Once we understood the EBus system and how to create our own EBuses, however, we circled back to these initial implementations and revamped them to use the system, which ended up cleaning up the code and optimizing it very nicely.
  • Engine crashes and features we wish we had
    • O3DE is still very much in development, so these are to be expected. The main time sink came from periodic engine crashes we can’t always seem to reproduce reliably, and various features of the engine / APIs we expected to be there but were not. A good example of this is setting the height of a primitive collider, such as a capsule or a cylinder. We could not find anything in the code that had this capability, so we had to do a workaround that involved duplicating the collider in question, reducing its height, then toggling between them.

• Audio unfortunately took longer than expected to progress due to the lack of an existing audio system within the default O3DE engine. Various options were considered, and we ultimately ended up choosing Wwise. Its integration was not easy to implement when compared to other Gems and that general process, and much time was spent brute forcing for potential answers. Eventually, with the help of O3DE developers in the Discord server, we figured out how to rebuild the engine from source to include Wwise, which led to more required trial and error to get full functionality on everybody’s machines again. After integration, figuring out how to properly have audio play within the O3DE editor took longer than preferred due to the lack of documentation. Again, with experimentation and looking through engine code, we continue to learn how to use Wwise and O3DE’s audio components to their fullest so our music and sound FX play in-game and interact w/ gameplay seamlessly.
• Figuring out how to build a Game Release from the project also ate up a lot of our time.