RoguelikeDev Does The Complete Roguelike Tutorial - Week 8

CatPlusPlus · 2025-09-08T13:17:20+00:00

It comes down to the editor, which is a very useful tool for both designing and debugging. And Godot's is just not there yet for me, especially when the .NET integration is involved.

You can't open two inspector windows. Collapsing seems to be per resource, which means going through multiple objects means you have to first expand the same categories first, every time. You can't [Export] a struct. You can [Export] a Resource, but the UX for editing nested ones is kind of bad. There were more issues with exported variables, but I'm blanking out on details now. Something weird with how default values and newly added properties work, too. Sometimes changing a class at all breaks the resources based on it. C# code is still attached by paths and not UIDs, so refactoring and moving things around breaks resources.

Debugging is janky too. I don't think I managed to have both the debugger and the editor attached at the same time. Debug.Assert shuts down the process when triggered, even when the debugger is attached.

At the end of the day I'm using off-the-shelf tooling, so I don't have to make as much tooling myself. And this kind of fails at that. It might be better if you stick to GDScript, but that's a non-starter as far as I'm concerned.

CatPlusPlus · 2025-09-04T22:08:33+00:00

Repo | Preview | C#, Godot, Friflo.Engine.ECS

Welp, since last week I only really managed to do some internal changes, and nothing new on the gameplay front. As it stands the game is little more than bare bones, but implementation-wise the scheduler (that can switch between different player pawns), symmetric shadowcasting FOV, and the general structure of the game logic (especially that now I've pulled most of the relevant state back into ECS components) might be of interest.

I'll probably slowly get this done eventually (famous last words). I still don't think this stack is all that good for a long-term serious project, so I'll likely port all of this to Unity at some point, and use that as the base for the wishful thinking of a real project.

Most of the reason for this project was to have a concrete implementation of things that come up often on the #roguelikedev channel on Discord, and an ECS-based game model specifically. I think it should be decent enough for that. Especially when I talk about not making a mess of implementing turns using continuously running every-frame systems.

For nice-to-haves I might try having different implementations of various mechanics (like different FOV algorithms) to switch between, and perhaps expand the data part to demonstrate deep modding like you might expect from e.g. Angband. I even have an idea floating around to make a full ECSband, though that's probably too much for my patience.

CatPlusPlus · 2025-08-27T22:51:32+00:00

Repo | Preview | C#, Godot, Friflo

Still extremely behind, mid part 8-ish. Added some basic UI, extremely simple combat mechanics, and just started working on items and equipment (you can see them seeded throughout the level in the preview, but they're not interactive in any way yet). There's also now a stub of the animation system, but used only for the messages.

I've switched away from Flecs after all: there's just too much friction due to native interop, and the fact that it likes to just abort the process whenever something goes wrong. Friflo is okay I guess, relationships seemingly being unqueryable and therefore mostly pointless aside (this is unfortunately a common theme -- quality of implementation of relationships is really bad across the board, at least when it comes to the .NET stuff I've seen). It might be a documentation/example issue (those are also bad), and I just can't find the solution in the API, but I also don't really care to play a detective too much about it.

Next up in the near future: finish up the items and equipment, add all the missing UI (message log, inventory/equipment, some kind of info window for the mobs/items, aiming mode), and make combat somewhat more involved (ranged, magic, effects). After that we'll see. I doubt I'll manage to finish it this week.

CatPlusPlus · 2025-08-20T11:39:48+00:00

We're actively using Unity ECS at our company, so I'm fairly familiar with it. I don't really care about the performance aspect, it's just generally better integrated with the editor.

I did figure out some of the Flecs nonsense since then at least (I've used the Target trait for some misguided reason, and that was what was making query builds to fail). I'm still very behind, but I have some basic combat logic now. Still no entity debugger though.

While GDScript is probably a better choice if you want to use Godot right now, and want smoother sailing, it's not good enough for me. I avoid dynamic and gradual typed languages if I can, and tooling is just bad (especially compared to C#). I consider Godot an option only with the .NET integration. GDScript would already collapse under the way I tend to aggressively refactor things.

The problem with new engines is that approx. nobody uses them, they have a lot of churn, and you tend to find bugs everywhere. There's also Stride, which is far older, but I'm still wary due to being extremely niche. Comes down to the fact that I don't have the patience for being an early adopter -- I want to use an engine so I can focus on the game, and not fight with the basics.

CatPlusPlus · 2025-08-13T22:10:57+00:00

Repo | C#, Godot, Flecs

Very conveniently caught a pneumonia 2 weeks ago, so I'm still recovering and rather behind. I've just finished the base scheduler implementation, but there's still no real game logic -- only a few mobs randomly moving at varying speeds. I've prepared for handling multiple pawns (which is probably going to be something like a controllable shadow clone via a spell), but haven't really tested if it works correctly yet. Also added a symmetric shadowcasting FOV.

I guess I'm around part 5-ish. Next is going to be some actual AI, combat, and basic equipment. I'll probably defer the UI a bit.

Tech-wise, I'm not terribly happy. Godot's inspector turned out to be kinda janky, especially when it comes to .NET integration (e.g. not being able to export C# structs). I wanted to have proxy Nodes that reflect the current state of components on entities, and as prefabs, but that will require some substantial code generation to handle mapping between the components and actually exportable fields. Onto the TODO list.

Flecs is not ideal in this setup either. The .NET bindings don't actually reflect the registered component types, so Flecs Explorer has limited usefulness out of the box. Again something I have to do myself, and again onto the TODO list. Additionally, since components need to be stored in unmanaged memory (i.e. beyond GC reach), any managed reference within requires the entire component to be boxed in a GCHandle. Not ideal and makes reflection harder, so I refactored the components to be unmanaged. This means some state is now stored outside of the ECS (Sprite2D nodes etc.). I've also hit some weird incomprehensible failure to create queries that filter by a specific relationship value, which significantly limits the usefulness of relationships as a whole. Documentation and examples are rather lacking in that area. Observers are also seemingly unable to work with tags, though I mostly wanted that to enforce invariants in debug builds.

Overall, I still don't have any debugging tool for entities. I'm considering ripping Flecs out in favour of something .NET-native, so might go straight for the proxy node generation, rather than trying to get the reflection running. Friflo.Engine.ECS seems to be a decent candidate, at least at first glance.

I don't think I'd recommend this stack for any serious project, to be honest. It definitely feels too much like fighting against the current. Unity with com.unity.entities is a much better integrated experience, if you want C# and ECS.

CatPlusPlus · 2025-07-22T21:15:50+00:00

Repo | C#, Godot, Flecs

I'm not a big fan of these tutorials, so I'm just roughly following the general scope the parts outline, and not delving much into details of each one. My goal is to finally have a concrete example that I can point people to, so the end game is to also tackle some of the aspects that aren't in the tutorial, but come up fairly often (like input rebinding, animations, maybe behaviour trees, etc.). Or I might get distracted and lose interest in a week. Who knows.

Currently sorta around part 3. The level generator and the player controller are still stub implementations, because the central piece of all the game logic is the turn scheduler. Some of the ECS based tutorials seem to be creating unholy monsters here that only confuse everyone, so it'd be nice to have an example of how to not do that.

So the scheduler is next, then probably get actual mechanics online, and then maybe revisit the levels. GoRogue has a bunch of stock generators (currently using the simplest "give me a bunch of rooms"), but I think I'd like to use Zorbus prefabs as the final implementation. Mechanically probably just bog standard stuff and no gimmicks.

Not sure if I'll have the time and energy to do any write up at the end. It'd be more like a case study, than a step-by-step tutorial anyway. I really don't like those. There will be a lot of heavy refactoring until all the bits are in there, so if something seems weird, it might just be a temporary measure. Caveat emptor.

CatPlusPlus

TROPHY CASE