CMPS80k: "The Three Princes" (final project)

30mb zip
other games from this class

I would put up screenshots, but the game doesn't look very good in screenshots. It looks *okay* in motion, and it has pretty good sound. More on that in a bit.

Postmortem: The Three Princes

Intro

Our initial concept for "The Three Princes" was "cartoon adventure," the cartoon part mainly because it let us get away with a simple art style. The "adventure" part we had to waffle about on for quite a while; the game is basically non-violent, since most of the time you're running away from stuff and you don't have any direct means of attack, but otherwise it resembles games like the Zelda series. That wasn't a problem; I had experience doing this type of game, so I knew it was possible. The problem was what came after.

Building a World or building a Story?

After we came up with the most general ideas behind our game, that it was a cartoon adventure, and that it was basically non-violent, we had to delve into details. There were a few other "nos" in there, some of which, like "no boss fights," eroded with the original envisionment when the challenges they presented had to be dealt with; of the three worlds in the game, I can only claim that the first one really does what we wanted, and even then, it has no side-quests, secrets, or easter eggs, making it a fairly barebones environment.

The problem came when we got to storyline. We became overly fixated on the plot of the game, and this led to a cascade of other problems. Spending so much time on the story meant that we had a lot of dialogue, and so one team member became a dialogue writer for the remainder of the project. But we also found that so dialogue cut up into little text boxes became a chore to read. For the intro to the game, we improved the situation by adding some additional scenes to visualize events. For the remainder, we cut what we could, but there wasn't time to do any more. We were chained to the story. And even then, we slowly let the literary elements of the story slip, eventually cutting the climax of the game into a cliffhanger.

Focus on story meant disfocus on gameplay elements. There was no formal design document. We split the three worlds of the game amongst ourselves, and came up with some general overviews, but the actual implementation was all up to me. Nobody else was designing the puzzles, enemy behavior, and order of events, and saying directly, "let's do it exactly like this." So I had the task of implementing some fairly unclear visions, and was for the most part playing "design troubleshooter" the entire way through; the results are predictably uneven. In general I tried to make the puzzles too easy and not too hard, but with little tweak time, there wasn't much I could do about making *good* puzzles, so there are only a few and the reliance was mostly on reusable enemies for challenge, which was also a terrible thing to go in blind on, but I think I managed through it acceptably.

Content

Content was a huge challenge. The dialogue writer did a decent, but not exciting job of telling the story; there are many errors both in the script and my implementation of it, but time was the main issue in fixing it. I did all of the music with Psycle and free VSTs, and I have to say that that was my favorite part of the project. I liked doing it and I liked most of the results. If people come back to this game, it will probably be because of the music.

The main issue was sprites. Our third member, the one that wasn't me and wasn't the dialogue writer, was in theory a sprite artist. He was, unfortunately, more of a "do-nothing artist" and it took some willpower not to blow up in his face. He made content, but not a lot, and most of it was poor. Either he did drawings that showed an obvious lack of effort(the player sprite, which I mentioned in my previous going-crazy-post here, was probably the most egregrious of these), or he found photos and cut and paste or shrank them down - sometimes doing so acceptably, as with most of the phone sprites, but other times resulting in backgrounds that looked "good enough" at first and on each closer inspection became more and more infuriating - one of them even still had the watermark!

So why didn't I come down on him? The problem was that I didn't feel like I was in a position to say "this is total crap, start over" without the support of my other partner, and I didn't get time with him alone and looking closely at the stuff so that he would agree until very near the end of the project. We made our complaints clear the day the project was due, and he claimed to regret being so sloppy after the fact. I guess I can believe him, but whether or not he meant it, what I felt had to be done during development was to make graphics myself -- quickly. I did what I could. It's too bad people tend to judge games by their looks, because this one could really do with an overhaul.

Testing

The morning the game was due, I finally implemented the dialogue, the last area, and some of the last characters. I had time to test and fix bugs from all of these new things once. The results: Poorly formatted dialogue, an "error if you go backwards" bug in the last area, and a character who asks for money, successfully checks for the existence of the money, but does not actually subtract the requested amount. Also, rocks that were meant to shoot up in the air but instead merely blast downwards at high speed. Sigh. I'd fix them, but I'm ready to move on.

Presentation

On the same day the game was due, we got to present it. Half the class(the other half goes Wednesday) got five minutes apiece to present on one of four screens running in the room. So I also got to see the other games. It felt very much like I was at an expo or something as each screen fought for our attention. Most were unexciting; a few were neat. My friend Nick with the neat physics/universe engine had his Ninja Olympics game running. There was a photographer there who shot about a zillion pictures of that. So I asked Nick, "How did your game turn out?" since I remembered noticing that his original concept with multiple gameplay sequences got cut down to just snowboarding as he realized how hard doing gameplay was. My game has snowboarding too, it's just not nearly as cool looking. But from what I saw, even the final result was cut down. The gameplay, in his own words, consisted of "move as slow as you possibly can while doing a zillion tricks in the air." It all made me feel better about my own game.

Anyway, when we went up, we used the computer sitting in the Media Services desk to run the game. This was a mistake; we should have brought along a laptop, as the computer was underpowered for the task. It took something like two minutes to load; once in-game, we were treated to slowdown, and lots of flickering and white areas because there wasn't enough memory in the machine to hold the overworld portion properly. Also, I could barely hear that music I so liked over the din of the class and the other games most of the time, perhaps in part because the speaker system got split amongst the games, but also because I got the impression that the volume on that machine was turned down.

Still, people were reasonably impressed and asked questions about the game. So I guess the presentation went well anyway! (but I doubt the photographer took any pictures of the flickering, white, slowed-down morass)

Summary

The last three-and-a-half weeks were at times painful to live through, but also constituted an extremely informative learning experience, one that bore strong resemblances to anecdotes I've read from inside the industry. I found that I wouldn't have had half as much game to show if it weren't for a weekend deadline extension, because so much content work was crammed into the end. Our decision to build to a story had many consequences, mostly negative for the total game. Skills really make the difference in what you can do - long, hard work is just a consequence of having a lot of skills and little time to use them. And most college students aren't game developers. Overall, I think this game was a success - perhaps not critically or commercially, given that it looks and feels more like an overextended prototype than a shipping release. But the core of what we were going for remains present.

Oh, and we got off to a slightly late start because my teammates, being students first and developers second, didn't want to actually think about the project until a little while before our concept document was due. We could have done something even larger had I convinced them to start some work early on, but I think that might have been a disaster simply because I wouldn't know the challenges ahead.

Here's the thing that's most important: it's a lesson I already knew and know a little better now. You can think you know something, you can "learn" it. Then, later, you get some experience, and you learn it much better and more thoroughly. Still later, you REALLY LEARN IT, PERIOD. I went from "learning" game development to learning game development by doing this project. It was big enough to challenge me properly. Going from learn to LEARN is going to be some years in the making; I know that now. But you always have to be naive first, and gain the real knowledge from the challenges you face.