Postmortem

This is a postmortem for Sacraments, my entry in the Chloris' Call spring 2004 RPG programming competition, hosted at www.rpgdx.net. For information on the competition, and to see the work of the other entrants, you should visit the competition page.

What went right

When I entered the competition, I decided on the success criteria for this project. Basically, it boiled down to completing the game, and getting at least one good review. As of this writing, I have not opened the game up for reviews yet (as it is still in beta), but I have gotten some positive comments via private message, so it looks like the game is on track to be a success by the initial criteria. Below are some things that helped me achieve my goals for this project:

Daily Work

As a hobbyist developer, I find that the biggest hindrance to completing a project is to simply stop working on it. Once you skip a day or two, it gets harder to sit down and work on it, either because you would have to get in and refamiliarize yourself with your project, or because you stopped working on the project because you've hit one of the less-fun parts. Either way, the longer you don't work on it, the more difficult it becomes to return to it.

Therefore, I decided to spend a little time every day working on it, even if it was only twenty minutes or so. I simply wouldn't go to bed until I had accomplished something in the game. Specifically, I wouldn't set grandiose goals for a particular day which would frustrate me if I was unable to reach that goal for some reason - as long as I achieved something, the day would be considered a success.

This worked very well for me. By not requiring great work every night, I allowed myself to take breaks of sorts from the development, but not complete breaks. I remained in the habit of working on it every night, but it was in such a manner that I didn't burn myself out.

Having a deadline

The other major obstacle to the hobbyist developer is his own ambition, it seems. You have all these great ideas and a compelling vision for the game you want to build. Then you look around and realize that it's only you working on this thing, and that's only in your spare time. You cannot try to make something like Baldur's Gate in your spare time and expect to finish anytime soon.

My weakness has always been writing the engine. I'd write an engine that is super-flexible, has a lot of great features, etc., but it would never be finished.

Having a deadline was the antidote for this. It forces you to make decisions of economy. The engine that sits behind Sacraments is very powerful, but it doesn't have some of the key features I was thinking about originally, such as detailed battle environments, a complex magic system, or even sound. By adopting the deadline of the competition, I forced myself to take a step back and take a hard look at what I was building, and decide what would not make the cut.

In the end, this proved very good, because lo and behold, I finished a game for once!

Focusing on story

The plot for Sacraments is a much-condensed and modified version of a larger, more sweeping story that I had been thinking about for a while. At first, I didn't think it could be shoehorned into a month-long compo project, but the time I spent getting the engine ready allowed me to brainstorm how it might work.

I wrote out a script outline, and wrote short biographies for each character, which I found to help immensely. Although much of the work I did on the story and characters never made it into the game, it really gave me a good foundation for writing the dialogue, which I wanted to feel natural for the characters. That's a difficult goal in most RPG engines, mine included. You don't have nuances of intonation or even gesture most of the time, so you have to communicate everything about your characters through dialogue.

The story ended up driving a lot of the game engine, too. For instance, it's a lot easier to make an RPG where there is only one person walking around, especially for a compo entry. But I really wanted to develop the companion characters, so I bit the bullet and put in the capability to have up to five party members (although you never get five party members in the game).

Cutscene engine

In order to focus on story, I knew I would have to put in a good cutscene engine, so I spent a fair amount of time tweaking and developing that so it could support the story I wanted to tell. Even simple things like adding pauses to the cutscenes adds a lot of emotional impact to the cutscenes, I think, and doesn't require me to fall back on the old "..." my-silence-speaks-volumes trick that you see in many RPG's. (I use it in a few places, but I probably would have used it a lot more otherwise, because I want the player to fill in the emotions themselves, and pregnant pauses gives them the opportunity to do so. Mainly, I use "..." to still have silence, but to really draw the player's attention to a particular person being silent.)

I got the cutscene engine to the point where I could just sit down with a text editor and write the cutscenes out like a script. This worked well, because it was easy enough that I could focus on the creative part of making the cutscenes. There are definitely some things I would change with the syntax, but overall it worked pretty well. Here's a snippet from the introductory cutscene of the game (text trimmed a bit for presentation):

-- Garrick walks up to the Magistrate

Group	Magistrate
	Pose	North
Ungroup

Group	Garrick
	Walk	North
	Walk	North
	Walk	North
	Walk	East
	Walk	East
	Pose	East
Ungroup
	
Talk	Garrick\n\c9999FFYou wanted to see me, sir?	Bottom

Group	Magistrate
	Pose	West
Ungroup

Talk	Magistrate\n\c9999FFAh, good to see you, Garrick!

As you can see, it is very human-readable. With the exception of having to stick in the "\c9999FF" color directives and keep track of where the characters are on the tile grid, it was a very simple process to create a cutscene, much like writing a story.

Doing my own graphics

Now, I'm no graphic designer, but I am pretty satisfied with most of the graphics in the game. There are several particular tiles which I still cringe a bit at when I see them, but all in all, I am pleased with how they turned out, especially when they are all working together.

Another benefit to doing my own graphics is that, well, it was fun! It gave me a break from doing the programming so I wouldn't get burned out on that part.

And pixelling characters is a good time to think about the plot of your story, it turns out. At 32x32, it is difficult to get a lot of character into a humanoid, but you do find yourself making graphical choices based on the personality of the person, which reinforces the story.

About 20% of the graphics in the game predated the competition, and even a lot of that content was heavily tweaked once I got into the competition. The "rain" stipulation in the compo requirements was a challenge with my graphics system, but I think I pulled off a reasonable solution for it.

I used Adobe Photoshop Elements for all the graphics in this game. I am used to using Photoshop at work, so Elements felt a little restrictive at times, but Elements is a solid graphics editor that has the vast majority of the everyday power of Photoshop. It was more than enough for my needs.

Playtesters

I was fortunate enough to have several people playtest the game before the final release date. Warspawn, Chofritz, Mokona, and Gustave provided valuable feedback and testing that caught some bugs that would have been pretty embarassing if they remained in the final version.

Macromedia Director

The genesis of this project for me lies in some tinkerings I was doing a while back with Macromedia Director to see if it was capable of pushing a console-style RPG. Director's imaging Lingo and native scripting language, plus all its other internal features, like its graphics engine, make it a nice rapid-development tool, but I was unsure whether it was really fast enough to build an end product in.

Turns out it is, and Sacraments is the proof. Using Director allowed me to not have to worry much about things like keyboard input, blitting to the screen, media asset organization and retrieval, etc.

Furthermore, it allowed me to develop a cross-platform product. If you're playing Sacraments on a PC, you can thank Macromedia for that, since the game was developed on my Mac laptop. I did not have to do anything to my programming to get it to work on the PC, so I ended up having a very wide delivery target for the game.

What went wrong

Every project has its ups and downs. Here are the things that didn't go so well, or which could have used a little improvement:

No sound

I regret that there is no audio in Sacraments. I am not a composer, so it was somewhat of a no-brainer call, but it still would have been nice to have some music in the game.

I don't think I could have done very good music, so audio was one of the things that got cut to make deadline. I felt I could make the game more compelling by spending the time on things that I am better at (graphics, programming, writing) than the things that I am not so good at (music).

(However, don't discount the possibility of audio showing up in some later, post-compo edition! I will have to add a game option for turning off the music, of course.)

Finalizing the story late

It took me a long time to decide what the story was going to be. As a result, I think I have some things in the game that do not reinforce the primary story of the game. Also, the core plot doesn't get going until after you've cleared at least one mission, which probably could have been better. But that's okay, of course, since RPG's are notorious for side-quests and distracting conversations with people that have nothing to do with the topic at hand. But it would have been better to have spent that time on something that reinforces plot, be it graphics or writing.

Game Balance

Game balance takes a looooong time to test. To do it right, you need to play your game from the beginning whenever you tweak the game settings. For a game that includes many hours of gameplay, that's simply not practical in a time-compressed setting like a competition. (Yeah, we had a month, but I only had a few hours a night to work on it!)

I think the game balance is probably the weakest aspect of the game. Although I've been able to tweak it somewhat, I suspect there will still be some parts of the game that are too easy, and some that are too hard, requiring the player to spend a lot of time doing routine build-up.

I have gotten some useful feedback from the early playtesters, though, and perhaps the revisions I make based on their comments will help.

Macromedia Director

There are some glitches and frustrations with Director, as well. Director is not a traditional programming language - you edit it inside the application, and it bundles everything up into one file. If you lose that one file (say, by accidentally having your map editor write over it, as I did at one point), you're out of luck. (Luckily, I had a backup from a day or so before, but that was still some lost days.)

Director, also, is not as fast as, say, C++. It incurs a lot of overhead from its scripting engine and all its other baggage. It was fast enough for the purpose of this project, but it wouldn't have pushed 350 fps or anything.

Conclusion

All things considered, a lot more things went right than went wrong with this project for me (which is why it saw the light of day). I learned a lot from this project, and I have a great sense of satisfaction with it, almost exclusively because I actually finished a game and released it. I've been trying to do that for quite a while now, but the deadline and the short commitment for the compo allowed me to actually realize it.

Special thanks to everyone who provided playtesting and encouragement!