Devtober Post-Mortem

I'll first apologize for getting this out a bit late, but seeing as how the rest of this past month has gone, perhaps that's more in truest fashion than anything else. As it turns out, taking a trip to meet some friends in a different city after a long week of midterms is absolutely terrible for productivity. 

Still, here I am at the end of it all, so let's get this postmortem started, eh?

What Went Well?

Design:

The story begins in late March of this year, as the 2021 College Game Jam rolled around and marked the beginning of my development for a game called "Voxelsmith." The project took heavy inspiration from a couple of games and mods I had played prior, and strived to serve at least as a demo by the end of the jam, as a full game would have been an incredibly monumental task to complete within a week's time.

All things considered, however, the "final product" felt more like something that could barely even be called a tech demo. Hell, the version I submitted to the game jam wasn't even functional at first, as I had little idea of how publishing a Godot project worked and had only minutes to spare before the end of my deadline. The camera would misalign while moving, the sounds didn't work outside of the editor, and nothing to say of the bugs concerning the main game mechanic the game banked itself on.

Still, that one week of hell had proved immensely valuable in its own way. While coming up with cool ideas for games is both fun and easy, the same can't quite be said for making an attempt at going ahead and actually building the thing. There were no small number of things that I had either overlooked or had to rush due to a lack of time, and so my post-jam notes became well worth their weight in gold, remarking on what did and didn't work, as well as what not to do the next time I tried my hand at it.

Enter Devtober, the month-long game development event that I had learned of about a week before it was set to begin. 

As an admittedly very lazy person, I hadn't even so much as touched Voxelsmith since the end of that game jam many months ago, and thus thought that this would both be a good excuse to work on it again, as well as a motivator to keep continually working on it.

My first step in planning out the game's development was a complete look-over of my design documents, as well as those notes I had made at the end of the jam. While there's a thousand-and-one answers people will give you on how to do design documents, or even if they're worth doing at all, I found keeping everything as a simple .txt document to be the most effective for me. Of course, as the design began to look more and more complex, I had to separate my main document into a set of smaller ones to keep from having to deal with a bloated wall of text all the time.

A lot of my actual design process revolved around both finding solutions to the problems the demo suffered from, as well as what would be necessary in order to completely flesh out Voxelsmith as a game as opposed to a tech demo. While the main mechanic of smithing was already something I had much experience with, the same couldn't quite be said for everything else. 

For example, what were the win conditions? What was the ultimate end goal the player was meant to be working towards? What shorter-term goals could the player pursue in the meantime? What would the various gameplay loops entail? How would we keep the player engaged with the same system over a longer period of time? 

All of these and more were questions I had to constantly be asking myself as I continued to elaborate on my original design for a simple blacksmithing simulator. Another thing to keep track of was making sure I didn't go too far and start overscoping, which is a hell I'm sure many game designers are intimately familiar with. 

In the end, however, I'd like to think that I came away with a very solid design to start working off of once Devtober began.

Art:

Surprisingly, or perhaps unsurprisingly given the nature of my game's graphics, the art process actually went rather well. The program I used for making my 3D models was MagicaVoxel, which is a pretty decent (and free!) voxel art editor that I'd had a fair amount of experience using before. Aside from the forge model (which I went way overboard on for absolutely no reason), the rest of the models were either very simple or had the benefit of being ported over from the demo version. 

Code:

As for the coding portion of the development process, a lot of it actually differed greatly from the demo version. And that should make sense, seeing as how I was now building towards a fully realized game rather than a tech demo I could cut corners with. 

Thus, much of the challenge was constructing a solid enough codebase that it could easily be added onto or edited without the worry of breaking everything else, which involved a lot of abstraction. For example, the code for the "WorkshopAnvil" inherited from a parent script for "Workshops," which once again inherited from an even more general "Interactable" script. Keeping things abstracted and separate like this also made things a lot easier when it came to doing things such as adding inventories to objects, or attaching item metadata to the various items in the game.

Demos:

What's a devlog without some demos of how the actual gameplay is looking? This month, I learned how to use OBS and OpenShot Video Editor in order to record some simple demo videos of game mechanics once I got them up and running. For the most part, the demo-making process was to just record myself showing off the mechanic, slap the recording into OpenShot, add some BGM from a website I totally don't know only because of VTubers, and then add some fade effects at the end. 

And Voila, one demo video!

In the future, I'd like to make these demo videos more exciting, perhaps by including some voice-overs explaining my design choices, but that's probably something that's going to have to wait until I have something more exciting to show off.

What Didn't go Well?

Design:

As the old adage goes: "No plan survives first contact with the enemy," and I think that's especially true when it comes to any sort of creative endeavor. Things rarely go as envisioned in your mind, and that's why we have to commit ideas to paper (or .txt, in my case) to capture as much of that vision as possible for future reference. 

And yet, there truly is nothing quite like practical experience to kick those plans in the teeth and tell you everything wrong with your plans. During Voxelsmith's development, there were many things in the design that weren't implemented, just as well there were things implemented that weren't in the original design. At some points, it almost felt like the design notes I had spent so long on earlier were pretty much useless when trying to figure out implementation, and at others, there were things planned for in the design that were either technically unfeasible or too time-consuming to bother with.

Ultimately, I think my main issue was not putting enough consideration into the implementation side of the design process. That is, how things were to be coded and how it was to be structured. For example, the whole bit about abstracting functionality and metadata I talked about earlier was something completely unplanned for, even if it did make complete and total sense from a coding standpoint. Perhaps if I had planned all that out beforehand, I wouldn't have had to restructure my code as many times as I ended up doing.

Code:

And, while we're on the topic, there's also the big "coding" in the room to address as well. 

For the most part, I'd pretty much just been winging it when it came to code structure, as evidenced by the many restructurings of my codebase I've had to do during the project duration. Surprise, surprise, developing highly-modular systems that work well together without bugging out is actually kinda hard as is probably something you shouldn't be doing blidnly.

Nothing can ever be easy, huh?

The most recent example of problems with abstraction has come with the pattern system, which was resulting in yet another round of refactoring in order to unify the voxel grid systems in a way that would allow for comparisons between pattern grids and smithing grids (as well as other types of grids in the future).

Another thing that I think could've gone better was the implementation of the inventory system, which, while working as intended at the moment, felt a bit hodgepodge rather than something I could call stable. The problems there mostly lie in how items were added/removed from inventories, which was done in a way that kinda "hacky" and will probably cause me no small amount of headaches in the future. There were also plenty of other mechanics related to the inventory system that I put off until later, such as being able to grab specific items from the inventory based on proximity to the cursor, as well as some other smaller features.

And lastly on my list of things I probably could've improved was the voxel system itself. Again, like the inventory system, there technically isn't anything functionally wrong with the way it works now, but keeping it this way would definitely cause issues in the future. The problem mainly stems from the fact that the voxels currently aren't really voxels at all, but instead a collection of simple cube objects. This really starts to show itself once you stand having to deal with multiple voxels, each of which consists of a 5x5x5 cube of subvoxels. That's 125 subvoxels (each with their own collisions and whatnot) per voxel!

The solution then, would probably be to make the system actually operate as a voxel-based system, where each voxel is described in data rather than being a physical object. Then, we use this grid of voxels to render an object mesh dynamically, which should save heavily on resources. Of course, that's the kind of thing that would take absolutely ages to implement, especially since I'd have to start from square one in terms of experience. Still, it's the type of thing I probably really should have done sooner rather than later, especially considering that the game quite literally has "voxel" in the title despite not actually having any voxels yet.

Animation and Sound:

These two are more just a matter of not having the time to get to them, but I thought it should be noted anyway. To be honest, I consider these two mostly "polish" features compared to the actual functionality of the game itself, so I don't really feel too bad about missing these.

Time:

This one technically isn't my fault, but I supposed that it was at least worth mentioning. As you might have been able to tell from the lack of devlogs this past week, real-life caught wind of my work and decided to do me a solid by ending my Devtober a week early. And by that I mean hit me with three midterms in a week along with a coding project and an upcoming visit to some friends in another city. At the very least, one for three of those was actually enjoyable, so I'll take what I can get.

Either way, this meant that I was pretty much unable to get any amount of work done during the last week of Devtober, which, while not at all my fault, does peeve me off a bit since I wasn't able to stick the whole thing out.

Final Thoughts:

All things considered, I think I've done rather well for myself during this Devtober. While I missed my primary goal of matching and/or exceeding my progress from my game jam demo, I can definitely say that the quality of my work is much higher.

The prospect of working on a game everyday was quite an interesting one to experience, and while I don't think that forcing yourself to work day after day is very practical long-term, the routine aspect of it is something I can appreciate. 

Perhaps the hardest part of doing personal projects like these is that there really isn't any "gun to your head," so-to-speak, when it comes to making progress. What I mean by that is that there is no pressure to get things done in a timely manner, such as a deadline or outside expectations. If you start up a project purely for your own sake, unless you've got some pretty good discipline, it's all too easy to just stop whenever you feel like it, especially considering that there aren't any stakes at hand for doing so. This goes especially for solo devs, since you don't have the benefit of a team to keep you accountable either.

The above reasons are the ones that primarily drew me towards taking up this challenge, and I'd like to hope that these feelings will stay with me as I continue forward with my career in game development. Moving forward, I'll be sure to continue working on Voxelsmith, and, while not daily, will also continue to make devlogs on my progress on a weekly basis instead. I'm not sure exactly when I'll posting them, but I'm leaning towards either Saturdays or Sundays.

For now though, I'll probably take this week off from game development to get back in the groove, mostly to take a step back and re-evaluate the current state of design and development before I start working again.

Totally not an excuse to be lazy for a week.

Absolutely not.

Yeah...

Welp, that about wraps up Devtober, it seems. For those who have kept up-to-date with these as they've came out, I'd like to thank you for continuing to read about some idiot's endeavors for so long. 

I'll also be releasing the most recent build of Voxelsmith on the project page, so if you'd like to try it out for yourself, you'll be able to find it there. I can't guarantee the stability (or quality) of the experience, but I think it only makes sense to show off how much progress I've made over this past month.

Anyway, that's about it for now. 'Till next time,

- Ian, Lunarium Works