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

51–60 of 71 posts

Re: Game dev in Rust: a year later

#51

Post by johnnyanmac »

pjmlp wrote: post #38
dismalaf wrote: post #36

Earlier quoted context omitted.

> A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all. ??? Unity is a C++ engine, C# is just used for scripting...

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 core engine and have gameobjects powered by entries under the hood, but I have no clue how much progress was actually made.

Re: Game dev in Rust: a year later

#52

Post by johnnyanmac »

dismalaf wrote: post #45
littlestymaar wrote: post #44

Earlier quoted context omitted.

> just used for scripting... AKA writing games. Many people writing games with Unity go far beyond what anyone reasonable would call “scripting”, writing code that consume a significant part of the performance budget.

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.

it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.

Re: Game dev in Rust: a year later

#53

Post by johnnyanmac »

pjmlp wrote: post #5
dwattttt wrote: post #3

Earlier quoted context omitted.

I was surprised to find out The Gnorp Apologue was written in Rust, it's done surprisingly well: https://old.reddit.com/r/rust/comments/18ul125/writing_a_gam...

From the trailer, it looks like something I would have played on an Amiga 500 or PC MS-DOS VGA with a Soundblaster/Adlib, so hardly a selling example for modern game development, even if it happens to be quite enjoyable.

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.

Re: Game dev in Rust: a year later

#54

Post by dismalaf »

johnnyanmac wrote: post #52
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.

it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.

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 called such... The interpreter is already built and remains unchanged, and runs the code without rebuilding anything.

Python doesn't suddenly become a non-scripting language just because your program reaches a certain size or scope.

It's weird that someone would take offence to calling scripting scripting... Like, it's nice that things are prebuilt and make programming easier... I reach for Ruby first whenever I have a problem I need solved.

Re: Game dev in Rust: a year later

#55

Post by johnnyanmac »

yodsanklai wrote: post #8

I'm learning Rust at the moment (I'm going to join a new team that uses Rust). I'd say it's quite fun and I'm not good enough to have a strong opinion on the language, but I have a few thoughts though. So far, I find the language design not super elegant. There are restrictive ownership rules, which are fine, but then a myriad of data structures that let you circumvent these rules. It feels somewhat ad-hoc. Regarding…

>I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

C++ has decades of infrastructure, and is still the standard for games, so it's almost certainly not the better choice if your goal is shipping.

It's arguably better for best practices and may be a standard in the far future, but you're going down an untrodden path if you make that choice. you'll be spending just as much, if not more time fighting your tools than making a game. (unless you're comfortable with the few stable-ish Rust game engines).

Re: Game dev in Rust: a year later

#56

Post by johnnyanmac »

dismalaf wrote: post #54
johnnyanmac wrote: post #52

Earlier quoted context omitted.

it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.

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…

Maybe "philosophical" is too strong a word, but I can't think of a better fitting term.

By those same definitions, we can Call any kind of middleware an API "scripting". You're not changing the underlying code so much as sending calls to some other code base to do the heavy lifting. But there's definitely some like between that and what popular game engines are structured by.

At the end of the day, the names are bikeshedding to me, what matters more is the output and experience of the tool more than the label applied to it. But names are communication, and communication is messy by nature.

Re: Game dev in Rust: a year later

#57

Post by littlestymaar »

dismalaf wrote: post #54
johnnyanmac wrote: post #52

Earlier quoted context omitted.

it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.

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.

Re: Game dev in Rust: a year later

#58

Post by littlestymaar »

dismalaf wrote: post #45
littlestymaar wrote: post #44

Earlier quoted context omitted.

> just used for scripting... AKA writing games. Many people writing games with Unity go far beyond what anyone reasonable would call “scripting”, writing code that consume a significant part of the performance budget.

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?

Re: Game dev in Rust: a year later

#59

Post by indy »

johnnyanmac wrote: post #48
indy wrote: post #14

Earlier quoted context omitted.

There's nothing wrong with writing your own game engine rather than going for Unreal or Unity, in fact that's one way of creating a truly unique game. My comment about "half baked" referred to the crates that people release instead of actual games. The Rust game dev community might be wise to steer away from the "we gave up on developing our game, but hey Rustaceans, here are some crates you might find useful!" appro…

despite being in the same industry, engine programmers =/= game designers. You may as well be comparing a network engineer to a front end web dev. As for "actual games": indie dev with mature tools is hard enough as is to properly ship. and many don't make money. Making the kind of game that would attract attention requires funding that these communities often lack.

I was thinking of the kinds of games mentioned in this thread: Tiny Glade and The Gnorp Apologue. Small indie games made by people who fill the role of both engine programmer and game designer.

On a larger, more professional scale someone like Jonathan Blow comes to mind

Re: Game dev in Rust: a year later

#60

Post by pjmlp »

johnnyanmac wrote: post #53
pjmlp wrote: post #5

Earlier quoted context omitted.

From the trailer, it looks like something I would have played on an Amiga 500 or PC MS-DOS VGA with a Soundblaster/Adlib, so hardly a selling example for modern game development, even if it happens to be quite enjoyable.

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 studios to change their tooling.

As small history lesson, it was the success of games like Quake that finally settled using C and C++ for game development, after they started to enjoy some love in the demoscene.

C on game consoles, followed by C++, only started to be a thing after the PlayStation, the first games console to ship a C SDK instead of having only Assembly based tooling. Also Yaroze only had C support.

C++ joined the party via the PlayStation 2 SDK.

C# was used for the first time successfuly on Arena Wars[0] back in 2004, with the studio doing their own OpenGL bindings.

It took Managed DirectX, followed by XNA and XBox Creative Arcade, MonoGame, Unity adopting MonoGame for their crossplatform rewrite (they were originally Mac OS only), lots of money to bring it to game consoles, for .NET based tooling for finally starting to be relevant as well.

Before Unity took over, it was already being used as alternative to create game tooling based on C++ and MFC.

Java never had much luck, because Sun understood game development even worse than desktop development, so the JavaGamming initiative went nowhere, even though there were nice engines like jMonkeyEngine, JOGL and LWGL.

There was LibGDX for a while, but the RoboVM acquisition from Xamarin, only to be shortly acquired by Microsoft thereafter, kind of killed what it had going for it.

Still, it is unavoidable on Minecraft, where Bedrock version isn't nowhere the mod community size as the Java one, and Android casual games. Also Android non-casual games do require some level of Java/Kotlin code, given that only rendering and audio is exposed on the NDK.

Note that despite all the Rust adoption talk by Android team, there are no plans for official Rust support on the Android NDK, and Kotlin Native might even get there first, still looking forward when this might change.

[0] - https://en.wikipedia.org/wiki/Arena_Wars

Post reply on HN