ExMods
/
html-site


			
				
					
						
						
							
							<!DOCTYPE html>

<html lang="en">
  <head>
    <meta name="theme-color" content="#20c420" />
    <meta name="author" content="NGnius" />
    <meta name="keywords" content="exmods,gamecraft,modding,mod" />
    <meta name="og:type" content="website" />
    <meta name="og:title" content="Exmods Blog" />
    <meta name="og:description" content="Quick mod development" />
    <meta name="description" content="Quick mod development" />
    <meta name="og:image" content="../static/favicon.png" />
    <meta name="og:url" content="https://www.exmods.org" />
    <meta charset="UTF-8" />
    <link rel="icon" href="../static/favicon.png" type="image/x-icon"/>
    <link rel="shortcut icon" href="../static/favicon.png" type="image/x-icon"/>
    <link rel="stylesheet" href="../static/style.css" type="text/css" />
    <title>Exmods | Rapid Prototyping</title>
  </head>
  <body>
    <h3><a href="index.html" title="You know your browser has a back button, right?">Back to list</a></h3>
    <h1>Rapid Prototyping</h1>
    
    <div class="text-content">
        <p>
            <span class="tab"></span>
            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 <a href="http://theleanstartup.com/">The Lean Startup by Eric Ries</a>.
            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.
        </p>
        <p>
            <span class="tab"></span>
            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").
        </p>
        <p>
            <span class="tab"></span>
            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, <a href="https://git.exmods.org/modtainers/HelloModdingWorld">HelloModdingWorld</a>
            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 <a href="https://git.exmods.org/modtainers/GamecraftModdingAPI">GamecraftModdingAPI</a>, 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.
        </p>
        <p>
            <span class="tab"></span>
            Recently, I put my rapid prototyping experience to a test by writing a mod to expose additional graphical settings,
            called <a href="https://git.exmods.org/NGnius/Kompressor">Kompresor</a>.
            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.
        </p>
        <p>
            <span class="tab"></span>
            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 <a href="https://harmony.pardeike.net/">Harmony</a>, 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.
        </p>
        <p>
            <span class="tab"></span>
            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 <a href="">dnSpy</a> and <a href="">ilSpy</a>.
            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.
        </p>
        <p>
            <span class=""></span>
            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!
        </p>
    </div>
    <footer>
        exmods.org|<a href="https://git.exmods.org/ExMods/html-site">Site Repository</a>|<a href="https://exmods.org">Home</a>|<a href="https://discord.gg/2CtWzZT">Discord</a>|<a href="https://twitter.com/GamecraftMods">Twitter</a>
    </footer>
  </body>
</html>