Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ambient: The Multiplayer Game Engine

ambient.run

Post reply on HN
Print view View original

91–100 of 148 posts

Re: Ambient: The Multiplayer Game Engine

#91

Post by echelon »

MindSpunk wrote: post #88
echelon wrote: post #29

Earlier quoted context omitted.

> 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…

> You can't even achieve PS2-era graphics with Rust right now That's just straight up false: https://github.com/EmbarkStudios/kajiya https://github.com/BVE-Reborn/rend3

You didn't respond to the substance of my comment, and your links solve none of my problems.

Where are my PS2-era shape keys? Bones aren't going to cut it.

Re: Ambient: The Multiplayer Game Engine

#92

Post by [deleted] »

Cyberdogs7 wrote: post #4

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.

[deleted]

Re: Ambient: The Multiplayer Game Engine

#93

Post by anentropic »

pjmlp wrote: post #64
tomcam wrote: post #33

Earlier quoted context omitted.

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,…

WebGPU doesn't necessarily mean "in the browser" though

Rust game engines are using it as a library for native games

Re: Ambient: The Multiplayer Game Engine

#94

Post by nicolaslegland »

TobiasEnholmX wrote: post #84
Cyberdogs7 wrote: post #4

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.

Ambient co-founder here. You're right, thanks for the feedback, we'll update the website with one soon.

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.

• 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.

Re: Ambient: The Multiplayer Game Engine

#95

Post by sandos »

charcircuit wrote: post #6

"the multiplayer game engine" 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?

Sadly there is this snippet:

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.

Re: Ambient: The Multiplayer Game Engine

#96

Post by whizzter »

raizer88 wrote: post #73
whizzter wrote: post #71

Earlier quoted context omitted.

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 shippin…

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…

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).

Re: Ambient: The Multiplayer Game Engine

#97

Post by mentos »

Biggest issue I have with my current game engine is compile times are about a minute for C++.

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

Re: Ambient: The Multiplayer Game Engine

#98

Post by loup-vaillant »

CGamesPlay wrote: post #18
Cyberdogs7 wrote: post #4

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.

I found it very funny that the "multiplayer game engine" hero video had... 0 players in it.

Zero is plural in English.

Re: Ambient: The Multiplayer Game Engine

#99

Post by coderedart »

unconed wrote: post #24
keyle wrote: post #20

A couple of questions... 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?

It says it is using WebGPU, which is the successor to WebGL.

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.

Re: Ambient: The Multiplayer Game Engine

#100

Post by loup-vaillant »

raizer88 wrote: post #86
Hikikomori wrote: post #82

Earlier quoted context omitted.

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, fo…

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.

> After this rating drop a lot on a player it should trigger a manual/automatic ban

I once heard of a game that instead of banning cheaters, isolated them together in a separate bucket. Cheaters could still play… amongst themselves.

Post reply on HN