It's been well over a year since I started work on my Dragon Age: Origins mod, Thirst.  Starting out as a very, very different concept - a short dungeon adventure where your character, a lone archeologist, is transformed into a demon and has to consume the souls of others to stay alive - and eventually working its way into a more standard but much more extensive traditional CRPG format, it underwent a huge number of changes.

While it still has yet to be completed, I have released a playable demo of the first several hours, and a clear vision of where things are going to go from here.  Thirst is not my first mod experience ever, but it was a huge learning experience that got me into "real" game development practices by forcing me to learn how to script using C++, how to properly structure narrative over a longer period of time, how to better construct levels to balance gameplay and realism, and how to handle complex interactions between many, many variables.

In this article I'll be discussing a few of the challenges I faced, and how I overcame and learned from them.

Learn the Tools Before-Hand

One of the reasons that Thirst took so long for me to produce, not counting the odd system crash that forced me to restart it from scratch (though few of those original ideas remain in the final mod), was that I was still becoming familiar with the tools for the better part of its development.  The Dragon Age Toolset is a very good piece of software and quite intelligently organized, with different editors based on resource types, but even so, learning how to perform certain actions, do more advanced editing of game files to produce non-standard results, and set up scripts properly to override default behaviour are things that took me a while to come to grips with.

The Dragon Age Toolset is a great piece of software to use, but its learning curve and workflow required months of experience to fully appreciate and learn.

 As a result, Thirst has some sloppy scripting in places.  There are a few quests that I wrote early on where I use more plot variables than what are really necessary to track progress.  One quest, for instance, revolves around getting information from a prisoner, who in turn demands freedom.  The player has many options for this - pay a bribe, pick the lock on the cell, steal the key, kill the guards, and more.  Lots of unique options demand lots of variables, but aside from minor details the outcomes are all relatively the same - the player frees the prisoner or doesn't.  Without a single variable to track whether the prisoner was freed or not, later scripts became overly convoluted as I had to check four or five variables instead of one.  Had I had better foresight, I would have been able to avoid this issue entirely.

Similarly, my workflow in building levels is something I continually improved over the course of the project.  I learned new techniques for visually improving them, such as adding post-processing like bloom and colour grading - but in turn, that also meant I had to go back and tweak dozens of levels' lighting schemes and layouts to make the new and improved effects work properly.  While not exceptionally time-consuming, it was still several days of work that I could have spent otherwise.  I feel the results were worth it and gave Thirst that "professional" look, but by not knowing how to do things before-hand I had to do more iteration than what was necessary.

Put Yourself in the Player's Shoes

When sitting in the creator's chair, oftentimes there are a lot of ideas flying around in my head.  Usually, they're pretty good and appropriate to a given scenario - for example, creating multiple outcomes or solutions to quests and making things interact properly is something that comes easily to me because I've played plenty of other RPGs in my time - but when it comes to actually implementing them, sometimes the end results are different from what players expect.

Sometimes, this can be very simple things.  At the very beginning of Thirst, while exploring a raided caravan, the player comes across a survivor who provides some background exposition, and starts a small quest that gives impetus for the player to explore later down the road.  Sounds good, except when it came time to play-test, a friend of mine who tried the mod out completely missed the character because he mistook him for another dead body, despite being placed right along the critical path.  Solving it was a combination of a few techniques - placing a torch nearby to illuminate the area and highlight it, adding a dialogue pop-up as the player nears ("help me" etc.) - but this lesson made me drastically re-think the placement of certain characters and the layout of later levels.

Early challenges like this one reinforce the value of character development and positive behaviour like exploring the environment and searching for supplies.

Other times, this extends more to options the player has.  Early on, I learned it was important to establish a sort of gameplay contract with the player that expressed what was possible for the player and what wasn't.  In an RPG, especially one with lots of stats, skills and multiple outcomes for every scenario, it can be easy for the player to assume that "everything" is possible - but of course, very real limitations have to be placed on those possibilities in order to keep the game consistent and the story moving forward.

For example, the encounter with the injured NPC mentioned above has about five different possible options (feed him healing plants, give him a health potion, cast a healing spell, use the Survival skill, etc.) - most situations later in the game don't have quite that breadth of options, but I included them to establish a few ideas, such as "hey, you can use certain items in dialogue!" or "your non-combat skills have value!"  A similar challenge later on, breaking through some bars using a variety of means, was another gate intended to teach players that not only do skills matter, but things like race and attributes as well (for example, a high Strength allows players to break their way through, and playing a smaller race like dwarf or elf allows the player to bypass the puzzle entirely).

Telegraph Consequences

Thirst is a mod that features heavy emphasis on choice and consequence.  While it's not quite the multi-faceted, "everything can change" story of a game like Alpha Protocol, many smaller details can influence each other.  For example, helping a character on a side-quest early on may yield an alternate option on a later main quest, allowing the player to bypass a portion of it.  In another instance, a major quest can be entirely skipped if the player is able to defeat a very challenging enemy.  Perhaps most clearly, two of the major quest-lines are mutually exclusive, and have story repercussions both in immediate and long-term ways.

However, one problem with consequence is that players don't like unwelcome surprises.  Defining exactly what is unwelcome is tricky - for example, is getting into a fight with a character over a prior action a reward, or a punishment?  The context of consequence is very, very important to make sure players don't feel like they've been betrayed by the game, or that their decisions didn't pay off.  This isn't to say that bad outcomes aren't possible or warranted - but when they are, players should be given an understanding that what they do will have some sort of ramification later down the road.

Important decisions are telegraphed in advance so that they feel natural and logical.  Smaller ones have less telegraphing, but serve as minor rewards (or failures) for prior actions that help reinforce the continuity of the game world.

That big choice between the two major quest-lines (City Guard and Criminal Underworld), for instance, is something that I couldn't just surprise the player with.  It's a big decision, relatively speaking, and the consequences in both gameplay and story are notable to say the least, shaping the middle portion of the mod.  Therefore, I made sure to properly telegraph the decision by adding dialogue hinting that helping one party would exclude the other.  When players find that their former allies have turned against them, now it makes sense in the context of the world, story and gameplay, rather than coming off as unexpected or arbitrary.  Even if a player feels it's unwelcome, it doesn't feel like a cheap shot.

Of course, big consequences also require the player be prepared for them.  Much like the gameplay contract regarding options available, as mentioned above, a contract around consequences must also be established.  As a result, I made sure to include a number of smaller consequences in the introductory stages of the mod that have clear lineage and dependency.  For example, the way the player deals with a couple of mercenaries in a tavern early on has ramifications later on, when the player runs into them and they either provide information during a quest, or attack the player.  Another such consequence involves helping a merchant slip past a trade embargo - if the player assists him, not only will he appear later on in the city, but he'll offer a new quest and provide information for another unrelated quest.  Yet another early quest has the option of ratting out a corrupt city official, which leads to his assassination, preventing the merchant's second quest mentioned above.  These outcomes aren't always stated clearly in advance, and the consequences aren't necessarily huge, but they are felt and understood all the same, especially as they ramp up in significance over the course of the story.

Don't Build Gameplay Your Tech and Systems Don't Support

I started working with the Dragon Age: Origins mod tools because, at the time, it was one of the few good sets of RPG tools I had access to, and because at the time there was a vibrant mod community for it (unfortunately, not so much today).  My intent was always to build a mod where there were lots of options for the player, with plenty of consequences to boot - however, the limitations of the Dragon Age game mechanics and systems also made themselves apparent when creating Thirst.

One of the biggest problems I had was that stealth and thieving skills are not very well implemented.  This mostly comes down to the fact that Dragon Age: Origins is a game largely centered around dungeon crawling and combat, and those thieving skills are just not especially valuable except for a handful of times.  Although I tried to develop some semblance of stealth gameplay, and I included several quests where the player can pick pockets, open locks and so on to succeed, it always felt half-baked because the core rules themselves were under-developed as well.  Re-engineering the game's character system and rules was something well beyond me, as that in itself would require huge time investments, play-testing, and tons of balancing that would ultimately be better spent on creating new content.

Ultimately, Dragon Age is a game whose mechanics revolve mostly around combat, and I decided to include more combat as the project went on to play to the strengths of the rule set and engine.

 Another problem I struggled with was handling certain quest outcomes.  I would have loved to include more dexterity checks in the game, or stealth checks, even in dialogue, for example, to allow for great moments like Age of Decadence's "throw your crossbow at guard and stab him in the face while he's distracted", but because of the fully 3D, close-up perspective Dragon Age: Origins takes, presenting those sorts of moments would have been a matter of hand-animating them.  Frankly, spending hours or even days keyframing out a short cinematic sequence that only as fraction of players would see was not a good way to spend time.

Even when I did include a few moments, like the player stealing items in dialogue, they didn't really come across that well, because while the mechanics were all there, the presentation I was able to achieve wasn't up to snuff.  The same also applies to voice acting.  Simply put, Thirst has none, but it does have the Dragon Age-style close-up dialogue cameras and character animations, which is arguably a bit jarring.  The fact is that Thirst has thousands of lines of dialogue, and voicing them myself is a near logistic impossibility that would add immensely to development time, not to mention the issue of dealing with a locked-down script (I'm not an amazing dialogue writer and I usually revise things many times over), finding adequate voice actors (I don't think I'd be satisfied with the mixed quality a small non-professional cast could provide, no offense to those who are doing voice-over with their own mods), etc.  None of these would be problems if I had gone with an old-school 2D engine, or even with a game like Neverwinter Nights 2, where text-only dialogue is common.

Closing Thoughts

In short, Thirst was a huge undertaking for me and I'm happy that I've managed to finally release something, even if it still isn't the complete version of the mod.  I learned a lot of lessons over the course of its development, and if there's some consolation in going back to create another 3-5 hours of gameplay and story over the next several months, it's that, now that I am familiar with the tools and know my strengths, weaknesses and limitations, not to mention a more efficient workflow, I can produce work much more quickly.

I'm not a professional developer, but hopefully my experiences have made for an interesting read, whether you're an amateur, modder, industry hopeful, pro, or just a fan.  I'd love to hear any similar experiences anyone else has had with their own work, as well.  Thanks for reading!