#gubdev

[gubbles-owo]

in researching various marine species to potentially base enemies off of, i discovered the humble chiton

i fucking love this model i made. 28 tris. texture size? 8 by 8 pixels. genuinely the tiniest texture i've ever made by hand. originally i was gonna rig this thing with a skeletal structure for animation, but i figured, why bother with all that when i can just squish the whole damn model?

look at them go!! took me forever to bite the bullet on it, but finally implemented boids flocking into enemy pathing, so they don't all clump up and chase u like its vampire survivors or smth. i had shorbs stacking atop one another and leaping over every wall and into the abyss, but with this in place i've finally got all that under control. was real worried about implementing it but it only took me a couple days

[gubbles-owo]

the wonders of convergent evolution! i accidentally reinvented wasps.

y'all i promise im working on other aspects of the game... it's not my fault something stupid happens every time i touch the shorbs, its simply in their nature oka y

[gubbles-owo]

extremely work-in-progress dialogue system with extremely release-ready dialogue

[gubbles-owo]

recently i picked up that scurge hive clone project again after over a year of abandoning it in the hopes that maybe i can actually get more done with it this time and let me present you with my greatest creation ever:

SHORB

i love this stupid idiot. so goddamn muc h

[gubbles-owo]

I MADE THE SHORBS FASTER AS A JOKE AND THEY'RE FUCKING TERRIFYING

this base speed is ridiculous for basic shorbs but i do wanna make this a variant. lurks in the shadows, and the moment it spots you it SCREAMS and GUNS IT directly for iso-chan's face. prolly defeated in one hit to counterbalance its power lmfao. the benefit of taking a component/modular approach means i can whip up that sort of thing very quickly! also cleaned up the rooms transitions here, they still feel kinda jarring so i'll have to work that out somehow... but i'd say it's a good start :3

[gubbles-owo]

and with that dump completed that's enough existing publicly for like. a month. or two. time to go back into hiding wheeeeeeee horrendous mental health and uncertain future aside: thanks y'all for the love of this exoskeleton of a game. with any luck i'll actually be able to finish the damn thing for once. solo dev is just, very excruciatingly slow and often so painfully difficult lol

[gubbles-owo]

among the many mechanics im shamelessly stealing from scurge: hive is the whole elemental damage system. take out an enemy with the element it's weak to, and it explodes into an elemental effect that chains to anything else weak to it, killing it immediately (but watch out, it can make other enemies faster and stronger)

chiton are simply Wet (water), so hitting them with Zap (electricity) makes them do... well, this. the system has been kind of hell to get working right and to further tweak the aoe, but goddamn does it make it satisfying to blast things. also shoutout to fresnel its goated for vfx shaders

[gubbles-owo]

oh christ almighty they're multiplying

AMASSING AN ARMY

a bit of game dev rambling below the cut:

given that the only "games" i've ever released solo were a short kinetic novel and a barebones breakout clone, this is the first time i'm programming enemy behavior! so i have zero clue what i'm doing here! :D i've got to find some way to prevent them clumping up, as i'm not really looking to make a vampire survivors sort of thing. while scurge is helpful as a base, unfortunately i'm too dumb/lazy to be bothered learning ARM assembly to break down how they handle enemy behavior internally. i've got some vague ideas for implementation but i can't say i'm super confident about getting them working in a way that's fun... well here goes nothing i guess :P

[gubbles-owo]

you know you're programming correctly when you're using the methods that the docs warn u to probably not use

[gubbles-owo]

sry to send u gore of ur comfort character but—

yeeeaaaahhh so they explode now

[gubbles-owo]

after avoiding the project for nearly a month because i couldn't figure out room loading/unloading, i figured out room loading

Be it undiagnosed adhd or who the hell knows what, when it comes to programming my brain wants to know exactly what I'm making before I sit down to make it. This, foolishly, means trying to work out every single fuckign little detail of how the whole system works— before I'm even aware of everything it needs to do— and oftentimes that alone is enough to completely halt any progress! Slowly learning that I occasionally have to step back from my default way of working and go "hey stupid don't wrack your brain over Everything at once; just get the bare minimum implementation to get SOMETHING up and running. we'll figure out the details in time." So that's why it looks jank and unpolished at the moment— but also why there is progress here at all xD

[gubbles-owo]

well, she's certainly trying her best.....

[gubbles-owo]

When whipping up Railgun in two weeks' time for a game jam, I aimed to make the entire experience look and feel as N64-esque as I could muster in that short span. But the whole game was constructed in Godot, a modern engine, and targeted for PC. I just tried to look the part. Here is the same bedroom scene running on an actual Nintendo 64:

I cannot overstate just how fucking amazing this is.

Obviously this is not using Godot anymore, but an open source SDK for the N64 called Libdragon. The 3D support is still very much in active development, and it implements-- get this-- OpenGL 1.1 under the hood. What the heck is this sorcery...

UH OH, YOU'VE BEEN TRAPPED IN THE GEEK ZONE! NO ESCAPE NO ESCAPE NO ESCAPE EHUEHUHEUHEUHEUHUEH While there is a gltf importer for models, I didn't want to put my faith in a kinda buggy importer with an already (in my experience) kinda buggy model format. I wanted more control over how my mesh data is stored in memory, and how it gets drawn. So instead I opted for a more direct solution: converting every vertex of every triangle of every object in the scene by fucking hand.

THERE ARE NEARLY NINE HUNDRED LINES OF THIS SHIT. THIS TOOK ME MONTHS. And these are just the vertices. I had to figure out triangle drawing PER VERTEX. You have to construct each triangle counterclockwise in order for the front of the face to be, well, the front. In addition, starting the next tri with the last vertex of the previous tri is the most efficient, so I plotted out so many diagrams to determine how to most efficiently draw each mesh. And god the TEXTURES. When I painted the textures for this scene originally, I went no larger than 64 x 64 pixels for each. The N64 has an infamously minuscule texture cache of 4kb, and while there were some different formats to try and make the most of it, I previously understood this resolution to be the maximum. Guess what? I was wrong! You can go higher. Tall textures, such as the closet and hallway doors, were stored as 32 x 64 in Godot. On the actual N64, however, I chose the CI4 texture format, aka 4-bit color index. I can choose a palette of 16 colors, and in doing so bump it up to 48 x 84.

On the left, the original texture in Godot at 32 x 64px. On the right, an updated texture on the N64 at 48 x 84px. Latter screenshot taken in the Ares emulator.

The window, previously the same smaller size, is now a full 64 x 64 CI4 texture mirrored once vertically. Why I didn't think of this previously in Godot I do not know lol

Similarly, the sides of the monitors in the room? A single 32 x 8 CI4 texture. The N64 does a neat thing where you can specify the number of times a texture repeats or mirrors on each axis, and clip it afterwards. So I draw a single vent in the texture, mirror it twice horizontally and 4 times vertically, adjusting the texture coordinates so the vents sit toward the back of the monitor.

The bookshelf actually had to be split up into two textures for the top and bottom halves. Due to the colorful array of books on display, a 16 color palette wasn't enough to show it all cleanly. So instead these are two CI8 textures, an 8-bit color index so 256 colors per half!! At a slightly bumped up resolution of 42 x 42. You can now kind of sort of tell what the mysterious object on the 2nd shelf is. It's. It is a sea urchin y'all it is in the room of a character that literally goes by Urchin do ddo you get it n-

also hey do u notice anything coo,l about the color of the books on each shelf perhaps they also hjint at things about Urchin as a character teehee :3c I redid the ceiling texture anyways cause the old one was kind of garbage, (simple noise that somehow made the edges obvious when tiled). Not only is it still 64px, but it's now an I4 texture, aka 4-bit intensity. There's no color information here, it's simply a grayscale image that gets blended over the vertex color. So it's half the size in memory now! Similarly the ceiling fan shadow now has a texture on it (it was previously just a black polygon). The format is IA4, or 4-bit intensity alpha. 3 bits of intensity (b/w), 1 bit of alpha (transparency). It's super subtle but it now has some pleasing vertex colors that compliment the lighting in the room!

Left, Godot. Right, N64. All of the texture resolutions either stayed the same, or got BIGGER thanks to the different texture formats the N64 provides. Simply put:

THE SCENE LOOKS BETTER ON THE ACTUAL N64.

ALSO IT RUNS AT 60FPS. MOSTLY*. *It depends on the camera angle, as tried to order draw calls of everything in the scene to render as efficiently as I could for most common viewing angles. Even then there are STILL improvements I know I can make, particularly with disabling the Z-buffer for some parts of the room. And I still want to add more to the scene: ambient sounds, and if I can manage it, the particles of dust that swirl around the room. Optimization is wild, y'all. But more strikingly... fulfilling a childhood dream of making something that actually renders and works on the first video game console I ever played? Holy shit. Seeing this thing I made on this nearly thirty-year-old console, on this fuzzy CRT, is such a fucking trip. I will never tire of it.

[gubbles-owo]

someone plz tell me to get off my ass and finish texturing low poly manticore already

i keep getting distragcted with N64 libdragon dev instead gomen

[gubbles-owo]

spent seven (7) hours in programming hell, trying to figure out why including header files into dynamically loaded mazes (levels) broke the entire damn rom turns out, i was using C wrong! apparently you're not supposed to include function definitions in .h files! only declarations go there, while the definitions get laid out in a .c file. i was somewhat aware of this already, but i swear to god i remember back in college that there were exceptions/cases where you could just throw everything in the header, but fuck if I can remember any of them. anyway, i fixed* it. (*i still have to feed the tilting logic to the board somehow and all of this broke the marble entirely but i digress). after seven hours there is finally visible geometry again

explodes

[gubbles-owo]

N64 marble maze progress!!

Mazes are now loaded dynamically at runtime, as to swap between levels on the fly. And all it took was a total restructuring of all of my code!! :3c But the most obvious difference here is the larger board structure and fancy lighting. There are now two interlocking frames; the outer only rotates front to back, and the inner one left to right. It's actually how real marble labyrinth games are built!! I'm extraordinarily thankful for the pitifully small handful of reference videos I dug up that cleanly demonstrated this mechanism in action lol. And while I'll probably plan to have a level that uses this kind of fancy lighting, I'm leaning toward carefully handpainting in static vertex colors for most levels. Things are a little dim here >w>` The performance of this on actual console is... not great. At least not if I'm targeting 60fps. On average I get around 49-55fps. I do have depth (z-buffer) enabled when drawing all the interlocking frames, and while I generally try to draw them front to back to minimize overdraw, I think all those depth compares are still eating up frametime... I'll have to sit down and do some real brain crunching on how to optimize all this. Restructure the board and disable the z-buffer to minimize depth checking, axing the realtime lights would prolly help, and zooming the camera out (or shrinking the base frame thickness) would also improve things. Libdragon's ucode isn't v optimized yet, and while the devs are wanting to improve it at some point, that's ultimately out of my hands!