Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game dev in Rust: a year later

users.rust-lang.org

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Game dev in Rust: a year later

#61

Post by pjmlp »

johnnyanmac wrote: post #51
pjmlp wrote: post #38

Earlier quoted context omitted.

Since Burst compiler was introduced for HPC# subset, that C# is used for engine internals as well. Unity is like doing AI with PyTorch, or CuPy, yep there is a low level C++ layer for the GPGPU code, that hardly anyone touches directly. By the way, CAPCOM goes even further, they have their own .NET Core fork, and games like Devil May Cry for PlayStation 5 were made with it.

>Since Burst compiler was introduced for HPC# subset, depends a lot on how far DOTS has come. I'm a few years out of date, but DOTS (and by extension, Burst) was more or less a very separate codepath you needed to opt into. Any game using it today needed to make the consious effort to grab the Burst package an integrate those optimizations themselves. I have heard plans to try and more or less integrate DOTS into the…

That is already much improved on Unity 6, and Unity 7 roadmap has more unification as plan.

https://unity.com/blog/unity-6-features-announcement

https://gamefromscratch.com/unity-7-development-roadmap/

Re: Game dev in Rust: a year later

#62

Post by xqt40 »

pjmlp wrote: post #39
xqt40 wrote: post #35

Earlier quoted context omitted.

I'm afraid, you would sooner see safe code in assembler with the help of ai than in rust. You can argue that ai can be used to enhance rust, but at this point why bother if ai will be writing code by your instructions.

Some people haven't yet understood that the transition into AI is similar to how optimising compilers mostly replaced Assembly programming. While not yet there, eventually AI based code generation will be good enough to generate native code directly, without going through existing languages code generation. So while we might get the equivalent of a -S compiler switch, to dump the AI compiler decisions and fine tune t…

Like I mentioned - belief in Rust is a religion and I got a proof in those negative votes.

I don't think that people like you understand what are appliances for AI - it is not about writing or optimizing code, but writing language from the scrap if needed. And my remark was that Rust will hit the wall where it will need to go fully AI, because developers simply can't fullfill the promise of safe code by default as it would require inhuman testing to even get near that promised result. Also Rust is meant for humans - which loses any edge if switch is happening towards descriptive and not even programming language that developers will use. Rust here simply has no edge at all as any programming language can be improved with memory safety in mind.

Re: Game dev in Rust: a year later

#63

Post by xqt40 »

johnnyanmac wrote: post #49
xqt40 wrote: post #34

Earlier quoted context omitted.

There are plenty of passion projects that have been successful. So this is not an excuse. I've abandoned rust because I don't find it useable to me with unneeded complexity to code. Also with graphics most of the code was not safe. So believing only took me that far.

so the retort is survivor's bias? Hollow knight was a game jam game, so my 2d autorunner definitely coulda made 8m dollars, right? >I've abandoned rust because I don't find it useable to me with unneeded complexity to code. I don't want to be too dismissive, but if you dont care about code safety, Rust is the absolute worst language to choose for game development. Yes, it's a lot more work upfront and iterative game…

Dude, it is not safe programming if you put all your code under unsafe brackets.

You can write safe code in other languages but it really requires more advanced programmers than Rust programmers will ever be - the idea of Rust is to simply taking out responsibility from all programmers and puts it on Rust developers, so how much you care about code safety - that is not what you need to think when programming in Rust.

>>>I want to make a game myself in Rust one day and I know for certain that my scripting will definitely not be in Rust.

I mean - do I need to say more?

Re: Game dev in Rust: a year later

#64

Post by dismalaf »

littlestymaar wrote: post #57
dismalaf wrote: post #54

Earlier quoted context omitted.

Is it really philosophical? Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do. Even Unreal programming is mostly scripting... Yes you're writing C++ but you're only telling the engine what to do, not rewriting it (well, unless you are). It's why scripting languages are…

> Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do. By this lose definition pretty much all of software engineering is scripting: you're always telling the underlying layer what to do without changing it: be it a web framework or the GPU driver.

I'd argue a lot of current programming definitely is.

How much foundational technology is actually being created? How many new OSes have there been in the last 30 years? Almost everything that's currently being built is built on top of many layers.

And why is this a bad thing?

When I was in university using R to solve economics problems I wasn't thinking to myself, "This is too easy, I'm just using a scripting language, I need to rewrite everything that's in CRAN myself". No, I was happy that so much foundational tech is already there to make our lives easy.

And when someone ships a game in Unreal or Unity they're probably happier to ship than regretting not writing their own engine.

Also, being in Canada, I can't legally call programming "software engineering" lol.

Re: Game dev in Rust: a year later

#65

Post by dismalaf »

littlestymaar wrote: post #58
dismalaf wrote: post #45

Earlier quoted context omitted.

Not sure why you have scripting in quotations or are implying that it's somehow bad. You're not modifying the engine code or writing a renderer from scratch when programming a game in Unity so yeah, it's scripting by every definition.

> or are implying that it's somehow bad. You're actually the one implying that, you said “it's just for scripting” > You're not modifying the engine code or writing a renderer from scratch You're not modifying the kernel or writing a GPU driver from scratch when you're building a game engine, yet you don't consider that to be scripting, why the difference?

> You're actually the one implying that, you said “it's just for scripting”

I'm describing how the engine is actually made... It's mostly written in C++ and C# is the application scripting layer.

If the whole thing was C# top to bottom I'd call it a C# engine.

Re: Game dev in Rust: a year later

#66

Post by littlestymaar »

dismalaf wrote: post #65
littlestymaar wrote: post #58

Earlier quoted context omitted.

> or are implying that it's somehow bad. You're actually the one implying that, you said “it's just for scripting” > You're not modifying the engine code or writing a renderer from scratch You're not modifying the kernel or writing a GPU driver from scratch when you're building a game engine, yet you don't consider that to be scripting, why the difference?

> You're actually the one implying that, you said “it's just for scripting” I'm describing how the engine is actually made... It's mostly written in C++ and C# is the application scripting layer. If the whole thing was C# top to bottom I'd call it a C# engine.

The engine is in C++, but the game itself is written in C# (and this is the actual part you'd called out earlier in this thread), and no it's not “just scripting on top of the the engine”, no more than writing a game engine in C++ is “scripting on top of the OS” your definition of what is scripting and whatnot is just off.

Re: Game dev in Rust: a year later

#67

Post by littlestymaar »

dismalaf wrote: post #64
littlestymaar wrote: post #57

Earlier quoted context omitted.

> Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do. By this lose definition pretty much all of software engineering is scripting: you're always telling the underlying layer what to do without changing it: be it a web framework or the GPU driver.

I'd argue a lot of current programming definitely is. How much foundational technology is actually being created? How many new OSes have there been in the last 30 years? Almost everything that's currently being built is built on top of many layers. And why is this a bad thing? When I was in university using R to solve economics problems I wasn't thinking to myself, "This is too easy, I'm just using a scripting langua…

This response has nothing to do with the original point I made though, which has nothing to do with “foundational technology”, btw. When people write games in Unity the game is actually written in C#, sure the engine isn't, but that doesn't change the fact that the game is, and calling that “scripting” just because it's built on top of another layer makes no sense, because as you say, everything is built on top of another layer!

Re: Game dev in Rust: a year later

#68

Post by johnnyanmac »

xqt40 wrote: post #63
johnnyanmac wrote: post #49

Earlier quoted context omitted.

so the retort is survivor's bias? Hollow knight was a game jam game, so my 2d autorunner definitely coulda made 8m dollars, right? >I've abandoned rust because I don't find it useable to me with unneeded complexity to code. I don't want to be too dismissive, but if you dont care about code safety, Rust is the absolute worst language to choose for game development. Yes, it's a lot more work upfront and iterative game…

Dude, it is not safe programming if you put all your code under unsafe brackets. You can write safe code in other languages but it really requires more advanced programmers than Rust programmers will ever be - the idea of Rust is to simply taking out responsibility from all programmers and puts it on Rust developers, so how much you care about code safety - that is not what you need to think when programming in Rust.…

>it is not safe programming if you put all your code under unsafe brackets.

Put less code in unsafe brackets. I haven't seen how a proper renderer is made in Rust, but I'd be shocked if something on the scale of Bevy's still was just "Rust without rust" as a quick c++ port.

I'm sure there Wil inevitably be some low level hardware tricks that need unsafe blocks, but that's much less needed in most modern code than back in the day. And if we're being frank, those kinds of optimizations probably aren't top priority compares to, say, a proper front end scene graph to interact with.

>I mean - do I need to say more?

That every language has strengths and weaknesses? I'm all for any wisdom you wish to share. I won't pretend to be an expert in any language.

My design decision (or rather, suspicion) comes more from the fact that scripting needs different demands (rapid iteration) than the underlying foundation (rendering/physics/asset management that can create the nastiest kinds of bugs). Therss inevitable issue bridging languages, but I think overall it would give the best of both worlds.

Re: Game dev in Rust: a year later

#69

Post by johnnyanmac »

pjmlp wrote: post #60
johnnyanmac wrote: post #53

Earlier quoted context omitted.

you could say the same of Balartro on first blush. It really comes down to if we are approaching an engine's viability from a lens of a techie who wants to push the limits of the industry, or as a entrepreneur who wants a tool that fits their workflow. I'm a bit in the former, but those latter games do help get funding for projects so the engine can push further.

Yes, a famous game done in Love2D, providing that it is the gameplay and not the programming language that sells a game. However it isn't on the same league as the studios that care about shipping games in C, C++ and Assembly as main development tools. Right now, other than Bevy existing efforts, and absent of regulations that force those studios to adopt Rust, there aren't many reasons on the market for those studio…

I don't disagree at all with any of your insight. It took Unity and Epic well over a decade each of support and proven games to even get their foot in the door with some studios. And to this day quite a few prolific studios will still use custom tech. Assembly has obvious dev strain that helped with c/++ adoption, while Rust isn't trying to claim it will relieve such strain in C/++, outside of bugs and safety. But I've seen enough game code bases to know thats a very distant, low priority in the modern gaming scene.

For those that do care: Rust for those studios won't be adopted as abruptly "we're using Bevy now!". Studios will probably start slowly tooling parts of Rust in more critical parts of the engine, or using frameworks made over the coming years. Most engineers not dedicated to that work may ever even know there's Rust under the hood.

-----

I guess my main reservation comes from me looking from a different lens. It won't be Naughty Dog nor IDTech that will make the "Quake" of Rust, it'll definitely a small, lean team closer to that of Croteam, or at least a yet unknown studio with that kind of discipline for optimization built into their culture. And with the current landscape it's not going to be trying to fight with AAA games to achieve that milestone. But it'll build it's own community around it and overall rise all ships from that. How high it goes from there, I can't say.

----

P.s. I do appreciate the history lesson. Also reminds me how I'm a bit sad that Microsoft killed so much of the potential C# scene last decade. C# always felt like a good middle ground between the nwas that was Java for Game Development while still staying in a safer space for those who don't need blazing fast C++ support. At least they still supported C# itself to a point where we almost have all the tools needed to work a basically unmanaged environment when needed.

Re: Game dev in Rust: a year later

#70

Post by adamrezich »

indy wrote: post #2

Tiny Glade ( https://store.steampowered.com/app/2198150/Tiny_Glade/ ) is an impressive example of a game written in Rust. Apart from that exception, Rust game development seems more about releasing half baked crates than actual games

Tiny Glade is not a game—it is a toy.

The distinction here is crucial—by having no combat, management aspects, or any sort of objective or failure state whatsoever, there is nothing to balance or iterate on design-wise.

It looks very nice, and I'm sure it took quite a bit of effort to make it look as good as it does. But taking an existing product's design (Townscaper) and adding more features and prettier graphics is not indicative of Rust being useful for game development, because game development entails a lot of design-wise balancing and iteration.

Post reply on HN