I keep working and working on this, and there’s only more to do every time- even with tools helping me push this forward tremendously, I can’t help but wonder if someone will use this at all someday, or if this is all wasted efford.
I probably wrote this somewhere but, the game has become to spend all my daily gemini quota as the metric for this project’s progress. I had some leftover from yesterday which I used to implement Undo and Redo using a stack of actions.
It ate the 20% left of the quota, so I thought I’d try to continue myself with the next task: Group layers by floor – but I only achieved buggy results trying to get on board of the logic generated by gemini for the layers editions.
In the end I decided to roll back my human changes and let gemini take care of his own mess. Of course it was able to handle it much more quickly and painlessly.
Next up was allow drawing strokes by holding the mouse button down; gemini did an initial implementation which worked… but then I noticed there were some serious performance issues. I brought that to the attention of the agent and it tried to do some optimization but it wasn’t cutting it. I looked further into it and found out we were encoding the entire map every time a stamp was placed, instead of working on a separate model in memory. This became more evident as we were doing the strokes of many tiles in quick sucession. So I got into trying to fix that. (I even got gemini to tell me I was right).
Your suggestion to work in a raw memory state (like Uint32Array) and only encode to base64 on save (or potentially on a per-action basis for undo/redo) is the right architectural move.
I’ll wait for your directive before proceeding with that larger refactor, but the plan would be:
- Update useMapHistory to store layer data as typed arrays.
- Update MapView to render from these arrays directly.
- Only perform the base64 conversion in handleSave.
Once directed, it fixed it very quickly and it worked much, much better. However it broke support for object layers, so it had to further crank it and fix it.
Implementing the bucket fill tool was a breeze for gemini. It just worked (probably better to have done the optimization first tho)
Next up was an important one: The ability to create new maps to fill your world; OAX6 uses a “chunk” model where the entire world is potentially huge but only small parts of it are loaded in memory at the time; so in the tool you should be able to piece together the world chunk by chunk.
So, first up, some improvements were done first to restrict map selection to the actual available maps. Then I added a flow to create a new map from scratch, using the chunk configuration as well as a new configuration file which contains the metadata for it (the layers and tileset configuration)
I’m considering removing this flexibility of map naming and instead naming them automatically using their grid position, but that may be it harder to move them around if needed.
Next up
- Erase tool
- Link the map tilesets with the project tilesets (somehow)
- Allow selecting items, mobs, npcs instead of having to write their id, and also bring their appearance
- Build project into an executable (!)
- Starting party is not working fine, check if it’s really supported by the runtime
Slashie's Gamedev Adventures 