Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
rustyroguelike
Discontinued Following along with the /r/roguelikedev tutorial session, in Rust and implementing my own library as well!
-
Book is also online: https://bfnightly.bracketproductions.com/
and on Github: https://github.com/amethyst/rustrogueliketutorial
Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes.
[1] https://github.com/three-rs/three
Looks pretty good! I will say, as someone who programs in their day job and has been trying for ages to get into game dev as a hobby, love2d [0] has been excellent for getting started. My github has a few repos of previous attempts at making simple games (in .cpp, .rs, etc) which I abandoned from the amount of work it took.
If you're in a similar boat, I would recommend checking the framework out. Lua's a pleasure to program in and you can focus on the game development itself instead of getting bogged down in the details of rust / cpp. In fact I've been thinking lately about how easy it would be to use it for things other than games -- quick prototyping of graphical simulations, psychophysics experiments, etc.
[0]: https://love2d.org/
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.
The issue is that Bevy _and_ bracket-lib provide their own main game loop, so it's not trivial to make both work together. This might help you: https://github.com/amethyst/bracket-lib/issues/160
Personally, I've resorted to using only the bevy_ecs crate. It was honestly easy and pleasing to work with (if you're willing to dig the generated docs), but I hit a wall when I tried to serialize my components to save/load games.