So it’s been like, five months since I promised to do a retrospective of WARPOUT. I did not realize that I’d take so long to write this post- juggling this between work, other projects, and still finding time to go outside and hang with other people was surprisingly an ordeal- and even when I did set aside time to work on it I didn’t really find myself enjoying it all that much. For both of these things I do apologize; I don’t really like shirking on promises, even if realistically only a few people would be “burned” by such a thing. For the sake of my sanity, future blog posts here probably won’t be as long as this one.

Anyway- I sank a month of vacation time to develop WARPOUT as part of a month-long game jam. This is how things went down- from the game’s inception to its reception at the end of the jam, and maybe a little bit beyond that.

Before you continue, if you haven’t played the game for yourself yet, consider checking out the game’s page here, which includes download links for your OS of choice.

Initial planning

Goals

Let’s start with some goal-setting:

Firstly, I wanted to try something a little more ambitious than my first jam project, Triple the Defence Budget. While TTDB was ultimately very successful in and outside of the PegJam environment (apparently it’s occupied a public setup at a local shop and pretty popular following PegJam 2025, which was surprising to hear about), it was also very, very safe at a conceptual level. When the time came for group matchmaking I already had the design for it nailed down and lot of the boilerplate code written out- all I really needed to do was sell the project’s idea to a couple of prospective group members. While this was demonstrably a winning strategy, I couldn’t help but feel like I’ve significantly undermined the creative process by doing things this way, especially on the part of my colleagues. This time around, I wanted to be more adventurous: this game should be larger in scope, and I should allow the game itself to inform me what needed to be done during development, so to speak.

Secondly, I wanted to have a finished, playable product in time for the in-person showcase event near the end of the month. This shaved my available time down for four weeks to about three weeks. Not much to comment on here; I mean, that’s plenty of time, right?

The origin

I was juggling around a couple of possible game ideas in the weeks leading up to Slow Jam. WARPOUT just so happened to be what I was thinking of when the jam started, and I immediately jumped on the idea. As for exactly how WARPOUT came to occupy my repository of game concepts, I think it’d be interesting to explore some of the context behind it with a (personal) history lesson:

This is Astrofoil (a title that I’ve come to calling the project after the fact- most of these things don’t really have names, or I’ll come up with something silly like spess). At a first glance it seems very similar to WARPOUT (a lot of the assets used in WARPOUT were taken from this game’s project files), but there are significant differences between the two games. Astrofoil could be described as EvE with more ‘pew pew’ and less spreadsheets; the game focused far more on simulating space combat and ship design- as much as you could within a 2D game, anyway. Players would begin the game by customizing their very own ship- choosing a type of hull and then configuring each weapon hardpoint or module slot for that hull.

Each hull had unique properties- for example, some had thrusters that were specialized for forward movement, encouraging the player to steer the ship to move effectively as opposed to simply pushing the analog stick in the desired direction. Others had ‘gimbaled’ weapon hardpoints- any weapon attached to such a hardpoint would automatically rotate towards a player-selected target instead of being fixed to the ship’s current rotation. Every feature like this is governed by a stat, and it’s up to the player to tune their ship’s performance to their liking through their selection of parts.

There were many types of weapons and modules created for the game, including some that were eventually given some form in WARPOUT; the autocannon, flechette guns, and missile launcher should be familiar, but we’ve had more interesting options like space mines (that would slow down enemy ships while also doing damage) or the meme-worthy power lance (a pile bunker-like weapon).

Yes- spaceship melee combat also got its origin in Astrofoil, though this iteration was far more complex. Collision damage was determined by the ship’s velocity; we constantly checked for changes in current velocity against a preset margin (called ‘shock tolerance’ in-game), and dealt damage to the ship if a change in velocity was deemed to be too high, in proportion to how much the margin was exceeded by. So, for example, you’d take a small amount of damage if you gently bumped into an asteroid, but you’d kill yourself if you punched the throttle and collided with it at maximum speed. And of course, you could configure your ship to be more resilient towards collisions- and consequently make it more effective in ramming other ships.

I could write for hours about Astrofoil and all of its systems and quirks- there are a lot to go through- but I’ll spare you the trouble and get to the issues that I wanted to solve in WARPOUT:

• Firstly, the player could never see the action. Everything in Astrofoil is excessively fast- ships, missiles, bullets, what-have-you- and that meant the effective range of any given weapon would far exceed the field of view offered to the player. A lot of time was dedicated into mitigating that issue; implementing a radar, arrows pointing toward potential targets, and a camera zoom feature that technically solved the problem but made everything look microscopic are a few of the solutions I’ve tried. Eliminating this flaw became a hard requirement for Slow Jam; in WARPOUT, the action simply must be on screen and visible to the player.
• Secondly, the complexity of Astrofoil’s stat system made balancing a complete nightmare, among other things. The only way to stay sane while doing so was to balance the game purely on vibes alone. Obviously, we don’t have time for that in a game jam setting, so my second goal was not to go too deep into this aspect of the game and try to streamline things. Whatever upgrade or stat system that gets implemented, if any, should feel meaningful at its most granular scale.

So there’s that.

Theme interpretation

People were surprised to learn that Slow Jam actually had a theme: “Cracked”- smushed in between other event details in the Game Collective’s Discord channel. Adherence to the theme was completely optional, but for me it’s a big part of what makes a jam a jam, rather than just another meetup to prepare a demo for.

Anyway, I adopted a pretty liberal interpretation of “cracked”; I’d describe it as a fast-paced, feel-good vibe in terms of gameplay- and I mean everything should feel good. Weapons should feel punchy and strong, powerups should feel valuable, and enemies should die in a truly flamboyant and satisfying manner. Generally speaking, everything in the game should your brain make happy chemicals.

The “GDD”

Some people would argue that a game design document (or GDD) is absolutely critical to the game development process. While I’m generally receptive to the idea that having one is useful- I’ve definitely said before that 90% of software development is just planning- I feel like a lot of the time what’s considered a ‘formal’ or ‘proper’ GDD is overkill when you’re alone and your design doesn’t have to answer to an entire team of people. If you’re approaching the medium non-professionally and are pursuing a project, don’t let a GDD (or lack thereof) keep you from making the thing you want.

Instead, I have a scattered collection of Obsidian notes that serve as WARPOUT’s foundation- basically just a place to write down all of my thoughts created during the brainstorming process. I spend as much time as I need writing down idea after idea, no matter how silly or practical, and then I move on to development proper once I feel like I have enough material.

Basically, I like to keep things simple. It’s easier to be creative that way.

(Author’s note: I think the initial claim I made for this section is probably outdated information- in fact I think I actually got it from Pirate Software of all people, who strictly enforced a GDD as part of the submission as part of his jam if I recall corfrectly. I was introduced to a more modern (and palatable) approach to documentation recently, which can be found here. None of this stuff made it into WARPOUT though- I just thought it was neat.)

Development

Inspirations

I wanted a simple, straight-forward game loop from the get-go, and looked towards arcade and old Flash games for reference points toward that idea. Boxhead in particular was a fixation of mine at this point, and it shows in the wave-based survival loop that is present in the final game. In short- you kill things, the things drop items, you use the items to kill more things.

You can credit the many survivor-slop games currently out there as anti-inspiration. Despite wanting to streamline a lot of aspects of Astrofoil, I really, really didn’t want to end up with a re-skin of a overly-saturated genre. This is partially why the final game has a unique twin-stick control-scheme and zero roguelite mechanics.

Weapon & Enemy Designs

Weapons were one of the first things I wanted to have down right out of the gate. I decided on having a color-coded ensemble of them as a strict requirement, with unique enemy types to accompany them; this limited the number of weapons I could create to nine, based on the possible hues you could get in the RGB color space:

• White (not technically a hue but it did end up as a weapon, so…)
• Red
• Orange
• Yellow
• Green
• Teal
• Blue
• Purple
• Pink

Coming up with a unique design for each color was a particularly difficult challenge- I actually didn’t know if I could come up with enough to complete the rainbow, so I’m pretty glad I did. Here’s some short thoughts for each of the designs that made it into the final game:

• Autocannon (white): Every shoot-em-up game needs a basic weapon, and this is WARPOUT’s. It fires small bullets in the direction your ship is facing. One mechanic that made it from Astrofoil is projectile inheritance- meaning the velocity of your ship is added to the velocity of each bullet fired. In practical terms this means it’s easier to hit a target when you’re moving toward it.
• Missile Launcher (red): It’s a space game. It needed missiles, especially homing missiles with a lock-on mechanic. The lock-on mechanic itself is pretty basic (target acquisition is basically just a raycast extending from the player’s ship); I wished I came up with a more sophisticated mechanic for this until I realized how fast-paced the final game would become.
• Star Mortar (orange): This came out of a need for a unique enemy rather than a weapon; the Crescent sits off-screen and bombards the player with mortar fire from afar. The version of the weapon provided to the player is much shorter range, but still retains much of its explosive power. To differentiate it from other armor-piercing weapons, it’s been designed to be effective at a certain range away from the player, rather than a simple point-and-shoot affair.
• Flechette Gun (yellow): Speaking of point-and-shoot affairs, this is about as simple of a design as it gets. It’s a space shotgun, damn it! Its iteration in Astrofoil was particulary powerful and satisfying to use, so it simply had to make an appearance in WARPOUT.
• Hornet Launcher (green): A long time ago, Jagex had a space shooter on the now defunct site FunOrb. That space shooter had a weapon called the Helix Cannon, which fired green bullets with a unique sine-wave-like trajectory. The Helix Cannon is a core memory of mine, I can’t explain it any further than that. At this point in development we had a ton of ‘guns’ and ‘cannons’ already, so this was reworked into a homing weapon, similar to the missile launcher.
• Antimatter Field (teal): The only “defensive”-type weapon in the entire game; the Lancer enemy protects itself with it before charging at the player. It was explicitly designed to destroy other bullets- I originally planned a priority system that determined which bullet is destroyed in the event of a collision, but it was far more practical to configure antimatter bullets like enemies with armor and an absurdly high health value. In the end, I wish I designed more weapons like this one.
• Laser Cannon (blue): It’s a laser; you point it at an enemy and it takes damage. It’s the only “hitscan” weapon in the game (it may be more accurate to say it’s a ‘raycast’ weapon). In Astrofoil, making this weapon fair in the hands of the enemy was a Herculean task- more often than not enemy ships could snipe you out of the sky once they had you in your sights, and there was little you could do about it. One of the ways I worked around this is by adding a delay and telegraph to laser shots, but only for lasers originating from enemy ships. This iteration of the laser was the one that made it into WARPOUT.
• Gravity Core (purple): The gravity core was the last weapon to be added, and it was originally planned to be a bomb-like weapon. The problem is that we already had the Repulsor Field, and that already functioned as a screen-clearing bomb. I eventually landed on the melee-like weapon we see in the final game, likening it to a ‘spacey’ version of a chainsaw. This was neat mainly because it didn’t function as a mindless instant enemy-deleter; care had to be taken when approaching enemies with this weapon since they could still shoot back while in the process of being sucked in.
• Repulsor Field (pink): A blatantly overpowered bomb weapon that shoots many armor-piercing bullets in all directions once placed. If you upgraded it, you got more bombs to place per ammo pickup (later iterations would just increase the weapon’s lifetime when upgraded). It’s a godsend for people aiming for high scores, and it’s just plain fun to look at. It was fun to program, too- this was one of the first weapons to be completed during development.

Aesthetics

The game’s title text crawl was inspired from a not-so-obscure SNES title called Hong Kong 97, brought into the public spotlight by the Angry Video Game Nerd, and remembered for using a literal photo of a corpse as an in-game sprite and as a game over screen.

Imagine WARPOUT but vertical, worse in just about every way imaginable, and you killed hordes of communists instead of aliens. That’s Hong Kong 97.

While I wouldn’t consider the game the peak of storytelling, there’s something very powerful its opening being so outwardly and unashamedly vitriolic towards a group of people, starting from its second sentence; you’d think a politically-conscious game developer would want to warm people up to the idea of beating up communists en masse before selling them that fantasy outright, but here HappySoft decides to go off on a roaring start.

I suppose Hong Kong 97 did also inform the general aesthetic of the game- despite being a SNES game, it looked terrible enough that I convinced it was made for the NES (this was something I held onto for months, even while I was drafting this article), so I decided to go for a very simple artstyle for anything that wasn’t ripped from Astrofoil beforehand. This ended up being everything but the background art, which was generated a long time ago using Deep-Fold’s Pixel Space Background Generator.

The game’s general look was mocked up very early on, and has changed very little since then- I tend to do this with every project, since visual aesthetics mean a lot to me. For some reason, greyboxing and programmer art tend to put a damper on my mood. Usually I’d do this in Aseprite, but in the interest of time I did this directly in Godot editor. My mockup would quickly become the game’s main UI scene.

Music & SFX

Similar to visual aesthetics, music and sound design are also a crucial part of the game design process for me. A man by the name of Max0r once said that Project Wingman simply “wouldn’t be good” if it didn’t have its excellent soundtrack composed by Jose Pavli, and I feel like this applies to all kinds of video game projects. If you’re anything like me, the very first thing you remember when thinking about a video game is the sounds it makes- and it’s in this area I feel like where I can make the most impact on the player. I just need to choose the right soundtrack.

If any kind of music could fit the theme of “cracked”, this portion of the BallisticNG soundtrack would probably be it. You’ll be disappointed that despite loving video game music and acknowledging how critical it can be to the experience of playing one, I actually don’t know all that much about music itself- but I do know that Always On Target hits everything that it should. It’s upbeat, has an addicting leading melody, and has just the right level of funk- I’m embarrassed to say that this track was playing on loop all throughout WARPOUT’s development. It’s the foundation that transformed this game into the drug-fueled xenocidal rave party that I originally envisioned.

But I can’t use it since that’d be ethically and legally wrong to do. So let’s get to the next best thing.

The bygone-era of Flash games is remembered for featuring the work ridicuously talented musicians. Here’s a few to jog your memory, and for your amusement:

• Waterflame, whose claim to fame is the song Glorious Morning- which was repeatedly featured in the Age of War series of games;
• David Orr, who composed the soundtrack to Sonny and its sequel;
• Cheshyre, who is responsible for most of the music in Madness Combat (while Madness is not strictly a game series, its music is still really, really good);
• ParagonX9, whose work was just everywhere throughout the era.

Since WARPOUT was primarily inspired by these games, it’s only natural that I turned to the primordial soup that these artists emerged from: Newgrounds. Surprisingly, Newgrounds is still a popular place for people to post their work; and I happened to luck out by discovering an artist by the name of Aszon.

Aszon’s track, Get Moving, You’re on TV! was featured on the site’s front page around the beginning of the month, and I’d have to say it’s a well-deserved accolade. The third chapter of Deltarune made waves when it dropped, and its influence is made particularly clear here- it really does capture that same energy that Toby Fox was channeling at the time. And to top it all off, it was distributed with a Creative Commons license. Needless to say, it was an instant buy (two dollars is straight-up armed robbery for a track like this. I should be in prison right now).

Get Moving, You’re on TV! and other tracks from Aszon would go on to form the musical backbone of WARPOUT. If you enjoyed the game, I strongly urge you to check out his page on Newgrounds for more stuff- the man deserves more recognition for his work.

For sound effects, I decided to try my hand at making my own through sfxr, or more specifically the implementation found at jfxr. It includes options for randomly generating different kinds of common sound effects, but it’s a far more powerful and flexible tool once you’ve spent a minute figuring out how everything works. I’m highly tempted to use it again in future projects.

Early programming

I mentioned before that Triple the Defence Budget was safe and restrictive, and the methodology behind programming the game is primarily the reason why. When the idea for TTDB was pitched to others during team matchmaking, I already had a rough prototype; the architecture of the game’s codebase was more or less set, certain assets were already drawn, and ways for team members to contribute were already paved out in the form of a modular weapons system API. In software development this is ideal- you spend most of your allotted time on planning out the program you want to make, and then you spend the rest trying to stick to that plan.

However, that’s software development. In game development I feel like there’s an important, intangible creative element that’s essential to creating something good, and in that department I really did feel like I robbed that from my fellow team members. In a way, we traded creativity for security and success when game jams are really about collaborating and sharing neat ideas.

I decided that WARPOUT needed to be approached differently, keeping with the spirit of the jam. To that end I played very fast and loose, my general plan being kept to a handful of high-level concepts. For the most part, individual components of the game were built without much regard for the components that would eventually be built on top of them, and I ended up paying the time back when it came time to marry all of those individual components together- this extended far beyond Slow Jam when I introduced patches based on player feedback. Despite this, I considered WARPOUT a success- I ended up finishing the project as designed, with all of my development goals met.

What I’m trying to get at is this: what’s the best way to program a game? Should you take a slower methodical approach with a tight plan, or should you dive head-first into building? In the context of a jam- I don’t really think it matters all that much. The time you save by going in head-first will be paid back when it comes time to integrate everything you’ve built into a cohesive product, in the same way that the extra time you spend planning will be returned to you. Everything balances out.

Control scheme

Early versions of WARPOUT used an Asteroids-like control scheme; that is, you could only steer and accelerate forward or backward. It was soon discovered that the level of movement that enemies demanded from the player would necessitate a more modern control scheme. The one we landed on was closer to the twin-stick shooters of recent years, but with a critical difference: we retained the steering element solely for shooting. This “restricted twin-stick” control scheme was something I was worried about when players got their hands on the game for the first time; the very first person to play was thoroughly confused as to what was going on, but thankfully those cases were few and far between. To add to this, those who were caught off-guard warmed up to the concept after a few games- they said it added to WARPOUT’s charm.

I wish I could say the same for the game’s keyboard layout. Yes, WARPOUT does support keyboard and even has mouse aim support (the ship will steer towards your mouse cursor), but it’s pretty much an afterthought and in my opinion the game is significantly harder and more uncomfortable to play if you chose to use it. Do your hands a favour and play the game on a controller.

Melee combat with spaceships, and other weird things

Melee combat was never supposed to be a part of WARPOUT; this was one of the emergent mechanics that came out while I was reasoning with the game’s physics model and movement. It just so happened to be a lot of fun to bump ships around with the afterburner, and I knew that this weird distraction in development needed to become a central game mechanic. Anyone who’s played the game knows the end result of that train of thought.

What was less apparent was the game’s warp mechanic- arguably, the game’s namesake. It’s a dodging tool, and it does its job well enough, but with the afterburner cementing itself as the strongest weapon in the game by design there wasn’t much appeal to warping anymore. I wouldn’t have an answer to this problem until the first day of Comic-Con, long after Slow Jam had completed.

It started with an innocent misconception with a player: “I’ve been trying to warp into the enemies, but it’s not working.” I had to get him to clarify, but it was clear that his vision of the game I designed was far different from what I actually did make- and that vision was making the warp mechanic a weapon in and of itself: he expected telefragging. I promptly kicked myself for not coming up with the idea sooner, because adding telefragging was probably the most excited I’ve been about WARPOUT’s development in a while, and warping was quickly reworked with telefrags included the very next day.

Another important observation I made while testing had to do with the amount of health afforded to the player: the game’s health bar had a staggering 15 energy points in the earliest development versions- you started with two of them, with upgrades to extend your limit as the game progressed. Those first few minutes of clawing your way up to a “safe” energy pool were always really engaging, but the effect tapered off once your health pool was high enough. The limit was eventually slashed to just five- which seemed to be where the game felt like a constant battle for survival without the player feeling too flimsy. Later on, the Berserker modifier (a temporary effect that doubles the damage given and received) would amplify the high-risk aspect of moment-to-moment gameplay.

Controlled chaos

One more interesting thing I observed had to do with mentally processing the things that were happening on screen. Early on in development, before the more nuanced enemy designs were implemented, the basic enemy types would simply fill the screen with bullets in all directions for the player to avoid. This was the kind of chaos that I had envisioned in my initial plan, but there was a big problem: even though having a lot of enemies and bullets would be a difficult scenario and should encourage the player to “lock in” on paper, I found myself being lulled into this dull, hypnotic trance during testing. I wouldn’t say I was completely bored, but for a project that needed to live up to the theme of “cracked” my engagement level was certainly less than I wanted. This got to the point where I even questioned the viability of the WARPOUT project as a whole, and I stopped working on the game for about a week as a result. My perspective didn’t really change until I started adding the more complex enemy types; the ones that required the use of armor-piercing weapons and had unique attack patterns for the player to address.

I theorized that when confronted with an overwhelming amount of things on-screen, the brain starts to “tune out” and rely on a sort of heuristic or “rule of thumb” to get by. In this case, during the crashout period where I found it difficult to work on the game, that heuristic happened to be “keep moving and fire in the general direction of the enemy”, which is about as interesting of a strategy as it sounds. The game finally became fun when that heuristic was challenged- the different types of enemies, modifiers, and hazards that were introduced were designed to encourage a more thoughtful and precise playstyle, one that forced the brain to actively engage in the current situation in order to succeed. With this, I realized that creating a fast-paced, chaotic experience for the player was far more complicated than I initially expected, and this lesson is probably this project’s biggest takeaway.

Wrapping everything up

The final strides of WARPOUT’s development were dedicated to two things: enemy variety and polish, two things that I concluded were absolutely necessary to truly achieve the title of “cracked”. Additional enemy types curbed the heuristic effect mentioned in the previous section, and those were worked on gradually in the latter half of the jam period, but the bulk of time was spent on polishing the game.

I should elaborate on what “polish” actually meant to me, at least in the context of this project. At this point in development, WARPOUT was mechanically complete- on paper everything in the game more or less worked according to spec, but what was needed was the game to feel good to play; something that was a harder thing to measure by far, and would be something that I would continue to work on weeks after the jam was completed. This emcompassed all areas of the project, from graphics to audio to music.

Triple the Defence Budget- an idle game with one button- was virtually all polish, and the techniques I used to make that game feel good to play would find ample use in WARPOUT as well. I made particular use of environment and canvas modulation to “sell” certain effects; I made the screen flash when you took damage, hit enemies with the afterburner, or grabbed powerups- and explosions were events that briefly changed how the entire environment was lit. Later on, effects like time scaling were applied to make certain attacks feel more impactful.

After the game was polished to my satisfaction, I quickly put together a title screen, intro sequence, and main menu complete with configuration options (powered by Slang) and a neat little highscores screen for people to show off.

Reception

With the (first) version of the game completed, all that was left was to bring it out to the Slow Jam showcase for everyone to see. This was a relatively small in-person event, whicn is great for me because I don’t have much experience showing off anything to anyone beyond showcasing Triple the Defence Budget at PegJam earlier that year. WARPOUT was positively received amongst this group of people, though not without a few things of note:

Firstly, the armor mechanics weren’t clearly communicated. I had tried to implement a basic tutorial in the game’s initial release, but you had to read it, which is a big problem in an action game where many things are demanding your attention. A lot of times I’ve observed players outright ignoring tutorial prompts (you can’t dismiss them, by the way- you have to do the things they’re asking you to do if you want them to go away) and left wondering why their shots weren’t killing enemies, or worse, thinking enemies were a lot tankier than they actually are. It wouldn’t really be until Comic-con when I figured out that having bullets visually reflect off of enemies did a far better job at communicating the mechanic than any text prompt.

Secondly, some people were actually getting a little disoriented while playing. It turned out that players (or maybe just myself, I don’t know- I’m just theorizing) naturally used the positions of enemies relative to their ship in order to determine how they were moving. This isn’t actually a conscious thing they’re doing, but it became apparent when enemies started to move along with the player ship. The asteroid fields in the background were actually designed to combat this effect; they’re backgrounds with a more dramatic parallax effect compared to the main space background, and that seemed to make the issue disappear overnight.

Lastly, some players expressed a desire to have more movement options between the afterburner and warping. This isn’t something I’m opposed to- we have plenty of face buttons left on the controller for them- but I simply haven’t had any ideas that seemed interesting enough to be worth implementing just yet. Maybe sometime in the future.

Closing thoughts

So that’s WARPOUT. I’m not going to lie, this project has lasted far longer than I had initially anticipated- the fact that this blog post took forever to write is most likely a side-effect of that- and I think I’ve got my fill. Version 1.2.0 is probably going to be the final release, at least for the foreseeable future. That’s not to say that the game is perfect; there’s a ton of room for improvement- enough to take up another year of development at least- but I’ve wanted to move on to other projects for a while now (as of right now, I’ve been pushing weekly builds of Song of Eterna for the last little bit). If I were to return to the project, it would be for a sequel- and said sequel would likely be a huge departure from the original game.

Slow Jam was certainly an exciting event to participate in- everyone loves an excuse to take a month off of work- but one of the reasons why I signed up was to see if its extended time window actually relieved the usual time-based anxiety that usually puts me off of game jams. The answer to me is a resounding “eeeehhhh, not really”; projects tend to balloon up to fill up the time allocated to them (at least without tight scope management), and WARPOUT was no exception. The last week of development was the most stressful- making sure progress was being done at an appropriate rate such that the game would be ready to ship come showcase time- and the fact this lasted a week is the critical detail. In PegJam, this phase was limited to the final few hours. If there’s any takeaway I could give you from this experience, it’s that you can’t avoid this situation in any jam, long or short- you just have to jump in and bear with it.

All in all, this chapter of my hobby ends in the best way it possibly could- at a point where I feel comfortable stopping. In a world where a lot of projects tend to fall short of their development goals for a myriad of reasons, I’m kind of thankful that I’m able to be content with this one. My next plans are to work on my “main” RPG project, Song of Eterna, and I’ve also happened to sign up for PegJam later this month. I’m really excited to share my work with you guys in the coming weeks.

Until then, see you next time!

Read more

• Previous post: rensoft.works is officially live!