[HN Gopher] Roguelike Tutorial in Rust (2019)
___________________________________________________________________
Roguelike Tutorial in Rust (2019)
Author : wsc981
Score : 300 points
Date : 2022-07-12 08:29 UTC (14 hours ago)
(HTM) web link (bfnightly.bracketproductions.com)
(TXT) w3m dump (bfnightly.bracketproductions.com)
| GuB-42 wrote:
| There are orcs, dragons, spiders, gelatinous cubes but no rust
| monsters. Disappointed.
|
| No seriously, that's great, and maybe rust monsters will be
| included eventually. Technically, it has an interesting effect
| (damages metal items) which may have a place in a tutorial like
| this.
| suby wrote:
| 75 comment discussion here from 2020
|
| https://news.ycombinator.com/item?id=22020229
| Winsaucerer wrote:
| I started working through this, except to make things difficult
| for myself I used Godot for drawing everything, via
| https://github.com/godot-rust/godot-rust.
|
| I only got to about halfway through section 2, but I think it was
| going well.
| kramerger wrote:
| I don't get it, how can people use this to learn rust?
|
| Sure, game development can be fun. But this looks more like a
| tutorial for rltk. It quickly gets pretty confusing if you don't
| already know some rust, gamedev and rougelike.
|
| (I recommend beginners to look at rust by examples instead)
| stu2b50 wrote:
| I consider this kind of tutorial to be about the middle area of
| learning. It's probably too much for a beginner to rust, but
| it's great at turning someone who merely knows rust to someone
| proficient in rust.
| otikik wrote:
| If you are a beginner to Rust _and_ gamedev _and_ roguelikes,
| it might be too much for you, yes.
|
| Different tools for different people. Absolutely.
|
| That said, the Venn Diagram of "roguelike enthusiasts" and
| "game developers" approaches a circle.
| wcarss wrote:
| Maybe a few years out of date, another tutorial bringing you
| through implementing a roguelike in rust:
| https://tomassedovic.github.io/roguelike-tutorial/
|
| I followed this one in 2018 and really enjoyed it, and it made a
| playable and impressive little roguelike! Though I didn't end up
| learning rust very deeply from the effort, it was a worthwhile
| experience and I are least gained some familiarity.
| m4nu3l wrote:
| I'm currently using Godot 3 for my solo indie project. It's a
| six-degrees of freedom space shooter. I use rigid bodies and
| physics very extensively, but what have proved to be very hard-
| to-remove bottlenecks were the scene tree and scripts.
|
| At some point the game was spending more time on those things
| that on the physics simulation.
|
| I have rewritten some code in C++ over time and parallelized as
| much as I can. However I'm starting to think that scripting
| languages are a false economy. There is no intrinsic reason you
| can't have a concise and easy to use language that can be quickly
| (in debug mode) compiled to the metal and dynamically linked to
| the project.
|
| I might look at godot-rust at some point although It's a bit late
| considering the amount of code I have written already.
| pjmlp wrote:
| >However I'm starting to think that scripting languages are a
| false economy.
|
| Yet, Epic after following the path of deprecating UnrealScript
| in name of C++ and BluePrints, has decided to hire Simon Peyton
| Jones from Haskell fame, to design their new scripting language
| called Verse.
|
| https://discourse.haskell.org/t/an-epic-future-for-spj/3573
| s-lambert wrote:
| Verse doesn't sound like it has to be a scripting language
| though, it sounds more like it's a high level simulation
| oriented language. Scripting languages nowadays have all the
| same constructs as typed languages, they just lack types. I
| would expect Verse to be a whole different kind of language,
| rather than just C++ without types.
| pjmlp wrote:
| You can see how it looks like on these screenshots,
| https://twitter.com/saji8k/status/1339709691564179464
| rowanG077 wrote:
| Afaik it's not known yet whether verse is compiled or not.
| j-krieger wrote:
| I really do not understand game engine designers insistence
| on inventing a new language for their scripting needs. There
| are dozens of well built languages that can be used for
| simple scripting. Just pick one of those.
| duped wrote:
| There really aren't. You need:
|
| - Fast to compile
|
| - Fast to run
|
| - Memory management that doesn't destroy frame times
|
| - Easy to embed, ideally with a small runtime
|
| - Can target whatever ISAs and OS's that the game runs on,
| like consoles.
|
| There are not dozens of languages that fit these criteria,
| particularly memory management, embedding, and toolchain
| support for consoles when you're using a proper JIT
| compiler and not a bytecode interpreter.
| patrec wrote:
| Well, there is luajit at least (the GC isn't very
| performant, but people who care about this sidestep it).
| Maybe Chez or Gambit scheme as well.
| Tuna-Fish wrote:
| When you are sidestepping the GC and have your object
| graph mostly in types built in the base language, Lua is
| no longer a pleasant language to use.
|
| I think UE is a situation where writing a new language
| specifically for scripting it is absolutely the correct
| choice. The user base will be large enough to support it
| properly, and there are a lot of things that are a lot
| more ergonomic when the language will be built to support
| them after the base system is already built, instead of
| the other way around.
| badsectoracula wrote:
| There are many engines that use existing languages, with
| Lua being one of the most common scripting languages used
| by games. However usually when an engine has its own
| scripting language it is because the existing languages
| wouldn't fit and/or the custom language can work better
| with the underlying engine.
|
| For example if a game engine keeps track of asset
| references, scripts could be themselves assets like any
| textures, levels, materials, etc and have asset references
| as literals in the code that the script compiler
| understands, allowing automatic and precise extraction of
| asset dependencies the scripts (and the assets that refer
| to those scripts) can have. This is, e.g. what Blueprint
| does (BP is just a visual scripting language that uses a
| graph with a visual editor instead of parsing text to
| generate an AST but the same idea applies).
| adam_arthur wrote:
| I suspect they could easily use an off the shelf language,
| or at least build a language that is a strict subset of one
| that allows for isomorphic code between that language (if
| targeting the subset first).
|
| I strongly agree this is a superior approach to a custom
| language. Even better if the games industry standardized a
| single purpose fit scripting language
| [deleted]
| sjcoles wrote:
| NaughtyDog was able to do amazing things with their in
| house lisp GOAL[1]. I expect SPJ's work to be in a similar
| vein.
|
| [1]:
| https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
| pshc wrote:
| My guess is that existing scripting languages don't mesh
| well with all the parallelized staged simulation, entity
| content systems, and lack of tracing GC that game engines
| like Unreal tend to have.
|
| I don't know much about Verse but looking at the preview I
| already see a type called a type called `<latent>` (async
| Promise?) and a `race` keyword (seems like a built-in
| `await Promise.all`?). I bet building these directly into
| the language fixes much impedance mismatch.
| t-3 wrote:
| A similar but opposite argument could be made that every
| application's scripting language will necessarily be a DSL
| focused on that application, so might as well design a new
| language.
| badsectoracula wrote:
| FWIW Blueprint is basically a scripting language, except
| instead of having you type something like "vector Foo =
| bar.GetPosition()" it has you create a "variable reference"
| block, a "variable assignment" block, a "GetPosition" block,
| a "reference to bar" block and then connect all of those
| blocks using "wires" alongside a wire that specifies
| execution flow.
|
| But for all intents and purposes it is a scripting language -
| the blocks are even converted into an AST-like intermediate
| representation that is then either converted to a bytecode VM
| or is used to generate C++ (though the BP-to-C++ conversion
| generates very weird code since BP allows -conceptually-
| multiple things to run in parallel).
|
| But the Blueprint "front end" can be replaced with another
| (text based) scripting language that generated the same IR
| and the rest would work the same. While i haven't seen UE3's
| source code so i can't be 100% certain, i'd bet that the IR
| and VM have their roots in UnrealScript - and chances are
| Verse is also targeting the same IR.
| pjmlp wrote:
| You are of course right, I should have phrased it in a
| different way.
| hackeroldz wrote:
| How hard is Godot to learn? I have no prior game developing
| exp.
| thealienthing wrote:
| It's a very easy and well documented free engine. If you have
| used and like python, you can learn the ropes quickly. But as
| OP mentioned there are drawbacks to the loose type system.
| But I would encourage anyone looking to make their first game
| to try Godot as it gets out of your way so you can start
| making your sprites move around and interact with the world.
| medo-bear wrote:
| > However I'm starting to think that scripting languages are a
| false economy. There is no intrinsic reason you can't have a
| concise and easy to use language that can be quickly (in debug
| mode) compiled to the metal and dynamically linked to the
| project.
|
| This might interest you:
|
| * https://reader.tymoon.eu/article/413
|
| *
| https://github.com/Shinmera/talks/blob/master/gic2021-highly...
|
| and the very recent still front-page discussion on hn:
|
| * https://news.ycombinator.com/item?id=32043026
| jasonjmcghee wrote:
| I've spent time in Godot and Godot Mono- if you're interested
| we could pair and investigate some of your bottlenecks. I've
| managed to remove those that I've encountered.
| jasonjmcghee wrote:
| Here's a simple example of a few steps, dramatically
| improving performance.
|
| It points to a few great tips- things like, being very
| intentional about node type, collision layers,
| monitoring/monitorable, and other concepts like pooling and
| the physics server.
|
| https://www.youtube.com/watch?v=_z7Z7PrTD_M
| m4nu3l wrote:
| What kind of game are you working on? I have managed to
| actually removing a lot of these bottlenecks by parallelizing
| or rewriting in C++. The ones I'm left with I believe are now
| more on the GPU side. I'm trying to use portal rendering /
| occludes for that.
| thealienthing wrote:
| >However I'm starting to think that scripting languages are a
| false economy. There is no intrinsic reason you can't have a
| concise and easy to use language that can be quickly (in debug
| mode) compiled to the metal and dynamically linked to the
| project.
|
| I'm a big fan of interpreted languages like python and the
| python like godot script. The power of quickly accomplishing
| tasks because of their fast and loose nature is great, but as
| I've built up some large repos at work written in pure python,
| I'm starting to regret the loose typing. Bugs caused by a small
| loss of data because of implicit type casting have been a
| source of much wasted time. I'm starting to convert to rigidly
| typed systems of program just for that peace of mind that any
| calls I make to an API will not compile because I am not
| passing the right type. It makes sense to switch to a language
| like CPP/Rust for big projects like a game.
| citizenkeen wrote:
| Coming from C#, I couldn't handle the untyped nature of
| GDScript, and quickly took up its static typing.
| m4nu3l wrote:
| It supports optional types. It's not perfect but I use them
| consistently and it helps.
| galangalalgol wrote:
| I have very fond memories of Quake C. It was a bit more like
| pascal in some ways than C but the compiler came with quake
| (the first one with the NIN soundtrack). It had the source for
| the existing bits of the game that were written in it, which
| was all the behaviours, and you could change it and recompile
| to a new dll. It was easy to use and quite performant.
| klaussilveira wrote:
| You're probably remembering Q3's QVM:
| https://fabiensanglard.net/quake3/qvm.php
|
| QuakeC was for Quake 1, also compiled, but not to a DLL:
| https://www.gamers.org/dEngine/quake/spec/quake-spec34/qc-
| me...
|
| Modern QC compiler:
| https://www.triptohell.info/moodles/fteqcc/README.html
| galangalalgol wrote:
| I'm definitely remembering quake1 but I might be wrong
| about the dll? I remember doing very poor version control
| copying the dlls into and out of the main folder.
| galangalalgol wrote:
| Ah yeah, progs.dat. So not a native compilation? The mod
| I was proudest of I called summoner that let you make a
| pet shoggoth that fought for you.
| jhgb wrote:
| > However I'm starting to think that scripting languages are a
| false economy. There is no intrinsic reason you can't have a
| concise and easy to use language that can be quickly (in debug
| mode) compiled to the metal and dynamically linked to the
| project.
|
| The Revenge of Lisp strikes again. Yet another reason for why
| your program should look like a big ball of mud?
| krapp wrote:
| >However I'm starting to think that scripting languages are a
| false economy.
|
| This is likely more an indictment of Godot's 3D capabilities or
| GDScript than scripting languages as a whole.
| m4nu3l wrote:
| No, not really. It's not about the 3D capabilities (I have
| different types of issues there) or about GDScript per se
| (other scripting languages have even worse issues like the
| GIL in Python), but the issue I had is that a lot of time was
| spent doing these:
|
| - Counting references. - Variant related conversions. -
| Resolving methods. - Interpreting the bytecode. - Sorting
| nodes before calling update functions. - Triggering callbacks
| etc.
|
| All of these would amount to a good percentage of the time
| spent in the main thread. I managed to optimize by a
| combination of parallelism (gladly GDScript has no GIL!) and
| by rewriting somethings in C++.
|
| I still have some bottlenecks with the rendering but that
| should be easier to scale back.
| chungus wrote:
| This is what I used to learn Rust, in tandem with The Book. I
| would read a chapter of The Book, then do a chapter of Herbert's
| Roguelike Tutorial. Very well written and fun material, that
| guides you deep into a tricky space with very little previous
| knowledge required. The maintainer is also very responsive to
| questions and pull requests. And has done an interesting talk[0]
| on procedural map generation at the annual 'Roguelike
| Celebration' conference[1] which is happening in October. (and
| for which the Call For Papers is still open)
|
| [0] https://youtu.be/TlLIOgWYVpI [1] https://www.roguelike.club/
| drivers99 wrote:
| What's "The Book"? Someone else mentioned `book` in backticks
| as well so I'm guessing there's one canonical book that Rust
| people are referring to.
| dhagz wrote:
| They're referring to this[1].
|
| [1]: https://doc.rust-lang.org/stable/book/
| SnowHill9902 wrote:
| I found it quite shallow. Am I alone in this? What's a
| better resource for learning Rust from a C++ background?
| lr1970 wrote:
| I found that the following book is much better suited for
| programmers with C/C++ experience:
|
| "Programming Rust, 2-nd edition" by Jim Blandy, Jason
| Orendorff, Leonora F. S. Tindall [1]
|
| [1] https://www.oreilly.com/library/view/programming-
| rust-2nd/97...
| thealienthing wrote:
| Amazing how powerful the concept of building a game is in
| teaching someone to program. The combination of graphics and
| learning some technical chops helps the user really get
| seasoned quickly in any language while also giving them
| something they can show their friends and family. Having
| someone cool to show off really helps maintain that excitement
| in the learning process.
| Aaronstotle wrote:
| I'm glad this tutorial popped up, I just started going through
| The Book over the weekend and I've been doing that and some of
| the Rustlings exercises.
|
| I need to check this out because as a new programmer, I have a
| hard time caring about exercise programs whereas a game
| provides a lot more motivation
| 0xRusty wrote:
| Absolutely incredible depth covered here. Very generous of the OP
| to provide such a detailed tutorial and reference! I'm going to
| try and go through this in a lot more detail when I get some
| time.
| hiyer wrote:
| Medium subscribers can read an HTML version of this book for free
| here - https://medium.com/pragmatic-programmers/table-of-
| contents-1...
| [deleted]
| lordleft wrote:
| One of the great blessings of the roguelike genre, especially in
| its purer-ASCII expressions, is that the barrier to create a
| complete and gripping game was considerably lower than games that
| required lots of art assets, animations, etc. It's a genre born
| out of the constraints of early computing.
| jaunkst wrote:
| That is one of the reasons why I got into programming. Not
| exactly because of roguelikes but MUDs. After playing muds, and
| wanting to make my own I started with Diku, and then started
| building them from scratch in many other languages.
|
| The ECS pattern became something really interesting to me just
| because of the highly serializable state.
|
| One of the MUDs my community was involved in had a great
| developer behind it. It was just so amazing how fast new
| features were added to the system. The idea that you don't need
| assets, animations, etc is critical.
|
| I would love for a book series that would cover something like
| this in multiple languages.
| zasdffaa wrote:
| Hard to call it gripping when I'm trying to find out how to do
| X in the interface. I suppose like emacs it comes with time.
|
| I admit on the few times I played it and managed not to get
| frustrated I do start to perceive it at least partly in 3
| dimensions with immersion, like an interactive cinema in my
| head, bit like when I played AD&D as a kid (which I admit I
| miss).
| kadoban wrote:
| That is the big downside, it takes a while to get invested in
| it, especially these days when there's a thousand other
| things optimized to pull your attention.
|
| Once you get into them though, they're some of my favorite
| games. NetHack might be the most absorbing game I've ever
| played, and there's a few others with that art style that
| came close.
| CGamesPlay wrote:
| Man, this Specs [0] library is so strange to me, coming from a
| Unity background. Is there some sort of comparison as to why one
| way is better than the other?
|
| [0] https://docs.rs/specs
| jakkos wrote:
| If you mean a comparison between SPECS' paradigm, ECS, and
| Unity's mix of OOP/composition, the main benefit of ECS is
| performance. The way ECS loops over arrays of data means that
| the memory accesses it makes are nearly always already in
| cache. Games spend a surprisingly large amount of time just
| waiting to receive values from memory. In the right
| circumstances, normally when dealing with huge numbers of
| objects (think simulation games), ECS can be entire orders of
| magnitude faster. Other than that some people just prefer
| coding in ECS. Unity has been developing its own separate ECS
| framework for a while now.
| bodge5000 wrote:
| ECS is an absolute pain to work with and makes everything so
| much slower...until it clicks. In the past I've compared it to
| learning programming all over again.
|
| The SQL reply summed it up quite nicely, basically you perform
| queries for anything with a class attached and then perform
| your operations on all of those. It sounds really inefficient,
| but in terms of raw performance the results usually speak for
| themselves.
|
| A good example I encountered with Bevy, another Rust ECS
| framework, is imagine you want your camera to follow your
| player. Rather than having a script on your camera and a
| different one on your player, you could just attach a generic
| class to both, query through anything with that class and
| update the position of it based on the input.
| nextaccountic wrote:
| Maybe you would like Bevy's ECS more?
| https://bevyengine.org/learn/book/getting-started/ecs/ (it's a
| later design that incorporated some improvements, like, you
| don't need to define a struct and impl a trait to define a
| system)
| dymk wrote:
| Bevy's ECS is incredibly ergonomic and makes writing ECS code
| fun. You give Bevy a function and it automagically turns it
| into a system by doing dependency injection. No need to write
| an impl for it, the system takes care of that for you. It
| makes prototyping very fun, as it's cheap to experiment with
| different system configurations.
| pornel wrote:
| It is a very different and seemingly weird approach. It's
| almost like writing SQL queries for your game world (e.g. "find
| all entities with a Flying component and attach them a
| WooshSound component). A clever memory layout makes these
| queries super fast.
|
| It makes separation of concerns very natural. Different
| parts/layers of the game, like inputs, AI, sounds, graphics,
| effects and animations can be coded separately. You don't end
| up with "god class" for player's object that does a bit of
| everything. You have player entity that has components
| attached, and each system operates on its own set of
| components.
|
| I can't really do it justice in a comment. It's a quite
| different approach, so it's not directly comparable. It's like
| OOP vs Rust's traits. ECS happens to match Rust's memory model
| and traits incredibly well.
|
| Here's a more in-depth talk about this:
| https://www.youtube.com/watch?v=aKLntZcp27M
| wdroz wrote:
| Even the Data-oriented design[0] is eyes opening (which is
| part of the ECS).
|
| The classic example is[1]: Instead of having a list of
| structs, where each struct get some types (int, float, ...),
| you use one struct, where the fields are list of types (array
| of int, array of floats, ...)
|
| [0] -- https://en.wikipedia.org/wiki/Data-oriented_design [1]
| -- https://en.wikipedia.org/wiki/AoS_and_SoA
| kramerger wrote:
| Unity uses ECS, just in a more visual way.
| wdroz wrote:
| I did some Unity3d back in 2013, I don't remember using
| ECS (intentionally?). After a quick search, it's seem
| that the MonoBehaviour are the old way and ECS the new
| ways? That's nice.
| kramerger wrote:
| When you drag and drop something into an object, you are
| actually adding a component to an entity.
|
| It's kinda behind the scene ECS.
| throwaway894345 wrote:
| I'm a little embarrassed to say that I've heard "roguelike"
| mentioned frequently, but I still have no idea what it means.
| What are some popular roguelike games that I might have played or
| could easily play to get an idea?
| nanomonkey wrote:
| Nethack is the one that springs to my mind. But I've never
| actually played the original Rogue. Angband is also fun, but
| never captured my attention like Nethack.
| fknorangesite wrote:
| > Roguelike (or rogue-like) is a subgenre of role-playing
| computer games traditionally characterized by a dungeon crawl
| through procedurally generated levels, turn-based gameplay,
| grid-based movement, and permanent death of the player
| character.
|
| https://en.wikipedia.org/wiki/Roguelike
| cupofpython wrote:
| Dead Cells is a popular recent one. Hades classifies as well I
| believe.
|
| A ~roguelike~ _rogue-lite_ is something where you start from
| the beginning repeatedly, and each "run" or playthrough you
| change the game state somehow (varies by game) so that the next
| run is easier / you have more in-game options for progression.
| Almost always with randomized game features available each run.
|
| It's worth noting that "rogue-like" is a description for the
| Game Play Loop, not the look / feel of the game. A roguelike
| can be top-down, side scroller, 2d, 3D, etc.
| fknorangesite wrote:
| > Hades classifies as well I believe. ... each "run" or
| playthrough you change the game state somehow (varies by
| game) so that the next run is easier / you have more in-game
| options for progression.
|
| Usually this is how the community differentiates between
| "roguelikes" (i.e., like the original Rogue[1] - with _no_
| persistence between runs), and "roguelites" where there is
| some amount of carryover, like in Hades.
|
| Of course, like any time you have a bunch of dorks arguing
| about nomenclature, there are a bunch of grey-area examples
| that people fight over as if it matters more than it actually
| does.
|
| Anyway, tangent: Hades fucking rules.
|
| [1] https://en.wikipedia.org/wiki/Rogue_(video_game)
| cupofpython wrote:
| Oh cool, I wasn't aware of that distinction
| hypertele-Xii wrote:
| > each "run" or playthrough you change the game state somehow
| (varies by game) so that the next run is easier / you have
| more in-game options for progression.
|
| You've fallen for the hostile takeover. Roguelike _used to_
| mean the exact _opposite_ of that: Each run starts from
| scratch, independent of all previous runs. _Some_ roguelikes,
| that is, games _like Rogue_ [0], implemented "player
| ghosts", monsters based on previously dead player characters,
| but _that 's the only persistent progression_ in a roguelike.
|
| It saddens me that the term has been hijacked by modern indie
| developers to pretend to mean just about any game that has
| any amount of randomness in it. Dead Cells is not a
| roguelike. Hades is not a roguelike. They are action RPGs
| more like Diablo. Diablo, by the way, is also not a
| roguelike.
|
| WHAT IS A ROGUELIKE?
|
| As the name suggests, it is a game _like Rogue._ The genre
| hasn 't evolved a better name yet, kind of how first-person
| shooters were originally called "Doom clones". So what was
| Rogue _like?_ First and foremost it was a turn-based tactics
| game, where you had an unbounded amount of time to ponder
| your next move. It had highly randomized content, you 'd have
| to make do with what you found. It was a dungeon crawling,
| exploration, turn-based tactical combat game with
| _permadeath_ and no persistence of progression. You lose, you
| start all over.
|
| [0] https://en.wikipedia.org/wiki/Rogue_(video_game)
| fknorangesite wrote:
| > It saddens me that the term has been hijacked by modern
| indie developers to pretend to mean just about any game
| that has any amount of randomness in it
|
| I think you are misunderstanding where people come from
| with this: it's not the randomness; it's games where when
| you lose, you start over from the beginning - not the last
| save/checkpoint/whatever. What this indicates is that, in
| the broader gaming scene, _this_ is the defining
| characteristic of Rogue(likes), not the permadeath.
|
| And in that sense, something like Hades or Everspace or FTL
| or whatever absolutely fits the bill, even if on your next
| run - from the beginning - even if you are very slightly
| stronger the second [third, fourth, hundredth] time around.
|
| I understand that there are still some purists out there
| who work themselves into a tizzy over splitting these
| hairs. But it's okay for there to be subgenres. It's okay
| for colloquial terms like this to have fuzziness to them.
| hypertele-Xii wrote:
| > I think you are misunderstanding where people come from
| with this: it's not the randomness; it's games where when
| you lose, you start over from the beginning - not the
| last save/checkpoint/whatever. What this indicates is
| that, in the broader gaming scene, this is the defining
| characteristic of Rogue(likes), not the permadeath.
|
| Starting over when you die is exactly how games worked
| since the arcade days. It only becomes meaningful in a
| roguelike when coupled with randomness; otherwise you're
| just replaying the same game over and over again (which
| is like, exactly the reason Rogue and its likes exist - a
| different adventure every time).
|
| > from the beginning - even if you are very slightly
| stronger the second [third, fourth, hundredth] time
| around.
|
| If you're stronger than before then it isn't _the
| beginning,_ is it? It 's a continuation. It's a save
| file. Rogue deletes your save file when you die.
| cupofpython wrote:
| I was going off of how the rogue-like tag is _currently_
| used in game marketplaces, like Steam. You are technically
| correct, I learned something new, and I updated - but as
| far as seeing the phrase in the wild and trying to predict
| what to expect, my comment stands.
|
| Hades and Dead Cells are certainly _not_ like diablo. the
| core game loop is to lose and try again, not build up a
| strong character over the course of a single playthrough as
| is typically expected of action-rpgs.
|
| It seems like the definition of rogue-like has expanded due
| to popularity of the genre (as things do) and you have a
| purist attitude that rejects the new compromises. Rather
| than create contention over something you cant control, it
| might be better to highlight permadeath and no persistence
| as a subtype of rogue-likes for which the original game
| falls under.
|
| And yes, it probably does need a better general-purpose
| name but unfortunately the thing it describes is rather
| abstract so idk what a concise self-evident phrase could be
| for it
| remram wrote:
| Most games labelled as rogue-like on Steam do not feature
| a persistent progression. Examples are Slay the Spire and
| Spelunky.
|
| Saying that it's _a feature of the genre_ is definitely
| wrong.
| cupofpython wrote:
| >Saying that it's a feature of the genre is definitely
| wrong.
|
| good thing I am not saying that then
|
| The point is that if you see "roguelike" then those
| features _could_ be there, not that they necessarily will
| be there. We are talking about a genre, which is a pretty
| general thing
|
| An FPS _could_ have grenades, but it might not. And
| including grenades does not suddenly mean it is no longer
| an FPS.
|
| Steam does list Dead Cells as both a roguelike and a
| roguelite. So yeah, you literally will find these
| features in this genre.
| nrjames wrote:
| Brogue is an excellent and free roguelike. You can grab the
| Community Edition of it over here:
| https://github.com/tmewett/BrogueCE
|
| It's fun to get a group of friends together and play a daily
| seed run... see who gets the most gold, who gets deepest, etc.
| graboid wrote:
| Holy cow, that's amazing. And it is so extensive. Thanks a lot
| for the link.
| bodge5000 wrote:
| Maybe a good place to ask, does anyone have any recommendations
| for game dev frameworks? Preferably something performant, stable
| and not too much of a pain to work with.
|
| Been using Godot for a year or two and loving it, but I do want
| to try out the code only workflow, I feel like it'd suit me
| better being freed of the constraints of an engine, but I'd at
| very least like to try so I can be sure.
|
| I tried Bevy before and it was fantastic, but its just not
| production ready. Also tried Raylib, the main problem with that
| being the sheer number of bindings somewhat segments the
| community and makes it harder to figure out how to start off
| with, but it might be worth another go. Might also consider going
| without a framework and just finding libraries to fill in what I
| need, but that might not play nice with "not too much of a pain
| to work with"
| krapp wrote:
| May be more lower level than what you're looking for but my
| current drug of choice when I want to write all the code is
| SDL2 and LuaJIT in Visual Studio.
| bodge5000 wrote:
| SDL2 I've been heavily tempted by, but it has a similar
| problem as Raylib where everyones writing it in a different
| language. Great when you know what your doing, but a bit more
| difficult to get up and started with.
|
| But maybe it is worth that extra time investment just for how
| popular and battle-tested it is
| pizza234 wrote:
| In Rust, there is none; they're just not ready, and not used
| either (there are very few full games written in Rust). The
| Bevy maintainers in particular give very low priority to
| foundational functionalities (see 1 frame lag and the unusable
| stages+states), and focus on advanced ones instead.
|
| There aren't so many alternatives actually (SDL is a very valid
| framework, but it isn't a game engine), and the choice depends
| on what's your real goal (experiment or develop a real game).
| In my opinion, if the goal is to produce a real game, for
| somebody who doesn't have significant experience, documentation
| (including: availability of books) is the top priority.
| bodge5000 wrote:
| Doesn't have to be Rust, pretty much any language (though I'd
| rather not Java just for personal preference).
|
| I'd say my goal is to produce a real game, its really just to
| experiment, but the experiment is to see if it should replace
| Godot for me
| Barrera wrote:
| What's not production ready about Bevy?
| norman784 wrote:
| Not stable release yet, so each release might bring a lot of
| breaking changes, when they release 1.0 the API at least will
| be more stable.
| pizza234 wrote:
| Two main problems:
|
| 1. state/stages can't be used together; since plugins may use
| states (and even baisc funcionality, like the fixed frame
| step), you can't use stages
|
| 2. in order to flush commands, you need stages, but you can't
| use them due to 1.
|
| The result is that with Bevy itself, writes (commands) become
| effective only at the end of each frame. There is a plugin
| written by a 3rd party, but the Bevy developers are treating
| this as very low priority (it's been open for a very long
| time, and it's not even scheduled for the next release).
| Paradoxically, it matters little because there's a lot of
| hype about Bevy, but there are little (or none) significant
| projects - only very small ones or demos, which don't require
| efficiency or precise timing.
|
| Additionally: the Bevy team doesn't write documentation at
| all. The "cheat book" is written by a 3rd party, with the
| consequence that it's partial, superficial, and it may be
| halted at any time (note that I don't fault the book
| maintainer(s); their contribution is crucial!). This isn't
| great when one approaches the engine for the first time; it
| actually sucks because engines like Bevy are (relatively)
| large beasts.
| pcwalton wrote:
| Note that https://github.com/bevyengine/rfcs/pull/45 is
| actually fairly active; it doesn't look like "very low
| priority" to me.
| alice-i-cecile wrote:
| Hi! I'm one of the four formal maintainers of Bevy. I'm not
| particularly interested in convincing you personally, but I
| think it's important to publicly address some
| misunderstandings.
|
| The scheduling rework that you're complaining about is
| _extremely_ high priority, and I have personally invested
| hundreds of hours into redesigning and refactoring this
| mess (which is now in its third serious iteration). It 's a
| challenging problem, and the volunteer who has taken
| responsibility for the rewrite has needed to step back for
| a while as they transition to a new job.
|
| I have also personally invested hundreds of hours writing,
| editing and reviewing docs for Bevy. That's what got me
| involved in the first place, and the team has done a great
| job. A fully revised book is also in the works, but getting
| the subtle details right are critical.
|
| As for serious projects: I've spoken with about a half-
| dozen commercial teams, including one with a team size of
| about 10 and a lifespan of nearly two years. Their feedback
| is remarkably positive given the immaturity of Bevy and the
| supporting ecosystem. While there are missing features that
| they want (hi bevy_ui), and annoying papercuts (yep, those
| scheduling concerns sure are annoying), they've over all
| been wildly impressed been how easy to maintain, reliable
| and performant Bevy has been for them.
| otikik wrote:
| > being freed of the constraints of an engine
|
| I am going to suggest the opposite: subject yourself to _more_
| constraints. Try programming on a retro-fantasy console like
| Pico-8 or some of its free alternatives.
|
| I found the (sometimes ridiculous) restrictions very
| liberating. In exchange you get raw immediacy. I want a game
| with a chicken on it. I spend doodle something with the 8-bit
| 8x8 bitmap editor. I draw it with 1 line of code, 4 more lines
| to control with the arrow keys. Total time: maybe 2 minutes.
|
| This radical immediacy is something I really missed in more
| unconstrained environments. I would get analysis paralysis
| "should it be a male or female chicken? what shader should I
| use to properly render the chicken wings when there's rain".
| hypertele-Xii wrote:
| Developing an actual game on PICO-8 is like solving a
| Zachtronics puzzle. Appealing to a small subset of developers
| who enjoy hex editing, hacking, and squeezing performance out
| of a limited system.
|
| But if you're more artistically inclined, you will only find
| frustration where PICO-8 flaunts its "cozyness". It imposes
| completely arbitrary and unnecessary restrictions where there
| should be none. These restrictions _will_ become a brick wall
| you eventually hit, and then you _have to_ start peeking and
| poking raw memory with hexadecimals like you 're programming
| in fucking C, or just give up trying to make the game you
| wanted to make.
| otikik wrote:
| I realize that this might not be for you, and that is fine.
| I must object to the "arbitrary and unnecessary" part. You
| might not agree with the reasons, but there _are_ reasons
| for the restrictions.
|
| I also want to say that I think of myself as actually very
| artistically inclined. An 128x128 screen in 16 colors is
| just a medium. You prefer other mediums and that's fine,
| but the implication of "Pico-8 isn't for artistic people"
| is simply not true.
| hypertele-Xii wrote:
| You're talking about surface level details and artistic
| choises. I'm talking about the _underlying workings_ of
| the engine, and the strangling limits placed thereupon.
| Limits like token count, which only serves to force you
| to "optimize" your code somewhere along development of
| your game because you suddenly "run out of words" to code
| a new feature you just thought of. Then the framework
| turns from "helps you make games quickly" to "grinds your
| progress to a halt because REASONS". Or if you wanted to
| make another level, the creative artist you are, but
| there's just not enough room in the map editor, so now
| you have to plug in a data compression library and lose
| access to the built-in map editor!
| garrypettet wrote:
| I've just started out with Flame and Flutter. As a newcomer to
| game development (but experienced in other genres of coding)
| I've found it great.
| lc9er wrote:
| There's Monogame, if you know C#. It's got a decent sized
| community and it's been used to create a number of popular
| games.
| bodge5000 wrote:
| Monogame is really tempting, I've heard great things about
| it. Funny little anecdote actually, I was originally against
| it as I felt it sat too close to microsoft, so decided to try
| a different framework with my usual editor, VSCode. Took me
| longer than you'd think to figure out the irony of that
| brennopost wrote:
| I enjoy love2d for small 2d games.
| jasonjmcghee wrote:
| You can do Godot with a code only workflow. The UI is just an
| abstraction over setting variables and writing configuration
| files. You'll likely want to use a language with good IDE
| support though, like C# (Mono). The Scene files can also be
| written by hand.
|
| But the Tool class (which you use to leverage the GUI) is so
| useful in Godot. You're probably going to use egui or imgui to
| build a replacement yourself in any other engine anyway.
|
| The instant feedback of changing key variables and seeing their
| effect is too useful not to leverage.
| bodge5000 wrote:
| Really good idea actually, I could test out the workflow of a
| framework whilst working with something I know. I remember I
| briefly looked this up in the past and there wasn't much on
| it, but maybe I should take another look.
|
| As for the tool class, I don't use that much in regular godot
| to be honest. It always felt a little like variable exports,
| a bit of a hack for users coming over from Unity to feel more
| at home but not "standard practice". Not sure why it feels
| like that to me, but I do alright without it.
| jasonjmcghee wrote:
| Oh man, it's so much more. You can put any code behind
| Engine.EditorHint condition and it only runs inside the
| editor. You can make shortcut keys to do things or execute
| code in _Process.
|
| For example, i've made a script where editing one tilemap
| updated another, the first being a palette for wave
| function collapse, generating the other.
|
| When i implemented vector fields, i first had it track the
| mouse instead of the player and did it all in the editor
| (not hitting play)
| fredrikholm wrote:
| I used this to learn Rust (after `book`), highly recommended!
| sanjayts wrote:
| What's the relation between this tutorial and the "hands on rust"
| book? Overlapping content or contains bits and pieces from the
| book?
| NonNefarious wrote:
| A "Rogue-Like?"
|
| Come on.
| NonNefarious wrote:
| greybox wrote:
| It's wonderful that someone took it upon themselves to write this
| and release it open source, thank you!
___________________________________________________________________
(page generated 2022-07-12 23:01 UTC)