Why Test?

Of all the fun, interesting, exciting game development topics I could write about, I chose: testing.

Why?

Because testing is essential to shipping your game without bugs and without hours upon hours of manual effort. As we'll see shortly, there are well-known patterns and practices you can apply; some generic to softwre testing, and some specific to game testing.

I discovered these practices after working more then a decade as a professional software developer, and applying them on and off for a decade as a hobbyist game developer. They take time, yes. They work, often and they're better (faster, more reliable, consistent) than manual testing.

Overall Strategy

Your goal with software testing is to release your game at the highest possible quality: that means NO BUGS! Everything should work the way the designers intended, without us spending tons of manual hours play-testing the same parts over and over and over (yawn).

Your overall strategy needs to include the following categories:

• Unit Testing: So you know your methods/classes/scripts/objects work at a granular level.
• System Testing: Make sure cross-object workflows succeed, like "user last-shots an enemy and gets bonus gold." Sometimes called integration testing, functional testing, or end-to-end testing.
• Regression Testing: Every bug you find and catch should be exploited by a unit test. If that test passes, it guarantees the bugs won't repeat.
• Exploratory Testing: There's no substitute for playing your game and trying weird stuff. You'll find quirks and things that your automated tests won't catch.

Without these fundamentals, be prepared for lots of bugs and poor game reviews! Above and beyond them, depending on your available time, skill, and interest, you may benefit from additional categories:

• Balancing: Write tests that make sure the game is balanced, e.g. each class has roughly the same DPS, or that dungeons generate with roughly the right progressive difficulty
• Performance or Crash Testing: Running previously-problematic code and making sure it's fast or doesn't crash. This includes running your game overnight to see if bad things happen.

I can't reasonably explain all those topics in a suitable depth without writing an essay, but get in touch with me if you would like more information on these topics.

Testing Process

Regardless of how little or how much you utilize the above categories of testing, you need to properly test your game whenever you make a change. Properly means: sufficiently testing those areas that may be affected, to make sure they still work as expected.

After all, global variables are still a thing. Singletons can easily be accessed from anywhere. Highly-coupled code is common in (and out) of games. You need to make sure you didn't break stuff by mistake.

How? Simple; but it all depends on two things:

• You have a continuous integration setup which builds on every commit
• You have a way of producing a final kit (installer, standalone executable, etc.) that you're going to ship

Let's start with baby steps. Whenever you make a code change:

• Write unit tests
• Run all unit tests continuously (before you check in)
• Have a continuous integration solution (e.g. Jenkins, Travis-CI) build your code and run tests every commit

This makes sure your code works (very granularly, at a class/scene/script method) and that you didn't break anything in an unrelated area. Good unit testing usually uncovers bugs (while you're writing the test code). They run fast (sub-second), so you can test lots of things quickly.

If you have integration/functional/system tests, they're usually slower (seconds each), but highly valuable, since they're like a mini version of your game in some scenario/situation. Run those as part of the build, too.

After the build runs, it generates a playable binary of some sort. Against this, you want to properly test the new feature/change/fix you just added. Like, properly, including things leading up to it and things after it should have happened.

With this done, you can be reasonably sure your game works, assuming you have good coverage of unit, regression, and system tests. You may want to run some exploratory tests: mess around and see if you can find anything or break anything.

Release-Time Testing Process

Your game is done, hurray! Congratulations! Now, the fun part: testing your game before you ship it. Since you have a robust build system in place, take the binaries from a passing build, and test it.

The best way to know if your game is likely ready, is:

• Play it from beginning to end
• Stop and fix any bugs you find, verifying them through the build binaries
• Depending on the game length, either start over, or finish the run

Repeat this until you can complete the game without finding anything to fix.

Also, when you find a bug, you don't need to re-test everything; you can re-test just the affected area (e.g. inventory management) and any other areas that might be affected because of shared/common/global code (e.g. item crafting).

Balancing, Performance and Crash Testing

If you write tests for balancing (make sure monsters, or skills, or levels, etc. are balanced with respect to each other), performance (make sure a certain part of the game runs fast enough), or crash (exercise a workflow and check it doesn't crash) testing, you can run them as little or as much as you like.

I recommend running them at least weekly or per-sprint, to make sure nothing broke unexpectedly. If you have a good CI system and don't mind longer test runs, you can run them as part of the CI.

Conclusion

Testing is expensive! It takes time and effort! Write tests, debug tests, update tests! Anyone who tried this process will likely tell you it's worth it. The pay-off of pressing a button or pushing a commit, and having confidence that your game works, in every way you tested, is well worth the effort.

Don't be daunted. Take baby steps. Practice. Ask questions. Try to add a bit more to each new project you start, so you can eventually master all these skills. They take time.

If you ever want a second opinion or sounding board, or have questions or comments, feel free to reach out to me on Twitter or Discord.

This blog post includes a discussion about AABB collision resolution: what it is and isn't, it's strengths and weaknesses, some common pitfalls, and how you can (hopefully) implement it in your low-level gaming tool of choice, if needed.

I learned all this (the second time) as part of adding fast/stable collision resolution to Puffin, a fast, lightweight 2D game engine built on top of MonoGame.

AABB, Collision Detection, and Collision Resolution

Some quick definitions to start:

• AABB (Axis Aligned Bounding Boxes) means two non-rotated boxes, that are aligned on one axis. In 2D, everything on the same "layer" or "z" is on the same axis; in 3D, it means your boxes are on the same plane.
• Collsiion detection means detecting if there is a collision (two AABBs overlapping) or will be a collision (eg. in 0.3s these two will start colliding).
• Collision resolution means resolving the collision. Broadly, there are two approaches to this: prevention or pre-collision resolution (stop just at the onset of collision when the two AABBs touch), and post-collision resolution (once two AABBs overlap, move them backward in time until they no longer overlap).

My approach to AABB uses pre-collision resolution, because it tends to be less complex and more stable.

Pros and Cons of AABB

Why should you use AABB collision resolution? There are many other options, such as collision points, sphere/line collsion algorithms, polygons, etc.

The strengths of AABB include:

• It works well in most cases. Most games can do well enough with just bounding boxes on their entities.
• It's relatively simple to code (math-wise), because it's just boxes.
• It's quite cheap computationally (eg. doesn't have an expensive square-root calculation, unlike spherical checks)

However, it includes some drawbacks:

• It doesn't work with rotated boxes
• It doesn't work well with non-box shapes
• It requires extra work for it to work well with multi-entity collisions
• It's succeptible to "tunnelling" (high-speed objects move through solid objects because of their velocity)

If you can live with those limitations, I recommend AABB, primarily because it is computationally cheap (works well with a high number of colliding entities).

Collision Resolution is Complex, like Physics

While AABB collision resolution is relatively easier to code, it doesn't mean it's easy to code. Many game frameworks don't include collision resolution, because this is part of the physics engine.

Read that again: it's often part of the physics engine. Physics engines are notoriously difficult to get right, and require lots of fiddling and corner-case evaluation. Even high-quality physics engines have limitations, such as tunneling.

It took me around 10 hours to discover all the caveats and get this to work right. And it works well, including with multi-entity collisions. Test thoroughly.

That said, my implementation includes a few bonus features:

• It's resistant to collision tunneling (but not impervious)
• It works with multiple objects colliding at the same time
• It allows an object to optionally "collide and slide" along the object it collides with

With that out of the way, let's dive into the actual theory of how to make a stable AABB resolution, and then some code.

High-Level Description of AABB

AABB collision resolution works by looking at the X and Y component resolutions of your velocity. Simply put:

• Consider the intended destination of your moving entity (where it will be after updating its position, not where it is now)
• Look at the distance dx to travel before we collide on the X-axis and dy for the Y-axis
• Divide these by your component X-velocity and Y-velocity respectively (vx and vy) to figure out how long before each axis collision takes place (tx and ty)
• Resolve the collision on the axis that collides first

This excellent diagram (credit: LaroLaro on GameDev.SE) shows a moving object (A) that will collide with a second object (B). Based on the component velocities, you can see from the projected A box that the faster collision will be on the Y-axis first.

Because collision resolution takes place on a single axis at a time, you may end up having to resolve the same collision multiple times to get a stable resolution. I find that running the collision resolution twice suffices.

And Now, the Code

Below, I discuss some pseudocode that's almost the same as the actual (C#) code from Puffin. The same code can apply to any programming language or framework.

One unorthodox implementation detail I used: when each entity moves, I make a note of their "intended" destination X/Y. If that location would cause it to collide inside an object, I instead update it so it stops just at the point of collision. In my pseudocode below, you'll see this as intendedX and intendedY.

For every collidable entity, you're going to compare it to every other collidable entity. Since we're using AABBs, this is pretty simple: just compare the coordinates plus intended movement of the moving entity, against the entity that isn't moving:

private static bool isAabbCollision(float x1, float y1, int w1, int h1, float x2, float y2, int w2, int h2)
{
    // Adapted from https://tutorialedge.net/gamedev/aabb-collision-detection-tutorial/
    return x1 < x2 + w2 &&
        x1 + w1 > x2 &&
        y1 < y2 + h2 &&
        y1 + h1 > y2;
}

You simply call this with e1.x + e1.velocity.x, e1.y + e1.velocity.y, e1.width, e1.height, e2.x, e2.y, e2.width, e2.height and it will return if they collide or not.

However, to stop at the point of collision, we need to consider our entity's velocity: if it's moving right, then the distance to collide on the X-axis is the right edge of e1 compared to the left-edge of e2. If it's moving left, then vice-versa (left edge of e1 vs. the right edge of e2). The same thing applies when we resolve on the Y-axis.

// Assuming we have two AABBs, what's the actual distance between them?
// eg. if `e1` is on the left of `e2`, we want `dx` to be `e2.left - e1.right`.
private static (float, float) CalculateAabbDistanceTo(Entity e1, Entity e2)
{
    float dx = 0;
    float dy = 0;

    if (e1.X < e2.X)
    {
        dx = e2.X - (e1.X + e1.Width);
    }
    else if (e1.X > e2.X)
    {
        dx = e1.X - (e2.X + e2.Width);
    }

    if (e1.Y < e2.Y)
    {
        dy = e2.Y - (e1.Y + e1.Height);
    }
    else if (e1.Y > e2.Y)
    {
        dy = e1.Y - (e2.Y + e2.Height);
    }

    return (dx, dy);
}

Then, for every collidable entity, if it results in an AABB collision with another collidable entity, we figure out which axis collides first, based on which one collides first time-wise:

// Another entity occupies that space. Use separating axis theorem (SAT)
// to see how much we can move, and then move accordingly, resolving at whichever
// axis collides first by time (not whichever one is the smallest diff).
(float xDistance, float yDistance) = CalculateAabbDistanceTo(entity, target);
(float xVelocity, float yVelocity) = (entity.VelocityX, entity.VelocityY);
float xAxisTimeToCollide = xVelocity != 0 ? Math.Abs(xDistance / xVelocity) : 0;
float yAxisTimeToCollide = yVelocity != 0 ? Math.Abs(yDistance / yVelocity) : 0;

Resolving collision based on collision time solves some corner-cases where an object is very close to collision on one axis, but moving much faster on the other axis (eg. a player falling off a tall building moves into it, and instead of colliding against the side, he collides with the top).

Once we know which collision is first, it's easy to resolve if the collision is only on one axis:

float shortestTime = 0;

if (xVelocity != 0 && yVelocity == 0)
{
    // Colliison on X-axis only
    shortestTime = xAxisTimeToCollide;
    entity.IntendedMoveDeltaX = shortestTime * xVelocity;
}
else if (xVelocity == 0 && yVelocity != 0)
{
    // Collision on Y-axis only
    shortestTime = yAxisTimeToCollide;
    entity.IntendedMoveDeltaY = shortestTime * yVelocity;
}

Finally, the most complex case: what do we do if the object would collide on both X- and Y-axes? We resolve the fastest collision first:

else
{
    // Collision on X and Y axis (eg. slide up against a wall)
    shortestTime = Math.Min(Math.Abs(xAxisTimeToCollide), Math.Abs(yAxisTimeToCollide));
    entity.IntendedMoveDeltaX = shortestTime * xVelocity;
    entity.IntendedMoveDeltaY = shortestTime * yVelocity;
}

Easy! If it would take 0.1s to collide on the X-axis, and 0.2 on the Y-axis, we increment the entity's X and Y by their velocity times 0.1 (the faster collision time).

Finally, for stable resolutions, make sure you run the collision resolution twice per update. Since MonoGame-based frameworks give you the update time, simply run the update twice, with half of the elapsed time, each update:

var halfElapsed = TimeSpan.FromMilliseconds(elapsed.TotalMilliseconds / 2);
// Resolve collisions twice to stabilize multi-collisions.
this.ProcessMovement(halfElapsed, entity);
this.ProcessMovement(halfElapsed, entity);

That's it, you're done!

Slide on Collide

With basic collision resolution out of the way, you might ask "how do I slide up against the target object instead of simply stopping abruptly?"

The answer to that caused about 50% of my development time. The answer is "you collide as usual but then move on the other axis as much as is reasonable," where reasonable means "don't move so much you collide with something else." In this case, don't slide if doing so would land you in another AABB collision.

Another complication I can't explain well is my need to refer to the "old" intended X/Y distances; I'm not 100% sure at this moment why I needed those, but those are needed for a proper resolution.

Some code:

    if (entity.SlideOnCollide)
    {
        // Setting oldIntendedX/oldIntendedY might put us directly inside another solid thing.
        // No worries, we resolve collisions twice, so the second iteration will catch it.

        // Resolved collision on the X-axis first
        if (shortestTime == xAxisTimeToCollide)
        {
            // Slide vertically
            entity.IntendedMoveDeltaX = 0;
            // If we're in a corner, don't resolve incorrectly; move only if we're clear on the Y-axis.
            // Fixes a bug where you  move a lot in the corner (left/right/left/right) and suddenly go through the wall. 
            if (!isAabbCollision(entity.X, entity.Y + oldIntendedY, entity.Width, entity.Height,
                collideAgainst.X, collideAgainst.Y, target.Width, target.Height))
                {
                    entity.IntendedMoveDeltaY = oldIntendedY;
                }
        }
        // Resolved collision on the Y-axis first
        if (shortestTime == yAxisTimeToCollide)
        {
            // Slide horizontally
            entity.IntendedMoveDeltaY = 0;
            // If we're in a corner, don't resolve incorrectly; move only if we're clear on the X-axis.
            // Fixes a bug where you  move a lot in the corner (left/right/left/right) and suddenly go through the wall.
            if (!isAabbCollision(entity.X + oldIntendedX, entity.Y, entity.Width, entity.Height,
                collideAgainst.X, collideAgainst.Y, target.Width, target.Height))
                {
                    entity.IntendedMoveDeltaX = oldIntendedX;
                }
        }
    }
}

Wrapping it All Up

That concludes a somewhat whirlwind tour of AABB collision detection. I hope you came out of it understanding the pros and cons, how to assess when you need it or not, and enough pseudo-code to actually get it working for you.

I would love to hear from you! If you have any feedback, please drop me a message/tweet on Twitter.

I recently engaged in a conversation with someone about religion and games; specifically, about me showing, explaining, and playing the audio of verses of the Qur'an in my games. This discussion lead me to think about, question, evaluate, and eventually understand (at a deeper level) why I do this, and why I included that section in that game.

To summarize: I think the use of religion (specifically, elements of Islam and Muslim culture) in games is essential for many reasons, including breaking stereotypes and building a deeper understanding of what Islam's canonical texts really mean. In fact, the word "deen" in "Deen Games" means religion, but it also means "a way of life."

Why Integrate Religion Into Games?

So, the core issue: why bother mixing religion with games? Certainly, this is not something people ask for (barring a very narrow definition of "game" and focusing on educational aspects, usually in the form of quizzes).

Some thoughts that come to mind: - Religion, in general, is something that is often looked down upon as "backward," "violent," and not useful. - Religion in games, is seen as almost a taboo; something people just don't do. - In the past, some people have made thinly-veiled religious propaganda as games

In particular, if you look at the demographic of Muslims, it paints a similarly bleak picture: - Muslims are often portrayed as terrorists, oppressors, and backward in media - Games are no better - Muslims commonly appear as the antagonists in first-person shooters, supplanting Nazis

Knowing all this, a not-so-obvious solution becomes obvious: why not use games to counter the negativity and stereotypes around religion and Islam in particular? Games reach around the world, but can uniquely engage players interactively; can create fantsatic scenarios that don't exist outside; and can cast players in the role of those they wouldn't normally choose to be. Games can show an alternative view, and potentially build empathy for marginalized groups. (In fact, some ideologies already use games to achieve all these goals.)

That brings us back to Deen Games. Our mission is not to create religious propaganda or poorly-disguised quizzes. We actively work to create fun, innovative, unique, accessible games that include Muslim culture, history, and beliefs as an integral part of the game universe.

As one person aptly tweeted:

If your beliefs do not bleed into your creative process on some level, they are not your beliefs. I expect a game made by Muslims to have some aspects of their beliefs even if they're not overt. Scrubbing games of every hint of a belief system to avoid offense is imo offensive.

What we can Learn from Islamic Games

My specific interest within Islamic games is to create games that leave the player with an understanding and practical application of canonical texts of Islam through games. Because games allow us to create arbitrary fantastical scenarios and situations (fantasy and sci-fi in particular), this provides us a rich, fertile ground for creative expression and building a real understanding.

Creating Islamic games with visibly Muslim characters not only breaks stereotypes, but it also normalizes us in popular culture, contrary to how we're often portrayed in media.

It also confers an additional benefit: it allows us to easily break the common tropes/stereotypes of games. For example, a fantasy game like Eman Quest might contain slimes, bats, sentient rocks; but also jinns and other creatures/elements drawn from our Islamic theology and history.

It's a Trade-Off Though

Like choosing a pixel-art or low-poly aesthetic to your game, choosing to include Islamic elements comes with some down-sides. I expect the benefits to (greatly) overwhelm the downsides, which include:

• This can break immersion. In particular, the Islamic content must be well-integrated into world lore.
• It doesn't appeal to everyone. A rather vocal group exists decrying religion in games. Even Nintendo has a history of removing religious elements from various games.
• It takes practice to integrate religious identity and iconography and beliefs in games - especially if you don't want a very superficial integration.
• Not every religious quote, source, message, symbol, etc. can or should be integrated into games.

Closing Thoughts

Thanks for taking the time to read this! I highly encourage you to drop me some comments on Twitter and let me know your thoughts.

Or, if you feel up to it, why not include a visibly Islamic element/character/outfit in your next game? I would be happy to work with you on this to define something you feel happy about including in your games.

Welcome to the rather large retrospective on Eman Quest. Eman Quest, if you haven't heard about it, is a "procedurally-generated mini-RPG with memory mechanics." You can try the full game, for free, on Itch.

This retrospective covers two parts: first, the overall idea (what did I plan to achieve? What did I actually achieve? Reflections), and the key lessons learned (mostly specific to Godot).

The Overall Idea: A Procedurally-Generated RPG

I really like procedural content generation (in general), although it's deceptively difficult to implement correctly (corner cases really get you). I always wanted to make a "procedurally-generated Chrono Trigger-like RPG," although that's a huge undertaking; Eman Quest was the first step: creating a small, "lightweight" or "mini" RPG.

What, exactly, did I include in Eman Quest?

• A fixed story about life, faith, and family
• Seven different areas; these are three geographies (forest, cave, and dungeon) each with multiple biomes (frost forest, death forest, desert dungeon, etc.)
• A unique world: each time you play a new game, it picks three out of seven biomes, and generates the required maps for each.
• Unique enemies, two per area, statically-generated and balanced with careful trade-offs (eg. glass cannon, tank), and a unique boss per biome.
• Procedurally-generated equipment (weapons, armour), including their stats
• A battle system that relies on not puzzle/thinking or skills/reflexes, but memory: remember the selected tiles, pick them to get action points, chain them to get tech points, and then use them for your turn.
• Two fixed skills in battle
• A progression system with experience, levels, and stats points you can distribute to your liking (respeccing is free).

I didn't include many things in Eman Quest; specifically, I analyzed Bastion, how they cut corners to cut down on the amount of content they needed to complete the game, and applied it to my game. Specificially:

• I scrapped procedural story-, world-, event-, and character-creation, and wrote a fixed story instead
• I scrapped the world map, because it adds little or no value
• I didn't incude any NPCs or shops, because those require a lot of art/coding. (You always find better equipment in chests than what you're using.)
• I cut a few things in content: avatars, some biome variants (crystal caves), variant bosses, and unique final-boss skills.

What Went Well

Overall, I am very happy with the result, and thankful that I could finish this project, although it doesn't come quite close to my initial vision (due to scope cuts and resource/time constraints).

Things I really like about Eman Quest:

• It "feels" like a procedurally-generated RPG.
• It's balanced (monsters seem quite distinct/different to fight) even though it's on the easy side
• Quite a few people completed the game
• The memory mechanics received some compliments (more on the design below)
• I shipped. Especially considering I tend to abandon long-running projects, this is especially important to me
• I polished the game considerably, including audio (background and sound-effects)
• I received some fan-art, and several questions about my protagonist; which prompted me to create an elaborate background, and a character representing many minorities: a strong woman, a Muslim, and an African
• I represented Muslims and Islam positively, and communicated one of our values (good treatment of parents)
• I learned a lot about game accessibility, and added a few accessibility options into my game

Below, you can see the fan-art of the protagonist, Aisha.

As my first full Godot project, I'm not really proud of the code quality; as I joked on my Discord server, code quality decreases as you get closer to production!

Memory Mechanics

Aside from the technical challenge of creating a procedural RPG, I challenged myself to create a fun battle mechanic based on memory instead of reflexes or puzzles. I also received lots of good feedback about this from users, who praised the memory mechanic as interesting.

The core mechanic works simply: a 5x5 grid appears, some squares highlight for a fractional second, and then disappear. You need to click on those highlighted tiles to accumulate "action points," which you can use for different actions (attack costs 2, critical costs 3, and defend/heal costs 1).

In initial prototypes, I experimented with requiring players to pick both energy (action poinst) and actions they wanted to play. This proved to be quite "stressful," because you have a fractional second to look for both required energy tiles and action tiles; midway through development, I streamlined it into what it is now. I also tried several variations (incluiding a "simon says" type mini-game and a stream of "which of these items did you never see before"), both of which didn't seem fun enough to include in the final.

I also found that battles become somewhat rote and mechanical/deterministic after a while: you pick the five specified tiles, then pick crit, attack, and repeat, healing as necessary. To change it up, and to reward skillful play, I added techniques/skills and technical points.

Players who pick three or more tiles correctly in a row (with no mistakes) acquire tech points. If you select all five tiles correctly, you get a total of three tech points. You can save these up and use either five or seven for stun/vampire skills respectively. This adds an element of strategy and non-determinism. Tech poinst also persist across battles, adding another dimension of planning.

What Didn't Go Well + Key Insights

I initially planned one month to complete the project; it ended up taking around nine months. Why? Many reasons, including:

• I realized early on that different forests just didn't cut it, and needed both variation (styles of forests) and map types (cave, dungeon, etc.)
• Creating art was not my strong-suite, and I needed three distinct tilesets, each with two unique variations
• Finding, drawing and animating 14 monsters, and their walk cycles, took a lot of effort; even though I found many of the base sprites and received lots of help on the art side.
• I added the story about five months in, and required implementing an entire message dialog system, key-item system, final-game events, and lots of unexpected things.
• Technical struggles with, and crashes in, Godot (more on that below).

I ran into several difficulties along the way. These include:

• Learning Godot's API, which seemed quite foreign to me (anything is a scene and can contain sub-scenes). Also, Godot is quite a wide framework, and it takes time to discover/learn/use things (like UI components).
• Learning about Godot's automatic garbage-collection (free and queue_free) and how they destroy all objects when changing scenes. This caused me to rewrite my early version to completely separate data about maps (tiles, treasure, etc.) from the visual presentation of those, which got GCed.
• I wrote garbage, prototype-quality code throughout. This lead to numerous bugs (some difficult to diagnose and fix), and a cycle of "fix something but break something else" late in development. You can see tweets with some bugs, including a few hilarious ones, here.
• I didn't write any unit or integration tests. This meant I could break things without noticing for days/weeks. I remedied this quite late in development by using GUT (Godot Unit Testing).
• Lack of CI. Unlike other, C#-based projects, I couldn't get Travis to run my tests; so if I forgot to run tests, broken things stay unnoticed.
• The final game crashed a lot, which caused a lot of stress and resulted in a lot of lessons; so I wrote a section just on that.
• Close to the end of development, I lost my GPU on my main development machine, and my main Windows installed contained drivers that didn't run with Godot 3.0.6. I ended up switching to Linux (which included up-to-date drivers), but lost of a lot of time; I also upgraded Godot to 3.1.1, which initially showed a problem with cave maps running at 2-3FPS, but works fine on Linux.
• Serialization for saving games. As the Godot docs on saving games suggests, you need to manually serialize all your (nested, hierarchial) data structures into JSON. This requires a lot of boilerplate, and it's very tedious (you may miss a field and not realize unless you test thoroughly).

The Game Crashed on Release

When I released the game, it crashed. A lot. This undoubtedly resulted in a terrible first-impression, although I received several supportive comments such as "it crashed once and then I reloaded and it was fine" or "it keeps crashing after battles but I completed the game."

Why did it crash, why didn't I notice, and how did I fix the crashes? Well, I'm glad you asked.

Godot runs the game in the editor, somewhat differently from when you export the final platform-specific release. This includes differences such as caring about case-sensitivity (which the Editor doesn't, on Windows), and - critically - crashing when you do Bad Things (like waiting for an event and disposing the scene before it comes back).

I always tested Eman Quest from within the editor, so I never noticed (or cared to notice?) the errors. The game also crashed on Linux and (troublingly) MacOS (which I don't have hardware to test with), but not on Windows, so I failed to catch it in my pre-release testing.

In the end, I upgraded Godot from 3.0.6 to 3.1.1 (someone commented that it didn't work with their graphics card, and 3.1.1 works with OpenGLES 3.1 and earlier), and the crashes disappeared. I also:

• Tested on Linux (after switching to Linux) and found I could reproduce, and fix, one crash
• Fixed sporadically-appearing errors that Godot printed out, which fixed at least one crash
• Received great offers of help from people on Twitter, specifically running MacOS, who found workflows in-game that reproduced the crash, and verified after I fixed them.

Action Items

I learned several key lessons out of this. Learning about Godot itself proved invaluable; beyond that:

• Write clean code. (Clean meaning, as good as you can make it.) This results in less bugs and less painful troubleshooting later on when things turn bad.
• Export and test your project often. This catches bugs, crashes, and all kinds of badness that you don't want players to find first.
• Fix all runtime errors, and any errors/warnings Godot generates. These often foreshadow crashes when the game runs (sometimes, only on select platforms - Windows seems fairly resilient)
• Unit test everything. Unit testing is cheap, runs quickly, and pays for itself in spades; you can quickly catch issues without manually retesting everything.
• Set up a continuous integration pipeline to run your tests. With GitHub and Travis, you can check in code, and get an email whenever you broke some tests (but didn't notice by running them manually). That can be invaluable to avoid breaking things that work.
• The Godot community is awesome. Ask on Discord, open a GitHub issue, post a tweet - there are experienced developers who will get back to you, promptly, with solid solutions. Just be careful what you ask for! (I upgraded to Godot 3.1.1 and needed to redo all my UI to fix a tiny bug with one slider.)
• Always update to the latest version of Godot. It really works better, and often clears up hard-to-fix bugs.
• Make friends on Twitter. You never know who will like, follow, comment, download your game, and - critically - help often comes from those who we least expect it from.

Finally, I want to personally thank everyone who helped me with the project - you know who you are. Without your help, coaching, support, and mentorship, I would never actually finished the game.

Godot allows you to capture in-game screen-shots, without the use of any plugins/addons. However, I couldn't find a complete, step-by-step guide to do this, without relying on any specific nodes being instantiated in your scene.

You can follow these steps. I tested these on Godot 3.0.6. Some of the code originated in a thread that mentioned that "you need this prior to Godot 3.1," but through testing, I eventually removed all unnecessary code. I can confirm that this sample works, because I implemented it in Eman Quest.

Saving Screenshots

Godot provides a rather straight-forward API for saving a screenshot:

var screenshot_path = "user://screenshot-test.png"

# Retrieve the captured image
var image = get_tree().get_root().get_texture().get_data()

# Flip it on the y-axis (because it's flipped)
image.flip_y()

image.save_png(screenshot_path)

This saves a screenshot into a file called screenshot-test.png, under the user space; on Windows, that's something like C:\Users\CURRENTLY_LOGGED_IN_USER\AppData\Roaming\Godot\app_userdata\Eman Quest\screenshot-save0.png, where CURRENTLY_LOGGED_IN_USER is your user name (eg. nightblade).

Loading Screenshots

Loading screenshots proves more complicated:

• To load the data, you can use image.load_png_from_buffer, but it takes a PoolByteArray - not something you can load with a call to preload("res://..."). This requires using the File API.
• To set the texture onto a sprite, you cannot simply assign it to an Image instance; instead, you need to create and initialize an ImageTexture instance.

After we sort through these issues, we end up with code like this:

var file = File.new()
file.open("user://screenshot-test.png", File.READ)
var buffer = file.get_buffer(file.get_len())
file.close()

var image = Image.new()
image.load_png_from_buffer(buffer)

var image_texture = ImageTexture.new()
image_texture.create_from_image(image)

sprite.texture = image_texture

This loads the PNG file screenshot-test.png from the user-space into an Image, wraps it into an ImageTexture, and assigns it to some Sprite instance

Crop and Scale

Since we loaded our PNG into a Sprite, we can execute other operations on it:

• You can set the region_rect properties (through code or through the editor) to crop the image
• You can set the scale to create a thumbnail of the image
• You can apply effects, colourization, etc.

This affords a lot of interesting use-cases, such as creating a thumbnail of the in-game screen per save-game (my personal use case).