I'm sure you've heard of Pixi. If you haven't, let me refresh your memory: Pixi is a mod for Gamecraft which adds commands to import images and Robocraft bots into games. These tools simplify text block animations and pixel art, among other things (like making giant 2D mechanical structures). Under the hood, Pixi is like any other mod except for one important design decision. And that design decision was the best idea I've had in a while.
Before I get to that, though, I want to provide a more in-depth look at the process behind developing a new mod for Gamecraft. This is also the same bootstrapping process that I used for Pixi, because I wanted to test it out but also because it's the easiest way to do it. A while ago, I created a barebones Gamecraft mod called HelloModdingWorld to use in the mod dev guide. HelloModdingWorld is a completely self-contained mod, with all the mod development project setup and configuration already done. The setup and config are updated after every Gamecraft update to keep it working smoothly. That makes it the ideal starting point for developing a new mod, unless you really want to start from scratch. The rest of the process is just changing the HelloModdingWorld-specific configuration to your own mod. That shouldn't take more than a few minutes, since it's just creating a new Gitea repo (from the HelloModdingWorld template), cloning it to your local storage, and then a couple of find and replace operations to change the project to the new mod's name. So, to start a new Gamecraft mod, all I have to do is login to git.exmods.org, create a new repo using the HelloModdingWorld template's git content and then replace all mentions of "HelloModdingWorld" in the code.
A short public service announcement about Git and Gitea before I continue: If you're a new programmer (or not one at all), you may not recognise those terms (or terms like cloning and check out in that context), but that's OK. Git is code versioning software which helps track changes and simplify simultaneous development efforts from multiple people. It's very powerful (it was originally created for developing Linux, and now it's used by almost every modern software project). The public service announcement is this: learn Git if you want to program. It makes it easy to store and retrieve your code from anywhere (through GitHub/GitLab/Gitea) and has lots of goodies that you'll never want to live without (reverting to an old version of your program is surprisingly useful). Most IDEs provide a nice user interface for you, so it only takes a few minutes to wrap your head around. I haven't worked on software without Git in years.
This reduced barrier ultimately led me to create Pixi in the first place, to prove image importing was possible. Though, most of the credit for the idea behind Pixi goes to a short conversation with [REDACTED]. Once the idea for Pixi, along with the mod setup, was in place, all that was left to do was the building the mod. In most cases, that starts with a lot of time figuring out how to do what I want the mod to do by reading decompiled Gamecraft code. After I've found the code that I want to modify, I write code to modify the Gamecraft code. The code I'd write for the mod and the code that I'd look for in Gamecraft are always specific to what I want to do. But for Pixi, I wrote code for the GamecraftModdingAPI to modify the behaviour of Gamecraft, and then wrote a bit of code for Pixi which controlled everything. Specifically for Pixi, I wrote code to control image to block conversion operations. Block placement was already supported by the API, thanks to earlier work by NorbiPeti, so I could skip most of the reading.
The brilliant decision I made after that initial experience was to never directly modify Gamecraft from Pixi. At face value, it may seem counter-productive for a Gamecraft mod to not mod Gamecraft, but it actually leads to a more stable mod. I'll describe the common difficulties for mods to illustrate. Mods are usually broken by Gamecraft updates. This is caused by the lack of a guarantee that anything from the last update is the same as in this update. In most cases, very little changes but even a single change can completely break a mod. To solve this, Pixi relies on the consistent interface that GamecraftModdingAPI provides between all Gamecraft versions. Mods often re-implement common features, which may interfere with each other. When every mod has to start from scratch, redundancy is expected and can sometimes cause issues when one mod doesn't do the same thing in exactly the same way. Pixi solves this for itself and other mods by using the GamecraftModdingAPI's common implementation. By implementing Gamecraft-modifying parts in the API, I can write code that can benefit all modders instead of just myself. I can also rely on other to update keep that code working with Gamecraft updates. Maybe I should have made this post about GamecraftModdingAPI, since I'm talking about it an awful lot. As if to prove my point, Gamecraft's 2020.06.11.18.50 update didn't require me to update Pixi since the changes were addressed in an update to GamecraftModdingAPI. Never directly modifying Gamecraft has saved me from directly modifying Pixi when updates occur.
The flip-side of that decision can be seen in ExtraCommands, which started way before GamecraftModdingAPI became what it is now. To this day, I still completely hate updating that mod. Recent updates have forced me to move over to using GamecraftModdingAPI to fix broken things permanently, but a lot of ExtraCommands could still break with any update. And at least one thing breaks every Gamecraft update, which forces me to spend time fixing the issue and then more time to make a new ExtraCommands release (a whole two minutes of hell). Perhaps knowing that I could avoid it is what annoys me the most.
Recently, I've been working on applying the same design decision to the Gamecraft Discord Presence mod (no public release version yet). Although progress has been slow, that's partly due to my lack of motivation at the moment and my crazy side quest to create a Gamecraft mod test system (which was a lot of fun work, but hasn't beared any fruit yet). The work to implement all relevant Gamecraft interactions in the API has led to some interesting new functionality, like Game and Application information and operations. All of that work benefits everyone, which is the big win. Mod development, and software development in general, is fundamentally about making something for others as well -- not just yourself. Once the API is up to snuff, I expect the actual work to upgrade the Discord Presence mod will be short and sweet. As a side-effect, I expect it to simplify the code, if my experience from doing similar work with ExtraCommands means anything.
Pixi has proven to be a learning experience for me, on top of the whole Exmods project (which was started as a learning experience). Developing Pixi has taught me what mods people want (game-maker tools, among other things) and what people are interested in (showy automation piques interests) while teaching me how to write better mods. Currently, I think that the mod development process is about as optimised as it can get, with the hardest part of the process being using git and opening the find and replace window of your preferred editor. Using GamecraftModdingAPI also makes the process easy, and it's only getting easier, to create a stable mod which can survive through most Gamecraft updates. With work I've put into Pixi so far, there's no doubt in my mind that having a standard API for Gamecraft mods is the way forwards. I wonder if we'll ever see an official modding API from the Gamecraft developers. Maybe it'll come with official mod support, but I'm sure that's a long way away. For now, I'm going to continue learning from Pixi and any other mods I end up working on.