Adventure Architect #2: Chivalry is Not Dead, Part 1
My name is Deirdra Kiai, and I am in the process of creating an Underground adventure game.
I am by no means new to amateur adventure game development, having been a part of the scene for about a good eight years now. My previous work includes the silly, pseudo-noir Cubert Badbone, P.I., the ambitious experiment in branching narratives known as The Game That Takes Place on a Cruise Ship, and a short but sweet Flash game by the name of When We Were Kids. I have also had the rare experience of foraying into professional game development, having worked as a programming intern at Telltale Games throughout most of last year. And now, building on all this past experience, I have started a brand new project: a twisted fantasy adventure called Chivalry is Not Dead.
This series of articles will serve as a chronicle of my quest in developing Chivalry, taking you behind the scenes of its design, production, and eventually, testing and release. If you yourself are at all involved or hoping to be involved with amateur adventure development, I hope you'll find something of use in my methods; otherwise, just sit back, relax, and enjoy the show.
Cubert Badbone, P.I.
The Game That Takes Place on a Cruise Ship
When We Were Kids
Now, first things first: before I decide to create a game, I find it absolutely necessary that I know the scope of what is possible for me to achieve in a given period of time. You don't need to look very far on the Internet to find examples of ambitious, epic-length projects-to-be that simply never get finished because the person or team responsible for the project took on much more than it could handle. Admittedly, it may take the development of a prior game or two to fully assess one's capabilities; however, putting at least a bit of thought into the questions of "What can I do?" and "How much time am I willing to spend doing it?" is definitely useful in the long run.
At this time of writing, I happen to be a university student, meaning that I am only able to work on the game in the time I squeeze in between assignments and exams. I'm also a rather impatient type who tends to get sick and tired of working on one thing for far too long; ideally, I would like to complete whatever project I undertake within a few months' time. Given my schedule, a full-length game would be out of the question, as would a series in the currently-popular episodic format. Bearing this in mind, I decided early on that I wanted to create a game of equivalent length to a novella or a short film.
Another thing I find of paramount importance to assess is my skillset: what tools of the trade can I bring to game development, and what, if anything, do I need other people to help me with? I have reasonably strong programming skills, owing to my studies in computer science. Although I'm not a professional artist, I've been a long-time doodler with rudimentary animation experience from a high school art class I took years ago, meaning I can whip up a semi-decent looking cartoon style with relative ease. I'm also not a professional musician; however, I've had enough experience studying music since childhood to be able to compose a catchy tune or two. I've also dabbled in a little bit of acting, meaning that if I were to make my game fully-voiced, I could contribute to a female role or two. Finally, I like to think I can write, with my strengths mainly being in the comedic, satirical sense.
Given this set of skills, it's plausible that I'd be able to do the majority of the game's work on my own, enlisting the help of others when it comes to testing and perhaps voice acting. (I cannot, after all, manage a believable male voice without the help of testosterone injections.) Many would claim that I could significantly cut down on the amount of time and effort needed to produce this game by adding more team members in some of my weaker areas, such as art and animation. Though I wouldn't argue that it would produce a much more polished-looking game -- it does make a difference when you have specialists able to add more detail and nuance to a specific area -- I have worked in enough teams and would-be teams to realise that there's a cost involved in working with others. Constant communication is necessary in order to make sure that all team members deliver their assets in a timely fashion, and that every piece fits with the game designer's creative vision. In the case of many amateur projects where team members reside on opposite sides of the world and have their own hectic personal schedules to deal with, this can be very difficult to coordinate. Considering that I would personally prefer to focus on creative work than deal with scheduling and managing other people, I tend to make it a rule of thumb to keep the teams I work in as small as possible. In this particular case, I will therefore be doing most of the work alone.
Deirdra Kiai on the... uhh... the right!
Be that as it may, I do enjoy employing workarounds to make game production go more quickly and smoothly. One of the ways in which I tend to do so is by using a pre-existing game engine that handles such things as pathfinding, collision detection, and rendering, as well as higher-level adventure game-specific implementations such as inventory and interactive conversations. After all, if something has already done many times before, why bother reinventing the wheel? Fortunately for adventure game developers, many options do exist when going this route, particularly for 2D games. Some engines are more art and GUI-oriented, such as AGS, Lassie, and Visionaire. Others are more scripting-oriented, such as SLUDGE and Wintermute.
Prior to working on this game, I'd had experience in SLUDGE and Lassie, and had subsequently decided that owing to my programmer's background, I preferred working in a predominantly scripting-based environment. SLUDGE, though fully-featured enough to result in complete games, unfortunately hadn't been updated much in the last year, so for a change of pace, I decided to try out Wintermute. Once I did, I found that I liked the engine so much that I wanted to use it for my next project. The documentation was well-detailed, the object-oriented scripting language was familiar and easy for me to learn, and there were many features I found very useful, such as support for images with alpha channels. Hence, my choice was made.
Now that I've made these important decisions for the project, I now have a set of criteria that I can build off of: a game that is reasonably short, predominantly comedic in tone, cartoonish in style, and to be completed mainly on my own using the Wintermute engine. Bearing this in mind, it then becomes time for the next step: figuring out the story and subject matter of the game.