One of ZOLE 4′s biggest downfalls for users was everything had to be inputted numerically – interactions, chests, warps – and I think that’s a big reason hacking the games never took off. Despite there being tutorials and lists, users were often left in the dark when it came to editing until testing.

So how do we fix this? The entire reason ZOLE 4 didn’t display NPCs for some interactions is because it would require hardcoding. Interaction is just a fancy, wrongly-defined word for variable-passable assembly pointers that I came up with when ZOLE 4 was in its super early stages way back in May of 2010:

Some might call them sprites, some events, and others NPCs. Interactions is a word I chose to sum up both.

The solution is to implement a macro system. They will consist of code acting as templates for things like warps and have support for creating images for specific interactions, making them renderable and easily editable on the map. This would avoid hardcoding how these sorts of things are handled in the editor, while making it easy for the editor to use (and expand upon!).

I’m not entirely sure how to handle the macro system. What comes to mind is making them a part of the API and defining specific macro types – ones that set stuff in the ROM and ones that make visual things appear. This might be really difficult to use though, so if things don’t work out well I might end up creating what would be macros inside of the suite.

So it all comes down to the API. What is it? Why do I need it? Most of ZOLE 4′s tools shared a very similar format – have a window, specify the map group and index, and display some numerical data to be edited. This could all be generated automatically and use macros or editor-specific code to handle how the editor works. Plus when I implemented networking into the suite, the API will take care of what the editor controls what packets get sent practically automatically – no more need to implement features twice.

The API would mostly consist of all the ROM-loading stuff. For example, it would contain classes to load and display maps, or load interactions, etc. I’m thinking I’ll create a template editor to create the numerical editor things, maybe, and have an abstract function that draws and handles editing on the map.

If things don’t go well, I’m going to scrap a majority of the API and just write the suite normally. ZOLE 5 tried this approach and made it so broad that it wouldn’t even work. I’d really hate for that to happen to ZOLE 6, AKA the Zelda Oracles Hacking Suite.