How to Make Multiplayer Online Games

Enable Subtitles for Twitch Chat

References:

Support:
- BTC: bc1qj820dmeazpeq5pjn89mlh9lhws7ghs9v34x9v9

[idkncc]

Finally new video from my favorite web developer!

[cryptonative]

Bro: I don’t have any experience with networking
Also bro: Written a web server in assembly

[BboyKeny]

As response to the question at 20:00. I've been using vanilla JavaScript with Esmodules and Jsdoc comments. Typescript LSP can parse the doc comments from .js files. That way I'm not using any dependencies or build system while having types and an LSP.

[rebokfleetfoot]

sync of the multiplayer was an issue, we blamed it on Einstein and his time dilatation theory :)

[mthia]

the twitch chat as subtitles is the best things i've ever seen

[im-anomalies]

I just have finished to watch the previous yesterday after work and here we are again! My fav content on yt

[greyshopleskin]

Thanks for all your videos.

Nowadays people just act as consumers of high level, messy abstractions without understanding the basics.

Complex solutions are invading each area and people think it is cool and the right way.

I’m so, so sick.

I enjoy your recreational programming videos. They help me learn about different topics and understand a little bit better the basics.

[Hazanko]

I'm building a game/engine and have written all of the networking stuff in pure UDP. There is a ton of stuff you can get away/be lazier with in a single player game; put simply you can be lazier with your data and overall layout.

In a single player game you can make a ton of assumptions, and/or rely on work that's already been done elsewhere.

A good example is, on the server application(or in single player mode), every character has a ton of values associated with stats and bonuses and what not. For the client to properly simulate what's on the server, you'd need to either send a massive chunk of data from the server every single time a new character was visible, or find a way to detach various actions from their full simulation and send a tiny packet and expand upon it client-side. Do you send a damage value with the projectile_add packet? what if the damage isn't calculated until hit and there are crits/resists/etc?

Then, obviously the nightmare that can be async, combined with the network layer and things like latency, dropped or re-ordered packets, etc. If a thread keeps getting blocked and goes to sleep, in my experiences the debugger isn't going to help, so it's print-to-console-debugging and other logging systems built into the program itself that you need to rely on. Sending some packets back and forth is incredibly easy and you could get something working in a couple hours probably, the bigger hurdle is the layout of your program being compatible with callbacks and simplifiying/minimizing interaction points between threads. Most of the system could be ''working'', until you put it under any load and realize it's constantly hanging waiting on main or networking thread... WHO KNOWS !?

The 'plus-side' is though, doing the work to align things for networking usually means any sort of future feature-extending becomes easier. Certain abstractions or gains that you might think pointless for a single player game or might not even think of until you'd explicitly need it, can actually end up being a gain regardless. Something like allowing a player to save their game is really easy when you already have data accessible and formatted for network messages.

Being that I decided to go with full UDP, I had to build the packet handling system for things like confirmation and resending for missed replies, connection/time-out/etc. TCP would be much easier I'd imagine in many ways, and would likely be the way to go for anything not intending to work on a larger scale(or maybe period lol).

[lengors]

1:07:50 While it doesn't generate the function, but with the newest version, it does infer the return type (`arg is Test`) if you follow some rules (which helps reduce code bugs). There's also some libraries out there for it

[antonpieper]

2:10:09 the difference is that interfaces get merged, so if you declare an interface Vector2, you can later redefine the interface and it won't replace it but rather merge it.

[byterbrodTV]

Can't wait for continue.
Thank you for all your content!

[RandomGeometryDashStuff]

12:35 yes, there is from gpu to cpu
how else would screen recorders like obs work?

[bbq]

3:00:06 If you change from interface to type you’ll force the users of the type to initialize all fields, solving the problem

[Martinit]

Even today (2024) you may want to use webpack for several reasons:
* minify and/or obfuscate your JS code
* eliminate unused code
* bundle several JS files into one or a few bigger files (fewer network requests to load all code)
* inline assets, like if you have a gazillion of images they can be automatically inlined as data-URI in CSS, again resulting in a single file

[aredrih]

(just some general feedback/through on the project. Not meant to be feature request; just take on the way you're going so feel free to ignore them)

So, a problem with having the entire state of the game to the client is that the client has the entire state of the game.
So wallhacks are hard to prevent with that design.

Another point is that you have a full server round trip every time a player tries to move (and the final position is decided by the server).
Not the worst on low latency but effectively not having direct control over your character can jarring.
Giving players control over their position does open up room for abuse but nothing a "trust but verify" approach can't prevent.

But if you allow player to decide were they are, there are "fun" desync that can happen with 1 player stopping before a corner an another one shooting the server prediction going past the corner. One think they shoot the other, the other thinks they didn't get exposed.
How you deal with that has to be decided by what feels right. You can make slowing down be slugish to reduce the size of the server misprediction.
The most complex games engines I've seen had timestamp in client message and rollbacked the server state to process event sequentially.
Even then, the issue had to be decided based on what felt right to avoid being biases toward player lagging and because you kinda want to reward head shots.

[WicToR]

1:05:15 ...these typeguards are going away in next version of typescript, it will assume it automatically (not sure to which extend tho)

[RandomGeometryDashStuff]

02:07:22 valid directions: __defineGetter__, __defineSetter__, __lookupGetter__, __lookupSetter__, __proto__, constructor, down, hasOwnProperty, isPrototypeOf, left, propertyIsEnumerable, right, toLocaleString, toString, up, valueOf

[TheEyeOfBrows]

On BSON: I used it quite a bit, and found it lacking for my purposes. I wanted smaller network messages, but the BSON serialized messages wound up being about the same size as the equivalent JSON. We switched to protobufs where we don't need readable strings.

[SeishukuS]

Not too far off from how I did multiplayer in my engine, though I'm still kind of stuck trying to figure out getting physics objects synched without blowing up the simulation or needing insane amounts of bandwidth.
I also added networking pretty late in my engine's design, it wasn't *that* bad adding it in... Not saying it's pretty, it's still pretty much hacked in still, but wouldn't take much to clean it up. lol
It's something that's fairly low priority.

[RandomGeometryDashStuff]

01:12:00 what if server sends bogus-amogus message that is not valid json and JSON.parse throws error?