EricBakuti s Level Designer / Scripter

Дата канвертавання19.04.2016
Памер18.29 Kb.

E r i c B a k u t i s

Level Designer / Scripter

6000 Ohio Dr, Apt 1023


Plano, TX 75093

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.

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.

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.

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.

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.

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.


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 of

База данных защищена авторским правом © 2016
звярнуцца да адміністрацыі

    Галоўная старонка