Eclipse is a first person high-octane speedrunning game where you'll have to kill the enemies and escape as fast as you can. Climb the leaderboards and impose your name getting the 'Devil Time' to show your friends how it's done.
Platform | PC
Playtime | 10 Minutes
Engine | Unity 5
Download |
Duration | 5 Weeks
Roles | Combat & 3C Designer, Product Owner
Team Size | 19
RESPONSIBILITIES
-
Designed and balanced the ranged and melee combat systems.
-
Collaborated closely with animators to ensure effective implementation on both player and enemy animations.
-
Implemented, balanced and designed the character movement. Worked together with programmers, level and UX designers to enhance the overall experience.
-
Planning tasks, sprints and setting timelines to meet deadlines outlined in the project scope.
-
Aligning the team to maintain a shared vision and cohesive development process.
Concept
The goal was to create a fast-paced speedrunning game with a mix of brutality, drawing inspiration from games like I am your beast and Neon white, with a touch of Doom. The focus is on free-flowing movement, mechanically intense gameplay, and rewarding finishers.
The movement and the intentions behind it
After researching movement technicalities, the speed running genre, and looking at our reference games I Am Your Beast with the kill and forget style combat ground based combat, and Neon white that focuses on timing and perfecting the movement of a run.
Our first iteration of movement looked like;
-
Responsive directional controls
-
Low friction when landing
-
A lot of air control
Taking advantage of the first-person perspective to allow instant directional changes without the limitations of body animations, preserving immersion.
Preserve momentum and promote fast, responsive movement.
We made sure that we had a gym level that would let us test out different scenarios and as soon as we had movement we started testing it out internally.
The Character movement of Eclipse
Summary
I focused on making sure the player felt fast and unencumbered. I also wanted to reward players for flashy plays, encouraging exciting gameplay.
The movement went through several iterations and technical additions along the way. Through a constant feedback loop from our QA and UX that ran internal and external playtest, close collaboration with amazing programmers and animators we validated and scraped ideas throughout the project.
Internal playtest gave us good feedback and gave us some new problems to figure out. A major question was: How do we tackle edges, walls, roofs and make platforming more "fun"?
After setting the base values we got working on turning the things that was slowing the character down into small speed boosts and movement tech instead.
These are some of the fun mechanics we ended up with
-
Roof boost
-
Coyote time
-
Wall surfing
Every time we added to movement, we always asked ourselves: "Does this improve the players flow through the level"?
Finishers
This one was especially hard to scrap, as it was a big part of the pitch we had for this game. By the time we were scrapping it had a lot of the movement done, combat was starting to take shape and you could see and feel the soul of a speed running game start to take place. We were internally playing and sending screenshots of the best runs we got in our discord.
This was also the thing a good friend of mine was the most excited to be working on. It was suppose to tie into your soul meter (I will explain that in a moment) but as soon as we put the prototype into the game it slowed the game down and ruined the flow.
Even thought we all knew it was going to be hard to make work, we were stubborn and kept working on it, trying to make it fit. However it did end up getting scrapped. What you see in the video is how far we got before giving up on the concept.
During the education the term "kill your darlings" got thrown around a lot, I remember us sitting late in school that Friday and feeling crushed as we killed the finishers. Knowing it was the right thing to do didn't help.
"Lucio" Wall-Running
This unintended mechanic went unnoticed for a couple of days and was a side effect of wall surfing. Once discovered it was termed Lucio wall-running.
We played around with it a lot, trying to make it work because it fit so well with our vision of the game's movement. However, it also completely ruined the entire level design, so it had to be scrapped.
Scrapped concepts
Combat Design
Summary
We wanted the player to have the tools to slice through enemies while traversing the level without breaking the flow.
The goal was to tie movement and combat together, making enemies part of the puzzle of finding the best route.
Soul meter
The intention was to reward players for finding routes where you effectively killed enemies continuedly. But also limiting the use of the dagger warp ability. Making players have to plan out their usage of the throwing dagger. Only gaining souls/health when killing an enemy with the dagger.
Bringing what you could call health and mana bar together also meant that players only had to pay attention to one bar in an already attention heavy game.
While playtesting this we got a lot of mixed feedback and caused some disagreement. But we had to remind ourself that who we are making this game for, speed runners.
Melee/ranged attack and blink ability
The goal was to give the player different tools to kill the enemy, to enable routes we might not have even thought of.
While still being aligned with our design of the Soul meter.
-
Melee attack
-
Ranged shot
-
Dagger warp
The damage, soul regained, projectile speeds, drop off and "weakened enemies / finishers" were iterated, changed and polished a number of times. Usually by adding or subtracting the value 50% back and forth and listening to feedback and looking at playtests.
Challenges
Making combat feel fast and unencumbered was not easy. We struggled with collision boxes for both the melee and throwing dagger, replicating intuitive gravity and feedback when you connect with a stab, throw or a bow shot. Through iteration, testing and addition we manage to get it to a state that left players with the intended experience.
Working with feedback
Summary
We as a team worked around the idea of an entry point. For this short of a project it was crucial to get everything that was done implemented and tested as soon as possible. Iteration and getting feedback was a huge part why this project became the game that it is.
Feedback
While looking at playtest and taking the feedback from players it became clear that there will always be a lot of opinions. Navigating feedback was tricky, sometimes you realized flaws in your design, improvements that can be made or that issues should resolve when the coming feature is implemented.
We often approached the feedback with a session as a team, we would sit down as designers and discuss topics that we thought were important and dismiss what we thought was not relevant or worth the effort to be more effective.
Playtest
We held countless playtest, externally, internally, with first timers and people that had tested from the start but was not part of the dev team.
Later we shifted to almost exclusively test with our target audience. Testing with a broader audience gave great general and quality of life feedback, but when it got to gameplay and testing mechanics. Having your target audience play the game gave a lot better data and feedback.
I worked close with the QA to ensure the features that needed testing was tested and crafted forms to follow up on players reaction to it.
Project Managment
Summary
I had lead teams before, but never in game development. I knew going into this project that we were going to be short on time, have people missing during events and have to coordinate people from 4 different locations. Together with our producer Christian Carlos who played a vital role in managing both the team atmosphere and the product backlog, we oversaw a production where we met the goal we set the first day of the project
"We want to be proud of both the product and how it was made".
I hope we get to work together again in the industry one day.
My responsibilities
-
Create and maintain a clear vision of the game.
-
Aligning the game's vision with the work of the development team.
-
Coordinate 20 developers over 5 locations.
-
Playtest and validate progress.
-
Manage and prioritize the product backlog with producer.
-
Ensure the project stays true to the original scope.
-
Coordinate with external supervisors.
Structure
I created milestones and together with the producer set up sprints to meet our deadlines. Held short summary meetings to show progress to the entire team. Estimated timelines for tasks with each developer to evaluate workload.
Atmosphere
Playing some games together as a team before production started, getting to know each other, having Friday afternoon to play games we drew inspiration from and show work we were excited about all helped to maintain a pleasant atmosphere even when debates got heated, things were breaking or when the deadline started to come closer. During the development there were a couple of questionable placeholders and fun easter eggs that was a positive side effect of a good working environment.
Retrospecive
What went well
Clear vision & ambition
From the start, the team established a clear and well-defined vision for the game, supported by strong game references. The fact the many team members were familiar with the genre contributed to a shared understanding of the intended player experience and helped align design decisions throughout the development.
Entry point
We prioritized achieving an early playable build, which allowed us to test, gather feedback, and iterate quickly. This approach enable rapid improvement of core mechanics, early identification of bugs, and more informed decision-making throughout the project.
Effective Scope & Feature Cuts
We demonstrated discipline in cutting mechanics that did not meet the games design or that introduced unnecessary complexity or workload. Candid discussions and feedback-driven evaluations allowed us to make objective decisions, ensuring that the final feature set supported the game's core vision and remained in-scope with our constraints.
What could have been done better
Documentation
Some design decisions were communicated verbally or made informally during development. While this was partly inevitable given the short timeline, what was avoidable was the lack of brief, structure documentation outlining the decision, the change, and the reasons behind it.. This gap occasionally led to confusion when implementing or revisiting features and ultimately cost the team valuable development time.
Feature Cuts
Even though we did eventually end up cutting certain features, significant time were put into making them work when there were clear indicators of immersion breaking gameplay. Holding on to an idea / imagination of how a feature will fit into the game while the game itself is telling you that it is not working takes admitting defeat.