Openchamp Devlog 3

Openchamp Devlog 3

Date: 11/17/2025

Hey everyone, What a week! Openchamp is moving a lot right now, and we've made some significant architectural decisions that will shape the future of the project and community. These changes also meant we didn't hit our alpha deadline, but I'm confident that the direction we're taking will result in a much more robust and maintainable codebase in the long run, along with moving in the direction we had originally wanted.

Announcements

Alpha Deadline Pushback

We've made the decision to push back the alpha deadline by 2 weeks. This wasn't an easy call, but we're rewriting the gameserver in C++, and unfortunately that takes time.

I know what you're thinking—"Cody, why would you do this right now?"

  • Architectural Clarity
  • ENet LowLevel Control for things like Fog of War
  • Server is faster, smaller, more efficient and more versitile.

A massive amount of time has been spent debugging our multiplayer sessions due to godot's high level api and multiplayer implementation just not meeting our needs for such a network-reliant game. By separating our server and gamecode into distinct applications, we establish a clear boundary between what runs on the server versus what the client manages. Additionally, this decision allows our ECS refactor to bring back our external asset manager plugin for Godot and implement a standardized file format system to sync client and server data. No more version mismatches or desync issues due to conflicting code paths (once it's fully implemented).

Development Progress

This week has been incredibly productive despite the architectural pivot. Shout out to @Ploinky for all the C++ and architectural help! Here's what we've accomplished:

Game Client / Server

  • Pathfinding: Implemented Server-Side A* pathfinding, allowing minions and champions to navigate the map intelligently
  • True ECS: Our GameServer uses a proper ECS system, with services like the NavigationService running on separate threads to keep our systems smooth and reliable.
  • Entity Spawning & Synchronization: Built a solid foundation for spawning entities and keeping them synchronized across the network
  • Player Spawning: Players can now spawn into the game world properly
  • Champion & Item Templates: Created several templates for both champions and items to kickstart our content pipeline
  • Native TSCN map importing: We directly import the 3D navmesh and Spawns from a TSCN file (godot scene), so level designers are welcome to start creating the maps of their dreams!
  • Solid Foundation: We've established what I believe is an exceptionally strong foundation to build the rest of our systems on top of, and we're moving out of the Engine Emulation stage and into the Gameplay stage already!

While the game doesn't feel like much of a game right now (since we're re-implementing core systems from Godot into our custom C++ instance), the architecture we're building is far superior to what we had before. With the code comments and clear separation of concerns, contributing should still be a breeze dispite the language.

Open Sourcing

We've re-opened the source for both the client and gameserver! You can now see exactly what we're building and how we're building it. Fair warning though: it's not pretty yet. We're actively reimplementing features, so expect things to be rough around the edges.

Other repositories are coming soon, or are present but not updated in a long time. This will be fixed as we progress through the developemtn of the game.

Why C++ for the Gameserver?

This decision deserves some elaboration. While Godot is a fantastic engine for client-side development, using Godot's dedicated server for multiplayer logic creates several limitations:

  1. Control: We aren't using Godot's high-level multiplayer API. Instead, we're leveraging ENet directly, which gives us granular control over what data gets sent, when it gets sent, and who sees what. This is critical for a competitive game where information asymmetry is important (enemy fog of war, anyone?).

  2. Performance: C++ gives us the ability to optimize server-side calculations (pathfinding, collision, entity updates) without the overhead of Godot's scene system or scripting layer.

  3. Clear Separation: The gamecode and server are now completely separate concerns. The client talks to the server over the network; the server doesn't need to understand Godot at all.

  4. Standardized Format: By using a standardized file format system (XML), we can easily sync client and server states without worrying about engine-specific serialization.

  5. External Asset Manager: Our Godot plugin can now manage assets independently and reference them by a standardized format that both the client and server understand.

Closing Notes

  • Timeline: We're targeting an alpha test in 2 weeks (around early December). This gives us time to get the C++ server to feature parity with what we had before, test everything thoroughly, and address any critical issues.

  • Community: Thanks to everyone who has stuck with us through these architectural pivots. I know it's not ideal, but I genuinely believe this direction is what OpenChamp needs to reach its potential.

  • Contribute: If you're interested in contributing to either the Godot client or the C++ gameserver, we're actively looking for help! Whether it's systems design, rendering optimization, networking, or anything else, reach out in our Discord. My DMs are also open.

As always, thanks for following along on this journey. We're building something special, and I'm excited to show you more soon.

Have a great week everyone,

~ Cody

OpenChamp Lead Project Engineer (allegedly)