← Back to context

Comment by LarsDu88

9 months ago

I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#.

It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year.

Also for ECS... one thing I tended to realize is that when developing a game, pigeonholing everything into an ECS can seriously tend to get in the way. A lot of (efficiently written) game code is best handled in an infrequent event-driven way.

An ECS backed game engine like Bevy can make big mobs more efficient, but few games will actually leverage this effectively for fun gameplay and at the same time modern PCs are fast as hell.

I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun. Now should a gamedev today, 26 years later, making a 2d isometric game for the PC be worried about performant multithreading????

> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.

Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.

The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...

EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).

These are definitely things that enhance gameplay for custom scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)

  • Complete distraction of a question -- for that video clip, what is the song playing at the time stamp you selected? Is that in-game music? I figure not.

    • Don't know the song but that is the ingame music for that specific map, and gets triggered each time certain enemy buildings are destroyed. Different music for each type of building

      1 reply →

Likewise - I've been learning Rust for four years now (significant C/C++/Python/Lua experience), and have written some reasonably complex apps in it, but I really just didn't get the Bevy / ECS "hype"...

I've tried to write several different types of games using it (with Bevy) in the past three years, and it just feels like shoe-horning something in.

But the biggest complaint I have with Bevy is that with all the refactoring that's been needed with the Bevy version upgrades: getting the code to compile again after the version upgrades has normally been fairly easy - but it then often didn't work correctly, and I'd have to spend time debugging the ECS system to work out what was wrong.

i.e. the "if it compiles, it'll almost certainly work" bonus of generic Rust code totally seems to fall down within Bevy.

I obviously understand that it's an in-development framework, in its early days, so some of that's on me for choosing it, but still, it's been a very painful experience, and I feel I've wasted a fairly significant amount of time over the past few years attempting it.

CPUs are way way faster, but RAM latency has barely improved in the past couple decades. That's why cache-optimized systems like ECS can still be a dramatic improvement when you're simulating a lot of stuff. Like, thousands of active objects.

  • They can be improvements, but you can do Data-Oriented Programming without ECS systems, i.e. Structure Of Arrays, which is what we often using in Rendering/Simulation for VFX for SIMD/GPU compute...

    But similarly, ECSs can be slower, if they don't have some optimisations, i.e. spatial data structure lookups: just using a generic ECS "database" system without any first-class spatial knowledge / acceleration structure lookup ability, is likely going to be slower.

> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.

That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation and successors were a lot more fun, and a big part of that was not having arbitrary unit caps in a way that affected gameplay; expanding the limit from 500 to 1500 did genuinely make the game more fun.

  • Agreed. Truly exponential economy makes late-game Total Annihilation/Supreme Commander/Beyond All Reason far more fun than Starcraft.

    Starcraft late-game is hoarding resources and running out your opponent's patience while looking for a slip up.

  • supreme commanders very high unit cap leads to crazy end games. it allows your economy to grow exponentially for the entire game. which has a big impact on late game strategy

Many people are choosing Rust because they want to use Rust. Rust has the reputation being "the best" programming language: Fast, safe, reliable, modern. I can rely on that very much. Who wouldn't like the feeling of using the best tech for their project.

What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.

Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.

>but few games will actually leverage this effectively for fun gameplay

In my opinion this is a result of big mobs having poor performance. When players get to choose they seem to like having more mobs thrown at them.

This can also be limiting for interactable objects.