I smell like farts @Holden @Abyss

Hi everyone!

First of all, we want to thank you all the warm responses and great feedback we have received for our game. We can’t help but smile reading each and every one of your comments and it really means the world to us. We have also had a blast playing all of your games as well, everyone has been so creative with this theme and it’s awesome to see such a large and passionate community!

Just in case any of you are curious, we wrote up a summary of our development process and some of the lessons we learned along the way. There were a lot, so this is going to be a pretty long post, feel free to skip to the sections you care about!

Before we dive in, if you haven’t played The Dragon’s Curse, you can check it out here!

Who we are:

We are a team of university students from the United States and Canada who like making and playing games! Our team is composed of:

Aditya: Programmer

Patrick (Abyss): Programmer, Copyeditor

James: Artist

Schuyler (Horus): Writer

Some of our inspirations for The Dragon’s Curse came from FTL and Renowned Explorers.

Looking back

Code:

On the code side, we decided to try the Heaps engine out this time around. We already had decent Haxe experience and Heaps seemed to be a Haxe engine that was widely used in industry. The engine was quite minimal (especially compared to Haxeflixel, which we’ve used in the past). I hear the 3d side is more extensive, but the 2d side pretty much just had functionality for drawing, playing audio, collisions, and resource management. In the case of our simple game, though, this was more than enough and we had a fun time setting up the skeleton of the game. We were even able to set up the level transition logic to persist data in precisely the way we wanted to (not that this would have been particularly difficult in any other engine). One thing we never got around to was setting up proper asset loading, so the game lags and presents a couple unpleasant purple screens at the start. We love trying out new engines so we’ll continue exploring, but our experience with Heaps was pretty positive.

Lesson Learned: “Some assembly required” is not always a bad thing - but be sure to finish assembling your tools before using them

To spare too many of the gory technical details, the game had two main components. A randomly generated map, and dialogue.

The randomly generated map was created by placing points using Poisson disk sampling and drawing roads along the Delaunay triangulation of the resulting point cloud. While this naive method of “place points uniformly and connect all neighboring points” did generate random planar graphs, they were neither interesting, nor was the method reliable. The graphs often looked similar, and the generation was sensitive to changes in parameters

Lesson learned: When random sampling, first constrain your sample space, then come up with a sampling algorithm. Doing it the other way around leads to mediocre results

For the dialogue, we wanted to maintain a separation between content and code. This was both for our own sanity and so Schuyler could write stories without having to dig into the codebase. We decided to consume stories written in a JSON format. We also encoded the consequences of each event in the same document. This allowed us to rapidly iterate on the story in parallel with development. On the flip side, a lot of coding effort was invested in making this system generic enough to allow schuyler to write compelling stories whereas a lot of it could have been inlined if the content was hard coded in. As features got added, we realized we had basically embedded a small DSL in JSON, and that perhaps our time would have been better served bringing in a scripting language like hscript.

Lesson Learned (but we all kinda already knew this): Flexibility and ease of use comes at the cost of up front NRE (non-recurring engineering) expense. Balance them carefully

UI was also a challenge because the map generation parameters were tuned to fill the entire screen. Attempts to scale the map down lead to unpredictable behavior, sometimes the map would only span half of the screen. Eventually though after some fine tuning, we were able to shift the map enough to make space for a UI displaying the player’s resources, relics, and curse progression in a comfortable manner.

Lesson Learned: When building modules from the bottom up, carefully analyze dependencies beforehand to make sure you don’t create conflicts for yourself down the road

Art:

Working on the art was a challenge, as I’m not particularly well-versed in drawing/rendering backgrounds - however, people seemed to enjoy them! I’m glad I managed to keep the style somewhat consistent, as that can be difficult for hand-drawn resources. I still wish I found a way to streamline drawing BGs more - that time could’ve gone to more BGs, character arts, or improving the map - but I guess that will come with practice.

Lesson Learned: Practice drawing BGs

Writing:

Creative process Working with JSON format Writing the scenarios for the story was really fun! I’m not a writer by nature, which didn’t make it that hard to switch to the JSON format my team set up for me. It was really interesting to work inside of the JSON, it felt like designing a choose your own adventure novel on the computer, but wiring up all the dialogue and dialogue options to go to the right spot on very little sleep didn’t go terribly well. Since I’m not really a writer, I spent almost a day reading scenarios from FTL, and RE:IS to figure out how to start writing my own. It ended up being really fun so the biggest thing I want to want to keep doing is writing scenarios for the game. It’s hard not to create the backstories for the companions and I really hope I get to expand upon them concretely. I think in the future the thing I need to work on the most is to keep myself consistent from beginning to end, or have enough time to be able to edit myself, so I don’t have to pull one of the programmers away from programming while I pass out and run out of time.

Lesson Learned: Sleep well and try to keep consistencies. Also writing is kinda fun.

We also put a lot of thought into editing the writing, beyond simply correcting for spelling. This project made me realize how much consistent language matters, as players can get confused who is talking or whether something is spoken or internal. To make these differences clear, I made sure spoken dialogue is in quotes with the speaker made apparent, internalized thoughts in parenthesis, and any game related resource changes in brackets. Some other changes include splitting up longer passages into separate boxes to keep the player engaged as well as making adjustments to character-specific language, such as Geiger’s mannerisms. Time ran a bit short though, and I was only able to edit about half of the scenarios, so you may notice some inconsistencies in the game. We will work on proofing the rest of the scenarios as we continue polishing the game!

Lesson Learned: Make thoughts, dialogue, and action easily distinguishable for text-based games

Thank you again for all your support, and we hope you gained something from reading our postmortem! If you have any questions, don’t be a stranger! Feel free to reach out to us here or in the comment section of our game!