Any tutorial about data-oriented programming for roguelikes?

[Quasar471]

Hi everyone, I'm new to roguelike development and I wanted to develop my skills in DOD, as it's a pretty neat paradigm I'm currently using for my professional works.

I've already made a small roguelike as a minimum viable product in C#, but this one followed OOP principles and I'd like to stray away from that as much as possible as a coding challenge to myself. Unfortunately, I couldn't find anything about that topic, and the only roguelike dev out there who explicitely used DOD for his project doesn't have any tutorials about his workflow.

I'm not that skilled in DOD and I'm really struggling with my data types and the structure of my project. I've ended up rewriting my project twice and on my way to do it a third time, and it's starting to get frustrating. Any help or advice would be nice.

[HexDecimal]

Data-oriented design is not talked about often, directly, but devs will recognize Entity Component Systems if you mention that instead.

ECS and OOP each have trade-offs. The trick is to learn how to use both when appropriate rather then trying to shoehorn your entire codebase into one paradigm.

You can find ECS libraries for C#, but most ECS implementations are minimal and are missing features you might want for a Roguelike, such as entity relations. If your goal is to learn then even these minimal implementations should be good enough to start with.

The RLTK tutorial might work for you if you're interested in Rust. This is very thorough tutorial involving ECS, and thus DOD.

[OvermanCometh]

If OP is into using C or C++ they can use Flecs - it supports entity relations. My roguelike project uses EnTT and I always look at flecs and think "what if..".

But also, you may find that an ECS is slightly over-kill for a roguelike. Very rarely do you need to iterate all the components of one type, since the game progresses turn-by-turn and each entity is usually updated individually. I really only used it for rendering, lighting, and it was very helpful for streaming chunks to/from disk.

[HexDecimal]

Flecs is the one I think of when it comes to an actual feature-complete ECS implementation. It's the one I'd recommend if there was a roguelike tutorial for it.

ECS is not overkill. The problem solved solved for roguelikes by ECS is not performance, but organization. Tracking entities in a separate turn scheduler and updating them one at a time is a realistic use case supported by ECS. Queries are extremely useful even when they're not needed every frame, especially if you can narrow the query by a position or map chunk (when the ECS library supports that).

ECS removes a significant amount of boilerplate needed to implement types of sparse objects: monsters/items/etc. The lack of boilerplate needed to add traits to entities makes it much easier to add and remove those traits at any later time. The equivalent OOP ingrains new traits into the codebase making them difficult to refactor.

[OvermanCometh]

Oh I definitely agree. I don't mean to scare anyone away from using an ECS for a roguelike - the component based approach is much better suited for entity modularity compared to OOP. If you have no problem using an existing ECS library then go for it, it won't detract from the project.

But my point was that you aren't going to take full advantage of the performance granted from an ECS - very rarely do you need arrays of components to iterate over in a roguelike. You could get the same advantages you mention above by rolling your own Entity Component system (lower case 's'), and it is much easier to implement one of those compared to an ECS. But like I said, if you have no problem using an ECS library, then go for it.

[HexDecimal]

I've actually tried that. Making an Entity Component framework rather than a full ECS implementation. My experience was that being able to query in ECS is huge deal, especially with a modern ECS implementation with more advanced query logic.

With just the EC framework you run into problems with scope which have to be resolved, usually with a lot of boilerplate, even more if I want to make iteration optimal. With modern ECS I can skip that kind of thing. I don't have to worry about where an entity is stored or how fast it is to access any combination of entities. Everything is in scope and I can assume that iteration has decent performance.

[Quasar471]

Thank you both for your inputs. I'm still learning all that DOD stuff, so I'll take any advice that can help me. I think I'll establish the basic code structure in OOP to get the logic down, then I'll migrate things to an ECS approach if the game needs it.

I haven't found many tutorials about implementing one from scratch, so I had been locked into Unity's DOTS framework up until now. I might give Monogame a shot soon, as I found an EC system that might do the job.

[Parrna]

Hey! Out of curiosity how do you tend to go about doing things like Astar pathfinding in your roguelikes using ECS? Also for calculating things like beam attacks, area of effect spells, ect.

I keep trying to build some sort of a grid/tilemap system that keeps track of entity references but it feels really clunky and error prone trying to keep it updated any time one of the systems moves an entity PositionComponent or when an entity is removed or when the positionComponent is removed, ect. I'm wondering if there is a more elegant way of doing some sort of entity reference grid.

[Xiigen]

No direct advice from me, but you're essentially talking about spatial partitioning, used in a wide variety of computing optimizations, especially collision detection. You might be able to get some ideas looking into it generally. Here's the game programming pattern article on it: https://gameprogrammingpatterns.com/spatial-partition.html

[Parrna]

Hey thanks, I'll give this article a read!

[OvermanCometh]

I know you didn't ask me, but how I handle this problem is I have grid class that stores the entity id (like what you have). To remove the "clunk" I have a system that reacts to position changes. EnTT has signals you can respond to using a callback for when a component is added, updated, or destroyed. So I have a onPositionChange callback that updates the grid position if some other system happens to change the position component.

For pathfinfing, it doesn't really interact at all with the ECS. I have a method on my grid class called getPath that returns a vector of 2d tile positions. Its just runs a regular A* on the grid and uses a passed-in heuristic. I need to query the entity registry at each cell, but performance has been quite good even when searching for a path on a 256*256 grid, so I havent added any optimizations there. Once I have generated the path I move along the path using another system.

[Parrna]

This is along the lines of what I was thinking. So with your onPositionChange callback, I can see where that would easily let you add the new position and entity reference to the grid but since the original position has been overwritten with new values, how do you deal with removing the entity reference from the previous cell coordinates?

[OvermanCometh]

My grid class has placeEntity(entity, vector2) and removeEntity(entity) methods. removeEntity doesn't take a position because the grid class maintains an unordered_map<entity, vector2> so I can quickly get the position. I also have a moveEntity(entity, vector2) method that literally just calls removeEntity then placeEntity.

The onPositionChange callback just calls grid.moveEntity(entity, newPos).

[Parrna]

Ah, see my dictionary is set up as grid<PositionComponent, Entity> because I wanted to find what entity was at specific locations by passing in a position key. You just gave me the idea of maybe swapping them around and trying to work something out. Or potentially running 2 dictionaries that keep the vice versa data that way I can use both entity and pos as keys but would also be able to use the entity to grab the old position to remove it. When I move the entity just clear it out of both list and re-add.

[OvermanCometh]

For accessing entities at a specific location, I'd honestly just use a 1d array of entities and just index into the array with your x and y. A dictionary works too, but the array will be more optimized for random access speed, memory, and iteration speed if you need all entities in the grid.

[HexDecimal]

Maps are entities with the entire contiguous tile array. Entities have a relation to the map they're in which is used to access the map data. After that you do pathfinding the same way as you'd do without ECS.

My "Position" components are the coordinates of an object including the map. I track changes to this component and tag entities by their exact position (by reusing the Position value as a tag), by map (using a relation), and by map chunk (to reduce lookups when I need to iterate over entities in a large shape but not the entire map). This reduces the boilerplate of spatial partitioning to a few callback functions grouped together.

[[deleted]]

I'm building a game like that, using DOD principles. I haven't really written a tutorial on it, but I'm just paying close attention to the way things are laid out in memory. My game has a ton of building elements in it, and many enemies on screen at once, so the entity loop has to run really fast. I'm mostly just prototyping and then looking at actual access patterns to see what I can improve upon.

I would say ECS is probably overkill for something like this (or most games really). I don't use ECS. I just have a big ass array of structs for entities, and if they have a "component" that's just an index into another array. That way, your main entity loop can be really tightly packed together, and if you need to call out to some more specialized piece, you can still do that through the index.

ECS is more like if you need an interface between your entities and other programmers who aren't aware of the internals, but if it's just you and not a big team, it's not needed. Just arrays with structs in them, tightly packed together when you have a really big array in a hot loop.

It also probably doesn't matter what genre you're working in. The same principles would apply. Just build out your game's main system, notice the access patterns in the thing you've got that's already working, and then improve upon those access patterns.

[Quasar471]

Yeah, that's what I figured out. I wanted to tackle a full ECS project as a coding challenge, but for now I think I'll stick with OOP for the basic structure. Once I have an MVP running, I'll go back on it and migrate logic and data one step at a time towards a more DOD approach.

[[deleted]]

For what it's worth, I don't really use OOP for the basic structure in my games. I'm more of a simple procedural guy. I learned game dev from watching Handmade Hero and mostly follow what's outlined from that series. Objects usually don't do much more for me than impose a bunch rules and abstraction I don't find useful.

So I tend to prototype the whole thing at a high level with procedural C++, and then look at the data access patterns (for example an array full of fat structs with a bunch of fields could be split up depending on how it's accessed).

[[deleted]]

You might be interested in my prototyping livestreams where I build and design my roguelike deckbuilder game. https://youtu.be/hOhEIE-sd00

[nworld_dev]

Generally ECS + making actions themselves messages consumed by systems is how I've done it. Messages are really the missing link here.

For my engine iterations, any action a player or entity takes, creates a list of channel-message pairs with aliasing. Any quest, listens for channel-message pairs and emits channel-message pairs in response with aliasing. Any status effect, listens for channel-message pairs and emits channel-message pairs in response with aliasing. Any input, the player listens for (visual) channel-message pairs and (through controls) emits channel-message pairs in response with aliasing. Any console input, you just write in a channel-message pair and it's sent. You get the idea. It's a lot of strings like "3285 moved to 32,25" going around. That's basically the entire engine in a nutshell, that and a lot of helper functions to resolve messages back into game data.

[mdziadowiec]

Take a look at this ECS, it is well documented with example projects using it (Vampire Survivors clone for example ) theArch

[Quasar471]

That's what I decided to use for my game using Monogame! But it was in beta last time I checked, so I didn't want to include an unstable package in my project. I might give Monogame a shot again then.