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

71–80 of 148 posts

Re: Ambient: The Multiplayer Game Engine

#71

Post by whizzter »

raizer88 wrote: post #59
whizzter wrote: post #56

Earlier quoted context omitted.

Giving state isn't the problem, the client being authoritive is the problem. 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.

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.

Re: Ambient: The Multiplayer Game Engine

#72

Post by meheleventyone »

whizzter wrote: post #50
nobu-mori wrote: post #22

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

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.

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.

Re: Ambient: The Multiplayer Game Engine

#73

Post by raizer88 »

whizzter wrote: post #71
raizer88 wrote: post #59

Earlier quoted context omitted.

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

Re: Ambient: The Multiplayer Game Engine

#75

Post by dgb23 »

raizer88 wrote: post #59
whizzter wrote: post #56

Earlier quoted context omitted.

Giving state isn't the problem, the client being authoritive is the problem. 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.

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.

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.

Re: Ambient: The Multiplayer Game Engine

#76

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

#78

Post by FredrikNoren »

nobu-mori wrote: post #22

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

Ambient CPTO here; We're working on expanding the docs on this, here's the GitHub issue: https://github.com/AmbientRun/Ambient/issues/150

Re: Ambient: The Multiplayer Game Engine

#79

Post by franciscop »

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.

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.

Re: Ambient: The Multiplayer Game Engine

#80

Post by FredrikNoren »

pjmlp wrote: post #31

A game engine for the Web without any usable demo, only a video. Who knows how it came to be. 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...

Ambient CPTO here; We're not quite on the web just yet! We're currently working on it though and it's looking promising, so stay tuned
Post reply on HN