Comment by interroboink | Hacker News Reader

Comment by interroboink | Hacker News Reader

Sometimes, when battling these issues, I wish the Smalltalk-style approach[1][2] was more popular/feasible. Basically, saving the entire state of the VM is a fundamental operation supported by the language. Only truly transient things like network connections require special effort.

There are some echoes of this with things like Lua's Pluto/Eris, or serializable continuations in other languages (eg: Perl's Continuity).

It's just such a pain to thoroughly handle that sort of stuff without language-level support. And doing a "good enough" approach with some rough edges is usually shippable, so it's hard to build a critical mass of demand for such support. And even if there was, it's very hard to add it to a language/framework/etc that wasn't designed for it to begin with.

I've had a decent experience with 'struct string' style approaches, like Lua's string.pack() or Perl's pack()[3]. It's a little brittle, but extremely straightforward and "not framework-y," which suits me. But it leaves out things like program execution state; it's just for plain data.

[1] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...

[2] example of using this serializable statefulness for serving web apps: https://en.wikipedia.org/wiki/Seaside_(software)

[3] https://perldoc.perl.org/functions/pack

A full memory dump for a game will nowadays often be multiple gigabytes, that's a non-starter.

Even back in the day, Game Maker had a function to dump the state to disk that was intended for game saves. It sucked - turns out there's a bunch of state that you don't want in your savefile - keybinds, settings, even most game state actually.

Save state should be opt-in, not opt-out, and on top of that a VM/memory dump makes it a very big pain to opt-out.

All valid issues, to be sure. But I do think that a big chunk of the suckiness is poor tooling (lacking easier/better ways to opt-out or customize various parts, for instance) rather than a conceptual problem. That's why I feel like it would require a language to fully embrace it (kinda like Smalltalk did) rather than being a bolt-on feature. And for games it would likely need to be innately aware of GPU concerns, too.

On the flipside, there are (hopefully obvious) big advantages for the development process, when you can snapshot full states.

Of course, none of it matters if you actually need max performance — no AAA shooters would use it. But there are lots of not-performance-critical games which might benefit more from the better development experience at the expense of some performance. Perhaps point-and-click adventures, sidescrollers, shootemups, and such.

Anyway, just spitballing (:

I'm working on a game now that has almost no state, and I wish for a way to have that same freedom I feel in a more stateful traditional game, without having to muddy up everything with serialization interfaces et. al.

You can surprisingly sort of do this in Java. Just create a lambda which will start the game at the current state when you call it.

Huh?

I don't, in fact I mostly hate serializations systems. IMO they lead to extremely long load times. It might be more work to put the data that actually needs to be saved into some binary blob but it's the difference between a game that loads instantly and a game (like Source games) that takes 10-20 infuriating seconds per level every time you die.

Reply on news.ycombinator.com