Game & Level Designer
SPILIOS
The Full Story of
MANCER
Mancer is a first-person-shooter that aimed to provide intense fast paced gameplay much like a "boomer-shooter" where there was no "ADS" (aim down sights) and the movement of the player is very fast relative to that of the enemies and the size levels. Due to the focus on movement fluidity the levels were iterated upon multiple times to provide adequate space and platforms for non-stop action.
The approach was to take inspiration from DOOM eternal and put a twist on it. Since the aim was to make the game a bit more accessible in terms of player age, I had to look past the gore as a reward that is prevalent in the DOOM franchise. Instead I changed the focus to the movement component, something that DOOM also does really well. Adapting the dash to provide a slight height advantage created many moments where players felt that they were performing well and were in control of the player character.
I also looked at a close relative to DOOM, namely Hexen to move away from the gore often associated with firearms and to reduce the amount of models required for the player weapon. Using a hand much like in Skyrim with varying particle effects, accompanied by unique sounds, proved efficient in conveying which weapon was equipped.
Finally for the enemies I looked at portal and its robotic elements. To me it was the perfect antithesis of the spells and magic that are prevalent in classical high fantasy usually set in medieval-like worlds. So it became natural to create enemies with this in focus. The main antagonist also favors robots over organic beings as well as science instead of magic.
For the world and levels I wanted to create a setting that went from more natural to eventually end up completely artificial. It is meant to represent the aftermath of an invasion by the antagonist where the player character has arrived too late to save that world. The level goes from containing remnants of a city to a lifeless robotic base. Since I wanted to showcase destruction I chose to work with unusual angles and less logical placement of platforms. The approach provided me with a lot of creative freedom.
Fireball
The Fireball was meant to serve as an area-of-effect, grenade launcher-like weapon that destroys walls. The weapon has medium-high damage and a low recovery rate. By placing destructible walls in combat arenas the player is encouraged to use it against the environment to open up new paths or platforms.
Arcane Shot
The Arcane shot is the basic attack that is always available and has no mana cost. It fires reliably straight for low damage and can be used over longer distances. When there is no mana to cast another spell the arcane shot is equipped by default. Shooting enemies at range allows the player to reduce enemy count before an encounter.
Lightning
The Lightning spell is used to open doors by shooting the nearby conductors that power them. It is also used in combat where it deals high damage on a single target enemy over a mid-range distance. The spell is balanced through the limited distance and high mana cost.
Spell Switching
Spells are switched with either the set button or the scroll function. This allows quick swapping to the intended weapon for the experienced player as well as a way to swap weapons while moving. Swapping is done nearly instantly to ensure fast paced gameplay and is represented by a change of color and a unique sound.
Mana
Mana can be used up and it automatically recovers with time. The mana for the fireball and lightning recover independently of each other after a set amount of time since it was last used. Separate mana bars for the spells are displayed in the HUD. Having no mana to cast the chosen spell switches to the arcane orb basic spell.
Dash
Dashing is a key mechanic in the game that allows the player to traverse otherwise impossible distances. Instead of utilizing coyote time there is a slight upward force that can push the player up on a platform that would otherwise be missed by a small amount. The dash is available once in the air and resets when the player touches the ground.
Core & Terminal
Destruction of the cores is the key to progressing in the game. Each core has a corresponding terminal that can be visible or hidden but always connected through a power cable that acts as a hint for its location. The core is exposed for a short time when the shield is lifted and resets if the timer runs out.
Smithis
The Smithis is the basic and long range enemy of the game. It has different behaviors depending on the distance to the player. At range it fires high damage projectiles that take time to charge up and at closer range it fires fast and low damaging projectiles. It has low health and can be used in numbers to challenge the player.
Wall Breaker
The Wall Breaker is a melee enemy that chases the player at a pace slightly lower than the player. It does high damage and knocks the player back if it gets within range. When the distance between the player and the Wall Breaker reaches a certain point, the Wall Breaker becomes much faster. It has high health and acts as a hindering component in combat that is both menacing and obstructs the vision of the player.
Drone
The Drone is a mid-range enemy that fires quick and unprecise laser beams towards the player. It can also strafe fire and tries to fly in random directions to avoid incoming fire. The Drone has medium health. Since the drone flies it can ignore cover the player might stand behind and forces the player to constantly move to stay alive.
Health
Health packs are scattered across the levels and smaller versions of these drop when enemies are destroyed. Depending on player health and enemy type these values are adjusted to balance combat. A low health player will see more health drop and strong enemies like the Wall Breaker always drops health. This provides a dependable source of health and promotes combat encounters.
First draft and First iteration
My plan was to establish the entirety of the game in the first draft for increased initial cohesion instead of having to puzzle together separate parts to make a linear level. This proved very effective for the team since it solidified our vision of the game and the flow of progression.
The first draft showed that movement was the main focus of player enjoyment and as such the first round of iteration focused a lot on adapting the LOS, spacing and available platforms to better match the movement. Since movement was easy to pick up and players found it easy to master in non-combat situations, hazardous areas were added to provide a non-combat challenge as well.
Environmental destruction was a large part of the game that began as simple fun for the player to become integrated in the exploration. Secrets, objectives and platforms were hidden behind breakable walls. This also served to make sure players switched between the available weapons and this in turn led to a larger variety of playstyles in combat.
Second Iteration and Final Product
Teaching the player during gameplay proved less effective than initially thought and this lead to a tutorial section that explained controls, distances, weapons and health mechanic. The whole game and flow of levels was adapted after this principle of earlier onboarding. This also allowed for longer playtime of "full gameplay" where the player understood the full arsenal at their disposal as well as the mechanics of the game.
These changes allowed the fast paced gameplay to become more apparent and became sought after by the players. To further increase the perceived intensity of the game, adaptive music was added. The music had three tiers of intensity where instruments were added as the token number for the engaging enemies was high enough. The tiers went from ambient -> drums added -> electric guitar added. This pushed players to engage larger groups of enemies to reach the final tier of music.
Navigation in indoor environments proved difficult when backtracking was enabled and a relatively low variation in meshes was present. To circumvent this, lighting in clearly distinct colors were added to each room as well as a lock mechanic that did not allow the player to backtrack. This enabled better seamless loading as well since a maximum of two areas were loaded at any moment.
Secret areas were also a large focus for the last iteration and clearer hints were added for the player to find these. A secret level as a reward for finding all secrets was also added. This level proved to be very popular amongst game testers and provided countless of hours of gameplay where testers could challenge each other to beat their respective scores.
Gameplay Mechanics Documentation
Using UML class diagrams as well as flowcharts proved a very efficient way of managing a larger amount of gameplay mechanics as well as conveying gameplay ideas to the rest of the team.
I made these diagrams for myself to begin with and quickly understood that they needed to be made with both designers and programmers in mind. Thus any variables were left out and the flowcharts were isolated as to not account for every possible interaction with other gameplay elements.
A flowchart for each unique gameplay mechanic was thus made. Below are some examples of these along with the primary UML class diagram used for the game.