Game Design | Programming School
Game Design.
Game Programming.
Game School.


MAL: A UAT Game Project Group

Brad Macomber, Justin Pereira, Dan Peschman and Brian Clifton banded together to create a game that morphed from a programming exercise into an full-fledged game. The four amigos presented the MAL game at the most recent UAT Technology Forum, and then agreed to an exclusive interview with UAT 's What's Happening. See the game online on Brian's site.

Did 80s music inspire you with this game?

Brian: Definitely, how could it not? I listen to 80's music everyday. All of it is great, especially "Take on me" by Ahha.

Brad: No comment. Well actually, I stole some inspiration for music from ancient NES games, if that counts.

Justin: Devo for at least eight hours a day.

Dan: For the other guys I'm sure it did, but I was too busy growing in the 80s to stop and listen to music.

What kind of game is it?

Brian: MAL is a 2D platform/arcade style game. It is probably closest in style to Castlevania: Symphony of the Night.

Brad: MAL was originally a group exercise in coding a simple game, which grew into the work of art you now see before you.

Justin: MAL is a 2D platform game on the PC. It’s amazing what kind of games you can produce without having to sell it to anyone

Dan: Castlevania + Metroid + Prince of Persia

Why the name (and the name change?)

Brian: Originally, I offered the name MAL, standing for M(urderers) A(nd) L(ooters). Also, the acronym MAL when said out loud is Spanish for bad, which is cool. Then later we started making up more and more possible names until the rest of the group came up with M(agicians) A(nd) L(ooters).

Brad: After Justin joined the team, the theme of the game started to weed out some of the murderer-type characters and included more magicians. So this is more appropriate considering that the style of gameplay and everything else has been steered likewise.

Justin: We’ve also looked at Magical Adventures in Looting, Meatballs And Lasagna, and Mario And Luigi.

Brad: My favorite is still Midgets and Lemmings.

Dan: I hated trying to explain how to pronounce "MAL," since I wasn't sure myself. (is it "mahl" or "maul"???)

How many levels are there now?

Brian: Well, the whole world is divided into Zones. Each zone is divided into screens. A screen is a unit that is 640x480 pixels in size, which complies to the resolution we chose to use for the game. Right now, I'm pretty sure there is almost 2100 screens in the entire world, and there is probably more to come.

Brad: The game contains a single giant, contiguous level. In the beginning of the game, progression through the game will be directed through a certain route, with "boss" battles being rewarded with more capabilities. The game world is currently larger than 2000 screens.

Justin: About two miles wide and one mile tall. This allows for a lot of permutations in using the different objects in our game, but because of the limited content you’re probably going to decapitate at least a hundred morg minions (the sexless skinny goblin things). Not a really bad thing, now that I think about it. So our biggest challenge has been giving the player new and unique challenges. I think that our choice to make the game really big paid off. Of course, I did make the game world, so it’s hard for me to get bored or lost.

Tell us about the Level Editor ... How did it work for you? The advantages and disadvantes of that? Why did you want to build it yourself? What did you learn from that experience?

Brian: We planned to have a massive game world, bigger than any sidescroller/platform style game out there. In order to do that, the world data needs to be stored and made available to be edited. With such a large world, editing each screen by hand in notepad is not really an option. I started writing the level editor from the ground up in straight C before we really even knew what we wanted, because I knew that it would take a long time to finish it. After we submitted our game to the Independant Games Festival, I started writing version 2.0 of the level editor in C++ based on my original C code. I wanted to build it myself, rather than using VB C# or Java, because I like to code everything myself. When you code everything yourself, there is only the code you need to run the program, and I can optimize the code heavily so that the compiler outputs efficient machine code. I rewrote a ton of controls like buttons, listboxes, the window itself, and more just because my way is more efficient than using Win32 api. Also, another key thing to note is that I could use the same code we used in the MAL engine in my editor to get a 100% WYSIWYG-"what you see is what you get" editor. I wrote the exact same graphic engine code in the editor as I wrote in the full game. I learned a lot about making intuitive interfaces and what end users want to see.

Brad: MAL is too complex a game to not have its own editor. Brian did a nice job of this.

What's the next step to development of the game?

Brian: Well actually, I just had to stop working on MAL. This is my last semester, and I have to get a job.

Brad: I have a huge list of features to implement. After adding a few more fun things, I have to enhance the script system to allow for the route of progression we've planned for the player to beat the game. Further unessential content will probably be postponed indefinitely.

Justin: I’ve been handed the task of refining a lot of the gameplay. I find myself tweaking numbers and tiles constantly now. More tedious than it sounds, but I think it’s more fun than adding the countless hundreds of frames of animation that went into the game. After all that I’m going to add pirate ships and make it 3D.

What do you ultimately plan to do with the game?

Brian: Use it as a portfolio piece, I guess.

Justin: Burn it to a single CD and hide it in the desert.

Dan: If it reaches a certain level of maturity before we all go bonkers and quit, I'd be up for trying to sell it as shareware.

Did you get any feedback about the game from the GDC conference?

Brian: I talked to one or two people who did make it to the top10 that did get a chance to play our game, and they said they really liked it.

Justin: I talked to some people in the student competition. They said they might have played it but didn’t really remember.

You ended up re-doing a lot of the code .. why is that? What is the goal?

Brad: Well, after the August deadline, we rewrote alot of the code in a few areas, and I think we've benefited greatly from this, in terms of making better decisions and being better organized. Incidentally, in case you're an intermediate programmer, I should advise you to not be afraid to rewrite your engine as many times as is necessary to test implementations of different ideas. One of the original Quake programmers reported that they rewrote their engine hundreds of times.

Dan: I think it's a good habit to go back and look for inefficiencies in one's code and try to make it more organized. That way, the next time you are confronted with a similar problem, you'll already know a better way to handle it.

What kind of technologies you used to make the game? (and why XML?)

Brian: The music is stored in ScreamTracker3 and Impulse Tracker audio formats which are loaded and played using a DLL I found from ModPlug Tracker; The graphics are rendered on the screen using OpenGL; The textures are all 32 bit (RGBA) TGA files; I store the textures in a custom ZIP format I wrote using the Zlib 1.14 compression algorithm; The sounds are WAV files which are loaded and played using DirectMusic; The keyboard and USB controller support is through DirectInput; The rest is XML.

Brad: We used Visual C++ .NET and Photoshop. We store most of the game data in XML so that the level editor and the game can be updated individually without getting stuck with binary data that's only compatible with one of the two programs. By forcing each program to parse the data from text (using agreed-upon strings), we don't have to worry about differing enumerations, etc. Also, I can tweak the world in notepad without having to wait for the newest level editor.

Justin: There was a conscious choice to not use 3d tools to create the game. We were very concerned with a consistent artistic style and eventually just the thought of using 3d tools on our 2d game would make me go cross-eyed. Call it a rebellious act from everyone telling me to put 3d characters in the game.

What about the storyline: What is it based on? What inspired you?

Brad: Initially this was a coding exercise; we wouldn't have much of a storyline if Justin hadn't joined the team. Also we watched alot of pirate movies. But that whole Kyrandia thing was a complete coincidence; they stole all our ideas 10 years ago.

Justin: When we added the mechanic of having to find the other characters and have them join you I felt that it was entirely logical to give the players some text to read and hopefully make the game more enjoyable. It’s a pretty messed up storyline but I feel that it captures what we wanted pretty closely. Our inspirations came directly from Harry Potter, Monkey Shine, and Kentucky Fried Movie (which I have never seen but it still managed to inspire me).

Is the game a little bit satirical in spirit? And what are you satirizing, anyway?

Brad: I can only imagine that you're referring to Justin's sense of humor.

Justin: Most our jokes were conceived on Saturday nights following a “wouldn’t it be funny if…” I would only write the script if the time was past four in the morning, which is when I thought everything was funny.

How long has the project taken?

Brian: we've been working on it for just over a year so far

Brad: The project would have been done in 2002 if it wasn't for all that homework...

What do you want to work on to complete it?

Brian: I feel kind of bad, I have to quit working on the project to find a job.

Brad: My to-do list is prioritized so that elements essential to making the game complete come before the extra stuff which I'd "like" to do but don't really need.

Justin: I don’t think I’ll ever be completely content with the level design, but that’s going to be the largest portion of work left for me to do. I’m also going to surprise the rest of the team soon with new monsters that I’ll create just to give them more work to do.

Brad: Really? I like more monsters.

Dan: As for me, I tend to put in elements that I think would be funny or cool even if they are unessential before the more important stuff. This might be because I seem to be the guy where most of the "Hey, it would be cool if..." statements are directed. In terms of what's important for me to finish, I have to create 6 or so more brains for some monsters, fix a few bugs, and tweak the AI for the other enemies so that they work how they are supposed to.

You wrote everything from scratch ... why did you choose to do that? What did you learn from that? If you ever had to do that again, would you do it again? Or do differently?

Brian: I personally write everything from the ground up (in C or C++). I don't use other people's code or libraries unless I know the person who wrote it, know it is very efficient, or I have no other choice.

Brad: We chose this route because we started as a group of coders, and this is the process in which we choose to be knowledgeable. It's good experience to code with other people and compromise to see how the pieces fit together.

Tell us what you learned about game project management ... how did you assign the roles, maintain the discipline and keep a sense of unity?

Brian: I learned a lot. At first, I tried being the "project management" guy and tried to get Brad and Dan to do things my way. That didn't go over so well, but after that, we all figured out our positions. We all pretty much collectively managed our project. I learned a lot.

Brad: We were lucky enough to have alot of dedication from all the members. Each person had an idea of what they were capable of and interested in, and for the most part everyone got a chance to contribute what they wanted. Also we had no designated leader, although I think Justin and I pretended to be leader more times than the others. I think in the future I'll have to be more careful in delegating and accepting responsibility, especially with other schoolwork being in the way.

Justin: Because of the size of the team (4) we had an incredible amount of flexibility, so I don’t think we received a very good impression of the normal game development process. It was nice, though, since we could communicate very easily over design issues and any problems we ran into. With a team so small things either get done or they don’t. If one of us lagged then the project would never have made it this far.

Dan: It was cool how I didn't need to know how the level editor or the physics or the data loading worked. I could write my bit completely independently without having to understand everything that goes on behind the curtains. Creating a flexible system in which we (programmers) could be mostly autonomous allowed us to be much more productive.

Tell us how your project gelled together with the members... how did you meet and agree on a common goal?

Brad: In some areas one person would have a plan which could be implemented without much regard from the others, and we seemed to have a general agreement about what the game would be like, but we also held "debates" to determine as objectively as possible the best decisions for gameplay.

Justin: While I might know something about art, and the rest of the team knows something about coding, we were very new to working on an idea for a game from conception to finish (as a team). It was very haphazard, and sometimes unproductive, but I think we really needed this to better understand the process. We all had very different ideas even though we could agree on the same genre, but I don’t think MAL would have the character it does now without the ideas and innovation of the entire team.

I heard there's some kind of "secret shoe" in the game. Is that just a rumor?

Brian: I don't know what you're talking about.

Brad: Where do they come up with this stuff?