EricBakutis
6000 Ohio Dr, Apt 1023
Plano, TX 75093
Level Designer / Scripter
682-551-7760
eric@tebakutis.com
http://www.tebakutis.com/
Creating Monster Arena – A Complex Scripting Project
Figure 1 - The Monster Arena
Monster Arena is a project I completed for my Term 4 Final at the Guildhall. Our
professor gave us a little under a week to develop new gameplay in Doom 3 with a strong
scripting focus. I’d always been fascinated by the fact that monsters in the Doom series
would fight each other, and wondered which would win. Using my knowledge of Radiant
and its scripting language, I created a fiendish amalgamation of Doom 3 and Pokemon.
My Monster Arena map allows players to choose from a roster of monsters to
fight for them, features AI that allows an enemy scientist to choose his own monsters and
send them against the player’s monsters, and includes a detailed and interesting arena in
which players watch the monsters on both sides fight to the death in a no-holds-barred
throwdown. Players and the enemy scientist have a twelve monster roster consisting of
common Doom 3 enemies such as shotgun-toting zombies and sinister Revenants.
In a little under 46 hours, I built, lit, and detailed the monster arena, created the
scripting and GUI system that allows players to choose monsters from a dynamically
updating roster and fight enemy monsters, and created an AI that seems to intelligently
challenge the player’s roster of monsters with its own.
Page 1 of 6
Archvile, I Choose You! (Creating an Intuitive Interface)
The first piece of my Monster Arena map I created was the GUI system which
allows players to choose the monster they’ll send into battle. I had to make this system
flexible enough to allow fun gameplay, while also keeping it simple and intuitive enough
that players could experience my map’s unique gameplay without an instruction manual.
Figure 2 – The GUI System That Allows Players to Choose Their Monster
My approach to the GUI system was fairly simple. I created a basic three screen
layout with the most important button (Start Fight) centered prominently on the highest
console. Because players generally read from left to right, I featured the simple
instructions on the leftmost screen, guessing that most players would look there first.
By playing Doom 3, players learned that you usually click on GUIs to use them,
and I took advantage of this. Because I had a limited amount of GUI real estate, listing all
twelve monsters would have required a tiny font that was difficult to read. Instead, I set
up a simple system where players could toggle through their roster simply by clicking the
right console—each time they clicked, it selected the next monster in their list.
Finally, I needed a clear manner to prevent players from choosing the same
monster twice. To make this simple and intuitive, I set up a scripting system to
dynamically update the GUI roster on the right as player monsters were killed. Once a
player selects a monster, the scripting system removes it from the roster. When the player
clicks the right console to cycle through their remaining monsters, the used monster no
longer appears.
Page 2 of 6
Red vs Blue! (Providing Clear Feedback to the Player)
My next challenge was communicating to players how their team was doing. I
made the player the red team for two reasons—first, because players read from left to
right (I placed the red scoreboard on the left) and second, because the player chooses
their monster first, and red moves first in many other games, such as Checkers. I also
made the player’s console screens red so they would connect that color with their team.
Because both teams use the same monsters, I had to make sure players knew
which team won if their monster faced a similar one (for example, Imp vs Imp). To do
this I put a large scoreboard on the arena roof that updates each time a monster is killed.
The left and right screens track the number of monsters remaining on each team, while
the center screens display clear fight results (such as ‘Blue Wins’, ‘Red Wins’ and so on).
Figure 3 - The Scoreboard Displays a Player Monster Victory
Even if players don’t grasp what team is theirs upon loading the map, the clear
relation of left to right I maintain through their interface communicates this. The monster
the player chooses always emerges from the leftmost door, while the enemy scientist’s
monster emerges from the right. In addition, when the Blue Team loses a monster, I
scripted the enemy scientist to turn around, move to his own console, and choose a new
monster, all where the player can see. By providing players with all this visual input, I
make it clear what team they control and how they can gauge their progress.
Page 3 of 6
Let’s Get It On! (Making the Monsters Fight Each Other)
After I’d designed an intuitive GUI system for the player and a clear way to
communicate to the player how they were doing, I next had to script the meat of my
Monster Arena project. I had to make Doom 3’s monsters actually fight each other.
This proved a far more complex task than it seemed initially. When you spawn a
Doom 3 monster through Radiant script you have the option of giving it an initial
enemy—this allowed me to easily set the player monster’s enemy as ‘Blue Monster’ and
the opposing monster’s enemy as ‘Red Monster’. I named both monsters appropriately
and they happily fought each other. The problem occurred in trying to make the surviving
monster face its new opponent—unfortunately, I could find no method in Doom 3’s
scripting engine to set a new enemy for a monster that had already spawned.
Figure 4 - The Player's Chaingunner Fights the Enemy Scientist's Shotgunner
To get around this, I experimented until I found the most logical solution. After a
monster won, I saved that monster’s type, facing, and remaining health in local variables
I passed to the spawn function. When the player or enemy scientist chose their next
monster and spawned it, I had that spawn function call another function that instantly
deleted the surviving monster, spawned a brand new monster of the same type in its
place, and set the health of the spawned monster to the health of the monster it replaced.
Because I was spawning two new monsters, I could then set them to hate each other
easily and have them engage in a fight without the player ever seeing this sleight of hand.
Page 4 of 6
Prepare for Trouble! (Creating a Believable Opponent)
The final significant challenge I faced was scripting the AI for the enemy
scientist. First, he needed to choose randomly from his twelve monster list. Second, he
needed to choose each monster only once, and understand what monsters he had
remaining. Finally, he needed to appear to be intelligent and logical in his choices.
Figure 5 - The Enemy Scientist Watches his Chainsaw Zombie Fight the Player's Archvile
My first objective was the easiest—having the enemy scientist choose a monster
at random was simple in Radiant scripting. The second objective was my true challenge. I
had to design an AI that would not only choose a monster at random, but not choose the
same monster twice or choose a monster that had already been killed. I tried a number of
ways to do this and finally settled on the easiest—I had the AI behave just like the player.
When it is the AI’s turn to choose a new monster, it clicks its own right GUI a
random number of times. Because I’d already scripted the GUI to remove used monsters
from the roster, this ensured the AI always chose a valid monster. After cycling through
the remaining monsters, the AI starts the fight. With this method I scripted a simple, low
impact AI that appeared to make decisions (and follow rules) just like the player.
Finally, to make the enemy scientist seem intelligent, I scripted him to mimic the
actions of the player. During fights, he stands at his lab window and watches, just like the
player. When his monsters dies, he turns and walks to his console, punches buttons on it,
then returns to the window to watch his new monster strides into the arena. Finally, he
randomly taunts the player with a number of verbal taunts whenever his monster wins.
Page 5 of 6
Other Complex Scripting Projects I’ve Completed
Mjolnir: Hammer of Tempered Elements
I worked on a four person team to create this
2D platformer in two and a half months. I
was the sole programmer on the project.
I coded all games mechanics in Torquescript,
including all player and monster animation,
player movement and collision, the Dash
attack, the element swap system, four types
of enemy AI, the combat system, the health
and life system, the HUD, level checkpoints,
level events, cinematics, and menus.
Insurrection
I worked on a fifteen person team to
create a team-based, objective based
Unreal Tournament 2004 mod during
Term 3 at the Guildhall. I was the Lead
Level Designer and a supporting
programmer.
Because we only had two programmers
on the project, I stepped up to make our
ambitious project a reality. I coded the
prototype for our game in Unrealscript to
prove our game concept to faculty.
In addition, I coded several new abilities for our six different classes (including
invisibility that could be activated with a button press, and powerful jumpjets that
propelled players quickly throughout the map) as well as over fifteen new weapons that
our six new classes used to blow each other apart.
Page 6 of 6