voxel @voxel@merveilles.town

I've entered a #gamejam this weekend and decided (perhaps unwisely) to try and make a #nes game in 48 hours. I'm using C in a free web IDE designed for this purpose https://8bitworkshop.com/v3.7.1/ learning to work with neslib is slow going, but realistically I'm probably miles ahead of where I'd be if I were learning 6502 assembly for this

Development from your phone, is it possible? I'm usually not more than a few steps away from a desktop computer so I've never really put much effort into researching the viability. But it's storm season here and I'd like to do something on my (i)phone other than browse cat photos on mastodon

how do I write a multi-toot thread without spamming the local timeline, anyone?

also I need a way to author collision geometry intelligently - I don't want to use the complex 'visual' geo for collision detection because it will be too slow, so every map area needs an additional invisible 'collision' geometry layer, a hidden world or dimension that can not be seen by the player but can be 'felt' as it determines where the characters can move

the maths is fairly hard (definitely the most mathematically complex part of the project), especially to do efficiently. But the bigger issue is the choices I make here have far reaching design decisions. For instance, if I limit the game to a (conceptually) flat plane, even though it's visually 3D I could treat it as 2D for purposes of collision detection and eliminate an entire dimension of problems

I have to implement collision detection and response for my 3D game engine, while keeping it as lightweight as possible (it runs on Dreamcast, have to conserve cpu cycles) and I'm really dreading it #gamedev

Not to suggest you should ever need an excuse to play, but one great side effect of having a 5 year old kid is that he's always keen to play Lego, which means *I* get to play Lego too.

Annoyed Possum just got thrown out this tree by a bigger Possum and is now pouting, didnt even care that I was there

Previous dreamcast prototype saw me defining all map geometry 'by hand' per vertex and hardcoding it into the engine. This was fine for a boring square room but not really practical for a game with more than a couple of locations. Plus it's hell to edit after the fact

However, I am making some good progress with the renderer. The idea is to model arbitrary modular rooms in blender and munge them into a format I can display efficiently on the Dreamcast. The rooms snap together at predefined portal points, and select appropriate mesh geometry depending on whether they're connected to another room or not. Although I have no plans to let players build levels, the map editor will run in-engine rather than being a standalone tool. #theLudarium #gamedev

Distractions are piling up; there's some kind of invisible grit on my mousemat, like running over gravel. Wiped the mouse and mat but it still feels like OFFROAD MOUSING

I'm putting on a 4 hour amiga cracktro soundtrack and I'm not getting up until I've finished writing this map renderer*

*fluid in/out pitstops excepted

https://www.tree.fm/ lets you listen to recording from random forests around the world. It's very nicely presented, Some of the recordings have faint traffic noise in the background, which ruins the effect a little, but is probably just the unavoidable reality for many of these places

on the other hand, i feel like i know 90% of whats in this book, but that remaining 10% is gaps from omissions and assumptions in the tutorials ive followed in the past. I'm hoping to reduce that by getting through this textbook, but i wish there were just an appendix titled 'just the parts voxel doesnt know or is wrong about' 😇

All my game development knowledge is from experimentation and gleaned piecemeal from a thousand online guides, forum posts and incomplete tutorials. Reading this opengl textbook is overwhelming just for the pure information density.