Comments

[a327ex]

Comments for the blog post. Questions, corrections, suggestions, or anything else, feel free to post it here!

[fnnbrr]

Thanks for sharing your thoughts, I've read through some of your codebases before so it's great to hear you verbalize your philosophies & decision-making processes. I'll think out loud in the comments as I read through.

First thought, I like your containers and use something similar. I've drawn inspiration from Unreal's Gameplay Tags because they have some useful features that Godot's groups and Unity's tags don't have - also, the fact that GameObjects in Unity can't have multiple tags really nerfs them in my eyes. Unreal tags are hierarchical (e.g. "StatusEffect.Poisoned" inherits from "StatusEffect"), and the tag test operations API highlights how tags can naturally be operated on like sets.

Another pattern I've found useful for containers is the idea of "reference counting" to easily coordinate between different code that modifies what containers an object is in. Here's an example without using this pattern: An enemy steps into a poison trap and also gets hit by a poisoned dagger. When the enemy exits the poison trap, it's incorrectly removed from the "poisoned" container even though the effects of the poisoned dagger haven't expired. With reference counting, each add/remove operation internally increments/decrements a counter, and the object is added to the container if count == 1 and removed from the container if count == 0. This pattern is also useful for things like pausing, where code would call methods like RequestPause() and ReleasePause() that would increment/decrement a counter to decide if the game is paused.

[fnnbrr]

I didn't see anything in this writeup on the state class from SNKRX, have you moved away from using it or was it just not necessary for emoji merge? I found the states easy to follow, and they're used in a similar way throughout 20 Minutes Till Dawn for managing title screen state, game state, and player state.

On the topic of UI, I'm curious to hear what you think of using markup languages like HTML for the job. The choice to use HTML/CSS for UI in s&box is interesting, I'm curious how it's worked out for them. Same deal with Valve's Panorama UI. The resources and support for this school of thought certainly are massive and relatively stable given the size of the web dev world.

[a327ex]

I didn't see anything in this writeup on the state class from SNKRX, have you moved away from using it or was it just not necessary for emoji merge? I found the states easy to follow, and they're used in a similar way throughout 20 Minutes Till Dawn for managing title screen state, game state, and player state.

Will be mentioned in more detail in the next post, but it's now the level mixin.

On the topic of UI, I'm curious to hear what you think of using markup languages like HTML for the job. The choice to use HTML/CSS for UI in s&box is interesting, I'm curious how it's worked out for them. Same deal with Valve's Panorama UI. The resources and support for this school of thought certainly are massive and relatively stable given the size of the web dev world.

I currently don't have any generic UI solution and do everything UI related manually. This will also be explained in more detail in the next post. As for the web, I don't think it properly solves the problem of UI generalization conceptually, so I'm not going to use it. I want to solve the UI generalization problem in a way that makes sense to me and in a way that feels correct and the web does not feel correct.

[Soulage23]

Thank you for all!

[SoulSloth]

Fantastic write-up. I'll probably be referencing this post and other resources you linked for months to come.

Per the 8-button gamepad idea, I started doing something along the "Propagating Menu pattern" on an abandoned project with a hover menu similar to what was in Black&White and Sacrifice: The idea was that colony sims(DF, Rimworld) and RTS games have an interface gap between the beginner path, which is clicking the buttons, to the expert path, using hotkeys/key-chords/key-seqs. With a propagating menu, a novice user could 'explore' options while the expert user treats it like a gesture menu, all using the same interface, creating a clear path from novice->expert.

Per the Uniform Tool Grid, I've actually used this pattern twice under two different scopes.

Emacs Leader Keys

The first is my emacs leader keys which defines a tree of commands which I invoke with Space. So, if I wanted to pull up the terminal window I'd press Space, then a, then t. This is, surprisingly, opposed to how most software does shortcuts, where you'll press "key chords" instead e.g. Ctrl+z undos. I've found this to be carpal tunnel inducing and inefficient in learning since most chords start with Ctrl, alt, cmd, which rarely have consistent meanings across Operating systems and vary from person to person. This is beyond the scope of "Propegating Menus", but It's hard for me to take a 'professional artist' seriously who unironically uses Ctrl-z in their program of choice nowadays. It takes two minutes to fix and not suffer the same wrist injuries as my Drafting relatives.

Ergodox Configurable Keyboard

Since I use Krita(drawing) and Blender(3Dmodeling/texturePainting) frequently, In order to not kill my wrists, I have a moonlander programmable ergo keyboard: You know about MMOs, so you could consider this analogous to having a universal macro system in hardware instead of tied to a particular software(I was actually inspired by FFXIV's macros system at the time). This is very useful because I have to do minimal configuration for any particular program between machines and can even have keys perform different actions depending on how long the press is, such as for blender where a short press on q registers as x, usually locking whatever operations being performed to the x axis and a long-press on q registers as Shift-x which locks the operation to the x plane instead. I had to tweak the particular timing for presses, but the ergodox has most options I can think of.

For Macros, in Krita, I have g mapped to delete to delete the current selection and then Ctrl+Shift+a to deselect. This is useful for lassoing/removing parts of a messy sketch, which I do frequently while sketching.

You'll notice that I only really have the Standard keyboard layer, the Blender layer, and Krita layer, so I don't really have the full-on "Propagating Menu pattern", but it sounds doable with the 32 configurable layers I have to work with🤔? IDK, I go through 'hot' and 'cold' spots when it comes to tweaking my setup so next time I feel warm maybe I'll try to achieve key sequence-nirvana

Hoped you found some of this content useful for your own thoughts!