Always good to see more game engines coming out. Might I make a suggestion though. For your hero video on the site, I would expect it to be showing off the multiplayer aspect of the engine. Rendering environments, even in extreme detail, is considered table stakes for a game engine. Show off your unique selling point, making multiplayer games much easier than with a different engine.
Regarding that video, stuttering on a travelling content made me tick. Video has a lot of duplicate frames, not in a perfect ratio of the encoded 60Hz.
Exactly, the video shown seems just like a 3d model and the camera going through it, something that could have been done in e.g. Blender with nothing to do with games.
What are the guarantees about the networking? I saw this in the blog post:
> 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.
Not necessarily, emulators has been doing this a while I think and with WASM this is the second impl I'm seeing of this.
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.
Unless they are cooperative games giving copies of the server data model to the client inevitably leads to wild cheating. I give you the example of Escape for tarkov, where not only the data model is shared, but the client is authoritative over the server. A beautiful game ruined by the incompetence of the network-side development team.
Tarkov like most games uses client side prediction with some server side checks on actions, it can be hard to see the difference between a predicted action and client authority, they've been slowly increasing checks over the years as cheat developers finds new things to exploit. Since checks can be costly for performance you don't want to check things you don't have to, so doing it incrementally as you need is ok, for a game that is in a heavy development stage.
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 agree on most of it. I think the way to do server side check is not in real time during the game, but after the game session ended. You should unload every gamestate on a secondary server that process everything and rate what could be manipulated with a degree of confidence. After this rating drop a lot on a player it should trigger a manual/automatic ban.
This went pretty terribly for Fall Guys[0] because the moment a false positive slips through, and then that player posts their clip of a game with close to 100% cheaters on Twitter or Reddit, it exacerbates their image of a game with a serious cheating problem. Everyone saw a game taking place jam packed with cheaters and it became a PR problem they had to overcome.
Giving full state is still a big problem. Aimbot, ESP, wall hacking are possibile only due to giving full state to the client. Most competitive games avoid this as much as possibile, eg. Dota2, Valorant, etc.
Right, I agree there but from a development perspective it's a problem that can/should be tackled later if you know you have a hit, and the Ambient design should have no issue in fixing it later.
- 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.
At the theoretical level I agree with you about creating an MVP first and then solve these kinds of problems the moment you hit the jackpot at the ROI level. The problem is that in 20 years I have never seen a single game do that. Because revisiting the whole network/data stack in a game that has come of age is a nightmare and the PM probably doesn't see value in it. By now you are a hit. The problem is that instead of milking the cow for 10 years because you have a cheat proof product, you make money for 3-4 and then you close. (possibily damaging your brand as a cheater infested game)
Right, and that's why I like this approach (that I'm doing and it seems the Ambient lib is built for from the examples I looked at) because there is an actual architecture that is designed for networking from day one and visiting netcode isn't as bad an issue because it's mostly just regular game-code as long as the core principles are followed.
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).
Only a couple of years ago I played an incredibly fun game with an open multiplayer aspect to it. You didn’t really know who was friend or foe. Alliances and rivalries formed ad-hoc and betrayal was always around tge corner.
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.
Yup it relies on two things though, the simulation being deterministic which is easier said than done and the simulation being cheap enough you can replay enough frames to correct the missed inputs without derailing the current frame.
I have to ask: Why not contribute to Bevy instead?
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.
Engines need to be high-performance across machines and networks, a challenge in itself, and their maintenance is more complicated than an operating system's. This is an observation based on the current engine and OS market. Why is it bad that they're a SaaS business? What other business models are ok for making game engines?
Not trying to be rude, but I can’t decipher what you are saying in the second paragraph. Is infinity blade created using the Ambient engine, or does it have deceptive demo videos, or what? Sorry, not trying to be dense.
Besides what the others answered, not only it showed off what was capable on iPhone, it showed what OpenGL ES 3.0 (the WebGL 2.0 foundation) could do.
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.
It does, anywhere else is better served with middleware that has full exposure to native 3D APIs without the constraints of an API designed to be called in a browser sandbox.
Infinity Blade was an iOS game released 13 years ago that was among the first to truly show off what you could do in 3d on an iPhone. It was an early killer app.
I'm sorry this is not really relevant to your comment, but I think it is important to restate the obvious. Why this page needs to put cookie panel? It takes 1/3 of page. Also there is just 'I Accept' button.
"Why not Rust?" is a question I ask about game development a lot these days.
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.)
Last game engine(C++) I worked on was a full hour to build if you touched a core header, and that was with Incredibuild that farmed out the compile across the studio.
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.
That is why we now have incremental linking, hot-code reloading and for the lucky ones on VC++, modules.
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.
> The terrible compile time is a big reason why I avoid rust for game dev.
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.
> You can't even achieve PS2-era graphics with Rust right now.
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.
Haven't looked into it, but I think there were a bunch of projects for Vulkan bindings for Rust. Not sure how much harder it's to use that vs using it from C++.
So ambient uses WebGPU, which on rust usually means the wgpu library, which has a vulkan backend for platforms that support vulkan. It's possible that's what you're thinking of.
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 sounds to me like an engine issue, it has nothing to do with it being in Rust. Same can apply to engine in any language. I.e. whether it provides certain features for you or not and you need to implement them yourself.
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.
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.
>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?
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.
There's this small one called Farmville. Though granted I don't know if it's still printing cash the way it used to. It's possible smartphones killed that sort of game.
My wife has been playing the same farmville farm for 12 years, since I met her. Hasn't spent a penny, but they release updates all of the time. I'm amazed at her dedication and theirs to this game.
> Yes, this is performant enough for games. Yes, it's being done in AAA games.
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.
Probably used scaleform. It was used by many games. It was a massive headache for engine programmers. The thing really had very very poor performance... I think it was always heavily hacked so that it could run decently, both the actionscript side and the scaleform side. At least that's what a programmer did for a year to get something decent. I can't believe it could have ended up anywhere else with that tech. Still, it was amazing for artists.
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.
Engines that reached escape velocity often did so by having usable artist tools and [...] no, that's pretty much the defining factor. Artists used them.
Seeing people in the age of 2 commercial engines (and only one you can reliably ship with...) attempt to challenge architectures the incumbents instilled, knowing the challenge of getting games made with a new engine, gives my cynicism a run for its' money.
Yep, good tools was the minimum a decade ago, these days you also need an asset store. I suspect the next decade you will need to have integrated AI tools.
The only opensource game engine that looks interesting is Godot, they are working hard on making their tools better and growing their asset store.
"Integrated", imho, is exactly how large engines will win.
Modularity is a huge challenge (ABI, Data Pipeline, where compute happens), but without modularity, only engines with teams of hundreds will be serious contestants.
Just by seeing those two peeps in the sofa I immediately knew they were Swedish (and right I was). :) Isn't it funny how easy it is to sometimes spot your own nationality?
Another example for you: people from Russia, Ukraine, Belarus can easily recognize other people from these countries (but we cannot recognize for sure what country exactly).
> The compiled assets are always streamed to clients, so that they can immediately start playing without having to download all of the content first.
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.
This is what I didn't understand about Google Stadia. I thought they will make gaming bigger in Youtube and automatically show a "play now" button next to the video. Maybe even the possibility to join the game of the streamer. It would work in an instant without download.
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.
Yeah, Stadia's load times were still bad, it was silly. And they didn't streamline entry into most games so you'd still be watching publisher logos, pressing Start to continue, navigating menus, logging in, accepting additional clickthrough license agreements, etc. What a farce that was.
This seems like a mostly very well thought out design (I have a qualm about one detail but maybe they're hiding it), I've been rebuilding an old prototype of mine in a very similar way.
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).
I know Planetside 1 was pretty heavy on client side - not sure about PS2 (but my impression was that it would be less client side logic - to avoid some of the cheating.
I think some time ago (2 years or more?) there was this guy, I believe from The Netherlands, who had made a game that seemed to be to support a massive number of players with minimal hardware requirements.
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.
found a small thread on reddit which posed the same questions [0]. it looks like the above comment hit it on the head; mostly client side with server just handling messages. looks like it didnt scale well either.
Yeah they've claimed that for awhile with no results. Dual Universe (which I backed) also demoed a many player test, but its never accumulated much pop and is not really a "fast" fps either.
I am at a point where I do not believe I could outsource the net code for the kinds of games that I'd like to develop anymore. By extension, this sort of ruins my ability to use any commercial product like UE5/Unity/et. al.
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.
It's interesting in that respect what the developers of Frost Giant Studios, comprised of ex-Blizzard RTS devs, are planning for Stormgate. Complex RTS games need a deterministic ("lockstep") simulation to be viable over the network. On the other hand, they are using UE5, which as you indicate, has a completely different server/client model.
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.
Actually as long as you have access to the lower level APIs changing that stuff out whilst not trivial isn’t that crazy. The big win with UE in particular is then phenomenal art pipeline and tooling which would take an age to reproduce in a custom engine.
> The big win with UE in particular is then phenomenal art pipeline
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.
Yeah, it's a shame because multiplayer was an afterthought for the current major engines that you listed. Off the shelf multiplayer can work really well if the engine was designed for multiplayer. The Source engine always comes to mind as an engine that has proved itself with many high quality multiplayer titles. I wish Valve made licensing Source easier/cheaper.
>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.
How many completed games have you shipped with your custom netcode and engine?
Unity multiplayer implementations have been very awful indeed. But UE4 netcode was pretty decent for local small room (under 16 people, whole scene loaded at once) scenarios out of the box.
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.
Ambient CPTO here; Yeah that's pretty much how it works; changes on the server state and replicated to clients, which keeps "mirrors" of that state and can augment it in different ways. And yes you can specify exactly which entities and/or components get replicated to the clients. We're working on adding more details on the networking stack: https://github.com/AmbientRun/Ambient/issues/150
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?
Hi, Ambient CPTO here; We're using wgpu (a rust crate), which supports a number of different backends, including Vulcan and WebGL (and Directx, WebGPU, Metal).
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.
its using `wgpu`: a rust library which provides safe graphics api and uses opengl (webgl2), vk, dx, mtl, webgpu as backends. c++ has a similar, but much older project called `bgfx`. If you see wgpu on web, its most likely using webgl2.
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.
Features look quite similar to what Unity offers (networking support, asset streaming, runs in browser). Maybe would be good to have a comparison page with Unity and other similar engines, so you can see "why choose Ambient"?
I was waiting for something like this to build the simplest MMO I could (like pixels fighting or something like that). Maybe I’ll try it later this year if my current side project flops (which is highly likely)
Yeah that's the idea; as a user you build multiple independent modules, which each are compiled in isolation, and which each produce a WASM module. The runtime then loads that module. All of this is very fast on the Rust toolchain with incremental builds, though of course it depends on the user breaking their code up into reasonably sized modules. The modules can independently be hot-reloaded (we had this before but it went away in a refactor, but we're planning to re-add again).
