Double Extraction is a single player mission built using the Call of Duty 4 mod tools.The level where Double Extraction takes place is from the Call of Duty 4 mission Blackout that comes with the Mod Tools.
To make Double Extraction the Blackout mission assets were completely stripped of pre-existing gameplay elements. Many art changes were then made to the Blackout level in order to facilitate the new gameplay. Much of the play area in Double Extraction was not actually traversable in Call of Duty 4. Because of this a significant amount of lighting, geometry editing and prefab staging had to occur. All of this was done with visuals in mind.
All gameplay and cinematics were scripted from scratch using existing Call of Duty assets and script functions for shooting, linking objects, spawning hud elements, pathing AI, etc. In the end this amounted to about 4000 lines of script. All voice over in the mission is self recorded minus the last line from the helicopter pilot.
Double Extraction went through multiple rounds of iteration driven by playtesting. I urge you to play it more than just once. Try obeying orders and try disobeying. Look for alternate paths and even try and break the mission. Much effort was put into making the Double Extraction absolutely solid and at the same time flexible. To give it a try yourself hit up the download links above and follow the readme’s install instructions. Though I recommend playing it first you can see a video of the gameplay in the demo reel section.
After my time on the Marvel Ultimate Alliance 2 DLC packs I worked on an internal prototype using the MUA2 engine. Without being too specific the prototype was based around cooperative play like what is found in MUA but with more meaningful team roles and mechanics. Though I contributed to the overall mission layout and implementation my main role on this prototype was AI scripting. Engineering had just replaced the scripting language and I was the lucky guy to put it through the ringer. And I do mean lucky :-P
New AI Design
Another unique aspect of the prototype not found in MUA2 was the addition of player stances. Player stances could be standing, crouching, prone, crouching in cover, pinned, reviving and so on. According to the design the AI needed to manage themselves in regards to these Player Stances.
Scripted Decisions
For this task I created a simple Finite State Machine to be run on each AI. The FSM used the previously mentioned player stances along with player location and player inflicted damage to dictate what state the AI should be in. Their AI states included but weren’t limited to sliding into cover, traversing, choosing targets, dying and being distracted. Also different from MUA was how targets were chosen. The AI chose which player to target using a scripted system that weighted each player according to a set of stipulations. These checks included, how many AI are already targeting this player, has this player distracted me, is this player in cover or out in the open, is this player reviving another player, and so on. This weighted system allowed the AI to intelligently make decisions while considering not just the player actions but the the states and actions of other active AI as well.
Damage
The last addition for the prototype was a major change in how damage was dealt. The prototype design called for a much more RPG like damage system that factored distance into hit chance along with player stance dependent damage modification. For example a standing player 30 feet away from an AI was to take more damage than a player aiming his gun over a wall 10 feet from the AI. For the implementation of this design the existing MUA AI damage system was turned completely off and all damage dealing was computed and delivered through script.
Double Extraction is a single player mission created for Call of Duty 4. I recommend giving the mission a try before watching the video but if you don’t have Call of Duty 4 this will at least let you see one play through. If you’d like to give the mission a try head over to the Level Design: Single Player FPS page and download it.
Do to some issues with the codec used for the recording of this map the video is not currently online. It is on its way. In the meantime please Give the map a try.
C# has become my programming language of choice for pretty much everything. Recently I’ve done some web scraping, some file parsing, and some generated actionscript classes among other things. Most of these little apps have been quite ugly but the XNA entry below is worth showing.
This is an engine I worked on for XNA. I use engine loosely as it’s not actually done. Even in its unfinished state there are some highlights from the project: a component based Actor System, a component based Engine Layout, a time based Event Manager (that generates no garbage!), a Screen based Game State system and an Input Manager. The zipped up version below is not the most recent version but it is the version right before I had some coworkers start contributing.
Update:Earlier this year an Engineer and I were slated to do some work in Vicarious Vision’s Experimental Games Lab. We were tasked with thinking of and prototyping new game ideas for an assortment of hand-held devices. After some thought we decided to use my XNA game environment. Over a month we made around 5 demos using ExMod and I’m proud to say that moving forward others in the Games Lab are continuing to prototype with the system.
I really feel that my UT2k4 map Snowed In provided a great opportunity for me to demonstrate some of my personal design best practices. I was very careful to go through all of the steps from an initial paper concept to final play testing. The following sections detail both the development of the map and the design decisions that governed the map’s creation.
The paper design is one of the most important parts of the map creation process. Starting with a drawing instead of with actual level geometry allowed me to iterate through my initial design ideas quickly. Yes just starting out building BSP in the editor would have been more fun but it would have been slower and harder to see the big picture. With Snowed In I went through a few different designs before I settled on this layout and the CTF game type. As you can see the initial paper design was simple, but just having it and using it to think about how gameplay and pathing would occur in the map was a big help.
Speaking of pathing, here you can see an image with pathing predictions so that I could further evaluate how player circulation would most likely occur. As you can also see some new passages were added up on the outside as a result of thinking through the expected gameplay.
After the initial layout plans were done the next step was to explore a visual style. I came up with a little background to fuel my visual research. Simply put the level was to be a military training facility. With that in mind I started to look at forts and army bases. This image of a bunker really caught my eye.
Now that I had a layout down on paper and I had a visual style gathered and in mind I started to flesh out the map’s shape and scale. This image shows a very rough version of the front of the base.
As soon as I had my first room built I was in there running around. I’d place a bot in the map that couldn’t move and I’d use him to get a sense of scale. I’d even do timed runs from one flag position to the other to figure out how long different paths were going to take. I knew this step was the most important so I was careful not to get ahead of myself by jumping to visuals and detailing before I was confident in the general layout.
Having confidence in the scale of the map from previous playtests and tweaks I was ready to do a detail test. For this I decided to use the front of the base. Here you can see metal bars in the windows and rain guards over them. As you’ll see later this look just didn’t stick and ended up being nothing more than a stepping stone towards the final visual.
I’ll be honest here, this is something I should have had in my paper map. I had an idea in my head of where certain weapons should be but I never got it down in that initial phase. I was lucky that this didn’t hurt me as bad as it could have. I was able to take the flow of the map and set up some nice gun and item locations.
I totally could have also gotten the bot pathing initial pass done earlier as well but because I had friends at work to play around with I didn’t need it so early. Eventually I realized that this was very important for when I was testing and tweaking at home. Definitely get these guys into your map as soon as possible.
It should probably go without saying that throughout the development of a map you need to be playtesting constantly. This may be with bots or it may be with friends but with each step of the way this has to be the sub step.
This is an image of one of the side paths that was added in the second paper map up above. This was the first playable room that I did a detail pass on. This was used to establish a visual density for the playable areas. By this time I’d decided to have the map during a cold night.
After detailing the playable side path I started to work on detailing out one of the non playable rooms on the inside of the base. Having these areas would make the actually small internals of the base feel more spacious. This also allowed for density without it adversely affecting gameplay.
Once I had the plans for the inside style pretty much nailed down I needed to look at the outside. I still wasn’t happy with the bars and rain guards I had previously. I ended up getting some feedback from fellow designers that said the base didn’t feel heavy. It didn’t feel imposing and protective. I ended up going back to the bunker concepts and using them to reshape the top of the base along with other portions of the outside.
Though polish was the last step it was by far the longest part of the whole process. It literally took hundreds of hours to finish this map. I had to finalize terrain layout, lighting, texturing, item placement, sounds, scripting, zone protaling for performance, blocking for gameplay, etc. It’s by far too much to go over in this break down but I will hit on some of the specific design challenges I faced during the finishing process and how I worked to fix them below.
One issue with any FPS multiplayer is spawn camping. My level was no stranger to this problem. A couple solutions to this are spreading out the spawn points so that they are harder to camp or providing some advantage to the person spawning. For Snowed In I chose option B. I created a safe area for each team to spawn in. I then provided multiple access points for the players to jump down and enter different portions of the playable areas. I also provided them with visibility below and with powerful weapons to collect on spawn. In order to keep the other team out of these areas I created visual shields and a new object called TeamKillPlayerVolume that only killed a specific team.
If one team completely dominates another in a game of Capture the Flag then only one team has fun. You want your games to go back and forth so that each team feels like they have a chance. In an attempt to facilitate this kind of back and forth I created a simple version of the UTJumpPad called TeamUTJumpPad that is team specific. This allowed me to place jump pads at each base that only worked for the team that belonged to that base. This way if you died defending your flag you’d still have a chance to hit a jump pad and catch up to the flag carrier.
Kung Fu Panda level design was a blast. I’m really fond of Metroid Zero Mission for the GBA and to date I’ve got over 90 hours invested in the DS Castlevanias. Having had so much fun with these games I was really excited to get the chance to design and implement this kind of play. Though I bounced around working on many different levels my main area was the Chorh-Gom Prison. This was later on in the game so I was able to make levels that were a bit on the difficult side relative to the rest of the game. The Chorh-Gom Prison also presented an inherent challenge due to it’s abundance of verticality. I was expected to replicate this environment and feeling in my level design.
I can’t say it enough, the paper map is the most important part of the level design process. All seventeen rooms of Chorh-Gom prison were designed out on paper and iterated on, on paper before 3D Studio Max was even opened. I was able to quickly get my ideas down and have them reviewed by other designers.
I didn’t complete all of the maps collision before doing any scripting or gameplay but this is a nice image of all of them complete. Each room’s collision was exported and played in the game before any art was done for it. I really try and avoid causing any rework for an artist. It’s also worth noting that as I created the maps I would work closely with the artist paired with me to make sure what I was doing was going to be okay.
Having already planned out the gameplay on paper, this step just like the collision step actually happened quite fast. I didn’t have to worry about what to do and I didn’t have to worry about how to do it because I’d already thought it through. All I had left was to just do. I’d love to show you the webs of visual scripting lines but the tool is propietary and as a result I don’t feel comfortable showing it. Instead here’s a picture of a Tigress Smash in a Chorgun Level.
I set a goal for myself with this project to create my first ever retail grade Multiplayer FPS map using UT2k4’s Unrealed. I spent the first 3 or 4 months of this goal working on multiple proof of concepts. Some of those concepts were the speed mapping that is mentioned below. The other portion of that initial time with the editor was spent on multiple detail testing maps. This work was to prove to myself that I could do the many things needed to make a map using Unrealed. Once I felt I was ready I began work on Snowed In.
I’m very proud of this map. As I’m not an artist, it was my first attempt at making something that was both functional and pretty. In the end, I think it turned out wonderfully. It’s completely built from brush work and stock map pieces. It also contains some special code objects that I created for it as well as jump pads, lifts, blocking volumes for smooth gameplay, zone portals, antiportals, bot-pathing, terrain, etc. Most importantly, I’m extremely pleased to say that it’s a ton of fun play. I hope you feel the same way. Be sure to check out the Design Breakdown of the map to catch a glimpse of how it came together.
Speed Mapping
As mentioned in the Snowed In blurb above, these speed maps were created during my initial ten weeks of working with Unrealed. They are in no way complete maps but instead represent the equivalent of figure drawing for a traditional artist. Some coworkers and I would regularly set aside one night a week to make a map start to finish. Each time we did this guidelines were provided. These would be things like:jump pads must be used, at least x lights must be present, only weapon a and weapon b can be placed, the end map must have 3 levels of verticality, etc. The general rules that applied to every session were that you had one hour to complete the map start to finish. By the end of the hour your map had to have placed player spawns, weapons, lighting and it had to be playable. The following is the fruit of those sessions.
After doing a quick detail test to learn about lighting, terrain, bsp editing and model placement I created Building Blocks. This map was built with almost no aesthetic consideration. Its main purpose was to help me learn the CoD4 multiplayer map process. In the end I think I hit on everything. The map has a nice circular flow with cover filled lower areas and very porous high grounds. Spawn points are spread along the outside of the map with multiple entry points into the innards of the map to prevent spawn camping. The mini-map is also working along with the helicopter kill streak paths. The only thing I’d say that’s missing (outside of the pretty) is strong consideration for the bullet penetration mechanic. The materials used were chosen more to give the entering players a sense of location and not so much to control where bullets could and could not penetrate. The map was tested and iterated on for about 3 days with groups of 4 to 6 players in free for all and team deathmatch.
Tony Hawk’s Underground 2 for the GBA was my first chance at actually doing some design. I was a co-op at the time and most of my responsibility had more to do with QA than they had to do with actual content creation. On this project I got to break open the tools. Specifically I hooked up levels to be functional, wrote the in game dialog and hooked up terrain based sound for each of the maps. I was so excited at the time to even get to do this little bit.
After THUG2 GBA I was moved to Spiderman 2 PSP. It was much further in development than THUG was when I came on so the options for doing any design were pretty nill. I spent most of my time testing though I did get to gather sounds for the game and I worked with the designers to come up with good challenge times for the simulation missions.
Sk8land was my first project as a full on designer. It was an interesting project due to engineering porting over parts of Tony Hawk to the DS and as a result many things came on late such as new goal types, multiplayer, collision, etc.
Sk8land
On Sk8land I didn’t really get my feet wet, I was pushed into the deep end. Much of my early time was spent designing and testing the tools that would be used to make the game. I also I worked on the design for the park editor, hooked up goals and multiplayer in a couple levels that I owned including Beverly Hills. I also story boarded out the games story for art.
Downhill Jam brought with it a unique challenge. On one hand it was a Tony game, of which it was my third. On the other hand it was a game based around a down hill experience where small short lived jumps were replaced by massive, hang you out to dry leaps of faith. Overall it was a very refreshing experience for me.
Downhill Jam
Edinburgh and Hong Kong were my two levels for Downhill Jam. Each was built completely from scratch for the DS game. I also helped to design out a few new goal types built specifically for the Downhill Jam experience.
The main challenge with the Transformers IP was working with a set of potential main characters that could run, jump, drive, fly and climb there way through the world. This expected traversal really set the initial game play expectations high for this game.
Story and Mission Design
Using experience from Spiderman 3 Console, created a generic mission design template for the scenario team to use. Worked with the narrative team to sculpt 12 missions that both supported the story and incorporated key game play mechanics. To make sure the resulting experiences were polished and the story tied to the current protagonist it was decided early on that each mission would be tied to a specific character.
Mission Scripting
Missions were implemented using an in house C Based Scripting System actually developed at the beginning of this project. Worked closely with engineering to make sure the needed functionality for missions was added for the scenario team. This meant designing systems for AI, entity regulation, encounter creation and abstract goal designs. On top of this, completed the the previously mentioned 12 missions. These missions included multiple Boss Battles, escort missions, messenger missions, defend missions as well as air based and ground based combat. Cut-scenes were also done using the scripting system and animated cameras in max. Also worked in a support role, providing scripting help and disseminating new scripting functionality as it came online.
Level Design and Construction
Created the collision for Hoover Dam using 3D Studio Max. This environment was constructed to support the planned mission designs for both the Autobot and the Decepticon story lines. Worked closely with art team to make sure the created visuals supported the prepared design. This level was unique in that it had both a large exterior and an intricate interior. Because of Hoover’s size and the combination of inside and outside poly reduction was a necessity. Poly reduced this level regularly whenever new art assets came in while making sure that the art and the collision lined up seamlessly.
AI Scripting
Worked closely with engineering to make sure the AI was scripted in a way that was extend-able for designers. All mission AI including Bosses were then able to build off of this AI base while overriding event calls to change existing functionality. Also created setup and play functionality for AI spawning dynamically in free-play (outside of missions).
This was the fourth Tony Hawk game that I worked on. As a result of this and the fact that a good portion of the previous Tony team had returned, the project went quite smoothly. At the same time I think it’s the most polished Tony Hawk that I was a part of. Considering that we made the whole game in around 5 months, start to finish and I consider it a significant accomplishment.
Proving Grounds
My main contribution to Proving Grounds was in the area of level design. This is where my favorite self created Tony level, Museum came to be. About eighty percent of this level was constructed from scratch. The other twenty percent was pulled from a console level. I actually poly reduced anything that was ported from the console and got it ready for art. The level was built with the portaling system in mind, with three main sections all intelligently broken up into pieces. I was careful not to break them up in a way that would break skate flow. On top of level design, construction and critique I worked closely on new single player goal design and new multiplayer mode designs.
Kung Fu Panda brought with it the usual challenge of adapting a brand new license to a game world. Luckily the Kung Fu universe lends itself well to many current gaming norms. The DS also offered the obvious though hard to do well, option for touch screen control. With a limited schedule and limited resources a great game was planned out and executed.
Visual Scripting System Design
At the beginning of this project it was realized that their was an issue with the design staffing and the current tool set. Out of the designers on the project only one was knowledgeable in scripting. This was an issue as the tool set to be used was coming from Transformers and was solely scripting based. Conducted research using other industry tools. Wrote up a system proposal for engineering describing a visual based scripting system where objects could signal other objects according to a well defined and intuitive state change. Some examples: a timer would signal it’s target when it received a signal, a counter would signal at its limit or up until its limit, etc. Every object was to be simple in functionality and all links were to be represented visually in 3D Studio Max. The actual connecting of objects was also done using smart tabs instead of the old text based tag editing of before. The system was a huge success and designers who had been limited previously by their lack of scripting knowledge were given great control in molding their room designs.
Mission and Level Design
Because of the short development cycle controls were not locked down in time for the start of mission design and level creation. As is always the case, art needed content yesterday. Paper designs were completed for 18 missions using the planned game mechanics as a base. These paper plans were for the Chorh-Gom region of the game. These 18 levels were the most puzzle heavy rooms in the title. Their post design construction was able to move quickly because of the well thought out plans created up front. Because of this systematic approach art was not held up.
Level Construction
The paper designs were then modeled up and implemented using 3D Studio max. The Chorh-Gom Prison presented in the film contained large amounts of verticality. This was represented in the game levels with the players fighting downward through vertical arenas and launching upwards using crumbling platform after crumbling platform.
Mission Scripting
Missions were implemented using the in house C Based Scripting System combined with the newly designed Visual Scripting System. This game was the first project to use the new Visual Scripting system mentioned in the first section above.
Boss Design and Scripting
Designed and scripted four major bosses that extended from existing AI functionality. Each boss intentionally highlighted game mechanics previously introduced to the player. Created a fifth unique boss, Tai Lung, who was designed and scripted from the ground up. A state machine was developed within the scripting system for Tai Lung’s many unique behaviors including various traversals, charges and barrel-throwing techniques.
General Support
Worked closely with the rest of the design team implementing any needed script heavy cutscenes. Answered design requests for special scripted entities and general support for mission functionality requiring text script implementation. Worked closely with art and animation building white rooms and hooking up new art assets as soon as they came in.
I wasn’t on Bond for that long. The project I was slated to lead was actually canceled after a couple of months so I switched over to help on Bond DS. I was on for a bout 2 months before transitioning over to Marvel Ultimate Alliance 2.
Quantum of Solace
I created a couple maps for Quantum of Solace. Being familiar with the scripting system that I’d helped design on Transformers and the visual scripting system I’d helped design on Kung Fu Panda I was able to give a good amount of scripting support to the already in place Bond team.
Worked with the creative team to come up with and scope out missions to be done by the scripting team. A general scenario was presented and a large detailed mission design was created from it. The design document included a detailed map, descriptions of special player interactions, needed audio and animation. It also had a very detailed time line outlining the missions planned minute to minute gameplay. This project fell between Downhill Jam and Transformers so time spent working on it was brief.
Marvel Ultimate Alliance 2 was my first experience using the scrum management model. So far I’m pleased with it. I love the daily updates and I was fond of the focused attention that was given (in my case) to each level of the game as it went through each sprint.
Mission Design
Created mission design documents using an existing template. Mission designs were based on small concepts compiled by the Creative Lead and the Narrative Team. Mission designs had to include a detailed level layout, an organized breakdown of the intended gameplay, an asethetic goals outline, a filled asset list and a cutscene outline. All prepped mission designs were promptly put through two vigorous review stages. All review generated feedback had to be addressed in a timely manner so that the mission implementation could be started as soon as possible.
Level Construction
Created level geometry while keeping end visuals in mind. Worked closely with Art to make sure that in game cameras would keep landmarks visible and that end level layouts would be visually pleasing.
Mission Implementation
Missions were brought to fruition over the course of 1.5 sprints or 4.5 weeks. Initially missions had to reach a state of full playable with stubs for things like cutscenes or more complicated AI encounters. After this stage was reached the mission was then taken to an alpha stage of completion. This meant all extra art and animation assets had to be in, cutscenes had to be working and any puzzles or other special functionality had to be present.
Mission Polish
In order to create a unified and polished game experience a full pass was given to each mission. The mission leads would first create a high level pacing map that covered each step in a mission’s progression. This content included encounter feedback, mood and art changes, difficulty adjustments and miscellaneous tweaks. This feedback was based on both the target quality level of the game and feedback collected from external playtest observations. Once this was all boild down into the pacing document the mission designer had everything he or she needed to bring the level to completion.
Specifics
Created multiple script heavy Boss Fights. This included the Protect New York Von Bardas fight, the Prison Transport Goliath and Yellow Jacket fights, the Rebel Hideout Bishop fight and the Chemical Plant Iron Man and Captain America fights. Also worked on multiple non boss focused missions and was a sub mission lead. In the last 6 months of the project, worked hard to polish up much of the game, fulfilling requested changes and bug fixing on the missions owned as well as for the missions of others. Post MUA, worked on the DLC creating the Magneto boss fight and helping with the other accompanying DLC missions.
Overall, Ultimate Alliance 2 provided a great amount of growth. Working with the current generation hardware was extremely liberating. Experiencing a project of this magnitude and still working to have an overall influence on the game as a whole was a rewarding challenge.
One of the scripting languages I use regularly at work is a Propietary C Based System. It’s actually pretty powerful when it comes to designer oriented scripting systems. Some of the features included are: function creation, file including, for and while loops, function pointers, if blocks, standard logical operators and enums. It’s a gimpy C. Because it is proprietary I’m not comfortable showing actual script. Instead, the sections below describe some of my past implementations using the scripting system.
Kung Fu Panda Final Boss Fight
Created the final boss fight for KFP using a finite state machine. This boss was pattern based. Because of this the states weren’t given the knowledge on what state should follow them. Instead each state reported to a transition table that made the decision for the state change. A global state also ran each update to make sure a state interrupting event hadn’t fired that would require a state change. This included certain player hit types, player position changes and boss health changes. Once the boss attack and move functionality had been prototyped the actual state machine was created in a day.
Transformers DS
All of transformers was done using this scripting language. Bosses were done by overriding functions in the AI’s update loop and missions were strung together using registered events including object collection, trigger touches, time waits and logic dependent messages. All of the cutscenes were also done through script.
A few weeks ago I decided to start messing around with UDK again with the new goal of really diving into UnrealScript. After playing some old school Crash Bandicoot I decided that my first UnrealScript project would be a Rail Camera (or spline camera). Though I’m still working on it the camera is in a good enough state to show. Here’s a link to the Source Code. The descriptions below outline the existing features.
The camera dynamically adjusts as the player moves along the spline. Different camera rotation and camera trail distance values are used according to whether the player is moving forward or backward along the spline.
Here’s a shot of the spline camera following the player. This week I plan on uploading a video of this in action.
UT2k4
Snowed In Unique Objects
The two objects below were created in using UT2k4 for my Snowed In map. These are very shallow modifications of existing objects that apply some team checks used to manage default functionality. If you know some UnrealScript you’ll notice that the default properties section is missing from each class. This is because these scripts were embedded in my map which when done prevents you from having a default properties block. Instead you set these in the editor after you add your class.
The title says it all. It’s a jump pad that only works if you are of a specific team. In Snowed In the jump pads at each base only work for that base’s team. This was implemented to foster the tug of war aspect of CTF that could be otherwise limited by the map’s smaller size. If a person from the opposite team tries to use a jump pad, that person is gently pushed off and an error sound is played instead of the usual jump sound. Click on the image to the left to see the full class.
This class was originally inherited from LavaVolume but in the end that brought on more pain then it helped. I ran into all sorts of bugs with bots not being able to path in the volume, to weapons being deleted by the volume. In the end, this much simpler approach worked best. The goal of this custom object is to kill a person, upon entry, if they are of the opposite team. These volumes are placed in the spawn rooms of my Snowed In map just above the forcefields. The goal of these was to make sure no one could get up inside the spawn rooms and spawn camp. You’ll also notice some code in there for handling flag carriers. During play-testing I quickly noticed that with the initial implementation flag carriers could hide safely in their spawn room if they used the air cannon. Now the class checks for a flag on each person that enters and if it finds one, sends that flag home.
This page is a list of past flash applications that I’ve worked on. Each section starts off with a small table providing: links to the actual application, the source (if provided) and the specific areas of improvement that the project dealt with. Following the table, each section then has a short description along with directions if they’re necessary.
State Machines, Actionscript 3.0 New Events System, Sound Management with Flash
I spent way more time on this flash application then I should have but man was it a lot of fun. You may have seen this guy on my homepage. Hopefully you recognize him. The back story of this program starts with me wanting to have an interactive avatar. A couple google searches later I came across the extracted art for the doom head from doom 2. Once I had that there was no turning back.
Overall I’m happy with the implementation of this. If you’re looking at the source code you’ll notice that I used a singleton approach for the state machine setup. This really wasn’t necessary and resulted in way too much code existing in the portrait manager class. I realized at the end that I should have made a base state for the doom head and that I should have let states store their own data. Anyways, there’s some cool little things going on in this so don’t be afraid to click a lot. Also, to really get the doom feel make sure you have your sound on. Enjoy.
Directions:
Click around, click fast, click slow, click in bursts and be patient.
2D Spring, 2D Orbital Rotation, Actionscript 3.0 New Events System, Dynamic Population Algorithm
This project was the result of some mini-game concepts that were being drawn up at work. Afterward this idea just wouldn’t get out of my head. Over the next couple of days I brought the concept to life. In creating this little demo I got to make objects rotate and I got to do some simple spring functionality which I’d never actually gotten the chance to implement before. I also had fun writing the functionality that dynamically populates the sun with planets and the planets with moons as the player progresses through the levels. The dynamic functionality is driven by seeds that specify the number of celestial bodies and their rotation speeds. I’ve provided some directions and the source code below.
Directions:
Click the Sun to pop out the first planets. When you click on a planet you will see that planet’s moons also pop out. Each planet has one moon which is the correct moon. The correct moon will always be unique to all of the moons present on the adjacent planets. To further explain this, if I have planets A, B and C the correct moon on planet B will not be a moon that shows up on A or C. All of the other moons orbiting B will be in common with at least one moon on A or C.
It starts off quite slow so I’ve compiled and linked two versions in the above table. The first is the game as it currently starts. The second is a compiled version that starts out on level 5. This you’ll see has way more moons and planets and they’re moving much faster.
Data File Conversion / Generation, Actionscript 3.0 Syntax
This is an extremely simple application that I did for a friend’s blog. All it does is pull a list of quotes and their speaker from an xml file. It then lets users cycle through them one by one by pressing the button. The original list was pulled from a google spreadsheet using a small c++ program. This tiny app read the data in from an exported CSV file and then spit out the desired xml. These quotes are then organized at random and set up so that the user can cycle through them. I also added some dynamic buttons that pop up if the current quote is too big for the given text box. After finishing this small project I used it as a spring board into the next version of ActionScript by converting it from 2.0 to 3.0.
Interfaces, Assert Class, Packages, Dynamic Visual Content, RSS like xml Poling, Animation Class
This application requires a bit of back story though I’ll do my best to keep it short. At Vicarious a couple of my friends worked on a Rock Paper Scissors application that could be played over instant messenger. It was all done through an aim bot that managed and recorded games. All of this data was instantly sent up to a web page to be displayed. It had general player stats, ranking lists and it even had it’s own achievement system (”just like” xbox live). Anyways, I did not help with this portion of the system. The application linked above is a viewer I developed for these stored games.
The viewer is setup to poll the game.xml file pulling in data as it changes so that games can be watched on the fly. All of the art is pulled in from filenames and references names provided in the art.xml file. This system was created to keep the application design completely up to the artist. As long as they provided the appropriate reference names for the pieces of the UI and for the videos to be played after each throw, they could make it look like whatever they wanted. I’m actually really proud of how this little viewer turned out.
Directions:
Really there’s not much interaction with this application. You should click play and replay. That’s about it. It’s what’s happening under the hood that’s cool.
State Machines, 2D Collision, Asynchronus File Loading, Event System, Inheritance.
Years ago I was playing around with making a side scroller. Specifically I was using the project to see if I could come up with some solutions for side scroller type collision detection on my own. I also used this project to write my first state machine based on the example given in Programming Game AI by Example. The state machine was used to manage the demo’s update loop. On a side note, I really love and recommend this book.
Directions:
When the level loads you’ll probably have to click on the window to give it focus. Once you’ve done that just use the arrow keys to move around and to jump. Lines can be jumped through if you’re jumping with the line’s normal (shown by the perpendicular blue lines). You’ll also notice a few different kinds of boxes showing different collision types. There is a slippery box, a jumper box and some boxes which only have surface collision. Enjoy!
Misc.
The small programs in this section are other little prototypes that I’ve done in the past. These programs are either functionally simple, have a lesser level of polish or they stand on code I’m not particularly proud of. That aside, each has at least a small feature that makes them worth mentioning.
This is a very rough application to demonstrate tile based movement in a top down game. Briefly at work I was under the impression that my next project was going to be a turn based strategy game. I quickly started to do personal research as this genre isn’t one of my favorites. The position changing is instant so don’t expect the character to slide smoothly. Movement cost is represented on each tile by a number. The only real redeeming quality of this program is how it calculates where you can move. Specifically, when you click on the main character the optional movement locations are highlighted using a recursive algorithm.
My girlfriend is artistic and one of her art related interests is My Little Pony customization. One night she had just put the finishing touches on a recent custom and she was wondering the best way to show it off to the community. I presented her with an idea and around 1am I had made what you see to the left.
Yeah I really don’t know what this is. A while back when I had decided to start playing around with Actionscript again I ended up making this as a warm up. The + and - buttons add and subtract balls. By default the balls want to get to the larger Drag Me ball and they don’t like to get close to your mouse. Depending on whether the friendly button is set to true or false they like or do not like each other. You will never see the horrible code that’s underneath as I stopped working on this as fast as I started.
Here’s a list of software I either currently use or that I’ve used in the past. Where necessary entries are paired with a description of what exactly has been my experience with the application.
At Vicarious Visions our primary tool sets rest on top of Max. Specifically our data manipulation occurs in proprietary software while our object placement and level construction is all done using 3D Studio.
Maya is the 3D program that I was taught in college. If I had to transition back it wouldn’t be a problem. I’ve spent enough time in multiple 3D suites that jumping back and forth has become a non issue.
I really enjoy UnrealEd and because of this I regularly find myself jumping back into this suite to both build levels and practice Unrealscript. To see some level design examples head over to the Multiplayer Level Design Section.
I started playing with Radiant way back in high school while messing around in Quake 3. More recently I’ve used this level builder with Call of Duty 4’s mod tools. Check out my multiplayer block out map called Building Blocks and also check out my completed single player mission Double Extraction.
Worldcraft was the second editor I ever used. When Half Life came out I needed to make levels for it so I switched from Qoole to this. My senior project in Highschool was a home in WorldCraft. I also constructed my dorm in college so that it could be played in counter-strike.
You may not know what Qoole is. It was a long time ago that I found and played around with this editor. Though it’s probably not worth mentioning, it at least shows how long I’ve been in love with playing and modifying 3D shooters. When Quake came out I was in Junior High and I needed to make levels for it. When I looked to the community I found Qoole. I had a ball making scenarios for my friends to run through.
Let me start off by saying I’m not an engineer, I am a designer. That said I love to program. When I’m not on a project professionally that requires scripting or some form of coding I spend large amounts of my free time working on personal programming projects. This page lists a number of languages that I’ve spent time with. Sections with projects I’d like to show have links to content pages.
Just recently I started really cranking on UnrealScript and UDK. My first full on UnrealScript project is a spline camera. It’s only been a couple weeks and I already have something I really like. Click the link to check it out!
C# has become my go to language. I’ve made a small in the works game engine called ExMod that is component based and uses XNA. I’ve actually gotten to use ExMod in the Innovation Lab at Vicarious Visions prototyping new ideas. I’ve also been using C# to write little helper programs for web research and for prototyping in Actionscript. I’m really enjoying the language and all the built in features that make it so great.
Most of the personal programming projects that I’ve worked on in the past have been done in Actionscript. The main reason for this is the simplicity that Flash offers when it comes to getting visual content into an application combined with the ease of distribution. As of Actionscript 3.0 the script is a full fledged programming language. It’s completely object oriented with support for inheritance, interfaces, packages, built in event handling and much more. Click the image to the left to browse some of my past Actionscript projects.
Working professionally I do get to do a good amount of scripting. Most of this work takes place in a propietary scripting system modeled heavily from C. Though it has some limitations (not object oriented, no debugger, missing niceties like switch statements) I get to do a lot of cool stuff with it. Much of what I’ve done in this system is detailed out in the experience section but I’ll give a few highlights in sub page to the left.
C++
I learned C++ in college and I made some goofy things using it with SDL and openGL in the past. Overall I don’t write a lot of C++ but interestingly enough I spend a good amount of time reading it. This is because all of the non script functions I use at work are exported to the scripting language from code. This means if something is broken or if I want to know how something works I have to read up on the C++ systems I’m manipulating.
This page is a breakdown of the process used to create my Snowed In UT2k4 map. Though this map was a personal project, the design process used demonstrates well my professional level design work flow.
I’ll admit that Isometric Cooperative Action Role Playing Game is not the best (or shortest) description for the MUA level type. It does however cover in one phrase many of the challenges faced when creating levels for this game. Specifically we had a high downward camera that limited player visibility combined with 4 characters that all ran around firing off powers and engaging in melee combat simultaneously. This had the potential to make the visible play space cloudy and cramped.
Kung Fu Panda was my first experience designing levels for a side scroller and it was a blast. The simplicity of designing levels in 2D allowed for rapid idea development. The gameplay was built on stylist slashing and tapping which provided an interesting layer to the general level design challenge.
Below is a list of the games I’ve had the privilege to work on. Each game is accompanied by a short list of my responsibilities on that project. Click on the title or box art of a game to view a detailed description of my responsibilities on that project. Each category is ordered from most recent to least. Oh and even though it’s linked from the main page, here’s another link to my Resume and LinkedIn.
Responsibilities
Visual Scripting System Design
Mission and Level Design
Level Construction
Mission Scripting
Boss Design
Boss Scripting
Design Scripting Support
Art Asset Implementation
Tool Support
Responsibilities
Story
Cutscene Storyboards
Single and Multiplayer Goal Design
Goal Implementation
Level Design and Construction
Gameplay System Design
My name is Joseph Cecot and I’m a video game designer with a focus in Level Design and Mission Scripting. Though I’ve worked within multiple areas of design including narrative and systems my real passion is in heavily scripted level creation and boss encounters. I am also continuously involved in the guidance of tools and content creation pipelines at a company level. In my spare time I like to prototype different ideas with other development environments such as the Unreal Engines, Radiant based Games, Actionscript and XNA.
JosephCecot.com
This site is my online professional portfolio. Please feel free to use the contact section to get a hold of me with any questions. Enjoy.
