top | item 40657574

Serious Sam handled massive amounts of enemies on 56k modem connections

412 points| sklopec | 1 year ago |staniks.github.io | reply

165 comments

order
[+] immortan|1 year ago|reply
I was one the developers responsible for implementing the netcode on Serious Sam. We often slept under the desks in the offices at croteam after lurking usenet. One post in particular described the QuakeWorld prediction system which inspired us. That night we coded a simplistic mvp as a colleague (hi dan) tested it over an old 486 nix machine acting as a router that we could simulate lag with. This was well before the actual game was built around it
[+] robertlagrant|1 year ago|reply
Why did you make the guys with exploding heads who run at you and their scream gets louder as they approach? I can still hear them.
[+] stavros|1 year ago|reply
I love how there's an article about how some legendary game was made, and someone in the comments casually goes "oh yeah, I built that, fun times". It's great.
[+] k__|1 year ago|reply
Awesome.

I loved that game.

I was a huge fan of co-op games and shooters, but all my friends wanted to play Counter Strike all the time.

With Serious Sam I could at least sometimes motivate them to play something I liked.

Thanks for your service! :D

[+] BirAdam|1 year ago|reply
Serious Sam was one of my uncle’s favorite games (along with Duke Nukem 3D). He was a hugely important figure in my life, and playing through his favorites is a good way to keep connected to my memories of him. So, thanks to you and your coworkers! Excellent game, excellent multiplayer, and very good memories.
[+] vanjajaja1|1 year ago|reply
you've no doubt heard it many times, but the split screen game play was very appreciated
[+] seanhunter|1 year ago|reply
That game was legit. You should be proud that all your efforts resulted in something truly great that people loved to play. Thanks!
[+] raggi|1 year ago|reply
Serious Sam was always a killer LAN party game. Not necessarily because it was the sexiest title of the day, or what anyone had planned. Serious Sam won the LAN party because even when every other game died under some driver issue, thermal issue, update problem, whatever, you’d load Serious Sam and it would just work. This continued through the later series too, hell of someone’s machine was completely dead in the water it would also reliably split screen and handled input well enough for split peripherals. The systemic parts of the game were truly exceptional on the reliability axis.
[+] skhr0680|1 year ago|reply
Serious Sam looked amazing for the shitty hardware it would run (FAST) on.

On a similar note, Counter-Strike never looked good, but was popular for a long time because it ran great on toaster PCs

[+] raggi|1 year ago|reply
Also, the many speaker sound of “aaaaaaaaaaaaah” was delightful
[+] mikeryan|1 year ago|reply
In the late 90s, I managed the EA Tech Support website. The support/QA* teams would have massive after-hours gaming sessions playing Serious Sam. It was the only FPS that ran consistently on our work PCs, and it was a ton of fun.

* At least at that time, EA QA and Tech Support had a lot of overlap; support guys would be come in-house beta testers in the Summer when they were trying to get games done for the holidays and do Tech Support in the Winter around Christmas when the calls went up.

[+] Tarragon|1 year ago|reply
We used deterministic game play to implement multiplayer on the GB Color port of Vigilante 8.

The GBC Link Cable would pass 1 byte in each direction at the same time. It's a pair of shift registers filling each other up across the cable.

The game was locked to the GBC's frame rate. There was a lot work to update the screen that had to happen in each (effectively) V-Blank and if it was missed the smooth scrolling stuttered.

At multiplayer startup we passed our seed. To run it looked like this:

On frame A it reads the controls, and packs them into a byte and puts that in the transfer buffer. The transfer occurs while it renders frame B. At the start of frame C it has the local controls encoded in the byte sent on frame A and it has the other side's controls in the byte received in frame B.

It applies the controls to the game state and renders frame C. Local and remote controls are applied with one frame delay.

There was no frame delay of the controls for local play so if you ever lost in multi-player feel free to blame lag and me specifically if you need to.

[+] HanClinto|1 year ago|reply
I just bought this cart a few weeks ago (love the old GBC rumble carts!) and I was impressed that it had link-cable multiplayer. It's a really good game!

Thank you for the technical note on the multiplayer implementation -- that's really cool!

[+] porphyra|1 year ago|reply
Croteam is such a talented team of game developers. I really enjoyed the Talos Principle (1 and 2) and they were some of the early pioneers of a completely custom Vulkan game engine for the first game.
[+] siberianbot|1 year ago|reply
I found devastating that in The Talos Principle 2 they had dropped their own engine and used Unreal Engine instead.
[+] itsboring|1 year ago|reply
I just found out the Talos 2 DLC is out on Steam this Friday!
[+] mizzao|1 year ago|reply
Is this the same idea as "1500 archers on a 28.8" for Age of Empires?

https://www.gamedeveloper.com/programming/1500-archers-on-a-...

[+] forrestthewoods|1 year ago|reply
Yes. Both are “deterministic lockstep” systems. Many many games have used such a system over the years. Although it’s probably less common these days for a variety of reasons.
[+] OptionOfT|1 year ago|reply
This number actually shows how weird it is to have a unit cap in Tempest Rising.

Either you have the resources, or you don't. Don't cap for reasons of capping.

[+] 0xbadcafebee|1 year ago|reply
Yet games with 10x the bandwidth struggle to support that many enemies. It only just occurred to me: an increase of technological resources actually has a reversing effect on the efficiency and creativity of computer science. As bandwidth, storage, memory and compute has gotten bigger, there is an inverse response in the software that makes it slower, more bloated, and less capable, per discrete unit of resource. Call it the Benjamin Button software design effect
[+] shultays|1 year ago|reply
Do you have a number for "that many enemies"? If article is giving one, I couldn't find it. There are plenty of modern games that is multiplayer and supports enemy numbers that I would consider "massive". Or massive number of players if that is that matters.
[+] MoOmer|1 year ago|reply
Better known colloquially as software bloat!
[+] account42|1 year ago|reply
Yes, this is known as Wirth's law.
[+] luag|1 year ago|reply
The kind of game where I believe I moved backwards more often than moving forward.
[+] tiku|1 year ago|reply
Haha they even made a game about it, and its called "I hate running backwards". It's on Steam. I don't know if its from the same makers but it is in the Serious Sam universe.
[+] mablopoule|1 year ago|reply
Well, you and Netrisca were together, while those thousands of enemies, they were alone.
[+] eps|1 year ago|reply
And the gun that seemed to shoot a fraction of a second before you clicked the mouse button.
[+] danra|1 year ago|reply
...and, IIRC, desparately grasping for generated ammo to pick up while making said retreat.
[+] namibj|1 year ago|reply
Similarly, Factorio's architecture transmits (almost; notable experience is rail planner) just input events, relying on a lock-step simulation core.
[+] robertlagrant|1 year ago|reply
I would love to work on a lock-step thing like that one day. Seems such a satisfying (and testable) design constraint to work with.
[+] LarsDu88|1 year ago|reply
Ahh, I remember playing a PC Gamer demo of Serious Sam as a kid. Even back then it was considered a "throwback" game to the days of old-school DOOM and Quake.

And now literally two decades have passed and its considered a classic in its own right.

[+] givemeethekeys|1 year ago|reply
Starseige Tribes was massive and ridiculously fun on a 56k connection.
[+] ItsBob|1 year ago|reply
Quite possibly my favourite game growing up (especially Tribes 2!)

In fact, I downloaded Tribes 2 a while back and was playing against bots just a few months ago.

The game is dated but it was still fun... in fact, I've often thought of trying to remake it in Unity or something!

Maybe one day.

[+] robertlagrant|1 year ago|reply
Tribes was brilliant. Skiing down procedural terrain (and watching other people ski up it), big maps, lots of players, in 1999.
[+] kentonv|1 year ago|reply
Isn't this exactly how Doom worked, long before Serious Sam?

But Quake went a different direction, sending the client updates about every entity they could see. Which had some benefits (players don't have to be perfectly synchronized) but also drawbacks (bandwidth proportional to scene complexity).

[+] Renevith|1 year ago|reply
This is covered at the very end of the article, in the "Comparison with Doom and Quake" section. And yes, that's exactly the comparison and distinction the author draws, and they explain why Serious Sam would have opted for Doom-style networking (the notoriously high scene complexity).
[+] Thaxll|1 year ago|reply
Quake is vastly superior because the server actually run the simulation, for Serious Sam the server is basically a dumb relay.
[+] Demiurge|1 year ago|reply
That was a fun game, I loved the demo.

I think some of the extrapolation might have also inspired optimizations made in CPMA mod for Quake3, which to this day, I think, has the best netcode of all games. You can actually compete with 100 ping, in it, which is completely unplayable in OSP or vanilla Q3. I don’t think any other game even attempts to be so optimized for competitive online FPS.

[+] tombert|1 year ago|reply
I loaded up the original Serious Sam The First Encounter about a year ago, and that game never ceases to amaze me with how much they were able to squeeze out of relatively low-powered 2002 computers. I had it as a kid, and I had never seen so many enemies on the screen at once.

Even now, the game mostly holds up pretty well and it still kind of impresses me.

[+] jasonvorhe|1 year ago|reply
Yeah, Doom Eternal struggles with like a dozen demons in one room and fps are immediately halved. It's such a pity. It's actually a decent game but if you can't keep somewhat consistent fps in a shooter game where every second counts, you'll just grind down the nerves and patience of your user base.

I know many people love Doom Eternal and other shooters with similar issues. Maybe I'm just sensitive to these kinds of frustrations.

[+] michelledepeil|1 year ago|reply
Impressive writeup. The deterministic aspect is not super popular anymore, I guess, but this entire post does make me wonder how the networking layer compares to a slightly more modern multiplayer game.
[+] javaunsafe2019|1 year ago|reply
Do I get it wright - the reason to implement a custom protocol above udp instead of using tcp was the benefit to have a certain amount of packets that didn’t need to be acknowledged?
[+] opyate|1 year ago|reply
> But why do we see smooth movement and animation?

>

> Interpolation. Serious Engine interpolates between the current and the previous game tick based on time passed between. Try opening the in-game console (~ key) and typing this to see how the game looks and feels without interpolation:

>

> /net_bLerping=0

>

> It's kind of like playing a modern console exclusive.

That list bit made me spit my tea out, I laughed so hard.

Great game. A staple of our LAN parties, what, 25-ish years ago now?

[+] jebarker|1 year ago|reply
> without interpolation … It's kind of like playing a modern console exclusive.

Ouch. It’s sad to see console gaming no longer be the place to go for highly tuned software.

[+] ipeev|1 year ago|reply
To be or not to be, this is a serious question.