Fyrox Game Engine 0.29 | Hacker News Reader

Fyrox Game Engine 0.29

fyrox.rs

134 pointssbt56749 comments

One of the good ol’ college mistake we made during our game dev capstone was spending half of it reinventing the wheel for a tile editor.

I recently used Tiled with RpgMaker and it feels like 2d sprite / tile editors are a solved problem. I also notice how 3d game engines note that they can also support 2D games. That space seems quite saturated and investing into 2D features seems like scratching one own’s itch. It feels like there is more upside to going all in on the 3d aspect, but potentially the 2D elements are quick to implement features to add to an engine’s laundry list of features.

I think this is a common feature (set) of modern game engines.

Unity and Godot do support 2d games development, so Fyrox, attempting to be a competitor in that space, supports it as well.

It's definitely going to take a lot of work, but the feature itself seems a modern standard, to me.

That is a great idea when the goal is to learn when to implement engines, not when doing a game.

When I gradutated, writing a particle engine was a subject complex enough for graduation project, nowadays it is a bullet point on an engine feature list.

I also think that in general game engines should quit trying to do everything and focus on specific niches. This makes the game engine simpler to build, which means everything can be better, and makes the games easier to build as well, by a large margin.

Rather than Unity and Unreal, I feel like we should have:

1. Game engines for 3D level based pre baked games 2. Game engines for procedurally generated 3d games 3. Game engines for isometric 3d rpg games 4. Game engines for 2d top down rpg games 5. Game engines for 3d space games

and so on

Some of these exist! Especially number 4, some people have build #3 but they did it on top of Unity, so you are still waiting 10 minutes for massive Unity stuff to load all the time.

There is one game engine for "isometric" RPG but that engine is not used anymore for various reasons.

It is the "Aurora Toolkit" from Neverwinter Nights.

As far as I know the only game that used it that is not from Bioware or Bioware-related companies is Witcher 1, that wasn't isometric anyway. (also I am not sure why they used that engine... since the game doesn't use Aurora Toolkit strenghts in any form...)

I am unable to remember the details but fun fact, the witcher 1 engine started life as mdk2. I don't think ether of the neverwinter nights games was isometric, I suspect you are thinking of what balders gate used, sometime known as the infinity engine

Infinity Engine was 2D.

Neverwinter Nights was a full 3D engine but the gameplay and controls were clearly descended from Infinity Engine ,at least the first game... (I didn't play the second to be sure).

So it could do a 3D "Isometric", if you wanted to. As far as I know it is the only dedicated 3D RPG engine that wasn't intended to be controlled as third person "shooter" style controls.

I think the idea of being able to develop both kinds of games with one (mostly) shared skillset has a ton of appeal. Not to mention the assumption that games are either 2D or 3D is not always correct.

Most 2D games are often rendered in a 3D world anyway. So that you can get cool transitions or concepts like distance much more easily.

Unity3D is still the defacto for most gaming studios and I agree with the first point that the game engine space is very saturated. Still I admire all the work and great 2D engines can render faster on specific hardware (cocos2D was a good example)! I say focus on one niche and build better integrated tools for that niche.

“The safety and speed of Rust makes game development a true joy.”

I’m not an expert in game dev but I keep scratching my head on the concept Rust game engines. The above statement is about optimizing for the wrong things, IMO. I want simple and fast development loop. It’s why Lua is so great for game dev and why there’s so many custom scripting languages. Maybe Rust game engines need to expose their API using a scripting language rather than Rust.

Of course, there’s plenty of game engines and plenty of room for experiments, so I’m delighted to see another.

Would love to hear from others who develop games on how they feel about writing one purely in Rust.

I can't speak for large games but the Bevy build-run loop is quite fast for smallish games (say 10k loc). Certainly more pleasant than say Python or JS where it starts fast and then you spent five iterations fixing errors Rust's type & ownership systems would have caught.

I feel like at this point JS is a compile target. TS + Phaser or PIXI is delightful.

Is this comment getting downvoted because there’s something wrong with it or because people disagree?

I think wasm + webgpu will probably take over game development since it's incredibly portable from the start, and has near-native performance. Bevy is directly integrated with both, so I'm really hopeful of its future.

The context matters entirely.

Is the person looking to choose an engine a hobbyist, hopeful indie, tech lead for a team? Is the project content driven or very procedural? What’s the timeline? Are there resources to dedicate to significant tooling, or handling cross-platform insanity?

List goes on of course. But my highly opinionated answer to your question is the only people using a rust game engine are hobbyists and hopeful indies who aren’t on a time crunch.

Maybe that's a feature and not a bug? From what I understand, crunch is supposed to be one of the worst parts of professional game development. If the argument is that Rust forces you to handle all of the edge cases up front and requires more development time to fix a poorly chosen design after the fact, I'd argue that those sound like things that would both technically and socially incentivize not relying on last minute crunch to get a game released. If Rust is widely known to be ineffective when used in a time crunch, seeing that a company chose to develop a game with Rust despite that might be a positive sign about what type of development culture they have.

I don't know enough about Rust development, but definitely agree that it's a good sign to see a culture that pays attention to potential future issues early in development. On the other hand, if an approach leads to constant tear-downs early on, it opens up the risk of runaway refactoring before you have a playable demo.

I feel like "Crunch" is sort of baked into a certain business model anyway, and the type of management that relies on it would probably find other ways of creating aggressive and unachievable last minute goals.

Poor word choice on my part, I did not mean 'crunch' in the traditional game development sense. I meant that a hopeful indie who doesn't have a timeline to worry about and can work at their leisure.

> ...crunch vs Rust...

Crunch is a management problem, programming language details won't help in this regard (and the entire role of programming languages in game development seem way overblown in the comments here anyway - you pick an engine mainly for the artist workflows it provides, and then use whatever programming language that engine supports best).

Game dev is highly iterative. Chances are the code you wrote will get deleted or rewritten anyway so forcing you to handle potential edge cases means forcing you to waste time.

I think Rust can play a similar role as C++ in driving the actual game engine code which is more static but I don't think writing the actual game logic in it plays to its strength. For that more dynamic languages with faster iteration times shine.

As for crunch time, that is a organizational problem, there will be not technical fix for that.

Lua is great and I've shipped titles professionally with it however it needs to be deployed at the right layer. There's going to be things that you need to be fast and usually native is your path there. I think in that context Rust shows a lot of promise.

Also the build loop on Bevy is pretty good from what I've seen, esp if you enable the dynamic linkage flag in development. The ECS system is really well thought out even if the engine is a bit sparse I think it shows a lot of promise to build a highly efficient game loop.

C# with the burst compiler in Unity is rather cool in this respect. Do normal scripting but have the option to use a restricted subset for C-like code that gets compiled or JIT’ed in performance sensitive jobs.

Too bad in a big project the recompile and asset reload times get annoying in Unity, even with assembly definitions. In one project I used a runtime lua interpreter on top of C# to speed up game scripting.

I'm just about to try diving back into HaXe for the first time since 2012 or so, before OpenFL was complete with web and mobile targets - when my primary tools for building 2/2.5D games were AS3 and Starling. Have you played with game code in the HaXe realm at all recently (like, since 2014?)

[edit] I also just noticed your comment further down about TS and Pixijs... and I'm debating whether to go the HaXe+OpenFL to many targets route, or use the TS toolchain just for OpenFL to javascript. My last experiment with this was trying to port ASWing to JS via HaXe, that's how old I feel! But I heard that the OpenFL JS target was at least originally built on top of Pixijs (which I adore, and has been my go-to for canvas/webgl interaction in recent years).

Lua is for scripting engines built in something else. Rust replaces the something else, not Lua.

AFAIk the 2 biggest game engines use C# and C++

You mean they use C++ for the engine and C# scripting.

Unity dreams of removing all the C++ code and replacing it with their "High Performance c#", ie. using the burst compiler and manual memory management to remove the GC problem.

Unreal Engine uses C++ for both.

Blueprints isn't C++ as such.

No, Unity has already replaced a few C++ modules with HPC#, their C# subset for low level coding.

They also plan to eventually use NativeAOT as part of the .NET Core migration to further go down that path.

Unity has been one of the reasons why C# has gotten so much better for low level coding since version 7, alongside feedback from Midori experience and wanting to win Techempower benchmarks.

I think the Bevy engine people are working on a way to use scripts for game logic, so many agree with you.

Scripts for game logic are officially a non-goal in Bevy.

- Mentioned here by its creator: https://news.ycombinator.com/item?id=24984942

- Here by a team member: https://github.com/bevyengine/bevy/issues/2352

- And here, under "Turtles all the way down", in a roundabout way: https://bevyengine.org/news/introducing-bevy/#why-build-bevy

Interesting. Personally I find Rust-only pretty appealing, but people definitely have differing opinions: https://github.com/makspll/bevy_mod_scripting

Dabbled with Rust a few years ago. It was not a true joy coming from the C#, Java, Javascript world because it was comparatively verbose to do similar things. It felt like it was meant to be an improvement on the C development paradigm.

At the risk of sounding naggy, I think you could maybe give Rust another go. A lot has improved recently, and depending on how long ago you tried it, maybe even radically. A lot of limitations in the language are now lifted thanks to a smarter compiler (NLLs, GATs, more ergonomic error handling syntaxes, etc)

Still not enough for GUI / graphics coding versus compiled managed languages, including those in the ML family.

I agree that the state of GUI in Rust is not quite mature.

As an aside, there's https://github.com/StarArawn/kayak_ui that seems nice, but I've not actually used it, so I can't vouch for it.

I enjoy hobby coding in Rust, however I see its main use case being deployment scenarios where no form of automatic memory management is considered a viable option (tracing GC, RC, mixed RC/GC, ARC, whatever).

Additionally I see a possible future with automatic memory management + linear types for low level coding, like Haskell and Swift are looking into, as more interesting.

The sweet spot of productiviy of automatic memory management, with the control of type system for low level coding, if really needed.

It depends, I worked on SS14 engine a bit. It's a custom C# engine. Versus a Bevy engine in Rust.

And most stuff SS14 devs are trying to enforce in their custom C# engine comes for free in Rust. ECS? Mandatory. Systems can't store state? By design in Bevy - systems are functions. Components need to be ported from class to struct? In Rust you don't have to choose.

That said some issues like faster iteration and sandboxing might make more sense for a C# engine, but so far there wasn't some huge obstacles for developing other kinds of games.

Not in any way associated with Fyrox or Bevy, but tried both and read their docs. So, I could answer some of these:

> Would love to hear from others who develop games on how they feel about writing one purely in Rust.

I've only made a few toys/concepts in Bevy and loved it, but there's been a few (two, I think?) Bevy jams with games hosted on itch.io (you can play most of them in the Browser thanks to WASM). I think the consensus in general is that people love the experience, even though it's fairly more lower level than any of the popular alternatives.

> Maybe Rust game engines need to expose their API using a scripting language rather than Rust.

I think this is the plan eventually, just not a priority, since more fundamentals need to be taken care of. Bevy already added some foundational work for scripting, but Bevy has a BYO Scripting Language plugin philosophy. So, you won't be locked into a scripting language of choice when using Bevy

Looks quite good for such early stage, specially by having quite comprenshible editors right from the start.

Will keep an eye on it, thanks for sharing.

Fyrox 0.25 Feature Highlights - https://news.ycombinator.com/item?id=31386739 - May 2022 (13 comments)

Posted 22 hours ago here too https://news.ycombinator.com/item?id=34306469

A good example of how a well chosen title can have an effect on HN. I've never heard of "Fyrox" so "Fyrox Engine" didn't trigger my attention at all. However I'll (almost) always click on a title that has "Game Engine" in it.

Yo sbt, get your ass outta Russia mate.

Whenever I see a product that advertises itself based on the technology it is built on I’m skeptical. Rust doesn’t make a game engine good.

Well it's a game engine and the language that is based on is important, you would for sure pass on a game engine written in Javascript and instead you will choose one that uses technologies you know.

So I think is important to explicitly tell which technologies are you using in a game engine.

Depends, PlayCanvas, BabylonJS and ThreeJS are written in JavaScript.

Although you might say that there is still the C++/Rust code of the browser rendering engine to take into account.

Reply on news.ycombinator.com