Ambient: The Multiplayer Game Engine
ambient.run
ambient.run
• Check https://global-uploads.webflow.com/63e51fd138280b42988eb5e6/... in VLC, pause the video then press the "e" key to advance frame by frame.
• Open https://www.youtube.com/watch?v=f_BaT3LDwo8, advance with the "." (dot) key.
> The server state is automatically synchronized to clients, and the data model is the same on the server and client. This means that in the future you can move your code between backend and frontend, or even run it on both seamlessly.
Different types of games need different types of networking. It seems like it's going to be hard to reason about how to program the game without knowing the constraints and guarantees on the network code.
Basically, keep a "full" state backlog and ship user control events, if control events arrive late you simulate forward to "now" from the backlog with corrected input.
I've been working on something very similar, gonna comment on the top-level.
What I'm describing is so-called rollback based netcode, the server should always keep an canonical state and deviating from it is at a clients peril.
- Aimbots is a problem regardless of state it, as long as you can see/shoot at it then aimbots can exist, stopping that is a separate issue.
- On ESP/Wall hacking you're right, it can be an issue
- Full snapshot/heap shipping as emulators and Kettlewells WASM sample is hard to patch here.
- an DoD ECS grounded design like Ambient could selectively withhold entities (ie out of sight), however I think for starting development it shouldn't be an initial worry as long as you don't design yourself into a corner in such a way that it's impossible to implement later.We've had generations of games that was built as webs-of-objects (and popular engines that still default to it), and yes, adding and maintaining netcode with that is like pulling tooth because you need to manually keep track of so much.
This puts netcode mostly as an automatable task with clear default rules, stuff like hiding players/entities out of sight becomes filters (in the same way as not updating far-away stuff).
It was very well made but had a couple of power balance issues, which is it bo expected.
The problem was that it didn’t get its network code right from the very start. After a fun honeymoon period that was way too short, we would see cheaters all over the place. Not even “just” wallhacking but also teleporting around and dramatically increasing gun RPM.
This sucked out the whole fun in just a few days. My friends and I never played again even though they might have fixed it down the line.
Unfortunately they are not doing lazy loading of loose loot and containers (including player/scav), so ESP is extra powerful in this game. But since Tarkov has complex maps there's little point in trying to hide players that are not visible, CSGO and Valorant are the only FPS games that does this but they also have simple and small maps with fewer players. So player-ESP and aimbot will most likely always be possible as long as you can bypass Battleye, so instead of cheaters rushing for loot they can see you might just go and kill you.
I once heard of a game that instead of banning cheaters, isolated them together in a separate bucket. Cheaters could still play… amongst themselves.
[0] - https://www.pcgamer.com/fall-guys-once-had-a-secret-cheater-...
Edit: Ah... I see it's a SaaS startup that wants to offer the servers as a service for game developers. Building on someone else's engine would make the hosting brand weaker.
But I'm being hypocritical here... knowing I have no time to contribute to Bevy and just hoping someone else to do my job.
Being used to most Web productions never coming at the level of Infinity Blade, seeing a video isn't really something that impresses the crowd.
https://www.polygon.com/2013/9/10/4715534/infinity-blade-3-c...
https://web.archive.org/web/20140210210113/http://www.unreal...
https://www.shacknews.com/article/72813/epic-releases-epic-c...
"Unreal Engine 3 Support for Adobe Flash Player - Epic Citadel"
-- https://www.youtube.com/watch?v=xzyCTt5KLKU
https://adobe-flash.github.io/crossbridge/
https://help.adobe.com/en_US/as3/dev/WSF24A5A75-38D6-4a44-BD...
Most stuff on the Web thus far, with exception of Google Earth and a few ecommerce sites, is closer to Flash 2D games than anything else.
Hence when a game engine advertises itself as WebGPU, I expect a browser demo at the same level as Infinity Blade, Unreal Citadel, or After the Flood graphics, not a video.
Rust game engines are using it as a library for native games
WebGPU's place is on the Web, no need for more extension spaghetti than Khronos already do by themselves.
we're talking about https://github.com/gfx-rs/wgpu which has Vulkan, Metal and DX12 backends
If you're using 100vw you need to set a max-width in percent since VW doesn't account for the width of the scrollbar.
@media screen and (min-width: 1280px) .footer { width: 100vw; max-width: 100%; }
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,
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!
The only opensource game engine that looks interesting is Godot, they are working hard on making their tools better and growing their asset store.
Congrats on the release!
I think there's a real opportunity here, if done well. It should be feasible to get initial load times down to single digit seconds, https://venge.io style, but then with progressive enhancement to AAA level graphics assets. I think that could be disruptive.
Load times on most games are ridiculously huge especially if you include download/install times, which you should, and not just initially but for patches too. There's no fundamental reason it needs to be so slow, and I think the industry is underestimating how much it's collectively costing them.
And because you have control over the game you can give everyone a hour or so free demo time, only then they need an abo.
The DoD ECS pattern should allow for easy state/log shipping to clients, with those 2 parts you can easily build what fighting games terms as "rollback" based netcode.
Rollback is often characterized as complicated but clean, the truth is that if you structure your data around rollback capable simulation from day one it becomes easy (and DoD ECS naturally fits there just like shipping to separate CPU parts back on the PS3)
This "trick" of fully shipping state images isn't exactly new, some emulators has done memory image shipping in the past and Ian Kettlewell published a WASM-heap shipping experiment(1) recently that works on the same principle.
Compared to the snapshot/heap shipping of emulators/WASM is that Ambient should allow for server introspection and upgrades of state.
Overall I like Ambient, and I'd recommend a look. Only big omission I see right now is audio being missing and it can be a tricky part to synchronize (due to how mixing works).
Yet I can't find any mention of multilayer in the documentation. The github mentions it offers synchronization of data, but what about things like rollback, interpolation, exterpolation, VoIP, messaging, P2P, load balancing, autoscaling, measuring latency, persistence, etc that are needed for multilayer games?
All gameplay logic is currently server-authoritative. We currently do not have any form of latency-hiding, including prediction, rollback, or clientside logic. We previously had rollback, but removed it due to its relative inflexibility. Our plan is to introduce clientside and shared logic that can be used for user-defined prediction with runtime assistance, but this will take some time.
Even with the battle royale craze, it seems like nothing has really replicated Planetside 2's black magic netcode (or at least amassed a playerbase big enough to show it off).
Or tried to. From what I’ve read online they massively rely on client-side computation, even for hit detection.
It seems more like trading security for performance than any sort of technical miracle black magic.
Unless I’ve missed something?
[0] https://www.reddit.com/r/Planetside/comments/8hx7t1/comment/...
I wish I could find the post, but I tried to search it in the past, without success. He did have a video with many players in game on YouTube.
Perhaps someone else remembers and can find the post.
Also client side hit detection, lol. Full of cheat and completely inacurate gameplay.
Networking is very fundamental to some types of games and the expected player experience. Grabbing a generic "this is multiplayer :D" box off the shelf and cramming it into your concept will likely fail miserably if you are seeking a high-quality outcome.
Certain flavors of net code cut extremely deeply into the game engine concerns. Rollback net code is a pretty big dragon in that it suggests your simulation must remain deterministic at all times. Ideally, if you are planning time traveling style net code, you would first have this problem cooking before you send a single byte across the wire.
How many completed games have you shipped with your custom netcode and engine?
What I've gleaned from interviews is that the simulation part of the game including the netcode will be completely custom. The way I understand it, they're effectively only using Unreal Engine for rendering, sound, UI, cutscenes and so on, but all the gameplay logic is their code. Customizing an off-the-shelf engine to that level has to be highly nontrivial, and probably out of reach for smaller projects.
This is the only fear I have with 100% DIY - If I want to go much beyond 90s graphics, I will need to do a lot of extra work (aka "draw the rest of the owl") to even begin talking to artists.
That said, there are ways to build games that do not require elaborate art tool chains. AAA visuals are the antithesis of my target. I am perfectly happy trying to do art in code until the wheels pop off the bus and I have to retool for an external art team.
That said I wouldn't be altogether shocked to see the real Merchant as a funding | creative founder of a game - he has money to invest and has past form developing voice character parts for established games in addition to having solid screen writing chops which can transfer to game universe development.
> Ambient is a single executable which can run on Windows, Mac and Linux
Until I read this:
> Note that content is always streamed so the only thing the joining user requires is Ambient itself to join the session.
So that's what the wasm is for. Even the client code is streamed to the client when you connect to a server.
Interesting take. I hope it's not, as someone else said, an "open core" SaaS where all the useful features will be behind a paywall and PRs for them rejected.
I guess the advantage over pure web games is that you don't need a website to host it?
> the runtime handles synchronization of data for you.
btw this sounds a lil bogus...
The first implementation probably just synchronizes every single change in state of the worlds database.
I wonder if you can flag things that only the server should know, and somehow calculate what each client can see and know about.
Is it using Vulkan at the back or WebGL? I'm surprised that it's not mentioned in large bold text, typically that is the case.
How are you financing this project? You're hiring people, so clearly there is a budget, but the engine is license under MIT, is it based on subscription for support or royalties?
Usually for wgpu apps: Vulkan does not exist on the web, but on the web it can use WebGPU or WebGL
WebGL does not exist on desktop, it will default to Vulkan but also able to use DirectX 11 and 12
webgpu only exists in like the most bleeding edge chrome/firefox builds and even then its very hit and miss. maybe it will start working properly after chrome ships it in september-ish.
We're VC backed, which is how we finance the project right now. Long term we plan to monetize additional (optional) services around Ambient, such as game servers.
Congrats on the release, and good luck!
I don’t see it anywhere but would love to find that Ambient can go from code change to running multiplayer clients in < 10 seconds
That's very impressive!
I believe that web-browser games are the next big thing.