Strata² is a first-person, horde shooter, bullet hell where you fight aliens while traversing the ever changing environment. Choose your loadout, upgrade your kit, kill enemies and ascend to beat the high score!
Platform | PC
Playtime | 15 Minutes
Engine | Unreal Engine
Download |
Duration | 6 weeks
Roles | Gameplay & Combat System design
Team Size | 9
RESPONSIBILITIES
-
Design and implement character movement.
-
Prototype, design, and implement weapons and abilities to allow multiple playstyles.
-
Calculate difficulty scaling equations and implementation.
-
Align the team to maintain a shared vision and cohesive development process.
-
Prototype and design level-building feature.
Summary
Strata2 followed and exceeded our original vision. I led the design and prototyping of some of the core systems, rapidly turning a concept into a playable experience within six weeks. I focused on building scalable, modular systems that we could iterate on quickly through constant playtesting, trying to break complex features into testable prototypes and refining them with player feedback.
The project resulted in not just a functional prototype, but a polished foundation for a dynamic combat experience.
Concept
Inspiration
It started with a conversation about the horde behaviour in Call of Duty Zombies, the way the AI can come from every direction and the player has small spaces to traverse and kite zombies. We wanted to combine that with flying enemies to create the dynamic combat we were aiming for.
While creating this power fantasy where enemies are coming from all angles and a level that builds itself uniquely in each game a video from Gustav Tilleby helped shape our mindset immensely. Environmental, game mode and playstyle "dynamism" was a concept we tried to honour.
Prototype
To achieve the vision we had for this game, we had to refine the parts that were hastily thrown together in the prototype. Below I will go through the following parts;
I will try to summarize both the outcome and the reasons behind certain decisions made during development. For the sake of brevity I have left out some of the detailed technical solutions so feel free to reach out if you have any questions.
Gameplay
Demo
Design goals
Character movement
I am fascinated by the fluent movement and ability to gather momentum in Deadlock enabled by behaviours in the different movement actions given to players. The Finals also does this in a beautiful way via their base movement mixed with class bound gadgets.
Both of these games are multiplayer games and therefore needs to be balanced for it. Strata, however, doesn´t need to make it fair or fun for an opponent. Instead the base movement can be filled with powerful movement techs.
The feeling of Surfing in Counter Strike was also a reference when designing the movement
Initially movement gadgets were to be part of the loadout selection and had their own shop in game. We decided to integrate all the movement gadgets into the core loadout after playtesting. It allowed players to express their playstyle in a more nuanced way and gave more tools available for traversal. It also empowered players and gave them more agency over gameplay, I will touch more on that later.
Technical
The goal of fluent movement where you can gather momentum we separated States and Actions
-States dictate the the world conditions such as acceleration, deceleration, gravity, max speed and air control. Which state the player is in can either allow or block available actions.
-Actions like dash, slide, grapple hook etc.. temporarily effect current variables set in the states.
This made it possible for us to decide and design how actions behave depending on what state the player is in and block different actions from being used together.
Nailing the core values of States, how Actions should behave, and what Actions should be allowed in tandem with each other came down to trial, playtesting and feedback. Here is a short video of gameplay showcasing some examples of action usage in sequence to traverse the level.
The confirmation of our design came when we started playtesting, new movement techniques were found almost every session. I want to thank Martin Annander for his lectures on systemic design, he taught me essential lessons to create games that give players agency over gameplay.
We got the advice to stop looking at ourselves as students and instead look at ourselves as developers. We took that to heart while making this game. We raised the bar of what "good enough" meant.
Retrospective - Movement
I'm proud of the system we built for movement. It is stable and consistent and dictating possible movement became easy.
Pro´s - Things i liked
-Provided consistency in an environment that was constantly shifting.
-Gave tools for players to be creative.
-Hit the goal we had for movement from the start.
Con´s - Things that could improve
-Dash felt more like a boost. Need to rework the equation that takes current velocity with dash value.
-Grapple hook, entry and exit logic needs some more work.
This is overall the best movement system I have designed and built to date. Before this project there laid a graveyard of underwhelming mediocrity. I want to thank Lucas Randers who coded the base in C++, he was amazing to work and theory craft with.
In the preproduction/prototyping phase we discussed both what type of game we wanted to make and our strengths as developers. The conclusion was to make a first-person shooter bullet hell and since we had no level designer we wanted a level that builds itself. Our environment would both pose as a threat and as a tool for the player.
-We worked a lot on responsive controls, fluid animation transitions and optimization.
-Predictable aim, we decided to go for projectiles rather than hit-scan.
-Targeted different playstyles with each weapon and ability.
"Player intention should accurately translate into the game"
Agency
Progression
"Meaningful selection of upgrades both in and out of game"
-We went for in game upgrades for the sake of scope. Every weapon, ability and ultimate has several upgrades. Randomly spawned in each ascension.
-Balanced possible progression and player power with increase increasing difficulty.
As a goal we had "make the player powerful". I thought that was a fine goal, it led to some good discussions and a realization that we don't know enough. We required more research, how do the other games do it?
Risk of Rain 2 inspired us a lot, it does many of things we want to accomplish extremply well.
Prashant Trivedi held a course in level design were he said something along the lines of "A player feels powerful when their intentions are accurately translated into cool outcomes".
I think that sentenced summarized our findings:
-
Agency - Player must feel in control.
-
Expression - Players must be able to express themselves .
-
Feedback - Players must get feedback thru visual, audio and UI that responds to player action.
-
Progression - Players must be able see and feel progression.
-
Challenge - Players must be challenged
All of these tie together, we nailed some parts, some could have been done better, and some were passed on for scope.
How do you make a player feel powerful?
Feedback
"Cause and effect. Player action should have immediate confirmation"
-Hit confirmation, blood VFX on enemies, hit markers and sound.
-Mini map, footsteps and danger indicators.
-Unique VFX and sound for each weapon, primary ability, and ultimate.
Expression
"Player should have the tools that allow expression of intention"
-Three weapons, AR, shotgun and dual wield pistols. Each with distinct characteristics to fit different playstyles.
-Abilities and ultimate's with unique behaviours and effects.
-Movement gadgets for traversal.
Challenge
"Fair telegraphed threats that behave in a predictable pattern"
-Introducing new enemy archetypes with different behaviours.
-Environmental events.
-Scaling enemies with numbers and combination of archetypes.
Retrospective - Gameplay
Making a player feel powerful was fun a challenge and led me down several paths that often tied together with different fileds of game development.
Pro´s - Things I liked
-
Agency - The kit given to the player allowed for seamless traversal with responsive controls that aligned with the goals we set out in the start.
-
Expression - Loadout selection, we managed to have several playstyles available that felt unique and interesting.
-
Challenge - We balanced the game for our target audience, gave them room in the start to discover the game and test abilities. Then we scaled it with new challenges, level events and more enemies that kept it feeling interesting.
Con´s - Things that could improve
-
Feedback
-The mini map was a band aid fix but didn't address the core problem: player focus stays in the centre of the screen and when it´s not, it goes towards score/time/cooldowns. Reworking this similar to Helldivers, with a compass and indicating if enemies are ahead or behind might have worked better.
-
Progression
-The shop system needed more work, some of the upgrades didn´t feel powerful or meaningful enough.
-Unlocking every gun and ability we had from the start was necessary since there was not that much content. The game would benefit greatly by adding unlockable weapons and refining upgrades characteristics.
-Adding achievements and statistics pages for players to witness their journey out of game aswel.
-Players not knowing enemy and block health, adding a feature to show damage numbers and make it possible to see health/shield while aiming at them.
Playing the game a lot, asking for feedback internally, having countless playtest sessions, and adding "polish" early got us to a state were our mechanics both felt and looked good.
Block Feature
Prototype
Since neither of us were particularly interested in level design, the goal when prototyping this feature was for it to build a randomly generated maze-like level during playtime.
I started brainstorming ideas that would create a dynamic and challenging level. A thought that stuck in my head was "what would it feel like to play in the bottom of Tetris". With that in mind I prototyped a system that would build the level much like Tetris. After adding basic AI, a gun, and abilities, we started testing it. Even in it´s bare form, it was fun. It shifted our thinking in regards to AI, combat and movement since verticality was introduced.
The prototype showcased the core idea and validated the game loop. To get it into a release ready state we needed to flesh out the behaviour, make it predictable while keeping the dangerous feeling to it.
Final Product
Technical
-
Spawner & single blocks.
-
Blocks remembers their neighbours when spawning.
-
Falls towards ground when none of it´s neighbours detects anything beneath.
-
Destroyed blocks get teleported away and reused.
-
Different states for falling into level and collapsing in chain.
-
Decals indicating landing position.
Customizing
We wanted to have the option to create level events; values that could be edited to create more content in an efficient way.
-
Spawn rate
-
Fall speed
-
Block chain max
-
Fall angle
-
"Hang time"
-
Collapse speed
Behaviour
In every level the blocks stack, fall, clear, and kills the player or enemies in the same way. The core foundation stays the same, a predictable pattern. The intention was to make it intuitive for players so they can interact with the environment for traversal and use it as a weapon.
During playtests we got feedback that blocks were coming out of nowhere. We needed to provide different indications that blocks were coming. We added decals, sound while in air, and landing sounds.
Players could now see and hear when blocks were coming, and they could also internalize a timer when the next block is suppose to land.
To make them feel even more alive we added a material on the blocks that turns visible when they travel through the dome that the player is restricted.
Retrospective - Blocks
I'm proud of creating this prototype, seeing it through the different iterations, and eventually were it ended up. It did exactly what we set out for it to do. It creates a unique level, inflicts chaos, allows for creativity, and behaves in a way that is intuitive.
Additions I would like to add:
-
Randomly spawning blocks with a different colour, that provide powerups when destroyed.
-
Randomly generated seeds, that can make a foundation of a level. Acting as another layer for level events.
-
Health indicators for blocks when aimed at, to make it easier to plan destruction.
-
Play with the idea for the player to able to edit and build blocks in run time.
I once again am going to refer to the relatively short video Making The Finals. It covers so many topics and inspired me tremendously. This feature was a tremendous challenge and Lucas Randers came in clutch again.
Enemy Design
When seeing the block mechanic come to life, it enforced our intent of having flying enemies. But it also introduced another hurdle, ground based enemies would wait idle and wait for the player to get back down.
We discussed many solutions, this clip from World War Z was brought up and gave us a clear goal. We needed to figure out a way for ground based enemies to update their nav mesh during runtime in order to create jump links.
It perfectly aligned with out vision for our game. On the ground enemies would make hordes, giving players that satisfying feeling of mowing down a group of enemies. While ascending vertically, drones would come from all angles above and enemies would slowly climb the environment in order to reach you.
In this part and all of the above me and Aditya Dash were constantly discussing and spit balling ideas. If you want read his process when designing the enemy archetypes you can click his name.
Flying Enemy Spawners
When it came to enemies I was mostly focused on how to create the feeling of a horde, player challenge, and scaling. Dogac Mengul was responsible for creating the spawning system, a way for us to scale difficulty, and introduce new enemy archetypes.
Spawners went through multiple iterations but not for the right reasons, I will touch more on that in the retrospective.
Customizable logic in the spawners:
-
Spawn Interval
-
Spawn Radius
-
Unlocking Time (Time that needs to pass in level for spawner to unlock).
-
Is active
-
Drone Offset behaviour
-
Option to change all of the above values depending on level
-
Enemy Type
As mentioned earlier we had Call of Duty as reference for the horde feeling. We also took inspiration from Vermentide 2, and how they use sound cues to assist awareness.
I tracked the spawners on a spreadsheet as cardinal directions. Balancing the amount of damage required with possible player DPS.
The idea was to make it harder in three different ways:
-
More Archetypes
-
Amount of enemies
-
Level Events
Ground Enemy Spawners
After the documentation and process was set up it came down to testing. A question we ran into was, how hard the game should be? With limited and contradicting feedback we refocused and play tested with the intended target audience.
We ended up with a rather forgiving start to level 1, with normal ground enemies that eventually scaled after a couple of minutes with drones. Giving Newer players a chance to get used to the controls and concept, while more veteran players got a chance to see what shops spawned.
Then ramping it up per ascension, and on every even ascension a level event is running.
Retrospective - Enemy
Pro´s - What I liked;
-Calculating DPS and trying to make equations that account for player scaling and enemy health was fun and scratched the mathematical part of my brain that had been docile for a while. There was definitely some guessing and trial and error involved.
-We found creative and efficient ways make the game harder without just increasing numbers.
Con´s - What should have been done better, spawning system;
-The first spawner iteration was created to spit out enemies on a timer, and as we went on we kept adding features and logic to it every time we discovered something we needed. Towards the end we were having problems with spawners not behaving in a way they should and it took several days to troubleshoot.
It was also a hassle to set up since I had to manually input every spawner with every value in each level.
Doing our due diligence and actively planning out what we needed for spawners, and creating a solid one from the start that would fit our needs. Making data tables for all the values like we did with shops, guns and abilities would have gained many hours of work.
Credits
Huge shoutout to every single member that took part in making this game, I had a blast!
Programmers;
Lucas Randers & Dogac Mengul.
Cinematic and Animation;
Oliver Delatajada, Albin Lundh and Hannes Dahlberg.
Design;
Aditya Dash, Athena Tran & Philip Neumaier.
Music;
Johan Samuelsson & Henrik Thomasson.
Links to come as I get them.