Comment by TacticalCoder | Hacker News Reader

Comment by TacticalCoder | Hacker News Reader

Parent Full thread

> Just a "simple" card game like solitaire would suffice for a lot of the lessons.

I've written an actual game, a 2D platformer.

If there's a domain where it's easy to demonstrate that the view is purely a function of the state it's precisely in gaming. In many games you can toggle (in dev or even for some during gameplay) between "the real view" and, say, wireframe view of the game (with lots of debug infos added too for example). Or you can toggle between a 3D view of your game or a top-down 2D one. Or you can toggle between different types of rendering (as in Diablo 2 where both a 2D and fake 3D view where available and the modern Diablo 2 ressurected, where you can you can show... The 25 year old view if you want to, at any time).

Many games are 100% deterministic and the entire game user(s) played can be recreated from only a record of the user(s) inputs (which is why some save files for long games can be tinier than tiny). And it'll replay the same on different screen configurations / different platforms.

The view in a game at time n is literally f(state n).

Certainly! That was indeed my intention here. The big learning I'm intending is just how much state that people take for granted is necessary to track.

I'm regularly wondering why games are not more talked about in software engineering. Even in the early 2000s games were:

    - more performant and responsive than most company applications
    - while displaying complex real time geometry
    - pretty well engineered
    - fun and engaging
    - didn't require reading 500 page manual to get by

respectfully you haven’t written enough games

> real game

turn-based and real-time games have different kinds of complexity, so a platformer won’t expose you to all of it.

turn-based games are roughly going to give you an easier time separating the game code, but the UI code is going to feel like a debilitating slog.

> Many games are 100% deterministic

Until you use floating points, networking, or different platforms.

This is more likely to be true in turn-based games, and super unlikely in anything real-time and multiplayer.

Most games like that periodically sync state instead of relying on applying actions on each client

Are you saying that IEEE 754 floating point (which everybody is using) is not deterministic?

You have to be careful with comparisons. In JavaScript, for instance, `(0.1 + 0.2) != (0.3)`.

Well that doesn't make it non-deterministic in behavior.

(a+b)-a doesn’t always equal (a-a)+b

It’s different behavior if the order of operations are non-deterministic.

Plenty of room for such things in games. Most of the time the effects are too small to notice. They can chaos-theory out of control, though.

So real time games nearly universally sync state instead of relying on deterministic synchronization via events/actions.

For a good read, look up lockstep deterministic networking.

There’s way too much nuance here to be so dismissive

Chaotic behaviour is deterministic

Weird how I write complete thoughts and supply references but this site full of tech geniuses mostly produces downvotes and single-sentence drivebys.

Come back when you have things worth contributing.

I’m a theoretical physicist, not a tech genius. Perhaps that’s the mode matching problem here. I don’t trust your 23 hour old account though :)

> I don’t trust your 23 hour old account though :)

This might explain why you aren't a genius. He's not saying anything that hasn't been featured on HN before.

This is a popular article: https://www.gamedeveloper.com/programming/1500-archers-on-a-...

It details how Age of Empires decided to make the game deterministic, how this had significant benefits, and how it's extremely difficult to do:

> At first take it might seem that getting two pieces of identical code to run the same should be fairly easy and straightforward -- not so. The Microsoft product manager, Tim Znamenacek, told Mark early on, "In every project, there is one stubborn bug that goes all the way to the wire -- I think out-of-sync is going to be it." He was right. The difficulty with finding out-of-sync errors is that very subtle differences would multiply over time. A deer slightly out of alignment when the random map was created would forage slightly differently -- and minutes later a villager would path a tiny bit off, or miss with his spear and take home no meat.

Do you think you look good by announcing that, since you don't know the subject you're discussing, you're not going to trust someone who does?

I don't trust new accounts whose instinct is to insult me. I don't need to justify that heuristic. Also I was right, chaotic behaviour doesn't mean non-deterministic, which the quote you posted affirms.

So not only was I insulted, I was insulted even though I was right. Also I have studied chaotic dynamical systems, so I have formal education in this.

The interesting thing about chaotic systems is that they have very divergent futures for very similar inputs, not that they're random.

Also I don't really care about being considered a genius, and I think it's sad that anyone would want to be thought of as one.

Saying stupid things is pretty likely to draw insults. They were obviously warranted here.

> The interesting thing about chaotic systems is that they have very divergent futures for very similar inputs, not that they're random.

If you were paying attention... that's exactly what ape_key was referring to. The problem under discussion is that very similar inputs to the game logic lead to radically different states of the game at a later time. The nondeterminism is what gives rise to the fact that the inputs are "very similar" rather than "identical".

Insults are warranted because I affirmed what he said? What? You’ve been a member of this site for 12 years. Maybe you are a bit too jaded from your interactions here. I have reported your comment

Simple operations like addition and multiplication are generally bit-for-bit deterministic, even across different architectures. More complex operations like fused multiply-add can have slightly different rounding behavior. But the big issue is with the more complicated operations, like trigonometric functions or non-integer exponentiation. Those often have differing implementations between platforms, and the only way to guarantee determinism is to essentially roll your own sin/cos/tan/sqrt/etc.

For 32-bit x86 it's certainly not. The C standard permits intermediates to preserve excess precision, and the only way to avoid that is by flushing to memory, which is slow. On Windows you usually get 64-bit intermediates and on other OSes usually 80-bit.

64-bit x86 and modern non-x86 architectures are usually deterministic for primitive operations at least, but libm differences abound.

Reply on news.ycombinator.com