#Favorite game engine for Rust

87 messages · Page 1 of 1 (latest)

unborn jacinth
#

get heated

#

Bevy comes to mind

spring bluff
#

Just me winit and I. :)

#

That's just me though. I don't like frameworks because they're typically overarching and tend to manage every aspect of your program, leaving you stuck in a massive runtime environment you can't control. ¯_(ツ)_/¯

turbid cloak
#

True.

#

I don't use frameworks, just plain APIs

unborn jacinth
#

is using winit not painful? lol

#

I'm surprised theres nothing between winit and Bevy then

ember jacinth
#

rendering libraries help a bit

#

if you're into ECS frameworks, they help too

#

however massive engines that attempt to do everything for you are annoying indeed

#

especially when you're working on an uncommon game idea

#

then most so-called game engines won't work at all

turbid cloak
#

Yeah

vestal coral
#

I'm using ggez as framework

languid condor
#

I've actually tested quite seriously several game engines.
Bevy has fundamental architectural deficiencies. It's pratically unusable for anything other than extremely simple games, due to the lacking state/stage management. There's a crate that works this around (iyes_loopless), though.
For 2d development, I've tried Ggez, Tetra and Macroquad. Macroquad is quite buggy, and when I've tested it, it also didn't support gamepads. Tetra and Ggez worked well instead, although Tetra is now discontinued.
For 3d, I think only Fyrox remains, but I don't have firsthand experience with it.
All the rest of the engines are essentially either alpha versions, or discontinued.

dire crater
#

I've heard the Godot bindings aren't bad.

ember jacinth
#

my first game idea: I wanted to implement a hierarchical orbital systems simulator, where each orbital system has its independent physics and interacts with other systems by either owning them or sending objects into/out of the circle-of-gravity-influence of its children

#

couldn't use any game engines at all because I can't represent the relative positions using trivial cartesian coordinates

#

couldn't even ues a trivial rendering engine becaues they all require persisting the coordinates of all objects as a [f32; 2] or [f32; 3] in the same system

#

my second game idea: a spatial graph-based logistics simulator, simulating the movement of different types of items (such as vehicles, liquids, gases, electricity) across the edges

#

this time it is a bit less uncommon, but I am not happy about the performance because there are no game engines optimized for graph-based simulation

#

there was someone who told me though, that when you're working on an uncommon game idea, you're not developing a game anymore, but developing a game engine

tribal jewel
#

I know this isn't necessarily the fault of bevy, but there was nothing in the bevy jam that impressed me and made me want to try bevy

#

most games were so simple that they didn't need an engine or framework in the first place

#

and there were crashes and bugs in a few games as well

ember jacinth
#

I think most of us here are more interested in writing a game engine than actually writing a game

#

depending on the definition of "game engine"

#

if we use "game engine" in the more broad definition, basically every game that doesn't have a fixed route of gameplay is a game engine

#

and in those cases, you definitely want to be creative and add something that nobody did before

languid condor
# tribal jewel I know this isn't necessarily the fault of bevy, but there was nothing in the be...

I had the same impression. I've been working heavily with Bevy in the last weeks, and it's definitely not approachable as library, in many ways. I've checked the dependencies of 2 of the 4 top games (sadly, not all the games released the source), and they didn't include iyes_loopless, so either the authors had extremely simple state/stage management, or they had to roll out their own. Bevy's API documentation is also non-existing - having to rely on a 3rd party to write a book doesn't inspire much confidence. Legion has less prettier ECS APIs, but it has a set of APIs that makes it easier to write simple projects.
Keeping in mind all the things above (which are certainly fixable, but requires will & resources), and the fact and ECS is... not the easiest design pattern in the world 😆 I can imagine why the jam gave that impression.

languid condor
# ember jacinth I think most of us here are more interested in writing a game engine than actual...

I had this impression as well. I think Rust, being a "systems" programming language, attracts technically minded people (nothing wrong with it; I'm the same 😄), so the general attention is more to the mean (the engine) that the end (the games). It's a bit paradoxical that essentially none of the engines have good (demo) games, the only exception being Fyrox (which has a very impressive one, though), and Macroquad.
There was hint of this phenomenon in 17cupsofcoffee's blog post (https://www.seventeencups.net/posts/three-years-of-tetra/):

if you want to write games, then write games, not engines

The blog post is amazing, BTW 😄

ember jacinth
#

I gotta just admit the fact

#

I'm writing both game and game engine at the same time

#

when people say it's too specific, I can use the excuse "it's a game"

#

when people say it's too generalized, I can use the excuse "it's a game engine"

#

for example I know dynec is a very purpose-specific ECS framework since day one, because it is very rare to run into a scenario where permutating entities is useful

#

especially at the huge cost of implementing entity::Ref for all components

rugged stone
violet apex
#

im using erupt/vulkan + winnit

#

so much pain

fringe flax
#

Hi, I've got some game development skills and used them in practise within unity (5+ years). I've also got some skills with rust (around a year now) and I was trying to get a game engine working: amethyst and bevy. It all seems awesome, but I really find it really hard to get started making a game in rust (with or without engine). Does anyone have some tips?

ember jacinth
#

@fringe flax why did you find it hard?

languid condor
#

it's a very interesting approach, designed in a very clever way to be approach ECS-based game development.
it uses Legion (for the ECS), which (AFAIK). was going to be the Amethyst's next ECS before Amethyst was discontinued. For graphics, it uses another library, which is more convenient to use than, say, Bevy.

#

It's also a turn-based RPG, so it doesn't have to deal with timing design (which is not trivial).

#

I'm actually in the process of porting it to Bevy and writing about it, but it will take me at least other two weeks.

fringe flax
#

Well @ember jacinth... Let me first start from the point of Unity. Unity has made everything available for the programmer way more easily than any other game engine I know. This goes from importing assets and creating components with scripts to the actual graphical user interface. All other engines are just not that sophisticated. Then, the newer rust-written engines update quite often with breaking changes resulting in me trying to figure out what is was and how to change it such that is does not create problems... But these problems are minor to the actual problem I'm facing: trying to build something well made. If I want to make something I want to make it as perfect as possible, but I just don't know what the best route is to take. To elaborate on this, I would like to give you some actual examples:

I want to make a tower defence game (with bevy at the moment) that makes use of a terminal window containing (possibly) multiple shell tabs that are used as input. In Unity, I could write up a shell class in C#, fix the UI and start testing my input and output. Yet, drawing the console (for a shell) in rust is vague. The standard UI in bevy could be used, but does not handle the console-like behaviour that well. Then the problem of drawing a world (level) arises. I want to spawn the world from a descriptive, config-like struct that tells me what assets needs to be loaded at what position and be able to do some pathfinding on it, but only loading an asset cost me already ten lines of code and makes the project less readable...

I also tried making a game from nothing but the rust std library. This worked fine for super simple games that make use of the console (like mastermind, hangman, sudoku, etc), but as soon as I needed a graphical interface I had to go though rough API's / libraries which are still really daunting to work with.

Please let me know if you've got something!

ember jacinth
#

so I guess your problem is all about ecosystem immaturity

#

I think the ecosystem with shell rendering is quite diverse

#

I mean compared to other things in rust

fringe flax
#

Console output isn't hard at all, because it is built-in the rust std library

ember jacinth
#

I thought you were talking about interactive terminals?

fringe flax
#

I was

#

But the interactive terminals are linked to the graphical game

#

So I have two processes that are completely separated from each other until a command is parsed

ember jacinth
#

as for loading assets... is it really such a trivial thing? everyone has different approaches for loading assets

fringe flax
#

Well, yes and no. It depends on what you want to load and where you're going to use it. If I need to load an image, I just need that image to be drawn somewhere on the screen. Loading 3D assets is somewhat harder

#

I just don't know the in and outs of game development in rust. I do not even know what the best practises are, because I haven't managed to build a graphical game in rust (and get feedback)

ember jacinth
#

btw, I don't understand why people who like Rust would like ECS with dynamic archetypes

#

the common ECS is just duck typing + polymorphism in disguise

#

isn't that what rust devs hate most?

tribal jewel
#

well, for game development flexibility is often more important than correctness

#

especially if you're prototyping

ember jacinth
#

can you give an example of "prototyping" where this matters?

tribal jewel
#

I can't give any concrete examples, haha. I don't know what the alternative would be to compare ECS to

ember jacinth
#

like for example, it seems the usual approach is that you recognize that an entity is of a certain "class" if it has some subset of components
but isn't this more prone to accidentally matching other entities?

tribal jewel
#

well, the components themselves can be strongly typed

#

So you can make it that even though two components carry the same data, they are semantically different

#

also if you need to recognize the kind of an entity, you could add a kind component

#

although I'm far from being experienced with ecs, haha, so I can't really give more insight.

#

I only used it on a few occasions

ember jacinth
#

and polymorphism too

#

making the same entity contain components from multiple modules vs creating a new entity for each module doesn't really have any difference

languid condor
ember jacinth
#

personally I like ECS because of its performance of memory locality and avoiding lock contention

#

but seems others like it for other reasons

mint tree
#

Macroquad

#

Emerald

mint tree
#

godot

loud saffron
#

I dont have first hand experience with amethyst but it seems nice

ember jacinth
#

too much assumption on user

ember jacinth