Appstores, antiviruses and gatekeepers of every sort. Employees want to play games without installing.
>HTML...
The problem is with CSS and the ever evolving HTML standard. Feels a bit heavy and the implemented features will always be incomplete.
If you care about compile/iteration times you can get them down to a reasonable level, Bevy does a good job splitting the heavy lift part into a section that is linked dynamically[1] which leads to pretty reasonable compile times even in something Rust based.
That said most of the high-churn areas I've seen drop to some scripting language(ex: Lua or others) for both hot-reload and avoiding compile times. Usually the heavy compute pieces are out in native with orchestration in scripting or something more flexible.
[1] https://bevyengine.org/learn/book/getting-started/setup/#ena...
This toy application https://github.com/pjmlp/gwc-rs takes about 15 minutes to compile from scratch on a humble Asus 1215B, whereas the C++ original (thanks to having Gtkmm available as binary), takes about 2 minutes.
Compile times are the least of your worry.
The big problem is lack of tools and libraries in Rust gamedev. You can't even achieve PS2-era graphics with Rust right now. Neither Bevy nor FyRox support blend shapes / morph targets, and that's a two decades old and absolutely essential animation tool.
Rust for gamedev is going to take a decade to really get going.
Don't you have access to Vulkan from Rust? So you should be able to do whatever you want, same as doing it in any other language I assume that can plug into it.
The issue is that vulkan is really low level. So while it's possible to do whatever you want, you need tooling to make it worth the effort to do in rust. For example, let's say this morph thing is a click and drag difficulty level operation in Unreal engine, but in ambient there's no specific tool for it so you have to write 10K lines of code to do the same thing. In this case, the issue isn't what's possible through the gpu, but rather how much work a developer has to do.
If you have to choose between writing big portions of code to do what other engines nice you for free vs. spending that time on your game, many developers will opt for the more mature engine.
(I say this as someone who is not a game developer, I've never used Unreal engine, and I have no idea what this morph operation is, but this is the shape of the issue at play here)
This is a massive amount of work before animators can make any use of it. Teams or indie devs that want to use modern animation in their games can't make use of Bevy/Fyrox(/Ambient?) until they develop these tools, which may take years at this rate.
Tickets for more modern animation have been filed in both projects for quite some time, but they lack the staffing and engineering headcount to work on it.
These engines are in a place where they can do rigid bone animation, but that's it. No faces, no breathing, no talking. You can hack your way forward with bones, but it's not as good and it's hard to build/maintain.
I'm doing my part by donating to many of the engineers building these systems in Rust, but I can't expend extra engineering help from myself or my team - we're too busy building things, and sadly I'll probably have to start launching web-facing stuff with Godot due to its incredible maturity. Our entire stack is almost entirely Rust, so it's a bit sad for us.
That's just straight up false:
https://github.com/EmbarkStudios/kajiya https://github.com/BVE-Reborn/rend3
Where are my PS2-era shape keys? Bones aren't going to cut it.
Every time someone says something mildly controversial about weird technology being used for UI in games, I like to point out Skyrim used Flash for its UI. Bunch of .swf files inside the packed data file. It used some weird non-100%-standard player, but it was still Flash.
Arena Wars was one of the first games using .NET already in 2004, years before Managed Direct X or XNA came to be, with direct bindings to OpenGL. [0]
Then we have quite a few sucessful ones in XNA, some of them them ending up as quite relevant IP franchises.
Minecraft being a success, regardless of being written in Java.
Runescape, a plain Java applet that kept legions of gamers occupied.
Or for that matter the 1990's game development literature trying to move the ecosystem from raw Assembly to C, and how long C++ needed to gain traction over C in most studios. Even today many of them rather code in "C with C++ compiler" style.
Which shows that even C++ had quite an uphill being adopted by the industry.
Tech doesn't matter if game design and IP is compeling enough to make people enjoy the game.
A great engine, with a top language and bad game design, doesn't go far.
Well, if you have got access to a language designed for making games like Jai, then that would presumably be better than Rust.
1) Yes, we're currently working on this and progress is good, so stay tuned for that! 2) We actually built a collaborative editor for this, which we've been using in-house for a year now. We choose to not release it right now, as there's still some things we need to work out with it, but it's coming too! 3) We plan to monetize services around this, such as game server hosting and tools for people to monetize what they create. 4) So the runtime is completely open source, so anyone can look into the code anyway. If you build something on top of this, you will also be able to choose if your own code should live on the server, client or both. If it's server only it won't be sent to the clients. 5) We've experimented with partial html UIs, but support for it on Rust native isn't great yet. We do have a fairly decent UI implementation (see examples here: https://github.com/AmbientRun/Ambient/tree/main/crates/ui/ex...) though it's not exposed to user code yet, but yeah I hear you that there's a lot of people who know html based UI tech. We'll see exactly where we end up there, but most likely the first step will be to expose the UI library we've built already to users.
Thanks!
I'm an engineer with a decade of experience as a web services engineer, and 5 years of game development engineering. Rust seems like the right direction for game developers -- safer code, faster compile times, more portable binaries.
Ambient looks very cool, but I had some questions --
1) WebAssembly, but no native web player? One of the most powerful things a game dev can do is provide a link to a game and just let people play it on itch or other space. Having a binary you have to download to play is a major turn off for small time games. It looks like it's on the roadmap, but without a clear target?
2) No editor/tooling yet? What's the plan for a unity-like editor interface? How do non-developers (designers, artists, audio folks) interact with a game made with ambient? Is that in the plans for the future? Could you expand on it a bit more?
3) Sustainability? A five person crew working on a free product, how do you plan on monetizing it?
4) Single executable? One concern that jumps out right away is the single executable for server and client. Often in multiplayer games you want to avoid shipping server binaries (for cheat protection, for instance, or to avoid the cost of deploying a large client to a headless server environment). Are there plans to provide the ability to separate client and server builds?
5) HTML for front end? Games are increasingly moving to HTML to power their UI. Given you are already using WebAssembly, it seems like it wouldn't be that far off to enable an interface so that UI could be handled in JS/HTML. (Yes, this is performant enough for games. Yes, it's being done in AAA games. No, you aren't the first commenter who thinks that UI shouldn't be done in HTML. No, I'm not interested in hearing complaints about it.)
Nevertheless, this looks neat,