ECS Survivors: A Deep Dive into the Latest Updates and Architectural Overhaul

It’s been a whirlwind seven months since the last major update to ECS Survivors, and I’m thrilled to finally share the fruits of our labor with you all. Life, as it often does, threw a few curveballs my way, but I’m back with a vengeance, ready to unveil the exciting new features that have been brewing in the ECS Survivors universe.

Part VII – Tilemaps: Breathing Life into the Game World

One of the most significant changes in this update is the introduction of tilemaps, a fundamental component of most 2D platformers and survivors-like games. Gone are the days of dull, gray backgrounds. We’re now diving into intricately designed levels, thanks to the fantastic Tiled tool.

Using Tiled, we can quickly create complex levels and embed metadata, making it a breeze to identify collidable objects like map edges. To load these tilemap files, we’ve integrated the tmxlite library, which has streamlined our development process immensely.

Initially, we created a new tile instance for each tile specified in the original file and drew them individually. The same logic applied to tilemap colliders – we created a box collider for each tile with embedded metadata. However, we soon realized this approach wasn’t optimal, especially as map sizes increased.

To address this, we implemented a clever solution: we draw each tile once, take a “screenshot” using Raylib’s RenderTexture, and from that point on, we only need to draw the screenshot. This reduces draw calls to just one, significantly improving performance. For dynamic elements like destroyable boxes or opening doors, we can still draw them individually since there will be very few.

The second issue we tackled was performance-hungry collision detection. In a 64×64 tilemap, we could end up with 4096 new colliders – an unacceptable number for performance. To solve this, we implemented a greedy meshing algorithm to maximize the surface area of colliders. This drastically reduces the number of colliders, especially in larger areas like map boundaries.

Part VIII – Accelerated Collisions: Scaling Up for Success

As we ramp up the difficulty in ECS Survivors by introducing thousands of enemies, our previous quadratic collision detection and resolution implementation simply won’t cut it. Enter spatial hashing grids – a simple yet efficient acceleration method for collision lookups.

In our previous system, detecting collisions for one entity involved checks with every other entity (n x n). With spatial hashing grids, we split the area into multiple cells, and now, looking for a collision with an entity only checks for other entities within its neighboring cells. This approach has allowed us to scale from 600 to 7000 colliders, resulting in more than a 10x performance gain!

Part IX – Levelling Up: Adding Progression to the Mix

What’s a survivors-like game without some form of progression? In ECS Survivors, we’ve implemented a levelling system where players gain experience by defeating enemies. Once enough experience is accumulated, players get to pick from three random power-ups.

For now, we’ve kept the levelling choices fixed, but this will likely change as we introduce more abilities and ways to enhance them. It’s a simple yet effective system that adds depth to the gameplay experience.

Part X – Yet Another Refactor: Architectural Overhaul

This update took the most time and nearly burned me out. After finishing the levelling up feature, I wanted to work on more gameplay elements, particularly procedural generation. However, to implement this, I needed a tool to build procedural generation rules. This, in turn, required another refactor of my code to allow for a window manager that could be used for both the game and other applications.

I ended up creating a layered architecture, separating my code into distinct modules. This approach allows for better organization and the potential to create separate GitHub repositories for each module in the future, avoiding tight coupling.

Here’s a brief overview of the changes:

1. File Hierarchy and CMake Configuration: I reorganized the file hierarchy to generate different libraries and build targets. This modular approach makes it more explicit and harder to import from a module that shouldn’t be used.

2. Applications: I created separate apps using the same new modules I refactored. This includes a base Application class, a GraphicalApplication class, and specific applications like ECS-Survivors, an Editor for ECS-Survivors, and a basic headless app.

3. Logging: Every good editor needs logging, so I implemented a simple logger. The logger is a singleton where you can register a “sink” – an anonymous function that handles the logged message and other info.

Conclusion: The Journey Continues

There are still many changes I haven’t covered in this blog post, and there’s likely more to come. I tried to bite off more than I could chew, especially in the later updates, which slowed down my overall progress. However, I believe ECS Survivors is in a good enough state for me to work on new features.

Looking forward, I need to focus on one thing at a time. What’s next? I’m not quite sure yet. I’d love to focus on gameplay elements – maybe a melee attack would be nice to have. The key is to keep the scope simple and manageable.

As always, you can play the latest build on Itch.io and access the source code on GitHub. Until next time, happy gaming!

Tags: ECS Survivors, Tilemaps, Collision Detection, Procedural Generation, Game Development, C++, Raylib, Tiled, tmxlite, Spatial Hashing, Greedy Meshing, Levelling System, Architecture, CMake, Logging

Viral Phrases:

• “Breathing life into the game world”
• “Scaling up for success”
• “Adding progression to the mix”
• “Architectural overhaul”
• “The journey continues”
• “Focus on one thing at a time”
• “Keep the scope simple and manageable”
• “Happy gaming!”
• “7 months in the making”
• “From dull gray to intricately designed levels”
• “More than a 10x performance gain!”
• “A layered approach to game development”
• “Modular design for future flexibility”
• “Logging: Every good editor needs it”
• “The never-ending side quests of game development”

,