Astral Collision Autopsy

I recently released the final update video for Astral Collision where I discussed why I wasn't going to be continuing to work on it. However, a conversation with HuntingSwan, a fellow game creator who'd been following the project, has made it clear to me that I failed to put that decision into its proper context, as Astral Collision itself was just a snapshot of my efforts to create a game with RPG Maker MV.

The purpose of this article is to give that fuller context. Before I do, however, I want to make sure people who are unfamiliar with RPG Maker MV have some basic knowledge of that program. If you are already familiar with it, please feel free to skip the next section.

What Is RPG Maker MV?

Part of the RPG Maker series by Kadokawa, RPG Maker MV is a game creation tool that was released in 2015. The RPG Maker tools are aimed at creators new to game development, though a flexible plugin system makes them suitable for more experienced developers as well. As the game engine that RPG Maker MV uses is written in JavaScript, plugins can be extremely powerful and are easy to implement, provided you have some experience working with JavaScript and a willingness to dig into the engine code to figure out how to do things.

The biggest draw to RPG Maker products in my eyes are all of the assets it provides for the developer using it. For a relatively affordable price, you get access to not only the editor and engine, but also a bunch of audio and graphical assets—music, sound effects, and art that you can use in the creation of your game. This saves a lot of time, effort, and money for those that choose to use an RPG Maker product!

However, as RPG Maker products are designed to be able to be introductory products, they are also simplified in many ways. In effect, they are designed to enable the creation of games similar to Super Nintendo Entertainment System era RPGs. The more you try to do something else, the more you'll find yourself running into the aforementioned simplifications.

I'll be talking a lot about running into those issues throughout this piece. This may give the impression that I think RPG Maker MV is a bad tool. I want to be clear: I do not think this. I think it is a very specific tool, and an excellent one for what it does. My issue is that what I'm interested in making has often diverged too much from what RPG Maker MV does well.

The Graveyard

Astral Collision is in good company. There are seven other abandoned RPG Maker MV projects that it is now joining. Yes, seven. It has probably gotten the furthest in development of any of them, but I don't think by as much as it might appear. It is certainly the most elaborate in terms of plugins, however.

To me, these projects aren't failures, they were learning experiences. Each one has run into issues, things that caused me to abandon it, but in so doing, I've learned lessons: lessons about how to use RPG Maker MV, lessons about what sort of game I want to make, lessons about how I work and what I'm interested in working on, and lessons about dangers to avoid. They've also built up a collection of useful plugins, which Astral Collision both benefited from and is adding to.

Digging into these lessons is the entire purpose of this article. [Editor's Note: This digging has proven to be extremely valuable for me! As such, I do want to thank HuntingSwan for the conversation that inspired it. I hope you, dear reader, find reading this article to be as valuable to you as I found writing it to be to me!]

Why Games Went to the Graveyard

The simple reason why all eight of those games have gone to the graveyard is over ambition.

But that needs to be broken down. For one thing, there are different types of over ambition. Also, I should really explain what I mean by "ambition" in this context. When I say "ambition," I effectively mean "what I envision the final product as being." So when I say that these projects have died because I was overly ambitious, I effectively mean I was trying to do Too Much. However, what there was Too Much of varies from project to project, though a common thread was me starting with a simpler set of ideas that then grow to become Too Much.

It's been a long while since I worked on many of those previously abandoned projects, so my memories of them are fuzzy. However, I think it is correct to say that the most common types of Too Much were in complexity of the design—so a technical kind of too complex—and too much lore. Both of these have often been the result of the same sort of thing happening, which I'll discuss momentarily.

First, I want to state that I think Astral Collision ended up with both types of over ambition. Second, I want to be clear that when I say "over ambition" like this, I don't mean that the challenge is insurmountable. On the contrary, I do think these things are surmountable; they can be accomplished. I just am not going to be the one to do so. The reasons for that will also be discussed later, as they're important to understand.

But back to why I keep running into over ambition problem in the first place.

How I End Up Overly Ambitious

One thing I've learned from analyzing why I want to stop working on Astral Collision is that what I'm interested in making are systems. I love examining, analyzing, and creating them. They are often mechanical, such as combat systems or build systems, but they can also be about worldbuilding with things like how societies or religions work. These are the sorts of things I'm most interested in as a designer, creator, and analyzer.

There are other things I'm interested in and fascinated by, of course; however, they don't hold me as a creative (as in, the one making them) the same way systems do. In other words, I enjoy consuming these things, but I've yet to find an approach to creating them that works for me.

The Dark Souls series, particularly Dark Souls 1, contains some good examples of such things. I love the careful worldbuilding involved in the level design and environment art. I love how the lore is delivered, the archaeological and forensic nature of figuring out how everything fits together and learning the history of people and places. I think that's super cool, and I want to replicate those things. I also have proven to not be effective in doing so.

A large part of the reason for that is because I haven't figured out how to, but I try and then run into issues before ultimately give up the attempt because of those issues. This is largely because I think my approach hasn't been setting me up for success. It's an issue I ran into numerous times in previous projects, but also one I ran into in Astral Collision.

So, what's my approach, and why does it keep causing me trouble?

Here's how I tend to make an RPG Maker MV project. I have some mechanical idea that fascinates me, so I begin making it. After a while, I realize I need some amount of lore for this mechanical idea to be expressed with. So what's happened thus far is I've made something, I've created a mark. I've made some characters and some enemies and some gameplay. This is the current guidance I have on the project, so I attempt to create lore to fit it all together. I usually have bogged down at this point for one reason or another. As I'm writing this, I just now realized that I should be looser with those initial marks and willing to rework them, but I haven't generally done that.

For what it's worth, I think what I've been doing is a bad way to go about creating a game with Dark Souls level lore and worldbuilding cohesion—a goal I often have with my RPG Maker MV projects. I think you either want to create the lore at the very beginning, as the first step of creating the project, and have everything flow from that, or you should create enough of the project that you then fit the lore to it (which is what I've heard Team Cherry did when creating Hollow Knight). Trying to make it in the middle introduces too many constraints based on what already exists, then creates too many constraints on what you make next. If people are interested, I can elaborate on these two approaches in a future article.

Anyway, this is a big area that tends to cause problems for me, but it isn't the only one. The other issue that occurs is more technical, but can be summed up as fighting against RPG Maker MV. Typically what happens is that I want to create a more open-world game than RPG Maker MV readily accommodates, resulting in a lot of time and effort spent on workarounds and conditional statements nested deeper than the bottom of the ocean.

Like I said in the RPG Maker MV explanatory section above, RPG Maker MV is an excellent tool for certain things. It does an excellent job of empowering you to create RPGs inspired by those of the SNES era. It does a very poor job of enabling you to create RPGs driven by nonlinear narratives. For example, I distinctly remember one project that I ended up abandoning when I realized that the order in which you acquire party members being randomized made it nearly impossible to construct interactions with them. Another issue, which I highlighted in the video, is that when you present the player with choices to make during a dialog scene, none of those choices can be conditional. This means you can't easily add in choices depending upon criteria; you'd instead have to set up separate conditional statements for which selection of static options the player gets to choose between.

As I tend to be someone who loves variety and unpredictable experiences, I keep trying to make open games that let the player explore the way they want, as inspired by games like Dark Souls 1. That game in particular lets you go in a variety of directions and guides you more by enemy difficulty than world constraints. The promise of what Metroidvanias (or as I prefer to call them, Upgrade Hunters) can be is something I also find fascinating.

RPG Maker MV is quite capable of handling these types of experiences up to a point, but I kept finding myself on the other side of that point.

In the end, I abandoned many of these projects when I found myself drowning under figuring out too much highly constrained lore and difficult to implement combinatorics. Combine that with often attempting to chase a build system with the complexity of Guild Wars 1 (a game whose build system I dearly love) and the lore delivery method of Dark Souls, neither of which RPG Maker MV does well out of the box, and you've got a recipe for challenges.

Let's Talk About Astral Collision Specifically

As I said to HuntingSwan, Astral Collision was the sort of game I felt I should make instead of the one I wanted to make. The main consequence of this was a very shallow well when it comes to finding motivation to push through the difficult parts of game development. But let's unpack what I mean by "sort of game I felt I should make instead of the one I wanted to make."

First, it's important to know that, after seven abandoned attempts, I wanted to set myself up to finally finish an RPG Maker MV project. My plan was to avoid the things that'd caused previous projects to die and to present the development on YouTube—for a time, I wrote short stories for my Patrons, and found that having that be content I needed to deliver on gave me a strong incentive to do something I'd been wanting to do, and I was hoping that documenting Astral Collision's development on YouTube would provide a similar kind of motivation. It turns out that I was correct in thinking that this would happen, but it also came with a number of highly negative consequences for me creatively—more on that later.

My plan to avoid the things that had caused previous RPG Maker MV projects to die meant several things, the first of which is that I wanted the player's party to be set from the beginning. One of the big causes of projects falling apart was the combinatoric challenges inherent in party members getting added in random or unpredictable orders. I also wanted to try to follow my whims better, to let the world be more chaotic so as to not get bogged down in lore stuff.

So, of course, I immediately failed to avoid both of those things. D'oh!

Oh, sure, the player doesn't get the members of their party at unpredictable points in the narrative, but the combinatorics are off the charts when I present the player with fourteen characters and then ask them make their party out of any four of them. And by off the charts, I mean that there are (does math, because for some reason I hadn't yet)…drum roll, please...ONE THOUSAND AND ONE possible parties! Yes, that's right: I, who wanted to avoid too much uncertainty about who was in your party designed a game in which there are 1,001 possible parties. Whoops.

Then I decided that each one should inspire a world! Because you know what's better than getting bogged down in the lore of one setting? Getting bogged down in the lore of FOURTEEN settings! What a brilliant plan!

So, yes, I pretty much immediately failed to address the things that'd caused me problems before. I couldn't realistically have the player party be narratively important characters because setting things up to accommodate for that many possible parties is, to put it mildly, unreasonably time consuming. That's why, if you look at Astral Collision, none of the party members ever say anything; all of their dialog is implied. You could argue that they "speak" in dialog choices, but that's as close as it gets.

This means that any story I tell is about the world and NPCs. This is, of course, a feasible approach: silent protagonists have been in many games. For example, the protagonists in Dark Souls games are silent, as is Link from the Legend of Zelda series. However, this does mean that NPCs the story is about and the world lore both have to be well developed, since I can't lean on the party and their interactions as a source of narrative or character interest for players.

And this is an area where I ran into issues.

Telling A World's Story

When it came to telling the story of the world of Astral Collision, there were several techniques I was looking to employ. As I think about it, these techniques can be largely divided into explicit and implicit techniques. The explicit techniques were NPC dialog, interactable objects in the world, journal entries, quests, and the bestiary. Implicit techniques are often more subtle, such as which enemies show up where, place names to an extent (this can waver between implicit and explicit, though), environment design and art, and so forth, all the way down to what merchants sell and what types of foods and cooking ingredients are available (some places were vegetarian, for instance).

Some of these are easier to do in RPG Maker MV by default than others. For the purposes of this discussion, I want to primarily focus on the explicit techniques. Most of the implicit techniques are fairly easy to do in RPG Maker MV; indeed, any major difficulties there come from the limited pool of tile sets (which limits environment art options), music (which limits an important part of presenting atmosphere), and similar sorts of asset-based limitations.

Of the explicit techniques, NPC dialog is the easiest to do in RPG Maker MV, since it is explicitly a thing that RPG Maker MV does. It's also easy to create, provided you have interesting things for NPCs to say. These generally fall into three loose categories: gameplay information (like directions), narrative (what is going on right now in the world), and lore (what is this place like, and what is its history). This is also the order of their importance. Gameplay information is the most important to deliver in ways the player can find so they know what to do or where to go. Then, narrative is important for the ongoing plot. Lore is really cool, but there are a lot of other ways to deliver it, so as I think about it, NPCs don't need to deliver it as much.

Interactable objects in the environment are similar to NPC dialog in that they are pretty easy to do in RPG Maker MV. You can deliver the same sorts of things with it, too, though I think it's best used for lore and to augment environmental storytelling by spelling things out for the player. However, it does suffer from one large issue, which is obviousness to the player.

An NPC is very obvious to the player, and the idea that you can interact with an NPC is relatively apparent, especially given the genre. What environmental objects you can interact with (such as a sign or dresser) and which you can't, on the other hand, is less inherently clear. Without implementing some sort of system to draw awareness to interactable objects (such as by pulsing them or using a sparkle—certainly doable, if potentially distracting) you run the risk that players aren't even going to realize they can interact with the object. As such, there's a good chance you don't want to put anything important on an interactable object in case the player misses it.

As a designer, you're left with another conundrum: how do you teach players who will poke around what environmental objects can be interacted with? This is where you want to set precedent, by which I mean if a type of object can be interacted with, it always can be. If the player can loot a barrel, all barrels need to be interactable (though they don't all need to contain loot—see trash cans in Pokémon games). This is so that the player can reliably predict what objects they can interact with.

In the end, going with a sparkle system where the sparkles vanish after first interaction (though the object remains interactable) is probably the best solution to this that I didn't think of until writing this piece, which if nothing else shows the value of doing a retrospective analysis like this.

Anyway, this brings us to the journal. The purpose of the journal in Astral Collision was twofold. The first was to record information and lore about people, places, and historical events. In this regard, I suppose the bestiary is a sort of related feature that would've been part of the journal if I'd coded it that way. The second purpose was to give me a place to put lore about equipment—needless to say, this aspect was heavily influenced by Dark Souls.

Now, RPG Maker MV does provide a field for information on gear; however, it is very small and cannot be expanded—the entry field in the editor is two lines tall and nothing will change that (you could, technically, edit the JSON data file it produces if you really wanted to, though I'm not sure if that would break when trying to export the game or not). So while you could change the size of the field in the game to show more lines, there is no point, since the editor size is locked. You could get around this by using the Note field, but if you have any tags (and this is RPG Maker MV, so you probably will, and I definitely did for Astral Collision) that has its own issues. Still, putting extended descriptions in the note field is a possible solution, but given that I was intending on having the journal anyway for the first mentioned reason, it wasn't one I considered.

The journal also marks the first plugin that I needed to create for the way I was delivering my lore. This means that putting in entries is tedious and requires a lot of clicking. It isn't the worst thing ever or anything, but the degree of separation from the specific areas I was working on—especially gear—made it annoying to work with. I think I also just don't enjoy entering stuff in like that, a thought I'll expand on more in a moment.

This brings us to the next plugin, which I needed for quests. RPG Maker MV does not include a built-in quest system per se. You can set stuff up for quests, of course, through the use of variables, switches, and items (including Key Items, which are a thing in RPG Maker MV), but it doesn't provide a native quest tracking system, such as a quest log.

The plugin I made uses a Hidden Item for tracking active quests. (Hidden Items come in A and B varieties and, like the name implies, are items that can be placed in the player's inventory which they can't see.) When opened, the quest log displays a list of all of these items, with the description field for the item displaying certain information (quest giver, for instance) and the note field being displayed as a description field.

Overall, this was a nicely functional system with some notable benefits. It is easy to manipulate the player's inventory to add or remove quests and you can do conditional checks in Events easily (including for Event pages, which is very helpful for quests).

However, it also came with some very real downsides. There's the fiddly NPC Quest informational display (a Q over a downward pointing arrow that animated differently depending upon whether or not the NPC had a quest to acquire or was part of an active quest), which required a secondary Event in the tile above a quest NPC. Because this icon was a second object, quest NPCs had to be stationary (I tried setting up a system to keep the quest marker above the respective NPC when they moved, and it did not work properly), and if anything could cause the NPC to temporarily disappear (such as it becoming nighttime, since I had a day/night cycle in Astral Collision), I'd have to make sure the quest marker could similarly disappear in all possible states.

The quest marker is but a small downside, however, to a pervasive problem in RPG Maker MV at large, which is database organization. Both the bestiary and the quest log used Hidden Items (one was A and the other was B) to track information in them. That meant both of these were item entries in the item database, alongside things like crafting materials, cooking ingredients, consumables, key items, and so forth. It doesn't take much before the database becomes a cluttered, disorganized mess. I could, theoretically, rearrange items into groups within the database, but that would be a nightmare because items are always referenced by their ID, which is defined by their position in the database.

Therefore, if I rearranged items to organize them, I'd have to go and update literally every single reference throughout the entire game—every chest, plugin, tag, and Event that references an item would have to be changed to refer to the correct one. This means that as the game develops, reorganizing items becomes more and more expensive from a time-spent standpoint, and thus not worth the effort. Better planning could help with this, but that's just not my style—if I've solved everything by planning it all out, I no longer have any motivation to actually make the thing, since so much of the fun for me in creation is the process of figuring things out.

I do, however, think quests are extremely useful. While working on Astral Collision, I started an analytical playthrough of Guild Wars: Prophecies, and one thing that stood out to me from that is the utility of quests (and a log with which to track them so you know what your objectives even are—I was heavily inspired by Guild Wars 1 when it came to designing Astral Collision's quest system). Quests can be used to expand on the narrative and lore, give the player a sense of purpose and direction, and guide the player to useful locations or NPCs.

Which brings us to the bestiary, which I touched on earlier. This used a bunch of custom code to cause enemies to silently drop a Hidden Item when they died. That item was specified in the enemy's note field as a tag. It then used another bit of custom code to call up a corresponding image (using the item's name, which needed to match the enemy's name) which contained the bestiary information.

I'm actually quite proud of the bestiary, but it does have the fundamental problem of being linked to items and the intense organizational issues that follow from that.

A common thread you can see in many of these systems (the journal's gear entries, the quest log, and the bestiary) is that they are all positive examples of a way I was able to do something in RPG Maker MV to tell a story about the world and deliver lore. However, they are all also—and this is very important—workarounds. They are all ways I'm having to circumvent limitations in the RPG Maker MV editor to implement something.

With the journal, I've implemented a workaround for the limited item description space (most of which needs to go to telling you what the item actually does). With the quest log, I've found a way to implement a very standard feature for the RPG genre that, bluntly, should probably ship with RPG Maker products. The bestiary is a similar workaround to the quest log, though I don't feel so strongly that it should be a standard feature.

Here's the problem: any time you're implementing a workaround, you're almost certainly adding overhead. This isn't a hack, where you cut through good practices to just make something work; rather, this is where the systems in place can be finagled to enable you to do something you want to do that isn't natively supported. It might work, but it's clunky, inefficient, and typically tedious to work with.

But the Things Work, So What's the Problem?

So, I have several techniques for conveying the story that can layer together to present the narrative and lore. Sure, many of them are clunky workarounds, but they do, technically, work. So, what's the problem?

Simply that the friction of trying to work with all of those workaround systems is too high for me to want to overcome. If the friction was lower—if, for example, it was a simpler matter to add a quest or item description—I would be more inclined to work on Astral Collision. As it is, the mental load of figuring out the design while also having to contend with the fiddly implementation requirements is too much for me to personally want to deal with.

Put another way, I grew tired of fighting RPG Maker MV. I wasn't leaning into what the tool does well; rather, what I was trying to do with it were things it does poorly. Not things it cannot do, mind you—you nearly can't say that about RPG Maker MV because of how powerful plugins are. However, just because you can do something doesn't mean you should.

This goes back to who I am as a person and as a designer and creator. I love exploring ideas that are interesting to me, and often, those are system-level concepts or the mechanical parts of those systems. It isn't tediously entering in data and information through workaround systems. Not that many people like doing that, but I imagine many others are more motivated to push through that stuff than I am.

This goes back to something I said much earlier on in this behemoth of an article, which is that Astral Collision was me attempting to make the game I thought I should make instead of the one I wanted to make. Bluntly put, I wasn't invested in the narrative and lore elements of the game to the degree necessary to push through the inconveniences.

Some of this is due to the character issues I mentioned earlier on (in that the player's party members can't really be active characters in the narrative due to the combinatorics). I can't invest in the characters' stories or their journey together because I can't explore that in any sort of way that's realistic to implement.

Another important aspect is that I was making videos about Astral Collision's development. I find that I want to explore and examine sexuality and nudity in my creative works, and that's just not something I can do when I'm making videos for YouTube. So while I am interested in exploring religious topics, as Astral Collision was made to do, I felt I necessarily had to cut out too much that is important to me so that I could make videos on the game's development.

The Final Verdict

Astral Collision was a learning experience. I made some serious mistakes in the design early on in a wide variety of ways. I ended up placing too many constraints, and that left me feeling creatively stifled. At the same time, I found myself struggling with the worst aspects of RPG Maker MV in the clunky plugin interface and database organizational issues. In the end, I was stuck.

I'll admit, as I've been writing this and explicitly detailing all of the problems I ran into, I've been finding myself thinking through solutions to them. For example, I could completely restructure the way you gain access to the player characters so that they arrive in a predictable way. This would require careful control of progression at large to ensure that works, but that's doable.

I could cut features, simplify systems, rework combat and stats to make balancing easier and clearer. For example, do I really need 99 levels? Or would it be better to have a smaller number with more difference between them? I could definitely see the latter working out better, maybe something like 14, 28, or 42 levels (1, 2, or 3 levels per world region, respectively). I could come up with a better system than the Skill Set system, which required me to make a vast number of skills. Alternatively, I could overhaul combat to make balancing easier by adding more ways to differentiate and balance skills.

In the end, there are a lot of things I could do to make it feasible for me to continue working on Astral Collision, but then I have to ask myself: is it worth it? How much work—time and effort—would it require? At what point is it just better to create a new game without a bunch of baggage I have to work through? I've made the call that it is better to, once again, start fresh. Not that writing this article hasn't made me want to reconsider that decision!

A Summary of Lessons Learned

The first lesson I want to highlight is the value of writing this analysis. When I did the video, I discussed things in general terms and focused on the things that were bothering me. However, when I set out to write this article, I had to turn feelings first into ideas, then into words. That transformative process was an illuminating one, and one that has proven to be highly valuable. That's something I want to remember going forward!

The next lesson I want to highlight is making sure that if I find myself implementing a workaround, I seriously consider an alternative to doing so. This is because workarounds, by their very nature, tend to introduce overhead and add friction to using a system, which generally conspire to make a task more tedious. This isn't to say I should always avoid workarounds, but rather, I need to be more leery of them.

This leads to a related lesson, which is that I should be deliberate when I use a tool. Tools are generally good at some things and bad at others—for example, Paint.NET has a very powerful plugin that lets me code new plugins, but its native text functions are extremely primitive. Likewise, RPG Maker MV is very good at certain things and not very good at others. Basically, this lesson is that I should lean into a tool's strengths more than I try to work around its weaknesses.

Another thing I've learned, and this is more about myself, is that I need to be very careful how I approach lore. Like I've said already, I'm a systems-oriented person. I should approach game creation from a technical and design standpoint, then figure out how lore fits together after I've gotten the game actually in place. It might be worth it sometime for me to experiment with the reverse (figure out all of the lore before creating systems that I then custom-create for that lore), but in general, I need to not bind up my creativity with lore because that saps out the fun of creation for me.

This isn't to say that I should avoid all worldbuilding during the creation process, but rather, that I should be careful in how much of it I try to do. I need enough to give myself a sense of direction, but not so much that I'm suffocated by it.

This actually dovetails into another lesson, which is needing to figure out when to solidify a plan or idea. I don't think I was flexible enough with Astral Collision, so when I ran into a bunch of brambles and briars, I had a really hard time changing course. As a result, I got badly stuck. The solution is to regularly step back and ask myself, "Is this working?" I then need to give myself enough space to think through if things are working, and if they aren't, permission to back up and try something different.

There are a lot of examples of this from Astral Collision, but I think a good one to mention is the day/night cycle. It technically functioned, but it added a ton of overhead. And for what? There really wasn't much gain from it; frankly, most of what I could do with it was make the player's experience more tedious. In something like Majora's Mask, where NPCs are on a schedule, you can add a lot.

Undoubtedly, there is more I could do (and to an extent, was planning to do) with the day/night cycle, but as I think about it, I'm not sure it was worth all of the extra hassle. That's something I should've evaluated at some point, along with many other things.

There are a lot of smaller, individual lessons learned, but I think this covers the major ones. I'd be curious to know what you all may have learned from reading this or watching the Astral Collision series!

So What Now?

When I was finding myself creatively frustrated with Astral Collision (because I had a bunch of ideas I wanted to explore but couldn't because they didn't fit into Astral Collision—you don't need two combat systems, for example), I started a side RPG Maker MV project that I'm currently calling "Psychopomps Are Missing". It's my current focus, game-design-wise. I'm finding myself creatively engaged with it. It feels lighter and freer than Astral Collision. I'm being careful to try to not write too much lore, but rather to focus on things in the creative ways I find most engaging. Critically, I'm also being inspired by things that work well with RPG Maker MV, notably Pokémon's balancing systems and method of progression.

I feel freer to explore things that tickle my fancy. It is a less constrained project. Like Astral Collision, it will explore concepts of religion and reality, but it also explores sexuality and nudity. As such, I won't be making YouTube videos on it.

What I am considering doing is writing articles here on the development of the game, akin to those YouTube videos. If that's something that would be of interest to you, let me know! You can do that in a number of places, such as the comments on this article, on my Discord channel (the link is over to the side), or you could tweet at me.

This has been a long one, so if you've made it through the entire thing, I both thank and applaud you!

Take care, and good designing. 😄