Introduction
Hello wonderful people from the internet!
We’ve already heard a lot about game design but now it’s time for the real fun – programming! Game development is a wild ride – one part creative vision, one part technical wizardry, and about five parts debugging things that really should work but just… don’t. We’ve been making steady progress on our indie Metroidvania, and today, we want to take you behind the scenes for a deep dive into the current state of development. So don’t let us waste any more time and talk about how things are shaping up!
What’s in Store?
We’ve been focusing on some key systems that will define the core experience of our game:
- Player Controller – Making sure movement feels snappy, satisfying, and fun, because if controlling the character isn’t enjoyable, nothing else really matters.
- Gear Skill System – Giving you powerful abilities through the items you equip, so you can tailor your playstyle however you like.
- Enemies & AI – Crafting a flexible and expandable enemy system (so we can throw all kinds of terrifying creatures at you with ease).
- Co-Op – Because everything’s more fun with a friend…
So grab your favorite beverage, settle in, and let’s break it all down!
Player Controller and Rotation
The player controller (PC) is in pretty good shape as of this month. Our first iteration didn’t quite meet our expectations and was also rated as „good but a bit strange“ by test players (blog link: here). Now, we have customized the PC – especially the jump mechanics – to allow for greater control and precision. We drew inspiration from several sources, with the main influence being a GDC talk about ‘Math for Game Devs’ (link). While we didn’t directly use the method presented there, we adapted it with Unity physics. This gave us valuable insights that we applied to our own challenges.
The big challenge in designing a PC isn’t the individual components – a jump can be programmed quickly, and running with acceleration isn’t particularly difficult. However, the real challenge lies in combining these components in a way that feels right for the specific game. In our case, rotation adds another layer of complexity, directly influencing the overall gameplay experience.
Rotation is a lot of fun and offers new possibilities for unique gameplay, but it requires careful consideration in programming. A simple example is the transition from jump to fall state. Typically, this is done by checking if the vertical speed is negative – if so, the body is falling. However, when the character is upside down, a negative vertical velocity simply means they are jumping. This requires recalculating components and defining a different ‘negative’ velocity for transitions. While this issue is relatively easy to solve, the complexity increases as systems become more intricate – particularly with enemy AI implementation.
In the coming weeks, we will continue working on simplifying this system so that scripts can be applied to game objects, enabling them to handle rotation automatically.
Gear Skill
The itemization or gear system will be a central part of our Metroidvania. There will be many abilities with diverse equipment possibilities and a variety of bonuses.
To manage this complexity, we need an in-engine editor that allows us to adjust stats, set models/VFX/sounds, and create gear efficiently. That’s why we’ve spent a lot of time developing the Gear Editor. As is common in game development, feedback, unfun gameplay elements, inefficient code approaches, or even new ideas from the game designer can change a system drastically. This led us to redesign our editor to better suit our needs. Before the change, the editor was more focused on runes (where the rune determined the ability, which in turn defined the gear). After feedback and iteration, we restructured the system.
How the Gear System Works:
(For a deep dive, click here: Itemization Deep Dive)
After defeating enemies or exploring the world, players will find gear. Each piece of gear has an ability, random bonuses, and three rune slots. The bonuses – such as increased damage – are random and modify the player’s stats. To maintain balance, we implemented visualization tools that allow our game designer to check and fine-tune thousands of bonus combinations without extensive playtesting. The tricky part is the rune system.
Runes modify the ability’s stats or behavior, and generalizing them in an editor is challenging. For example, consider a projectile-based ability. One rune might increase the number of projectiles, another might cause attacks to pull enemies toward the impact point, and yet another might add an AoE damage effect. These mechanics create awesome gameplay possibilities but are difficult to generalize in an editor. Nonetheless, we are confident that we’ll be able to implement a robust solution in the coming weeks – hopefully!
Why Even Build an Editor?
The greatest advantage of an in-engine editor is that it streamlines gear creation. Instead of manually assembling different components, the editor ensures a structured workflow while automatically handling the underlying code. It also prevents errors by enforcing step-by-step validation, flagging missing or incorrect elements before they become problems in the game.
Enemies
This milestone was all about fighting and combat. And to not only fight against the air, you obviously need some dummies to punch against. That’s why we took a shot at our enemy system! Let’s get started, shall we?
The Enemy System: Building a Strong Foundation
Enemies are more than just obstacles in a Metroidvania – they’re the key to pacing, challenge, and player progression. A well-designed enemy can turn a simple platforming section into a thrilling gauntlet or make you feel like an absolute legend after a hard-fought victory. That’s why we spent a lot of time laying the groundwork for a system that is flexible, maintainable, and scalable – because, let’s be honest, nobody wants to spend hours reworking code every time we introduce a new enemy.
Maintainability and Flexibility
We wanted a system where adding new enemies doesn’t feel like reinventing the wheel every time. Instead of hardcoding behaviors for each enemy (which, trust us, gets messy fast), we developed a modular system that allows us to swap out and tweak enemy behaviors easily. Think of it like LEGO bricks. You can mix and match different AI behaviors to create unique enemies without rewriting everything from scratch.
Scalability
Right now, we have one enemy fully implemented, but thanks to our system, adding new ones will be smooth and efficient. This means more enemy variety without unnecessary headaches and extra coffee! Though, let’s be honest, the coffee’s happening either way.
Trying Out Unity 6’s Visual Behavior Trees
Unity 6 introduced an updated Unity Behaviour system featuring a visual behavior tree, and we couldn’t resist giving it a try. Why?
- Behavior trees make designing enemy AI more intuitive and modular – No more trying to untangle spaghetti code just to make an enemy jump.
- Debugging and tweaking behaviors is easier compared to traditional scripting – Because nobody enjoys scrolling through hundreds of lines of code to figure out why an enemy is breakdancing instead of attacking.
So far, we’re loving the flexibility it provides, and it’s making enemy design a much smoother process. Plus, it’s kind of fun dragging nodes around and watching things come to life (until they turn against us, but that’s a problem for future us).
Co-Op
As many of you know, we’re developing our game with co-op in mind! Yes, that means you won’t have to explore the world alone – you can drag a friend along for the adventure. Multiplayer adds a whole new layer of complexity, but we’re committed to making it work seamlessly.
Keeping Co-Op Development in Sync with Singleplayer
A common mistake in game development is designing singleplayer first and then hastily slapping multiplayer on top as an afterthought. We want to avoid that at all costs! Instead of treating co-op like a late-game DLC, we’re developing it alongside our core gameplay systems. This means everything – from enemy AI to puzzle mechanics – is being built with multiplayer in mind from the start. This way, we won’t have to rework massive chunks of code later hopefully saving us from a lot of sleepless nights and existential crises.
Challenges & Learning Curve
Let’s be real – multiplayer development is a beast. And we’re new to it! Getting two players to experience the game in perfect sync over the internet is a whole different ball game than just making a solid singleplayer experience. Here are some of the fun challenges we’re tackling:
Enemy Synchronization – Making sure that both players see enemies moving and attacking at the same time. Because nothing ruins immersion like an enemy that’s already dead on your friend’s screen but still trying to kill you on yours.
Network Lag – Ever played a game where your friend teleports across the map like a ghost? Yeah, we don’t want that. We’re working hard on keeping everything smooth and responsive.
Co-Op Balance – Making sure multiplayer isn’t just “singleplayer but easier.” Enemies, puzzles, and exploration should feel just as exciting with two players as they do alone.
What’s Next for Co-Op?
✔ Testing networked interactions – Ensuring smooth enemy and player syncing so your co-op buddy doesn’t randomly phase through walls (unless that’s a feature).
✔ Internal playtests – We’re gearing up to see how it all plays out in real-time. Spoiler: It will involve a lot of debugging, awkward desync moments, and probably some memes. It’s a long road, but we’re confident we’ll get there. Multiplayer might be one of our biggest challenges, but it’s also one of the most exciting features we’re working on. And of course, your feedback will be super valuable once we get co-op into a testable state! Until then, we’d love to have you along for the ride – whether you’re here to cheer us on or just to witness the inevitable chaos.
Whats next?
This was our first tech-oriented blog post, and it definitely won’t be our last! We love sharing our progress and keeping you updated on the state of the game across all departments. If you want to learn more, have advice, or need help, feel free to join our Discord. We’re always happy to welcome new people to our community!
ENSO Out
