the actual game implementation really is fun! the amount of stuff to do just branches out a lot.

but until i get there, ill need to think things thoroughly (and write them down to not forget). feels like vagueposting but idk. it's real scary when i cannot refactor around a big flaw.

(outside-in meaning, try to figure out what i want to do in godot, then how godot should interact with rust, then the rust implementation. doing it the other way means im anticipating what i want, which is usually wrong.)

once again wondering if i should restart my game's code. in the past, i wanted gamestates to be small in memory (and on disk), which is unnecessary.

the plan is to restart, work from the outside-in, care 0 about premature optimization, and get to the fun part instead of diying engines forever.

i took the screenshot in desktop mode, but im super curious. i just set up my og htc vive. literally decade old hardware.

waiting for the steam frame aaaaaaaaa

A blue dragon with yellow accent colors wearing striped monochrome clothes, looking into a mirror in vrchat.

first time successfully customizing a model for vrchat!

(hope to get to the part of the game with the chatting 🙃)

A drawing of two kobold Sxolian wearing a studded collar and fishnet arm wraps. One is doing the "peace" sign while looking right with sparkles coming off of him, with the other just looking to the right standing there.

🏳️‍🌈🏳️‍🌈❓

having trouble deciding *what* i want to push onto github. tbh the real answer to force-push over experimental code.

but yeah this week i will clean up my path node stuff. i also need to do a better job at spreading my work over the week instead of going sicko mode for two days and recovering.

in the previous version of my game, one script would imperatively initialize the gamestate. nodes were responsible only for visually representing that gamestate. those nodes were never read from.

i can still do that again. just wondering about any long term pros/cons.

but that's the "fun" mathy idea that works.

the other idea is just software engineering. godot internals work with some data redundancy, and i wanted to match that but now im not so sure. loading a scene, nodes are the source of truth. running a scene, a source of truth writes into nodes.

the player would see this flat version in game. they should only be able to see one of the many overlapping chunks at a time. and if they walk in a big enough loop, they should arrive in the same position while seeing a different chunk.

The same squares as before, except now all the same size. There were 161 squares, now taking up 41 spaces.

(i just did some math for how much to scale to remove most gaps. the squares in the image only scale by half.)

if you only provide translations without scaling, the function stops being injective. translations are commutative. this results in this screenshot.

A bunch of squares in a game engine editor. A central square has four smaller squares around it. Each other square has three smaller squares around it. No two squares overlap.

paths and transforms have inverses, but im ignoring it in the function. i want long paths in any direction to scale down, to display everything cleanly. this gave me this screenshot.

(if i did respect inverses, half the steps would scale up instead 💀)

the idea that's working is a godot node3d whose local transform is a function of a path, stored in the node.

a path is a sequence of steps. paths can be joined, but they're not commutative. transforms/matrices behave the same, so we can map steps to a set of transforms.

(not sure how to not vaguepost about gamedev. im down to explain more and its not a secret, but there's just not a good reason to write a bunch)

satisfied the intense urge to gamedev for now, but feeling a little intimidated.

my new ideas are working, i threw together some rough stuff i don't plan to keep. i still need to think real hard before i can make the stuff useful.

also found this, which supports my thinking. scenes are initializers with no extra behavior.

docs.godotengine.org/en/stable/tu...

studying godot even more to try to fall sleep, but i just want to hop on a computer and test things.

i think i can suppress properties from being shown and saved with Object::_validate_property. my custom node's 3d position is a function of my own position type.

godot servers are named confusingly tbh. i wish they were named "services" instead?

i mean this kind of stuff: docs.godotengine.org/en/stable/cl...

(but yeah, on other projects, i have messed around with online multiplayer and ran into the same issues too)

maybe modification should be tolerated somehow. the physics server doesn't complain if the editor or a script directly moves an object into another, when that would've been a collision.

maybe the correct way to think of a node is like a python __repr__()? at any time, you can exec(repr(thing)) to initialize a new thing. which makes sense, every node can be duplicated.

this causes friction with my rust game logic, where things can't be freely modified.

scripts are also doing arbitrary stuff at runtime. they *can* modify info the server cares about, directly through a function call, or indirectly by modifying a field.

if nodes were solely responsible for initializing, then id have an editor. but they also do stuff at runtime.

the physics servers write positions and rotations into collisionbody nodes. (this is what lets you do the save and load trick.)

nodes are definitely responsible for initializing stuff in the server.

loading an entire scenetree initializes servers to about the same state it was when it was saved. except, you can add stuff to servers without interacting with the scenetree, so it's not the same state

been studying how godot's servers work, to see if i want to make my game logic do something similar.

at this low level, not sure what nodes and the scenetree are exactly responsible for

Wonderul headshot commission from @bluekiwi101.bsky.social! A lizard chasing their dreams to fly.

throwback to that time I drew almost every character in Mother 3

Starting a technical design document right now. I've had awkward experiences with "monolith game design documents" and I think a focused set would be better.

I'll also want to set up a mockup / "user story" of the game. I'm thinking of an in-engine thing that conveys the same "feel."

I can handle the project's massive scope. The issue is, in that scope, I keep forgetting things, changing my mind, getting distracted.

It's kind of like that by design, being a personal tinkering side project while I was employed. It's not a side project anymore. So let's formalize it.

I got (productively) mad at being gamedev creativity-blocked on my main project. I haven't done much in a long time.

It's kinda scary, but I'm going to Get Very Serious about making the damn thing exist in any form. This is my extremely scuffed weekly standup.

There are up-to-date versions that run in the browser, though they're very much still a WIP. If you're still interested, lemme know! With enough interest, I'll set something up and post a link.

(you could also find it on github if you were really determined)