froggy
rustyroguelike
Our great sponsors
froggy | rustyroguelike | |
---|---|---|
5 | 1 | |
300 | 103 | |
- | - | |
3.2 | 10.0 | |
over 3 years ago | over 4 years ago | |
Rust | Rust | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
froggy
- Hands-On Rust: Effective Learning Through 2D Game Development and Play
-
Object-Oriented Entity-Component-System Design
What I found in practice is that many people start using the ECS for speed, and then draw themselves into a corner of the design space. Now they have to weight every step on "how would it work in ECS?", and dedicate effort to fight the ECS paradigm.
For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component.
One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for.
[1] https://github.com/kvark/froggy/wiki/Component-Graph-System
-
[Media] rg3d game engine v0.22 - feature highlights
I had similar motivation back in the day for CGS in https://github.com/kvark/froggy, which was also powering https://github.com/three-rs/three. It's nice to see Rust ecosystem not locking itself on ECS, even if they are so cool :)
- Froggy - A Component Graph System experiment
- Component Graph System
rustyroguelike
-
Hands-On Rust: Effective Learning Through 2D Game Development and Play
We should probably agree to disagree; your approach is just as valid as mine. My first attempt at a roguelike in Rust ( https://github.com/thebracket/rustyroguelike ) was a straight-from C++ approach, using dynamic traits and a lot of casting. It was my first try at using Rust, and is pretty bad - but at least it completed the "r/roguelikedev does the tutorial" event. Going from OOP to a non-inheritance language was quite the leap.
You absolutely can have an entity structure containing a vector of dynamic component types. It can get quite messy when you start having a lot of component types. When your entity runs, it has to look at the data in its components. That either means that component is a big enum (no need for dyn and Box there), or component is a trait and you're going to be doing a bunch of dynamic casting to find out what components an entity has when it ticks. Either can work (as can having an Option for each component type, which replaces the dynamic cast with an `if let`). Ultimately, there's not a lot of difference between an entity iterating its components and calling methods on components (or branching based on the components it has) and running a query to retrieve the components you want and acting on them. It's not that different from a NoSQL database (everything in a node graph) vs. a relational database (tables keyed to an identifier) - both work, each has their strengths and weaknesses. (I also really didn't want to try and teach dynamic casting early in the book!)
Some specific points from your reply:
By "replication", I meant network replication. You can get the same benefits by tracking changes within an entity/component, but it's really handy when a single storage system does that for you. Not that useful to a traditional single-player roguelike, but a nice tool to have.
> Yes, but that's not what a turn based tile based game is. Generally you want to iterate over things in order - gravity (if a roguelike has such a thing) gets applied on the player's turn, and only for the player. If you step over a ledge you don't wait for the "gravity" system to kick in and apply gravity to all entities, it is resolved in the same instant for only the entity that has just moved
That very much depends upon what you're creating. (Nox Futura is a Dwarf Fortress like). In the gravity example, it was solved by remembering to exclude the Flying component from the gravity query. The roguelike example in Hands-on Rust actually runs the player and monsters in different phases, but re-uses a lot of systems in the process. Matching on the turn state and executing systems isn't all that different to matching on the turn state and running tick functions on the entities included in that turn - especially if you have an energy cost/initiative type system breaking out the moves (the tutorial I created does this). Both Hands-on Rust and the tutorial effectively use message-passing for chaining events together.
> if anything I could see issues arising from the fact that you basically have dynamic typing when it comes to what behaviors an entity has
You have the exact same problem with a dynamic vector of components.
> If you're not doing query-based ECS with systems there's also no particular reason to not use vecs of components within entity structs.
It mostly boils down to preference. I find Query<(MonsterAI, Position, LikesToEatPlayers)> easier to work with than having each entity iterate a component list, query the type of each component and then act accordingly.
> As a final note, in the excerpt about items you have this justification for not using an enum instead of components:
Again, we're solving the same problem in similar ways. There's really not a whole lot of difference between matching the enum and iterating MultiEffect and querying if an entity has components. Either way, you have code that says "oh, it explodes" and makes a boom.
In other words, we both prefer different ways to accomplish exactly the same thing. Neither of us is right or wrong, there's plenty of ways to skin a cat. Hands-on Rust is as much about teaching Rust and gamedev in general as it is roguelikes in particular; if you want a big, working roguelike - the tutorial ( https://bfnightly.bracketproductions.com/ ) does that.
What are some alternatives?
rapier - 2D and 3D physics engines focused on performance.
Hazel - Hazel Engine
StationIapetus - 3rd person shooter in the very early development phase
entt - Gaming meets modern C++ - a fast and reliable entity component system (ECS) and much more
habitat - Modern applications with built-in automation
RG3D - 3D and 2D game engine written in Rust [Moved to: https://github.com/FyroxEngine/Fyrox]
bracket-lib - The Roguelike Toolkit (RLTK), implemented for Rust.
rustrogueliketutorial - Roguelike Tutorial in Rust - using RLTK
love - LÖVE is an awesome 2D game framework for Lua.
three - [abandoned] Totally not inspired Rust 3D library