[HN Gopher] Veloren - Open-source MMORPG written in Rust
___________________________________________________________________
Veloren - Open-source MMORPG written in Rust
Author : agluszak
Score : 241 points
Date : 2021-02-05 15:38 UTC (7 hours ago)
(HTM) web link (veloren.net)
(TXT) w3m dump (veloren.net)
| protoman3000 wrote:
| I like how everything written in Rust gets upvoted here.
|
| Jokes aside thanks for sharing. It's always interesting to read
| game source code and Rust beginners can learn a lot reading this
| code.
| drannex wrote:
| Reminds me of the three or so years HN was obsessed with all
| things node.js and npm that ended about three years.
|
| Rust is a great language, not my preference (Julia is better
| imo, and I still absolutely love C), but the community and
| tools being built in Rust are fantastic.
| ibraheemdev wrote:
| > Julia is better imo
|
| Can we please stop saying X language is "better" than Y? It
| really does not make any sense. Both languages were designed
| with _very_ different goals in mind. Each of them is a good
| fit for their respective use cases, but saying Julia is
| "better" than Rust makes no sense.
| ajkjk wrote:
| Completely disagree. There's a tendency these days to say
| that because you can't quantify better-ness, things can't
| be better. Which isn't true at all; betterness can be
| subjective or heuristic or approximate.
|
| Of course, saying something is better than something else
| is always prefixed with an implicit "I believe that...", so
| it's fine to argue with it. But that doesn't mean it's an
| illegitimate thing to say.
| bicx wrote:
| This comment was written in Rust
| goblinux wrote:
| I'm out of the loop, what is the huge fascination with Rust? I
| see people getting excited about normal sounding projects that
| are written in rust - is it the new C? new python?
| netizen-9748 wrote:
| Closer to the new C
| zelphirkalt wrote:
| The thing people get excited about are guarantees you get
| when compiling your (hopefully well written) Rust code.
|
| A huge chunk of software we have today is built upon other
| software that is built upon other software that ... but that
| whole foundation is rather shaky and probably incorrect.
| Basically, if you want to express it that way: Everything is
| broken and we have played the wrapping game for far too long
| as a professional group. There will probably forever remain
| bugs in that gigantic mountain of code, that we rely on.
|
| People get excited about rewriting things in Rust to avoid a
| good chunk of the legacy code written in languages that are
| not memory save and that do have a lot of undefined behavior
| or allow for race conditions easily once you even as little
| as touch concurrency. People want to finally have a solid
| basis, which is proven to be correct in implementation. Rust
| goes a long way towards this goal, so people like it.
|
| I subscribe to some great projects' repositories and read the
| issues. These projects sometimes bring me great value and I
| am not saying they aren't useful. Usually however, non-
| trivial C++ or C (and other languages) projects have all the
| same kind of issues. People thinking every noun has to be a
| class and the standard paradigm of mutating everything
| everywhere, be it through setter or directly, then forgetting
| to update state at some point, where it was necessary. People
| sharing state across multiple threads and forgetting to
| acquire a lock or releasing it. Or in some other way building
| race conditions. People thinking they will be able to do
| manual memory management correctly and then having segfaults,
| which require long debugging sessions or a lot of experience
| to fix. Use after free bugs. Security issues resulting from
| such causes. This and all that kind of stuff, that a good
| type system should prevent you from doing. And that is where
| Rust delivers.
| serverholic wrote:
| Here's a relevant statistic. Microsoft tracked all their
| security vulnerabilities over 10 years and found that 70%
| of them were caused by memory-related bugs.
| swsieber wrote:
| For me personally:
|
| * It has the performance profile of C
|
| * A really good package manager
|
| * I don't have to worry about segfaults/runtime issues from
| manual memory management
|
| * I love the type system (yay expressive static types with
| pattern matching)
|
| * Also prevents data races and other things like iterator
| invalidation
|
| * Also, null safety, among other things leads to a lot fewer
| runtime issues I need to figure out
| __s wrote:
| New C since it's about zero cost abstractions (in the don't
| pay for what you don't use sense)
|
| It does this well, since at the same time I was able to write
| 10k lines of JS game code into 10k lines of Rust game code: h
| ttps://www.reddit.com/r/rust/comments/k3jy5g/i_rewrote_10k_..
| .
|
| Have since rewritten server from nodejs to Rust. There the
| line count grew. But async/await was splendid there, & serde
| made implementing the json server/client protocol straight
| forward
| protoman3000 wrote:
| Borrowchecker and lifetimes automatize a big chunk of
| verifying all the states my code can yield.
|
| Rust has many zero cost abstractions that make writing things
| easier.
|
| It's super high level at the speed class of C - sometimes
| even faster given that libraries for common tasks are well
| programmed. With the high level abstractions the compiler may
| probably reason and optimize better?
| mynameisash wrote:
| Others may give a better answer, but from my perspective -- a
| data engineer who started learning rust maybe 8-10 mo ago --
| I find that I am enjoying Rust because:
|
| * It has algebraic data types, pattern matching, etc. -
| language features that just don't exist in most languages
| I've used. (I did play with F# for a bit and really loved its
| capabilities, but I've never had the occasion to get into F#,
| unfortunately.) Once I start using these features, I suddenly
| find that all these other languages are sorely lacking.
|
| * Its safety guarantees mean that I spend more time in the
| IDE fixing compiler errors and less time in the running exe
| finding my problem. I often find that when my program
| compiles, it is generally correct. This has given me a lot of
| confidence in the quality of my releases (borne out in actual
| production code, not just toy projects)
|
| * Speed of execution is (in my experience), better than an
| order of magnitude faster than in other languages for a
| similar implementation.
|
| YMMV, and there may be some of that New Relationship Energy
| here, but I can absolutely see why it's been on SO's most
| loved languages for five years in a row[0].
|
| [0]
| https://insights.stackoverflow.com/survey/2020#technology-
| mo...
| MauranKilom wrote:
| I read all the HN comments and it wasn't until I saw the logo on
| the site that I noticed the game isn't actually called "verloren"
| ("lost" in German). That makes me wonder: How did you come up
| with this choice of name?
| jarbus wrote:
| Been following this project for a while. Incredible community &
| devs, and it's getting better with each update. Surprised at how
| well it runs, too.
| rektide wrote:
| two years of weekly blog updates on the project! that's super
| impressive
|
| in open source, talking about the work is really as important
| as doing the work. a key catalyst in turning "free as in beer"
| to the kind of communal shared understanding anarcho-
| syndicalist working practicing healthy community. i want a
| "free as in ourselves" mantra or some such to trot out here.
| anyhow Veloren keeping their story of development alive is such
| a respectable powerful act, keeping users & developers &
| everyone in between engaged & interested & learning.
| Grimm1 wrote:
| This is super neat, I've been looking for an experience just like
| this recently. I think I'll be spinning up a server!
| zesterer wrote:
| That's great! Make sure to tell us if you do, we'd love to put
| it up on the public server list!
| Grimm1 wrote:
| Yup definitely will let you know
| moritonal wrote:
| Looks neat. I'm struggling to get why Rust is important in this
| context? Is it a demo of Rust's features and a fun way to learn,
| or is it a major feature of the game which lets you do things
| that games like Miecraft (in Java) couldn't do?
|
| * I'd assume peformance was great, but is there metrics to show?
|
| * Is the client and server written in Rust, or just the server?
| zesterer wrote:
| Hi, I'm the founder of the project.
|
| We chose Rust because it's performant, memory-safe, and comes
| with a host of modern features that make writing code with the
| language very enjoyable.
|
| We could have chosen C++, but I'm very glad that we didn't.
| Memory safety is great: I've not needed to break out gdb even
| once throughout the history of this project, despite the size
| of the project. This safety means that code is easier to review
| because it 'does what it says on the tin' and is much less
| prone to UB and non-local behaviours. It also reduces the
| prevalence of bugs. I've been shocked by just how much easier
| it is to write reliable and bug-free code with Rust than it is
| with languages that I've used in the past (C, C++, Python,
| Vala, amongst others).
|
| The type system is also very powerful and it lets us encode a
| lot of useful invariants that can be checked by the compiler.
| Knowing that what you're doing is correct-by-nature is a great
| help and it frees your mind up to focus on the logic of what
| you're writing rather than getting distracted by irrelevant
| details like representation.
|
| Rust plays very well with data-oriented design. This works
| great for us. At its heart, Veloren uses a high-performance ECS
| that is extremely cache-coherent. There's still lots of
| optimisation work to do, but we're already seeing that servers
| that can handle hundreds of players and millions of entities
| without issue, despite the fact that terrain generation is done
| server-side (and, as such, we have similar performance
| constraints to games like Minecraft).
|
| The client, server and client/server frontends (frontends are
| logically independent and alternative frontends can be written
| for the game) are all written in Rust. In addition, the in-
| development plugin API will allow for plugins written in Rust
| and compiled to WASM.
|
| In addition, Rust is also very portable. Compiling the game on
| (and for) many platforms is incredibly easy. The game runs well
| on Windows, Mac OS, Linux, BSD, and community members have even
| gotten it running on the Raspberry Pi and a hacked Nintendo
| Switch!
|
| I hope this doesn't come across as being overly evangelical,
| but I think I speak for all of the developers when I say that
| we have no regrets in the slightest about choosing Rust! That
| doesn't mean it's the right choice for all projects, of course.
| The Rust gamedev ecosystem is still relatively immature.
| Although this is changing fast, don't expect to find any nuts-
| and-bolts game engines ready to go. However, if you're not
| afraid of diving down into low-level APIs here and there, Rust
| might be a great choice.
|
| Edit: At a second glance, I see you're asking more about why
| mentioning the language is important. As a community-driven
| project, we rely on encouraging new contributors to work on the
| game and the choice of language is something that developers
| usually care about a lot. Extensibility and open development is
| really important for us and so 'showing the innards' is a big
| part of what we do when interacting with the community. Unless
| it's security-sensitive, we'll always discuss development
| issues and ideas in a public forum where anybody can add their
| input.
| moritonal wrote:
| "I hope this doesn't come across as being overly evangelical"
|
| Not at all, I'm worried now my post seemed mean! This was
| exactly what I was looking for. I wanted to know if this was
| chosen just as a PoC for Rust, or whether it actively made
| development better (which it sounds like it does :D). There's
| a big difference between "Here is X written in Rust" and "X
| is so much easier because we wrote it in Rust!".
|
| The fact you then go on to use ECS within Rust must have
| amazing returns on metrics. Good luck on your progress!
| aimor wrote:
| I heard about Veloren from the Rust Game Dev Podcast (Aug
| 2020). I really enjoyed listening to the team talk about
| details of the game's development, thank you for talking
| about it so openly.
|
| https://rustgamedev.com/episodes/interview-with-team-veloren
| Geminidog wrote:
| The fact that you haven't used gdb is a huge deal. This is
| very rare in large C++ projects.
| ksm1717 wrote:
| I think they were more asking why Rust matters to us as
| readers or users. Not that it isn't great insight, but your
| answer is more like why rust matters to you.
| lubesGordi wrote:
| The answer matters to people who write games in C++, or
| anything in C++. They want to know that Rust can handle/be
| productive in various domains.
| ksm1717 wrote:
| Agreed
| Kye wrote:
| The #1 problem in MMORPGs is people exploiting bugs for
| personal gain at the expense of the game's economy and
| competitiveness in PvP. Some of those bugs end up being in NPC
| scripts, but most are the kind Rust helps prevent.
| Thaxll wrote:
| This is not true, Rust woudn't prevent anything in most
| cheats / issues you see in online games. 99% of them are
| busines logic related.
| spijdar wrote:
| Which bugs? I wasn't under the impression that exploiting
| memory safety issues was the dominant type of bug to gain an
| advantage in multiplayer games, but usually logic errors or
| some kind of broken script, corner cases in nested control
| structures, that sort of thing.
|
| I can see an argument that Rust could also help prevent those
| as it is a higher-level language and has a few language
| features to prevent _some_ of the logic problems, but not
| that many?
| zesterer wrote:
| It's a mixed bag. Short of defining a formal spec and
| writing the program with a theorem prover, "bug-free" code
| isn't really a realistic goal. However, Rust does come with
| tools that at the very least allow the building of APIs
| that are very difficult to abuse via the trait system and
| other features such as sum types. Ultimately, spaghetti
| code is possible in virtually any language, so keeping a
| good eye on architecture is necessary no matter the
| language. What I would say is that Rust makes it _easier_
| to keep architecture constrained and correct.
| gpm wrote:
| Honestly, I think rust actually prevents a _lot_ of logic
| problems, but it 's hard to quantify and a subjective
| feeling that I'm not sure how I'd even go about trying to
| "prove". Order of magnitude I'd say 50% less _logic_ bugs
| than a language like Java.
|
| Why? Just good language design. Things like "enums"
| (algebraic data types, not C-enums) making for type checked
| state machines, really strict typing, immutability by
| default, simple language semantics, good linters that
| people actually use, the borrow checker actually does
| usually lend itself to good design too, and so on.
| zesterer wrote:
| This is a good summary tbh
| bcrosby95 wrote:
| Why must you trigger my inability to stick to a
| programming language? Elixir, Clojure, or Rust - round-a-
| round in my head they go. Will it ever stop, hell if I
| know. _sigh_
| Kye wrote:
| My knowledge is many years out of date, so I might be
| wrong.
| spijdar wrote:
| I'm also not really that familiar with either Rust or
| modern multiplayer games, I'm just speculating. It seems
| like if you could buffer-overflow the server, there are
| more sinister things you could do besides game-the-
| game...
|
| (that said, I have personally found bugs in text-based
| MUDs that could have been prevented by Rust. They were
| all "just" DoS bugs though, instantly crash the server
| type things)
| hctaw wrote:
| There are memory safety bugs that won't cause a
| segmentation fault or create a buffer overflow exploit, but
| result in logical errors. For example:
| void inner (const T& t1, T& t2); void outer (T* t,
| int i, int j) { inner(t[i], t[j]); }
|
| There are three memory safety bugs in that code:
| - the pointer `t` is not checked for null - the
| indices `i` and `j` are not checked to see if they are
| outside the bounds of `i` and `j` - the indices `i`
| and `j` are not checked to see if they are the same.
|
| The first bug will cause a segfault and crash. The second
| is a potential buffer exploit. The third is a logical bug
| that can be exploited depending on what inner() is supposed
| to do. Most people know to check the first two, the third
| one is subtle and isn't necessarily a bug. But it may
| become a bug that can be exploited inside `inner`,
| especially over the lifetime of the code.
|
| Rust will prevent all three, or force you to perform the
| checks before using an `unsafe` block.
|
| But more than that, this kind of issue crops up due to an
| inherent weakness of code review - it catches errors in
| blocks of logic, but not in logic below it and logic above
| it. Since C/C++ don't have idiomatic error handling worth a
| damn (the only "idiomatic" errors in C++ are debug
| assertions, ime) you can't defend against silent logic bugs
| due to violating invariants of callers or callees that are
| expressed through Option/Result types in Rust (I mentioned
| this in a comment above). That's the real benefit of
| writing code in Rust, in addition to the absence of
| footguns.
| zesterer wrote:
| > The first bug will cause a segfault and crash.
|
| Or, you know, nasal demons
| rowanG077 wrote:
| In general in most modern languages there aren't really things
| you "cannot" do with one language that you could with another.
| It's more of a question of how easy it is to do something.
|
| And in general is should be much easier to create a performance
| sensitive game in Rust then in Java. Besides that Rust is much
| more ergonomic to use.
| Macha wrote:
| For certain classes of developers (of which I'd include
| myself), Rust is more accessible than C++. The tooling is more
| modern, the APIs feature functional constructs I'm used to for
| other languages, and it's not like C++ doesn't have its own
| feature explosion. If you're an open source game project, then
| it's signalling what developers might be most interested in the
| source in the hopes that some will then contribute, when
| addressing a forum of primarily developers.
| emteycz wrote:
| I think it's important piece of information for HN given it's
| open source. I wouldn't care if it was closed source.
| zelphirkalt wrote:
| Rust is probably mentioned for the more up to date language
| concepts and type safety, as in "Look, our code is probably
| more reliable than the code of many other games.", which in
| turn might mean, that the user experience will be better.
|
| Those things could be a huge deal for any game developer,
| especially, when you already know Rust.
| musingsole wrote:
| But is Skyrim even worth it if you don't have mammoths
| walking in the sky and broken necks from overzealous head
| tracking?
| hctaw wrote:
| I think Rust makes a compelling case for production code with
| a high degree of reliability without sacrificing too much
| performance. Something I think developers don't appreciate
| enough is that Rust helps you write code that doesn't crash
| nearly as much as something in C/C++, particularly with
| respect to how library authors express fallable code with
| option/result types and the lack of memory safety footguns
| like iterator invalidation.
|
| Consumer software is better without crashes. It's sad how
| rife software is these days with segfaults that can be
| prevented by design.
| imbnwa wrote:
| Superficially speaking, I've seen a lot of comments around
| Rust's mismatch for assuming C++'s duties in game development
| so perhaps this is one of those "Rust in Production" signals
| hombre_fatal wrote:
| Minecraft was written in Java, so that can't be it.
|
| Open-source + built in a slightly interesting language are
| the only reasons we'd be discussing an MMORPG.
|
| Good luck to the team. MMORPG that anyone wants to play is
| probably the hardest challenge in gamedev and game design.
| imbnwa wrote:
| > Minecraft was written in Java
|
| Did not know that
| Macha wrote:
| > Minecraft was written in Java, so that can't be it.
|
| And everyone who plays large modpacks, goes around large
| buildings, or just sets off a ton of TNT has seen how it
| has suffered for it.
|
| On the other side, anyone who has seen the selection of
| mods available for Java edition vs bedrock edition (the C++
| rewrite) despite a modding API for bedrock being officially
| supported has seen how it has benefitted from this.
| pjmlp wrote:
| 2nd system effect, badly written mods perform poorly
| regardless of the language.
| vlang1dot0 wrote:
| > Minecraft was written in Java, so that can't be it.
|
| What does that have to do with the parent comment? The
| usual argument I've seen is that game developers "move too
| fast", "don't have everything designed ahead of time",
| "have to iterate quickly" and Rust's insistence on writing
| correct code gets in the way of that during the prototype
| phase.
|
| Java doesn't really have that issue as it is quite a bit
| more forgiving than C++ and will happily let you hammer a
| square peg into a round hole at the expense of performance,
| as evidenced by Minecraft.
| pjmlp wrote:
| The only evidence is that school kids cannot write mods
| like AAA studios, it wouldn't be any different if those
| mods were written C++, or JavaScript (Bedrock)
| hinkley wrote:
| As a wannabe game designer who moved on quickly to other
| things: object lifetime problems are a bane of game design.
| They give you memory leaks, and in some situations are how item
| duplication bugs work.
|
| In particular if you do the engine as a collaborative piece,
| then running a game starts to look like any other volunteer
| group: a bimodal distribution where few old hands keep it on
| the rails, a lot of new people whose raw enthusiasm overpowers
| their lack of experience, who need to be given tasks they can
| not fuck up so badly.
|
| In between it's a race between burnout and life balance for the
| people who have shown up for three years. They provide a lot of
| the leadership and competence, but they also tend to disappear.
| So you need to groom the newbs to replace them regularly. The
| old hands are the scribes who provide historical data when
| those transitions don't go smoothly. They are continuity and
| influence, not productivity.
|
| Any system that provides some safety for people still working
| out how to contribute is going to fare much better than one
| that is alienating. Rust to me is a mix of both, therefore
| plausible but not a slam dunk.
| mkl95 wrote:
| As a part time game developer who uses mostly C++ and a bit of
| Python, I have considered writing a project with Rust a few
| times, but I've always struggled to find meaningful examples.
| This is game-changing.
| renewiltord wrote:
| It's a dev community. The language is important as a hook for
| people interested in writing code in the language.
| Shared404 wrote:
| I've been keeping an eye on this one, it's not quite there yet if
| you are looking for a game to play. However, it has a massive
| amount of potential, and I'm looking forward to seeing where it
| goes from here.
|
| I've also read the code looking for examples of how to do things
| in Rust, and found it quite pleasant.
| adamnemecek wrote:
| It's like the first large scale game written in Rust.
| f430 wrote:
| what would be the advantage of this vs established libraries
| written in C#? any thing Rust offers that other languages
| don't? website is short on details, would be great if they
| could display its features. There are other MMORPG/MMO
| frameworks that are quite mature but this looks promising
| too.
|
| edit: reply to one of the comments below regarding the
| argument Rust = good therefore great for gaming. This.
| Neither does a good engine. For me I stopped UE4 and went to
| Unity because of the sheer lack of documentation and
| community support behind C++ with UE4. C++ is a powerful
| language but man was it hard finding tutorials and
| documentation that was up to date.
| chundicus wrote:
| Likely a joy for Rust and a desire to try something
| ambitious that hasn't really been done.
|
| Rust doesn't have the mature libraries that C# offers, but
| it isn't barren anymore either. It does offer nice
| assurances like entirely avoiding race conditions by
| default (when using safe Rust). Rust often leads to
| performant code, but it's hard to say if that's really a
| feature of the language or just a bias due to the kinds of
| people using it and the projects they work on.
|
| If you're just looking to get into game development without
| any other goals in mind, then C# is a safer choice
| Xevi wrote:
| > It does offer nice assurances like entirely avoiding
| race conditions by default (when using safe Rust).
|
| Doesn't it "just" prevent data races? I don't think it
| prevents all race conditions.
| chundicus wrote:
| Data races is what I meant; good catch.
| steveklabnik wrote:
| You are correct, yes.
| carlmr wrote:
| >Rust often leads to performant code, but it's hard to
| say if that's really a feature of the language or just a
| bias due to the kinds of people using it and the projects
| they work on.
|
| It does make memory management much more explicit, which
| makes it at least easier to write performant code.
|
| The question however is what your program is doing. If
| it's limited by network requests or something similar
| with high latency you won't be able to optimize much on
| the language side of performance.
|
| If however you're processing a lot of strings, the safe
| borrowing mechanism can help you avoid most copying.
|
| For example on my previous job we had a part of our CI
| build that would parse a huge text file and combine it
| with some information from an ELF's debug info in Perl.
| It took 45 mins for one execution. It was also impossible
| to read.
|
| I rewrote it in F# which after some heavy optimization
| work worked through it in 2 mins.
|
| I had just heard of Rust and rewrote it in Rust,
| basically transforming F# to Rust syntax and trying to
| eliminate as many copies as possible. Now the whole
| execution took 8s.
|
| So at that point I was sold on Rust, however the library
| ecosystem was still lacking. Nowadays it's much better.
| [deleted]
| brundolf wrote:
| To add to what others have mentioned, relevant features
| that come to mind (when comparing with C++):
|
| a) Module system lowers the complexity overhead of using
| third-party libraries, which means you aren't
| tempted/required to reinvent as many wheels
|
| b) Easy, reliable, monolithic build system, particularly
| for cross-platform builds
|
| c) Ease of writing bug-resistant concurrent logic (my
| understanding is that concurrency doesn't get used much in
| games because it's so hard to get right)
|
| Of course the above can mostly be said for C# too. But Rust
| could maybe be seen as the best of both (C++/C#) worlds
|
| I would say its biggest disadvantage is simply that neither
| major engine uses it (officially). Unity and Unreal are so
| powerful at this point (and free for smaller projects!)
| that you're better off using them for nearly any game
| project, unless: a) you just feel like writing your engine
| from scratch for fun, b) you're doing something wildly
| novel, or c) you're a AAA studio that can afford to hand-
| roll an engine in order to save on licensing fees down the
| road. Maybe Rust will see adoption in category c one day,
| but there's a huge amount of institutional momentum to
| contend with.
| adamnemecek wrote:
| The goal is making these libraries in Rust. Rust is
| fundamentally a better language for game development than
| C#.
| Thaxll wrote:
| 0 games have shipped in Rust and there is no plan anytime
| soon in the future that it will.
|
| People think that a good language would make a good game,
| that's error #1. The ecosystem matters more than the
| language itself, basically using Rust is starting from
| scratch so you can't use all the good things that C++ /
| C# had for the last 15 years.
|
| Edit: I want to clarify that I know that Rust is a good
| language, but as of now in 2021 it's just not ready for
| games, and there is no sign of change. It's fine to say
| "I can make games in Rust, it's going to be hard and
| painful but I can get something, but saying it's better
| than C# is definitly wrong.
| adamnemecek wrote:
| > 0 games have shipped in Rust and there is no plan
| anytime soon in the future that it will.
|
| The language is still pretty new but there is a lot of
| people investing in this. Embark studios and Ready at
| Dawn come to mind.
|
| > People think that a good language would make a good
| game, that's error #1. The ecosystem matters more than
| the language itself, basically using Rust is starting
| from scratch so you can't use all the good things that
| C++ / C# had for the last 15 years.
|
| It's not an error. Ecosystem matters but to a point. Like
| game engines are written with a particular type of game
| in mind. If your game doesn't fit the particular use
| case, it might make more sense to roll your own. Also, if
| you have been building your own game engines in C++,
| doing it in Rust should not be much of a problem.
| smolder wrote:
| If you're waiting for some AAA title to ship, you'll be
| waiting a while. Big studios aren't going to be first
| adopters and they have expensive commercial tools for
| building games already. That said there are a bunch of
| toy project Rust games you could say are complete or
| "shipped" and many more games under development. There's
| no reason to be pessimistic about its use in the space.
| https://itch.io/games/made-with-rust
| vlang1dot0 wrote:
| > 0 games have shipped in Rust and there is no plan
| anytime soon in the future that it will.
|
| That's trivially false.
|
| > Last week, I released A Snake's Tale on iOS, Android,
| Windows, Mac, and Linux.
|
| > A Snake's Tale was programmed entirely in Rust, and to
| the best of my knowledge, it is the first commercial game
| made in Rust to be released.
|
| Dated 09 May 2017.
|
| https://michaelfairley.com/blog/i-made-a-game-in-rust/
| adamnemecek wrote:
| I think the parent means like AAA games.
| bogeholm wrote:
| Moving the goalpost
| Sinidir wrote:
| no
| Thaxll wrote:
| As someone replied I was talking about AAA games indeed,
| everyone can make a game in any language with 50 reviews
| on the app store after 3years.
| steveklabnik wrote:
| AAA games are coming, there's at least two studios public
| about their in-progress Rust work. And backchannel
| whispers that may or may not come to fruition with more.
|
| Time will tell.
| vlang1dot0 wrote:
| What AAA games exist in C#?
| NortySpock wrote:
| Kerbal Space Program, for one
|
| https://unity3d.com/showcase/case-stories/squad-kerbal-
| space...
| serverholic wrote:
| Gotta start somewhere.
| netizen-9748 wrote:
| Sounds to me like those things just need to be rewritten.
| Or is the plan to keeping using the same language and
| libraries for the next 60+ years?
| timwaagh wrote:
| Rust has an interesting way of handling memory so that you
| don't need a GC. GCs can cause stutters in games.
| pjmlp wrote:
| You can do a full GC between loading levels, while using
| a little allocation as possible during a frame rendering.
| vlang1dot0 wrote:
| It's a game not a framework unless I'm completely
| misreading their website.
|
| The advantage vs some C# library is essentially the
| advantages of Rust over C#: precise control over memory
| layout and usage, no GC, higher performance, an ecosystem
| that was designed to be x-plat from the beginning instead
| of bolting that on after the fact.
| pjmlp wrote:
| I bet there are more platforms supporting Unity and
| Unreal (which also has C# support) than Rust.
|
| C# also has all the C++ like mechanisms to do GC free
| allocation.
| UnpossibleJim wrote:
| I'm not sure this is why they did it (I doubt it is), but
| reading through the documentation I saw that it's playable
| on Linux, Mac and Windows. I don't know when I've seen an
| MMO that's not browser based that was playable on all three
| platforms. C# engines usually ship to Windows and Mac -
| though, in saying that, I'm not sure if that's engine
| enforced or developer choice.
|
| The most likely reason they chose to do it in Rust, though,
| is because they wanted to and no one else had.
| zesterer wrote:
| BSD too!
| lwansbrough wrote:
| Two Rust features stand out to me: no GC, and Rust's
| excellent wasm support. In the Unity games I've played GC
| doesn't seem to be much of an issue but your code is always
| going to be faster in Rust.
|
| I use C# (.NET) daily and I think it's great for game
| development, but Rust certainly has its own advantages.
| zesterer wrote:
| > In the Unity games I've played GC doesn't seem to be
| much of an issue
|
| Remember that all of the 'hot' code is internal to Unity
| and is not written in C#. C# basically just takes on the
| role of a particularly powerful scripting language and
| isn't dealing with cleaning up huge amounts of data as
| would be the case for anything dealing with assets
| directly.
| adamnemecek wrote:
| It's very easy for it to become an issue if a game was
| written in Unity though. It tends to be really sluggish.
| E.g. Disco Elysium (amazing game) but the load screens
| were too much.
| pjmlp wrote:
| Unity is rewriting their C++ code in the HPC# subset and
| Burst compiler toolchain.
|
| There are a couple of talks related to it.
| [deleted]
| gpm wrote:
| Zesterer (a dev) answered this in depth to another comment
| on this thread, ctrl-f for that name ;)
| jtanderson wrote:
| Alternatively, here is a link to the in-depth comment!
|
| https://news.ycombinator.com/item?id=26038027
| atoav wrote:
| Where Rust really shines compared to other languages IMO is
| when software grows beyond a certain scale. The way the
| language forces and encourages you to "do it properly"
| really prevents a lot of lazy decisions that would come
| back to haunt you later in unexpected ways.
|
| The magical part about Rust really is how accurately
| (compared to other languages) you know which little gear in
| the big machine is failing. Often you even know precisely
| why and how it is failing.
|
| Precondition for this is of course that you really grok
| Rusts ownership and type system.
| est31 wrote:
| You can do it non-properly in Rust as well, e.g. using
| unwraps, etc. but even then it's still way better than an
| UB-ridden component of a C++ codebase.
| sinistersnare wrote:
| Using `unwrap` is not something that can come back to
| bite you in a long term (other than API design wise).
| Replacing it is dead easy, as the compiler helps you.
| Also, you can replace it with a call to `expect` to give
| a relevant message too.
| est31 wrote:
| That's why I said it's way better. It's usage is still
| not considered good practice for most scenarios.
| pling87 wrote:
| Context: For those of you who still remember it, CubeWorld was a
| Minecraft-like RPG game that had a wildly popular Alpha, was
| eventually abandoned by its developer, was later revived, and was
| then universally vilified by the masses because the developers
| "ruined" the game.
|
| Veloren is the spiritual successor to CubeWorld, made by
| disappointed fans wanting something better.
| Quot wrote:
| Just a small correction to that (because I don't like the hate
| that the Cube World devs get):
|
| They never abandoned the game. It was a two person team
| (husband and wife), and both devs worked full time jobs while
| making CW. After the initial alpha release, CW got a ton of
| attention and became a DDoS target, which triggered some mental
| issues in the lead dev.[1] They went dark after that for a long
| time (probably because everything new was usually posted by
| this lead dev).
|
| The silent mystery with the game just built up even more hype
| over six years until the full game finally released, and the
| massive attention and disaster seemed to happen all over again.
| Every post about the game complained about the new design
| decisions with leveling. The lead dev seemed to think this was
| the best version of the game (based on his comments in his
| blog) and he seems to not have taken the criticism well,
| leading to him going dark again.
|
| I wish he would have taken the hits and continued with the
| game, but if it's affecting his mental health in this way, he
| is probably better off abandoning it. I hope he gets better and
| I am still looking forward to anything he and his wife make in
| the future.
|
| [1]
| https://web.archive.org/web/20190910123212/http://wollay.blo...
| pling87 wrote:
| Thanks for the clarification. Not to throw shade on the
| original CubeWorld developers - the work they did and the
| level of polish they were able to achieve was quite
| incredible for such a small team.
| zesterer wrote:
| Yep, this is correct. All of us Veloren developers very much
| appreciate the work the Cube World developer put into the
| game: it's great fun. Veloren isn't trying out outright
| compete with the game: increasingly, the project is adopting
| goals that differ. Over time, I'd like to see Dwarf Fortress
| be the game Veloren is most frequently compared to instead,
| since that seems to be the direction of momentum.
| protoman3000 wrote:
| Anybody looking for the actual source code, it's here:
|
| https://gitlab.com/veloren/veloren
| timwaagh wrote:
| Would have been better to do the game on a commercial basis and
| release the engine open source if they wanted to demonstrate the
| viability of game dev in rust, but otherwise it looks promising
| Karsteski wrote:
| I've been hearing about this game for a while now, I'm very glad
| it's making progress. I'm going to start following the blog as
| I'd like to try it out myself. I'm also glad that it's written in
| Rust, as I would very much like Rust to succeed as a high
| performance programming language :)
| Kiro wrote:
| What is the gameplay like?
| zesterer wrote:
| We're aiming for something that plays a bit like Legend of
| Zelda but allows you to interact with the world in a manner
| closer to Dwarf Fortress. We're also trying to keep movement
| fluid and dynamic with lots of opportunity to use the
| environment around you as you move throughout the world.
|
| All of this is a work in progress (hence the pre-alpha
| versioning), but we already have a few hours of gameplay with
| dungeons and caves to explore, lots of items to craft and find,
| and several skill trees to upgrade. In the long-term, we're
| aiming for more procedural interaction with elements of the
| world.
| mepian wrote:
| Is it possible for players to modify the world's landscape,
| like in Minecraft? If not, is this planned for the future?
___________________________________________________________________
(page generated 2021-02-05 23:01 UTC)