Ultimate Quest

This article originally appeared in Dev.Mag Issue 27, released in November 2008.

Ultimate Quest is one of two Game.Dev DreamBuildPlay 2008 entries. It is an expansion of a ASCII-styled text adventure that was originally entered into a Game.Dev competition, polished and completed for Microsoft’s annual competition. The following is a discussion by one of the game’s two creators about the process of creating the game.

We’ve come a long way, crafted what is probably the most complete game I’ve ever created in under 3 months, entered it into a huge, global competition, and came away sane and with a product that we’reproud of. Are there better ways to spend sleepless months? Probably, but few of those result in such a sense of accomplishment as seeing groups of strangers, gamers and non-gamers alike, playing your game in the largest expo in the country. And laughing and having fun.

So we’ve achieved what we sought to do, and learnt much in the process of getting here: The value of development tools in larger projects (like our UEditor), the massive benefits of working in a group, quite a few intricacies of puzzle design, and the practice of iterative design. And, of course, the general experience gained from creating an entire Xbox game from scratch.

Ultimate Quest screenshot

But let’s go back to the beginning, soon after we decided to work on UQ for DreamBuildPlay. We had theoriginal game, which we believed was successful enough, and now we had a new challenge of making it work on the Xbox. The largest obvious challenge was the completely different control scheme. We couldn’t use a text parser input or the traditional point and click systems that worked so well for the PC adventure games of old, since both of these would be incredibly awkward on a 360 controller.

We eventually settled for a system not unlike that which was used in the later LucasArts adventures Grim Fandango and Monkey Island, where the avatar’s position is essentially your cursor and the player can only interact with objects in the avatar’s immediate vicinity. In our system, nearby objects were highlighted and placed in a ring around the player for selection by the user. We added an additional twist into the mix by giving the player the ability to highlight all objects on the screen that are interactive, regardless of distance to the player. This essentially removed all artificial ‘pixel-hunting’ challenge that some adventures used to ramp difficulty and required us to adjust our puzzle design accordingly. We couldn’t hide things in obscure places on the screen to make our puzzles harder, so we had to add additional steps and/or complexity to the puzzles in order to achieve the same effect.

As it turned out, however, our puzzles ended up too difficult because of this. With both Azimuth and I being a more veteran adventure gamer crew, the puzzles we did have made the difficulty curve a rather formidable obstacle. One of the largest focus points we have at the moment is to include simpler puzzles at the start of the game so that players aren’t immediately stuck without any idea of what to do. There is little more frustrating for a player than to be overcome by a game’s difficulty right from the start, and this is something we urgently need to address.

The 3D remake is a lie

The 3D remake is a lie

Once we had a control scheme we believed could work, I started on a preliminary version of the game tile engine and what eventually became the UEditor. At the time, it was simply a tile map editor, but I quickly worked on ways to make it easy to use, allowing it to place pretty much anything we needed on the map, including interactive and static world objects. Eventually, it grew into the tool we’d also use to craft and test in-game dialogue as well. The dialogue editor used a flexible and powerful tree-based system, which could also control special game events and access persistent in-game variables and even player inventory items. Essentially, all actual in-game content is created almost exclusively in the editor, which made the entire game extremely modular and easy to extend. Levels, complex merchant dialogue, action responses and more were all crafted from the UEditor and imported directly into the game.

The graphical style of the game underwent some of the most drastic iterations. Initially we settled for an 8-bit pixel-doubled style as something of a homage to old Sierra titles. Difficulties coupled with a few concerns about the general acceptability of something like that led us to a slightly higher fidelity graphical style and then, eventually, to the painted style we finally settled on. The transition between the different iterations took place over quite some time, and the final change was rather a bit too close to deadline for my personal taste. However, seeing the final product look like it does did vindicate the effort.

Once upon a time, UQ was supposed to look like this.

Once upon a time, UQ was supposed to look like this.

All the framework and testing and design considerations took a considerable amount of our 3-month deadline. In fact, it was only when the deadline counter started ticking past 3 weeks did we realise that it was time to create an actual game. By this point, we had a framework for level creation, most of the requisite art assets and the underlying engine that would power everything, but we didn’t actually have any game content or puzzles. The last 2 weeks of the deadline were spent in a frantic rush to make a fairly complete offering for the competition, as well as clearing out all the bugs that reared their heads.

At this point we looked to the original UQ prototype extensively for inspiration on setting and puzzle designs. Many of the puzzles were adapted and extended from the original ones. We lengthened many of the originals, adding extra sub-puzzles and layers of complexity in the mix. The result was a collection of puzzles that were quite devious and very much in the traditional adventure game spirit, with many convoluted solutions that we hope are fun to solve, even if they may be a bit too challenging to stand on their own without some sort of training puzzles for preparation. The game was essentially two meta-puzzles: The first involved getting money for your character to use to purchase goods at the store, and the second was to get membership into the adventurers’ guild. Each of these was achieved by solving a web of smaller puzzles that would eventually lead to the primary solution.

By crunch time, we had completed a game that was quite a bit longer than the original prototype, with a far more flexible dialogue system and engine powering it. There were still bugs to work out and testing to be done, which took up most of the last two or three days (thank the heavens for the deadline extension, both because of this and because of upload difficulties), but the game was in a more complete stage than anything I’d made before, and we were proud to submit it to DreamBuildPlay.

But, as much as I’d like to say the journey is over, we’re now planning to work hard to get this game in a complete, sellable form so that it can be placed on XNA Community Games (which launches near the end of November for all Xbox Live members) as soon as we can. There are quite a few things that need to be done to achieve this: A rework of the initial puzzles and tutorial sections to make the game simpler, rich Marketplace and Live features (like a demo mode and user presence information), and general tweaks to improve playability. We’re confident we have something we can sell and, in fact, hope to use the game and the resultant engine as a stepping stone for future adventure titles on XBLA.

About Claudio de Sa

Code cruncher, word wrangler, gamer and hobby designer, Claudio likes to crush zombies, shoot zombies, slash zombies, and otherwise effect the lamentable lynching of the less-than-living legions. When his time isn't dominated by dealing with the deceased, he'll be experimenting with crazy game ideas, or be otherwise crafting things. [Articles]