So this started on this thread by weeble but I ended up rather... running away with the code idea and overhauling it drastically.
While I've resumed working w/ Weeble on this in his original thread, I'm keeping this thread updated as well as I make changes.
V2.0 details
With V3.0 I've completely removed the concept of 'biomes' from the codebase; the walls, floors, borders, and their respective palette choice can be assigned fully independently per-room now. I've not yet modified the map to show off this feature, though as a side-effect screen-transitions are even faster now as the engine only generates those tiles which are absolutely required.
Also new is a full fledged built-in editor allowing you to modify the maze design with a realtime view of the room in question when customizing the palette/textures for each component. Note that editing the actual palettes used by the tiles is done by editing the lower-left corner (sprite tiles 240 and 241) with the upper row being palettes 0-15 and the lower row being palettes 16-31.
To access the editor go into the in-cartridge menu (P by default) and select the appropriate menu item; likewise to exit the editor choose to either discard or save changes in the menu.
I'm still working to improve the rendering system, but felt releasing this version with a fully functional editor built-in is a valid point where games could easily be made with this engine.
Impressive stuff! I feel pretty guilty for leaving you to puzzle out the code on its own. I'd vaguely intended to write a blog post explaining various little bits and pieces, like the "jigsaw-piece" technique that ensures that no room needs to have more than three biomes while still making sure that there's always a transition between adjacent biomes. (Basically, every room is like a jigsaw piece with a notch on two opposite sides and a peg on each remaining side. Each jigsaw piece is filled with its own biome, and since no piece ever has more than two notches, only two of the adjacent biomes can protrude into it.) Looks like you did impressively well on your own!
With all the space and CPU you've freed up and the fact you can edit the maze by hand I imagine you could make some pretty cool spaces by combining prefab rooms/room-pieces and more furniture/decoration. I really wanted to have a leaf-canopy/crystal overhangs/mesh-ceiling in some areas but didn't think it was possible, but it probably is now. My goal was always to try to make a simultaneously large but interesting space. I think you've opened up all sort of possibilities here.
BTW I know you've replaced most of the code now, but nevertheless let me know if you would like me to release my code under an MIT license. I like the CC BY-NC-SA 4.0 for experimenting and collaboration, but since you're actually making an engine for people to use I wouldn't have a problem with people selling their games on itch.io and stuff like that.
And just to answer your very valid questions here, I think once we have a solid engine and are done collaborating here on the forum, yes, I would very much like to relicense the resulting meta-cartridge under an MIT license, as while I'm good at engine design I know I'm middling at best at designing a full game world, especially when an engine such as this allows for something Zelda-sized so easily which is a LOT to design. :)
Could you distill the tech to the purest example, as in how you store map data in the game?
Yeah, last paragraph has it right.
//edit: Frankly I've thought you did something more clever like storing map data as strings so you can use the entirety of spritesheet, including shared areas and use top map data for static screens such as menus, etc.
Well you could easily convert the map data to a string stored in the game, the issue then is 'does it compress well?' though. I've found it's too easy to run out of string space; sometimes it's better to keep some data in the sprite/map regions instead.
The underlying game engine uses the normal 'map' based rendering for the playfield, including flags on the correct sprites to simplify collision handling.
The 'unique feature' list is actually:
- Generate lots of distinct mixtures of tiles including unique blends between the mixtures so things don't look as rigidly tied to the grid
- The shadowing effect to add further visual depth to the playfield.
- Map and tile-components are stored in a way that's very amenable to utilizing multiple carts to allow larger/multiple game worlds or more tiles/graphics.
It would be pretty trivial to move the 'maze' data up into pure-map space honestly, and yes you could actually render things from Lua memory instead of using map() calls as it does now if you wanted to keep 100% of the sprite graphics available for some reason.
This isn't meant to be 'showing off' like ElectricGryphon's various tech-demos do, this is meant to be a functional, usable (albeit basic) game engine for building games similar to Zelda 1, handling the hardest part (IMHO) of dealing with the large overworld map. With more room types (there's room for up to 64 unique right now, I'm only using 4) you could easily hard-code specific obstacle layouts inside that way.
[Please log in to post a comment]
