+ + In software development, creating a minimum viable product is a very popular strategy for getting to market quickly and getting customer feedback as soon as possible. + Once the software has made it to market, improvements are made iteratively based on feedback and the product roadmap. + This is the basis of the agile development strategy, which aims to ensure the product meets what the customer wants all throughout the development process, + instead of releasing the software once it's all been finalised and hoping that the customer likes it (called "waterfall"). + If you're interested in how this can apply to business practices, check out The Lean Startup by Eric Ries. + Admittedly, it's not the most interesting book to read -- I have read about half of it, + but got tired of it (which means it's one of two books I never finished, the other being Relativity by Albert Einstein -- so The Lean Startup is like Relativity?) + -- but it's great for learning about how lots of tech startups think. + If you want to start a company, or your own for-profit hobby project, it may be worth a read. + Regardless, agile is the currently the industry-leading way of doing development. + There's some useless trivia that you'll probably never need unless you want to sound smart to friends. +
++ + Agile software involves short coding "sprints" -- usually one or two weeks long -- where new features are added and existing ones are changed. + At the end of a sprint, the new changes are released to the customers. + To complete coding sprints on time, many things have to go right. + Beforehand, features and changes for a sprint have to small enough to complete in one sprint + (in exceptional cases, bigger features which can't be split up sometimes span multiple sprints). + During the sprint, changes have to be made to work with minimal unexpected complications. + Issues often come up when multiple developers change things which are inter-dependent (Svelto.ECS tries to mitigate this). + If a feature ends up taking too long, deadlines can be missed. And companies don't like missing deadlines + (although construction and governments seem to do it pretty often). + To reduce the risk of missing deadlines, it's helpful to create a prototype of a feature first. + This allows the developers to get acquainted with the intricate details that will need to be done, which is vital to estimating the amount of work required. + But the prototype has to be made quickly, otherwise the sprint can't be started and deadlines will still slip. + That's why rapid prototyping is a favourite buzzword of a lot of companies. + I think FreeJam also calls them mock features (there's lots of unused code which mentions "mock"). +
++ + Since this blog is about Gamecraft modding, I'll stop talking in generalities. + Rapid prototyping for mods is actually pretty easy. + For a new mod, HelloModdingWorld + has a mod skeleton ready for you, so that you can avoid most of the setup and boilerplate. + For an existing mod, it's easy to throw together a new feature in a new git branch or using a copy of the code without risk to the mod. + I hate to shill the GamecraftModdingAPI, but it can really make prototype features easy to implement. + Once you've got a feel for how the feature should be done properly, you can reuse code from the prototype to make it happen. + Seeing a new feature working is the most rewarding part of coding, at least for me, even if it's only a prototype. + Seeing a feature working after only 30 minutes of work is icing on the cake. +
++ + Recently, I put my rapid prototyping experience to a test by writing a mod to expose additional graphical settings, + called Kompresor. + While I didn't get it working in 30 minutes, I made video recordings of every minute I spent working on it and the footage didn't come close to a full day of work. + A lot of that time was spent manually associating the file's data to specific graphical settings, which was tedious and unavoidable no matter how I did it. + With that in mind, and if you don't count the long time I spent editing the footage, the first sprint for Kompressor took about 6 hours. + That's pretty rapid for implementing a mod that modifies most readily available graphics settings. +
++ + The next Kompressor sprint, whenever I find some time to record me typing and talking to my self, should be just as quick. + I'm planning on focusing on adding game save compression for that coding sprint. + The file compression involved will require some runtime game patching using Harmony, which is something that I don't mention that often. + Harmony is an easy way to hijack C# function calls and run your own code before, after or instead of the original. + All of that is setup while the game is booting, and removed when the game shuts down, so it's a very safe and powerful way to mod Gamecraft. + Harmony also offers quite a few helpful ways to designate what to patch, which can make patching as quick as writing a couple lines of code. + When rapidly prototyping, this makes running code as a consequence of vanilla Gamecraft code easy and convenient. +
++ + But how do you find the function you want to patch? + Well, I've saved the best (worst) for last. + Finding the function takes a lot of reading code. + The best tools for reading code are C# decompilers like dnSpy and ilSpy. + Unfortunately, I can't offer much advice for speeding that up except that it takes common sense + (CommandLine.dll does not contain block-related code) and experience (ECS does not stand of Extremely Cool Sliderule). + Searching the Gamecraft codebase for what you're looking for is undeniably the biggest slowdown that you can encounter while rapidly prototyping. + Depending on what you're trying to mod, you may be able to avoid it, but if you can't it's not the end of the world: + Reading Gamecraft code can be quite educational, especially for someone who doesn't know a lot about C# (like me). + Function-finding can be slow, but think of it as an investment for speeding up future endeavours. +
++ + See? Modding doesn't have to involve days of yelling at your code about a missing semicolon (only hours instead). + Writing a minimum viable mod is a great way to explore what you can do with mods. + Write some code, give it a test run, and repeat to see where you can go. + Investing a few hours could get you pretty far. + You could even make your investment back by completing a mod bounty -- the cash for importing 3D objects into the game sounds pretty sweet. + If you're really enthusiastic about rapid prototyping, hit me up since I've been thinking about hosting a modding hackathon (modathon?), but I'd like to have more than 2 people show up. + So go try some sprinting! +
+