mauvecow.bsky.social
// Game designer / Pixel artist / Linux //
// Currently: Addlemoth //
// Previously: Them's Fightin' Herds, Defender's Quest 2 //
// Personal: https://icosahedron.website/@mauve //
// 日本語でも話せる〜 //
118 posts
279 followers
83 following
Regular Contributor
Active Commenter
comment in response to
post
that's also post-2013-burnout mauve that had long since realized the art of making good code is Keep It Fucking Simple, Stupid
so yeah actually that's all fine lol
comment in response to
post
anyway that's all I got for you today, stay safe out there and take care of yourselves.
comment in response to
post
Also streaming in the cards once more. I've been noodling away at a new stream layout but haven't gotten too far with it. Some day.
Linux streaming is still Not Quite There Yet but it's definitely getting there.
comment in response to
post
Other things:
- Now that things are settling I'm trying to get caught up with everyone. SINCEREST APOLOGIES to everyone I had to kinda push off because I was overwhelmed and doing too much.
- I wanna get back to drawing more, need to be in the right headspace though.
- Wanna talk design again.
comment in response to
post
if perhaps someone is interested in helping me get addlemoth over the finish line (and maybe funding some less awful character art) i would appreciate
there is a free demo you can play in your browser hint hint
bsky.app/profile/mauv...
comment in response to
post
Addlemoth:
- So there's a roadmap to completion here! A big spreadsheet filled with every asset that needs doing.
- I'm currently finishing up the last of the mechanical design stuff before moving onto art and stages forever.
- I apologize for being held up for so long on this. Life's hard.
comment in response to
post
there's a part of my brain going, very loudly: i'm never inheriting a legacy codebase ever again
comment in response to
post
Let's start with dq2:
- So many tech issues. It's legitimately more than I expected.
- We made a couple oversights in balance, we'll fix 'em next big patch.
- I want to talk about the tooling I made and the rationale for a lot of things, not sure if stream or just bsky thread or something.
comment in response to
post
this beta has a massive number of problems, not just ui/ux, or the matchmaking, but the netcode is notably glitchy. I'd get continual spiking with some people who i know were not on wifi.
i was having some fun with it but honestly i kinda bounced off.
comment in response to
post
it's like 0% surprising at this point at least
comment in response to
post
it's a turn-based puzzle game! in the vein of DROD. there's a link to a demo on my pinned post here~
comment in response to
post
those of us who have worked in procedural generation knows that behind every curtain of randomness are a bunch of people curating it into something that doesn't suck to experience
comment in response to
post
that being said, there's something to be said for not overcomplicating things, because at some point "we've made a really cool random map with twists and turns" just becomes "i turned left this run, as opposed to right on the last run" to the player.
comment in response to
post
oh yeah those are going around right now, i got a "hi long time no see old friend!" type text from a mystery number the other day.
comment in response to
post
it is very much the game you buy once and play for the next six months
i think i was clocking close to 80 hours at that point and i just didn't caaaaaaaaare
comment in response to
post
which leads to the question: how do i make code less important to developing games?
and the answer i've come back to is to work on making it really really hard to footgun yourself trying to do things.
comment in response to
post
anyway these are just Random Programming Thoughts from someone who would very much like to never deal with troubleshooting dumb crashes again.
comment in response to
post
A better way of writing that would be along the lines of "B reads that it is being attacked from the collision handler, queries A for information, and then sets flags for a transition handler to handle on the next pass."
Every step is clearly defined and can only modify specific parts of state.
comment in response to
post
Chain reactions have subtle order of operations issues, could potentially cause recursion and further chain reactions to other objects, and so on. Don't allow it.
Behavioral definitions need to be first class and have limited scope of things that can change. Only modify within limited depth.
comment in response to
post
Handling bad program flow is a lot more subtle and a lot more insidious to deal with. Usually it's from doing things conveniently and then the problems spiral out of control.
A gamesdev example would be "A hits B, so A calls B to damage it, causing state changes in B." Chain reactions of behavior.
comment in response to
post
I also mostly return dummy objects in cases where I don't _especially_ case about failure, as long as it handles it gracefully.
Addlemoth does that a lot, if I actually need to verify that a query failed I can just do something like: if (obj == MapObject.Empty)
It's pretty crashproof!
comment in response to
post
In my own code, where possible, I've reframes it so that only functions that start with the word Query can null. eg QueryFoo(bar) can null, and GetFoo(bar) cannot.
It also returns a ForceNullCheck<T> which requires an .isNotNull() type function to be called before it allows usage.
comment in response to
post
Nulls are the devil. I increasingly see eradicating them where possible as a goal, or having code enforce null checks where I can.
The crashes tend to show up most frequently on queries: GetFoo(bar) unexpectedly nulls, software doesn't handle it, loud explosions follow.
comment in response to
post
Exception throwing is just crashing with extra steps.
It makes sense in I/O code which needs to potentially bail at one of a hundred possible positions, and, well, basically nowhere else.
Don't use it if you don't have a very good use.
comment in response to
post
In my experience as programmer the main three sources of software crashes are:
- Forgot a null check on code that can return a null.
- Function has poorly defined flow and recursed until the stack crashed
- Didn't check for exceptions from code that throws exceptions, which is a crime in itself