rustyroguelike VS love

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.

I've built a few games with my son over the years. The fun part for us was all about fast iteration, and then laughing at the bugs together.

There are some other recommendations here for how to approach 3d, and he is specifically asking for 3d -- but I want to put in one more pitch for 2d: the fun-to-tedium ratio can be much higher.

I wonder if you could spend some time prototyping some of his ideas in LÖVE https://love2d.org/ -- if you show him the smallest sketch of something working, he might have an idea about what to add next.

Many years ago, on a flight, we went from 0 to game before we landed (with no experience).

* When a cell is born it randomly takes on the color of one of its (3) parents.

To try it out:

1. Install LÖVE for your device from https://love2d.org (~5MB and open source). (iOS requires building from source on a Mac, or installing the third-party Love2D Studio: https://love2d-studio.marknoteapp.com)

2. Install my Lua Carousel from https://akkartik.itch.io/carousel (~100KB). It includes all its source code and can be edited live on a computer as it runs.

3. Copy the ~100 lines of code from the bottom of https://akkartik.itch.io/carousel/devlog/651711/new-version-after-9-days and paste them into Lua Carousel.

Probably the most important piece of software we'll be playing around with is a game engine called LÖVE. Lua is well known around developer circles as being a good scripting language when it comes to making games, and this engine is one of the more popular. I'll be going through installation at the end of this post.

I got it – these are the steps I took:

1. Download Love from https://love2d.org/

libGDX is great, but I can understand if it's not for some people. This also applies to love2d, raylib and Monogame

You don't need to use git if you don't want to. Try downloading the 0.10.2 source directly here (the file you want is love-0.10.2-linux-src.tar.gz); I see you've tried this already but try again just to see what happens. Extract it to a directory (e.g. love-0.10.2-linux-src) and then run:

Love2d (MIT/C++/Lua) https://github.com/love2d/love

- Löve (doesn't have a separate page, but showcases a few games at the bottom of the page): https://love2d.org

The game, Wasp Escape, was built using the open-source Löve 2D game library for Lua.

love2d (lua) is a productive, fun, good docs, and most importantly proven / field-tested 2d game library, with easy to learn fast to compile and fast to run language - lua. while lua might not have a lot of features as python, the big bonus is that its much more focused language, which is important because otherwise you can get easily distracted on bells and whistles that other programming languages provide, i know that from experience