Doomenstein

Overview

Role: Programmer
Genre: 3D FPS
Engine: Personal Engine in C++
Team Size: Myself
Development Time: 3 months

High Concept

Doomenstein is a 3D FPS multiplayer game where two players control their soldiers fighting against each other.

Core Mechanics

Multiplayer

The game allows two players to play at the same time. Only one player can use keyboard control and another player can use any Xbox controllers. The image below shows an example of a multiplayer waiting hall.

The problem of allowing multiplayer mode in Doomenstein is how to displace each player's screen correctly. I had to add split-screen support in my own engine that displays each screen with correct UI and synchronous gameplay. To solve this problem, I defined the whole game screen from 0 to 1 in both the x-axis and the y-axis. If the game has two players, each player will only have a viewport of 0.5 y-axis. Also, when rendering in-game UI such as weapon and HUD, it would apply the current x and y size to fit the split screens. The images below show a simple function that updates game cameras based on current player numbers and in-game split screens.

To support multiplayer combat, I created a new class called game mode that controls attacks, spawns, and winning/losing conditions. By doing this way, each player object does not need to access another player object's information, and the game mode class helps me debug combat bugs and provides better architecture management. Below is a screenshot of the game mode class and some functions that control players' interactions.

Various Weapons

In the game, each player has 4 different weapons to use, and each weapon has unique settings/animations. Players would be able to switch weapons using 1-4 on the keyboard or left/right trigger on Xbox controllers. The weapon system is data-driven, which allows me to change weapon settings without rebuilding the whole project and also provides different variables to change weapon settings. Below is a machine gun animation sprite with idle and firing animations.

The weapon system is completely data-driven that the game reads all weapon definitions from an XML file. The definition defines each weapon's render assets and firing settings. This data-driven approach helps me change weapon settings without rebuilding the game project and also balance weapon definition much quicker. The images below show a sample weapon definition in the XML file and reading XML function in the weapon definition class.

One challenge that I encountered when implementing the weapon system is that the weapon Plasma shoots a projectile to the target while the whole game is based on fake 2D physics. Since all actors' collisions are calculated by the 2D collision method, and projectiles should die once any parts hit an actor or the map, how to detect the top and bottom collision became a problem. To solve that, I defined a bottom collision height and a top collision height in the projectile definition and created a function that handles collisions among projectiles, other actors, and the map. The image below shows a function that handles the collision between projectiles and actors.

3D Sound

In the game, all sound effects (except background music) are 3D effects that players can hear where they come from and how far the sound is. I added a few more functions that allow the audio system in my engine to play a sound at a 3D position, update the sound position, and update listeners' position to change sound volume. This system allows players to identify sound position and distance, which improves the battle experience. The images attached below are the 3D sound functions I added to my engine.

Post Mortem

What Went Well

Was able to finish the game in 3 months.
All features and mechanics are fully functioning without bugs.
Added two more interesting weapons.

What Went Wrong

The framerate is lower than 60 FPS in the debug mode.
Didn't implement win/lose screens.
Didn't implement the respawn screen.

What Needs Work