twi

script kitty



↓ cohost let me center align this challenge ↓
This user is it. (What is it? It's it)
This user is a host for the fungus.
↑ cohost let me center align these challenge ↑



i'm the body selling robot and i'm always selling bodies

breaking into mausoleums doing something naughty



  • also a cat obvs
  • does art, video, coding, gamedev as executive dysfunction allows
    • (godot, zig, some c/c++/c#. if you need a programmer hmu on twitter or something)
  • 日本語はあまりできませんけど、学ぼうとしています
  • very autistic, probably inattentive adhd
  • θΔ maybe, nonhuman for sure
  • 29 & kink/sex positive, period
  • dni if you: have a dni in bio,
    click here to sexually harass this user

(pfp: actual nitw concept art)


hthrflwrs
@hthrflwrs

working on savegame systems today, aka the literal most boring part of game development


hthrflwrs
@hthrflwrs

q: what's so bad about savegame systems
a: they require a completely different knowledge set (json serialization, file i/o), they take forever to test (since finding edge cases requires constant saving/reloading), and there's approximately zero interesting decisions to be made along the way

gonna try adding one of those "last saved the game [x] seconds ago" things to the quit screen though, so that's fun


lexyeevee
@lexyeevee
  • from the very beginning, keep the broader state of the game in a "progress" thing, in an incredibly boring format. you think the player's inventory is a property of the player character? dead wrong. that's a property of the human player's progress through the game. if forgetting about it would feel like losing progress, it goes on the progress object

    • but if it makes any sense whatsoever, track which player's inventory/etc it is, somehow. maybe you have no intention of ever having multiple players, but this is the sort of thing where it costs nothing now to leave the door open to the possibility, whereas trying to retrofit it on later will be a truly staggering pain in the ass.
  • PUT A VERSION FIELD ON THE PROGRESS OBJECT. DO IT NOW. SET IT TO 1. DO IT. DO IT NOW

  • consult the progress object frequently. it is the arbiter of truth do not let anything else think it knows better. do not "cache" anything you fool just check the progress object

  • now serialize it, like literally throw it at a json library

  • that's it you saved the game

  • for bonus points you can describe the schema later and validate on load or whatever but honestly if someone constructs a bogus save file and crashes their own game that's on them


@twi shared with:

You must log in to comment.

in reply to @hthrflwrs's post:

My curse as primarily a Backend Developer is that I always need to have something like this and data storage in place first when I try to make almost any game from scratch due to who I am as a person, so I end up making at least one big fucking JSON parser and then end up losing steam on actually making the rest.

the last save system i worked on ended up with like a dozen copies of the main save file class to support upgrading older save versions and, it was the most miserable thing in the world to ever have to touch.

my favourite part of making a save system is figuring out a cute extension name for the saved files (Frogsong saves were .frog). And then i think of one in about 30 seconds and the rest of the task sucks ass forever

in reply to @lexyeevee's post:

I wrote a binary save format last year for work, and while I had an object version on my core save class I managed to forget to include a binary version field.

I did preemptively include a generic "save flags" uint64 though, so the first flag added was "this save uses binary versioning, starting at the byte right after the flags". I feel very lucky to have dodged that one.