That looks more of like a brainstorming overview for basic mechanics than something comparable to a game design doc

you may have confused with mere brainstorm flowcharts but noun-verb diagrams are also for what could interact with what instead of going over multiple pages like you usually would in a GDD, and think about more how the player is using the game mechanics throughout the game (use of game systems through game mechanics), its a more visual approach than of GDD ideally you would start from elaborating all the game mechanics to properly elaborate the rest to be balanced to them

story/backstory, the art style

those could be written separatedly from the noun-verb diagram since yes its not a part of the process of going over "what interacts with what" and still get the benefit of having a noun-verb diagram specificity and more organized on the artistic side of the game

helpful screenshots of other stuff to compare to and keep people on the same page

correct me if im wrong but i dont think many people are relying on GDD for that? i could be wrong though, this seems it could be a separate part of playtesting and version management documentation

That looks more of like a brainstorming overview for basic mechanics than something comparable to a game design doc. The GDD gives concrete info on all aspects of the game. This also includes things like the story/backstory, the art style, helpful screenshots of other stuff to compare to and keep people on the same page, etc.

The only thing I got from that image is that it's a survival game where you fight monsters. How does that work though? What's the combat like? What's the general vibe of the game? Is it third person or first person? What's the scope? That's what a design doc is for.

Interesting concept.. briefly tried on my phone browser, and was having a heck of a hard time, but at least it made me feel like it's worth trying on my computer. The text has some oddities - is it translated from another language?

Wow it looks amazing! I think, what helps me the most to not blindly implement all feedback: Having my intentions and vision written down and always checking if this supports it or not. Sometimes their suggestions (eg quality of life improvements) could actually decrease the immersion. Which I always try to avoid.

1045 meters!

I want to clarify that by “currently” I mean the info logs will be removed from release builds. They actually shouldn’t be there outside of debug builds and are a bug. The game is intended to be played with the only feedback being data sent over the port from your own hive-- code

Currently the only feedback will be in the form of info logs printed to stdout and sending data back over the port via the x command

Just a quick guess, make sure before any hive-- code you have 0, eg 0q2>x. This specifies the worker to run the code on. Currently, only 1 worker with id 0 is spawned at startup; the plan is to make it so you can build more workers.

You're totally right my code was malformed. I looked closer at hivemm-design and realized you had syntax examples toward the bottom. I'm still not quite getting feedback from the game, but it does acknowledge transmissions and doesn't crash now.

Thank you.

Also I will have to mess with that panicking issue, but my suspicion would be that the hivemm code is malformed. In design-notes/hivemm-design there’s some examples

This is a documentation issue, AKA “I need to explain how shit works better” which is an ongoing process. Dbglua is for connecting to the debug socket for inspecting the game state directly, the code for this is in the debug.rs file. Clientlua is an example lua client that connects to the actual gameplay socket. My apologies, proper documentation is on the todo list. Glad you took interest in it tho!!!

Hi Saithe, I've cloned your repo and am trying interact with it but I'm not getting any sort of feedback from it.

Maybe I'm wildly misunderstanding how this works.

I've added args from hivemm-design.txt such as "m0" or "q1" or "x", both passing them directly on line 5 of dbglua and by passing them as args when calling dbglua. In all cases, dbglua returns 'ok' and no changes occur to the game state.

Attempting to pass any arguments by any method using the "--release" flag when running and using clientlua instead of dbglua results in the app panicking in lexer_system.

I'm not the greatest with rust or I'd try to debug myself. I can read it, I can't write it though.

If you'd like I can gather some logs and submit them on your issue tracker @ git.gay

This sounds super cool. Crossposted to !automationgames@lemmy.zip to get it in front of more people

Based on the pics the diarrhea does not look contained at all.

No, it is entirely self contained.

Do you need to play Diarrhea 1-3 beforehand to understand the plot of Diarrhea 4?

814 m

I'd add an Android version but I don't have any patience to add the necessary Android IDE and keys.

Edit: It's almost free on Godot to add touchscreen support. You just tell it to treat touch input as mouse clicks.

Nice, works on mobile.

@Drbreen@sh.itjust.works — thank you. Your comment is fair, and I think you are right: I led with motivation and abstractions before explaining what ALIS actually is and why it might be relevant to developers here.

ALIS is an early single-player UE5 survival project. Its public repository can also serve as an Unreal architecture reference: developers can inspect and adapt its modular plugin boundaries, JSON-to-DataAsset pipeline, implemented inventory, vitals and loading systems, plus its build, test and release tooling.

The public tree is intended for code, documentation, review and contribution—not as an asset-complete game checkout. Contributions to code, tests, documentation and public text data are welcome in the ALIS repository.

To help me correct the message: what concrete context did you expect first from a post like this in /c/gamedev—a concise explanation of the playable build, or a focused technical breakdown with code and trade-offs, such as the plugin boundaries, data pipeline or one implemented gameplay system? If neither, what would have made the post useful to you?

Also Hive-- is extremely simple. It’s meant to be a abstracted over, but is very straightforward to learn. Currently the language is documented in the form of design notes under design-notes/hivemm-design.txt. It isnt meant to be user facing but does hold all the information required to use hive--

The plan is to have very extensive documentation.

The game has no ui, it runs as a background process that you talk to over IPC. You send Hive-- code to a worker and any value that code exits with is returned to you over the socket. You can only see the data your workers can gather from the surrounding environment. The debug build currently prints the position of worker 0 to the terminal for development purposes.

I looooove the after! Much less bizarre. Well done!

My game currently uses the previous animation, but since I've improved a bit in pixel art, I decided to make some aesthetic improvements. I'm glad you like the previous design, though.

I prefer the before silhouette honestly. Even though the shading was very flat, something about the proportions just looks better to me in the left side.