rustyroguelike
bracket-lib
rustyroguelike | bracket-lib | |
---|---|---|
1 | 27 | |
103 | 1,452 | |
- | 0.8% | |
10.0 | 0.0 | |
over 4 years ago | 3 months ago | |
Rust | Rust | |
MIT License | 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.
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.
bracket-lib
-
Does anyone care about CLI/TUI games?
I think having to use a terminal is the scary part for many people. rltk/bracket-lib can be used to get a similar look and feel if that's what's important, but it is geared toward roguelikes.
-
Minimal 2D library for games? I'm struggling a bit to settle on one to learn.
Maybe bracket-lib from the amethyst authors? Iām currently working through that book and find the library quite intuitive and simple to use. It started out as a toolkit for rouge-like games but has been getting more general. On that note, I recommend the hands-on-rust book which teaches rust concepts while building games with bracket-lib. As you have read the book, Iām sure you would get through the first chapters quickly.
-
Bevy ECS or custom implementation?
https://github.com/amethyst/bracket-lib has a great integration with Bevy, designed for exactly this sort of thing.
- Turn-based game - architecture feedback/opinons
- libtcod use 8x8 font but scaled up to 16x16?
-
How difficult could it be to make a console program that looks like this and has a game loop running on a separate thread? Any suggestions or crate recommendations are welcome!
I've been doing some experiments with terminal based games and landed on https://github.com/amethyst/bracket-lib It's not exactly terminal based in the sense that it actually runs on OpenGL by default. But that's a plus imho because dealing with the bits of the terminal window that can change outside of your control (like fonts, window resize, etc) is a giant pita. It does let you swap the backend to run on crossterm if that's what you really want to do but if what you're after is the aesthetic like I am having bracket_lib handling all that makes life so much better.
- Rendering TUI To Web
-
Sharing Saturday #420
Bracket-Lib for Bevy Github
-
Sharing Saturday #418
Bracket-Terminal/RLTK for Bevy Github Branch | Twitter | Patreon
-
Sharing Saturday #416
bracket-lib šš» (using this now)
What are some alternatives?
froggy - Component Graph System experiment
bevy - A refreshingly simple data-driven game engine built in Rust
Amethyst - Data-oriented and data-driven game engine written in Rust
VTerminal - A new Look-and-Feel (LaF) for Java, which allows for a grid-based display of Unicode characters with custom fore/background colors, font sizes, and pseudo-shaders. Originally designed for developing Roguelike/lite games.
libtcod - A collection of tools and algorithms for developing traditional roguelikes. Such as field-of-view, pathfinding, and a tile-based terminal emulator.
python-tcod - A high-performance Python port of libtcod. Includes the libtcodpy module for backwards compatibility with older projects.
bevy_webgl2 - WebGL2 renderer plugin for Bevy game engine
Rust-HTML-roguelike - Rust WASM + HTML roguelike
rot.js - ROguelike Toolkit in JavaScript. Cool dungeon-related stuff, interactive manual, documentation, tests!
Axes-Armour-Ale - A fantasy, ASCII dungeon crawler for Windows, Linux & OSX
roguelike_tutorial
rdl2021-tutorial - /r/roguelikedev Tutorial 2021