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're proud 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.

But let's go back to the beginning, soon after we decided to work on UQ for DreamBuildPlay. We had the original 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.