Showing posts with label Game Design. Show all posts
Showing posts with label Game Design. Show all posts

Saturday, September 10, 2011

...I have a new web site

Hey I have a new website, sylvaind.com.  I spent a few days making it in HTML, CSS, with a tiny bit of Javascript.  The new site is mostly focused on my career so I'll keep blogging here for now.  Send me any thoughts!

Wednesday, August 18, 2010

...more press previews about Keyboards

Here's some links to previews about playing real keyboards and training in Rock Band 3:
http://www.joystiq.com/2010/08/17/preview-rock-band-3-keyboard-pro-keys-and-keys-trainer/
http://rockbandaide.com/7443/rock-band-3-keys-preview/?utm_source=rss&utm_medium=rss&utm_campaign=rock-band-3-keys-preview

Read this blog post I wrote up to find out more about Keys and Pro Keys in Rock Band 3:
http://www.rockband.com/zine/rb3-features-pro-keys

Here's a video of Daniel talking keys on Xplay a G4 TV show.  Drake is playing Keys behind him and I'm playing Pro Guitar:
http://g4tv.com/videos/47033/E3-2010-Mad-Catz-Interview/

Thursday, July 29, 2010

...and I took these pics at Comic-con 2010

Was in Sand Diego for less than 48 hours - that's a long way to go!  Next week I'll be doing the same - we're flying to LA, San Francisco, and Minneapolis and then NY for press.

Dean standing in front of our stage.  There were lines all day every day waiting to play!
We started off by playing Everybody Wants to Rule the World in RB3.  Then we showed off a full song in Dance Central.
Half the Crowd...

Drake said something...he talks fast...and well.  Good Job Mr. Drake.

Tuesday, July 27, 2010

...Comic-con MTV games panel video

Here's a short writeup.  Pics coming soon!


Here's the video of the whole thing including us playing Tears For Fears:

Sunday, June 20, 2010

...E3 2010 Pics

Check out our booth before everyone got there:


I managed to get a ton of pics next to the Pro Guitar display:

The Dance Central girls were loving the Beatles setup.  Well one of them looked unhappy until I turned on no-fail:

The Dance Central Area has a really cool setup:


We had 3 Rock Band 3 stages - this was the smallest:


Bryn and I had 1 break the entire time, during which we took this shot:


We spent most of our time in one of the private rooms giving demos and letting people play the Pro Guitars:


Holy crap there was a lot of stuff to tear down:


 And at the end there was a party on the roof of the Standard where we stayed.  My coworkers jumped in the pool and caused mayhem.  I pretty much just went to bed as I was sick all week!


Saturday, May 15, 2010

...the feel of Halo 3 versus Modern Warfare



So I've been playing the Halo: Reach beta lately.  While playing I was reminded me of a conversation I had with a Bungie employee a few months after the release of Modern Warfare.

He asked me what I thought of MW and after a few minutes of discussion I said something like "I feel like I am good when I play Modern Warfare but when I play Halo I often feel like I suck."  He asked why I thought that was and I at the time I didn't have a good answer.  Playing Halo: Reach reminded me of this and got me thinking about this again.  Sorry that this isn't exactly topical but I seem to never let a question go until I have some kind of answer for it :) 


Here are some facets to the games that made MW more of a general positive multiplayer experience to low-level player like me than Halo 3:

The Time it takes to kill enemies

Relative to MW, players in Halo 3 multiplayer can take a lot of damage from weapons before they die.  I am told high-level players really enjoy this aspect as it leads to prolonged encounters.  For low-level players however it often feels like good planning and positioning matter much less than your ability to keep your reticule on an opponent.  I often come up with a good plan that allows me to flank my opponents rear, only to have them turn around and blow me away.  This even happens when I join another teammate who is currently engaged with a high-level player.

Weapon and equipment acquisition

In MW, players choose the weapons and abilities they are going to use before they start the map.  MW players can also change this loadout whenever they die.  Players know what they are going to use while in the level and can change their strategy as they choose.  It is easy to experiment with different weapons and abilities until you find a combination that works for your style.

In Halo 3, weapons are spawned at designer-specified locations on the map at specific intervals.  This style of gameplay skews kills towards players with good map knowledge and familiarity of weapon behaviors.  Learning the ins-and-outs of each map and weapon takes time investment and isn't necessarily transferable between maps.

The player leveling system

Halo 3 has a player skill system that is based on Trueskill.  As you play games and win or lose, your ranking number can increase or decrease depending on the rank of who you are playing and how you do.  There is also playlist specific experience values denoted visually by icons.  The iconography, while a little vague, never goes down in rank.

MW has an experience number for players that only goes up.  The better you do in a session, the faster it grows towards the next number.  Each level brings with it new abilities or weapons that the player can choose to use.  Underneath the hood, MW does have a system for smart matchmaking (Trueskill?) but this number is not outward facing.  As a low-level player, I find this system of only positive rewards much more fulfilling.

Friday, April 02, 2010

...Pax East

Dan, Casey, Brian, Chris and I had a Harmonix designer panel at Pax East. Around 800 people came to see it.

I took this right before we started.

Monday, January 04, 2010

...Bioshock AI Q&A with Dean Tate

Dean Tate is a Senior Designer at Harmonix. Immediately previous to his time here at Harmonix Dean worked on Bioshock and Bioshock 2 - specifically working on AI and level design.  Seeing an opportunity, I decided to have a Q&A with Dean. The questions here primarily focus on Bioshock's AI and their integration Bioshock's levels - I think this aspect was particularly well done in Bioshock. I hope you enjoy peeling back the curtain a bit to see how it was done and what was learned.

Sylvain: How much of the AI in Bioshock is scripted versus autonomous?

Dean: A great deal of our AI was scripted but we worked really hard to somewhat mask that fact. In a lot of games, it can be really obvious when an AI is scripted versus when an AI is systemic. This is something we really wanted to avoid. In a lot of cases, this just meant exercising some restraint; one thing that can make scripted AIs appear to very obviously be scripted is when they display some whacky behaviour that you never see the systemic AIs use. So for example, Splicer AIs in Bioshock take cover, but they don't use cover animations. So we avoided having situations where the player would enter a room and AIs would be scripted to be laying in wait behind cover and then pop out and attack. We wanted consistent behavior between our systemic and scripted AIs.

We also worked really hard to blur the line between 'scripted' and 'systemic'; our AI scripting system, with enough designer crafting and tweaking, could very gracefully handle having an AI that is scripted become systemic without players noticing the transition. It also allowed players to intervene and affect when that transition occurs. Dealing damage to an AI for example to stop it from continuing down it's scripted path. I think everyone on the level scripting teams took great strides to use this ability to great effect and avoid crafting situations that were very obviously scripted. Scenes that occur behind bullet-proof glass, for example.

Sylvain: What kind of high-level (and low level) systems were used for AI thinking? How did you interact with the system (did you manipulate data or edit script logic or just go into code)?

Dean: I didn't touch the low-level code at all, which was all handled by our AI Programming Lead, John Abercrombie. A lot of our AI system was hard coded; things like how our ecology functioned and how AIs viewed each other, AI abilities and weapons functionality and behaviour, etc. Getting those things right was just a process of heavy collaboration and back and forth iteration. At a level above that, I had access to and could tweak all of the numbers that affected discrete AI behaviors. Things like AI movement parameters, attack parameters (how often an AI attacks, how far from the player it tries to remain, under which conditions it will initiate different attack and movement behaviors or weapons, etc). I did all of this by manipulating data in text files. Very high tech stuff (snort). Experimenting with changes to an AIs behaviors was quite a laborious affair that involved (if I remember right):

-Opening the correct text file
-Finding where I wanted to make a change to the text file data, and then saving the file
-Closing the file
-Running our level editor, and opening up one of my AI testing levels
-Tweaking a set of scripts so that they're spawn the correct AI (the one I had changed) when the level ran
-Baking the level content and data changes to a testkit
-Testing my changes to see if the desired effect had been attained, often while making sure a bunch of debug info was being displayed so I could be sure I was seeing the effects of my changes.
-Rinse, repeat

Each of these steps was important. For example, if I made a change to a parameter in the text file and then forgot to save and then close the text file before testing the change, the change would not take effect (I remember this because I made this mistake all the time!).

Things could and would often go wrong, and I'd need to repeat the entire process. I also sometimes ran into what I called "Placebo Parameters": parameters that were supposed to effect AI behaviors, but that in fact hadn't been hooked up yet in code (or, more often, weren't working because of a newly introduced bug). I'd tweak the value over and over again, checking the effect it had on the AI's behavior, stroking my chin and thinking "that didn't seem to make a difference...", tweaking the value some more, working towards getting the desired effect, before finally realizing "Hey! This isn't actually doing anything!" The lesson learned was that when a programmer gives you a new value to tweak, you should first set it to a minimum or maximum value and test it out; then, you can be sure it is doing what it is supposed to do.

And then, at a level above my base behavior editing and tweaking, level designers had some control over AIs through the use of our scripting system. The ability to initiate or cancel specific behaviors, toggle behaviors on and off, give AIs movement and navigation orders, etc.

Sylvain: Wow that's quite a long process for each change! How did you deal with changing an AI's behavior and making sure that it didn't mess up how they worked in all the other areas of the game?

Dean: It was quite a laborious process. When you're making incremental changes to any system, you want to make one change at a time, test it, make another small adjustment, test it again...making large sets of changes all at once makes it much harder to catalogue the effects of each individual change.

Making sure that changes didn't have unexpected knock-on affects was tough. Whenever large sets of changes were made I needed to make sure that our QA and Design teams were well aware of the changes and kept an eye out for abberent behaviors. Designers would focus on making sure any scripted sequences they had already implemented didn't become broken (thankfully, this didn't happen often) and QA would make sure that interactions between our AIs and other game systems (weapons, plasmids, etc) didn't become broken.

Sylvain: What kind of perceptual model did the AI use? What were the main parameters you had control of?

Dean: Wow, I'm remembering some pretty old stuff here. It's been years since the game was released, so I hope this is all accurate. To the best of my knowledge, it is.

The most interesting fact about our perceptual model is that Big Daddies are essentially deaf and blind. They have very little need for any sort of perceptual model up until the point that they have a target to attack. If that target is the player, than they will employ vision if they lose sight of the player; however, their vision is essentially 360 degrees and very long range, so basically if they lose the player they'll try to get within line of sight and then continue to attack. So if you think it's hard to lose a Big Daddy once it has started attacking, now you know you're not just imagining it.

Sylvain: I'm assuming then that they has a simple timeout after which they stop looking for you?

Dean: That's right. If I remember correctly, once a Big Daddy has chosen a target to attack, it won't return to a neutral state until the target is dead (this includes the player). Splicers are different. They will pursue a target they have lost sight of, and eventually lose interest and return to a neutral state. This happens after a timeout period that kicks in once the AI has lost sight of the target and then traveled to the target's last known location (AIs hold absolute knowledge of a target's location for a few seconds after they lose sight of it)

Our splicers used a perceptual model that is extremely similar in design to that used in other Irrational and Looking Glass games such as System Shock 2 and Thief, only tuned differently. Splicers are much more aware in general than their counterparts in those games, and when it comes to vision, hiding in shadows is much less effective for the player (splicers will have a harder time spotting you than when you're out in the open, but not to the degree that they do in, say, in Theif 2).

To go into a little more detail, splicers rely heavily on vision. They have near and far forward facing vision cones that have quite a narrow arc. If the player falls within these cones, it'll take the splicer some time to notice their presence. The amount of time is based on factors such as lighting, as mentioned, and the amount of the player's body that is obscured. The splicer will notice the player more quickly if the player is within their near vision cone, and longer if the player is standing within the far vision cone.

Splicers also have peripheral vision cones. They have peripheral vision in an almost 180 degree forward facing arc. If a splicer sees the player in their periphery, they will exclaim "Hey what's that!" and turn to face the player, putting the player squarely in their forward facing vision, giving them a chance to actually spot the player and then attack, unless the player reacts quickly enough to duck out of view before this happens. This was a tricky thing to balance; we wanted our AIs to be much more aware than in previous games, but still wanted situations to occur where it didn't feel like they were so absolutely aware of the player's presence at all times that there was no middle ground between "neutral" and "attacking" (for example, it didn't feel good to have a splicer immediately attack a player that it had spotted in its periphery).

Splicers also have backwards facing vision cones. If you sneak up behind a splicer, it won't hear you coming; it'll literally see you coming, because it has eyes in the back of it's head. This is spooky as hell and you will now have trouble sleeping tonight.

The tricky task I had in tuning splicer vision cones was in hitting some numbers that worked well in most situations across our game. All of Bioshock's levels are quite different from each other, and there is much environmental variation; large spaces, cramped spaces. Brightly lit caverns and dimly lit closets.

Finally, sound and hearing played a lesser role in splicer perception. Sounds could be tagged as "investigative" and given a radius. If a splicer hears one of these sounds, and it's source is in LOS, they will turn to face it, at which point they're relying on their vision cones to spot a possible target. If they hear one of these sounds and it's source is out of LOS, they will path to its location while always facing the source, and again, vision becomes key.

Sylvain: How did you handle spawning of enemies that wander around the world?

Dean: Bioshock levels are chopped up into regions, each of which has a desired population level that is split along the ecology lines; protectors (Big Daddies) and aggressors (Splicers). That desired population level is in most cases satisfied with scripted spawns or initial spawns when the player first enters the region; the player will enter the region, and it'll then be filled with AIs that spawn at designer-specified points and then do what they're told; either designers tell them to follow some scripted behavior, or the AI will do something systemic. Splicers will patrol (patrol points and paths are designer crafted), Big Daddies will seek out Little Sister vents, and then escort their Little Sister to dead bodies that hold Adam. We called these bodies "booty". Booty can be designer placed, or be dynamically spawned when a splicer dies.

When a region's population drops below the desired level, our population manager takes over. It'll wait a designer-specified amount of time before spawning in new enemies, and it'll spawn them at points which the level designer has specified. These points hold a bunch of variables that designers can change; enemy archetypes spawned, the chance for each type to spawn, and patrol path assignment. The system is actually quite simple, and very similar again to the spawning manager used in System Shock 2. Designers could tune spawning manager variables for each level, and for each region in a level; so there can be regions that have a high respawn rate, or a low respawn rate, differing population levels, etc. We used this to make some areas feel more dangerous or "busy" than others. Because every level designer could tailor-tune the system for their own specific level, we needed to develop some ground rules and best practices to ensure the system was somewhat consistent game-wide.

Sylvain: Did you have any strategies to avoid enemies killing each other when the player wasn't nearby or was this not an issue?

Dean: I'm a little iffy on the exact details of the LOD system we had in place (LOD stands for Level of Detail). I think it was something quite simple: AIs would deactivate their attack behaviors if they fell outside of a certain range of the player. The design also didn't really allow for random battles to break out amongst AIs unless the player was already close-by; in fact I don't think they can break out randomly. This could happen at some point reeeeeally early in development, and it basically created mayhem and chaos and an ecosystem that was impossible for players to understand. They would always end up coming across either battles in progress between Big Daddies and Splicers, or, much worse, rooms full of dead bodies. The former was bad because it made it very difficult to telegraph to players that Big Daddies only attack when provoked (which had been something quite unheard of in this genre), and the latter was worse because it made encounter pacing an impossible task for designers.

Sylvain: Finally, how did the AI evolve through the project and what lessons did you learn?

Dean: Our AIs evolved massively over the course of the project, though the basic archetypal foundation of each individual AI remained intact almost from day one; the grenadier (Nitro Splicer), assassin (Houdini Splicer), ranged aggressor (SMG Splicer, Pistol Splicer), melee aggressor (Melee Thug), the gatherer (Little Sister), the protectors (Big Daddies); we settled on the behavioral basics of each of these guys very early on, and then over the course of the project iterated on the details of their behaviors massively.

The Big Daddies are a good example of this. Early on, we intended to make these guys hulking, lumbering masses of muscle and power, and we stuck to this goal quite literally for a very long time. Their movements were very slowly, they had delayed reactions, were easily outran, their attacks were hugely damaging but had a long windup period, etc. As the game evolved from a slow-paced stat driven fps/RPG (that's rpg IN ALL CAPS!...fps in low caps...) into Shooter 2.0 I pushed to make our Big Daddies much more agile and reactive once they had become aggressive. I wanted there to be a clear difference between "neutral and mellow" and "angray!". I really enjoyed seeing player reactions to the huge behavioral switch that came when a Big Daddy decided that it needed to defend its Little Sister. "OH GOD, I THOUGHT THEY WERE SLOW!" players would scream, as a Bouncer smashed into their face with the speed of a freight-train, or a Rosie became impossible to outrun.

Another example of design aimed at "sticking to your base and iterating on the details" is the grenadier (AKA the Nitro Splicer); we knew early on that we wanted an AI that threw explosive projectiles. That was the basic design (and totally original, right guys?). As time went on, we layered more interesting behaviors and system interactions on top of this design base to make this AI more interesting; the grenadier gained the ability to throw Molotovs, to drop smoke grenades like chaff when retreating, and let loose a devastating kamikaze attack. Players could also catch their grenades by using the telekinesis plasmid.

Starting with a simple yet strong design base was I think in the end a very smart move (I'm not taking credit either; I very much worked on the details of each AI, but came into the project once they already had a strong base laid out). Though the basic design for each AI archetype wasn't exactly imaginative or completely original, we managed to create something fresh with each archetype by living in the details. This meant little wasted work. In fact, we shipped with almost every AI archetype that was originally conceived and designed, bar one Big Daddy archetype that made it very far into production before being cut; though you may see him re-appear sometime in the future, *wink*.

I'd like to point out one interesting thing that came out of the design process; these days, a lot of good AI design is focused on ensuring that AI states and behavioral intent is fed back to the player clearly, usually through the use of VO. Basically, AIs will scream out to the player what it is they intend to do. "I'm hiding!" or "Here comes a grenade!" or "Take cover!" or "Flank him!" or whatever. Our AI VO writer (and Audio Director) (and fellow Australian) (and my best mate!) Emily Ridgway pushed against this idea from very early on. She made the stylistic and creative choice to use our AI VO to help sell the idea that each splicer is a twisted, ruined husk of a person. A lost mind overtaken by dementia, paranoia and confusion. They're not battle-hardened soldiers employing military tactics against the player; they're lost and scared and want you to go away. And so, when writing lines for our splicers, she made the conscious decision not to have them clearly state their behavioral intentions. This was met with quite a bit of resistance, which I'm glad wasn't successful. I'm quite happy with the idea that in Bioshock, you never quite know what a splicer is thinking or planning...

I feel like I should end my response to this question with one big overarching "lesson-learned".

Let me think...

I know!

If you're going to end your game with a fight against a giant naked bronze man, you better really mean it.

Saturday, June 20, 2009

...Harmonix Designer Emails (#2)

Dan Teasdale

Welcome to the designer email thread, Mr. Brian Chan! In honor of him joining the thread, I have a topic that he might have some idea on how to solve:

Item Hoarding


As a collector, I find myself hoarding powerful weapons and never using them "in case I need them later". I did it with airstrikes in Mercs 2, I did it with nukes in Fallout, and there's probably a bunch of games that I've repressed doing it in.


Is this good? Is this bad? How do you think designers can solve this, or at the very least balance a game where people won't use the most powerful weapons?



Brian Chan

Thanks, everyone, for presenting me with such a warm welcome. I'm looking forward to learning a great deal from all of you. And thanks, Dan, for asking me something I can actually answer (I'm still in that muddle of new terminology and culture shock that comes with switching workplaces [and cities]).


When a player finishes a game with "leftover" items, it can be either a positive or negative indication. On the positive side, the leftover items suggest that the game presents choices, with the items representing the path not taken. If players vary as to their leftover items, even better-the game presents meaningful choices and allows for alternate solutions. On the negative side, leftover items might signify poor communication to player of item utility or scarcity. That is, the player might not have used the item because he or she didn't understand its value or how common or rare it was.

The problem is summarized by the notion that, if players cannot experiment, then they cannot plan. By providing safety nets for experimentation (and failure), designers can discourage item hoarding.


I like when a game provides the player with some sort of consequence- free sandbox in which to "try before you buy." Often, games do this via gated tutorials. In a game where balancing is achieved via scarcity or resource cost, it's nice to give the player "freebies" so as to whet their appetite. And, if an item is a higher- magnitude version of another item the player is already familiar with, then this fact should be made abundantly clear to the player.

A few games solve the scarcity problem without sacrificing balancing- by basing the economics on (easily) renewable resources. In Bioshock, I don't mind testing out new plasmids because EVE is relatively plentiful. In World of Warcraft, all resources can be translated into time, which is a resource that the game's players don't seem to mind spending prodigiously.



Chris Foster

I thought I came to Harmonix after past jobs strategy games and MMO's so that I didn't HAVE to think about balancing uber items of destruction!

I can think of a few tools to balance hoarding versus wanton nuke-spamming: consequences, limitations and scarcity.

Consequences are ways to say that using a superweapon isn't all wonderfulness and smiting, but that there are potentially painful tradeoffs at work. If a super item is going to create lasting negative faction somewhere in your game, or hurt your character/base while crippling someone else's, then you can make people think more strategically about its use.

Limitations are ways to make sure a superweapon isn't always useful in every situation. I think there are a bunch of limitations that aren't appropriate here, since if a weapon is too limited, it's by definition NOT super. I'd be more interested in limits that make the weapon harder to use but no less potent, such as a missile that is slow moving and therefore somewhat easier to avoid, or a weapon that requires prolonged manual control to hit its target in the most destructive manner possible.

Scarcity is a double-edged sword, as Brian called out. Having plentiful resources in your game, but a significant cost for the best weapons, can be a pretty potent balancing factor. You can see this in everything from Civilization to Death Tank. (And if you haven't played Death Tank multiplayer, stop reading this and play it now.)



Dan Teasdale

I'm going to channel a conversation Sylvain and I had after I sent the email, and in turn steal his thunder. Hopefully I'll misrepresent it and he can come in and make it sound more awesome.

So, the biggest problem I have isn't on the spamming end - making something less appealing to use is kinda easy. My problem is when things are so powerful in a way that's not a direct tie to my standard weapons, with the direct example being airstrikes in Mercs. I'll swap my normal weapons up to the most powerful instantly, but I'll hardly ever launch airstrikes unless:
* I've cornered myself in a save and have nothing else to use
* The game forces me as part of a mission objective

Sylvain then brought up Halo, which solves this problem so elegantly that I didn't even realise they'd solved it. Essentially, restricting you to two weapons means you can never hoard a weapon. If you get a superweapon, your incentive to use it is that you'll be able to pick up another weapon soon, so you'll happily spend the small amount of resources.

Thinking forward to Fallout 3, they end up in this weird mushy area. You have your inventory, and when it's full you'll start burning through some of the cooler things in order to make room for other cool things. The problem with that though is that there's still enough room to carry lots of weapons, so the "superweapons" you're burning are things like medical supplies and stimulants.

(As a side note: It's unnerving how many pacing and design problems Halo solved compared to how revolutionary people think of it as being - especially so considering how much designers didn't enjoy it past the first few levels (myself included). Say what you want about the level design issues in the second half or the cookie-cutter narrative, but things like balancing health for encounters rather than levels, or getting players to experience more cool things by reducing their amount of choice, these things have ended up changing how people balance all types of games.

Funnily enough, designers never give Bungie never credit for it because of the other issues in the game. At the same time, Half-Life did the exact same thing but flipped (standard mechanics, amazing narrative innovations) but it's the game that people reference in terms of the turning point of FPSes. For mechanics designers, it's mildly depressing food for thought :) )


Chris Foster

While waiting for Sylvain to take back what's rightfully his, I'll chime in with this observation.

Your Halo anecdotes remind me that good game mechanics are really like good film editing. When I studied film in college, one thing that was hammered into me is that bad editing -- like an jump-cut, or someone facing left talking across the room to someone who's supposed to be looking at them but is ALSO facing left -- immediately draws attention to itself. However, good editing is invisible editing; it works so well that no one realizes it's working, and all of its subtle emotional and psychological manipulations occur while no one is looking.

When a game mechanic does exactly what is necessary to produce fun, then it's likely that no one will notice that the mechanics are even there; they're too busy having fun. And while that can be a little tough on the designer's ego, remember that the flipside is someone calling you out for your BAD design decisions. I'll call it a fair trade.


Sylvain Dubrofsky

Thanks Dan! I realize at this late hour that the deadline for this email is tomorrow and you typed up a lot of stuff I immediately thought of from my own gaming experience so I won't have to lose too much sleep :)

I remember finishing Half-life 1 having used primarily pistol and crowbar throughout the game. I had all this ammo left over for all these cool weapons that I barely used. The same thing happened with RE 4. I must have had 30 grenades when I finished that game!

Halo had a nice natural solution for the problem. As an aside I am a fan of the series (especially Halo 1 and 3) and think the innovations the game generated are often overlooked - primarily: checkpoint saves, dedicated melee and grenade buttons, 2 weapon slots, dual wielding, regenerative health and the FPS-style driving controls.

I agree with the Brian in the previous email that I prefer getting each new weapon (or any item really) in an environment where I can freely experiment with it - AND that fact is made clear to me. Also agree with Chris that Death Tank rules :) I find if I get too many weapons in Death Tank I get overwhelmed so I tend to only concentrate on 3 or 4 powers at a time.

The biggest improvement in this area was a personal change. I've changed my tune since I was younger and started "trusting" developers more. By this I mean that I will now use my best/funnest weapons first and trust I will continue to get ammo drops such that I won't be stuck with just my pistol and melee weapon. This trust worked very well in Half-life 2 - they had very well paced ammo caches and the tension of getting low with my best weapons had a nice release when I found the next cache of ammo.

Wednesday, May 27, 2009

Saturday, February 23, 2008

...some quick things we're learning making the TF2 map

1. Make sure your spawn rooms are perpendicular to - not part of - the main path.
- It seems obvious, but we missed this for awhile. It's not a great experience when the flag holder can run through the safety of the spawn room to easily get to the capture point without people being able to chase him.

2. Keep engineer sentry range in mind for all major meeting points and defensive points.
- The should be a generous amount of good sentry spots in the map. For players, taking the time to setup a sentry and then have it destroyed by people simply shooting out of it's range gets frustrating. We made a prefab of this distance to move around the map as needed.

3. Large wide-open areas tend to be lacking for team-based play
- Areas like this may be fun for snipers, soldiers and scouts, but we saw that the resultant gameplay to be too unorganized for fun team play especially with the other classes. We have ended up constraining more as we go and the level is getting more fun.

4. If you are going to place the flags multiple floors up, don't let the capturer simply drop off to get away
- Constraining this with fences has given the defenders a better chance to regroup.

5. Make sure the spawn room exits are simple and obvious.
- At first we had 3 ways to go, one of which went up the stairs. This was really confusing (even to us!). It seems like 2 directions from the room is ideal...one to battlements and one to flag area.

6. We made Snipers pits within view of each other.
- Allows snipers to have to kill and avoid being killed by each other.

7. Most importantly - testing the map with people is worth 1000 hours of theory.
- So much becomes obvious when we watch and play with people. We play on opposite teams and constantly switch classes to see how it feels with each. Also we have all talk on (sv_alltalk 1). Pay attention to what people are saying and suggesting, but also notice events such as why people drop (sorry about the unfair squishing!).


Extra Bonus - Here are some stats I found on the forums that have proved usefull:

All Classes

Walk ---- 83h x 49w
Crouch -- 56h x 49w

step ------------ 18
Jump ----------- 43
Jump + Crouch -- 70

min height before fall damage -- 269 (this is lower if you crouch)

------------------------------------------------------------------------

Class specific (listing highest values I was able to attain, recommend lowering these unless you want the jumps to be as difficult as possible):

Sentry Range ---------------- 1132.15
Engineer Sentry Jump -- 136 (jumping from top of your sentry gun to reach higher locations)

Scout double jump ----------- 90
Scout double jump + crouch -- 117

Soldier Rocket Jump -------- 324
Soldier *Super Rocket Jump -- 528

Demoman Sticky Jump --------- 608
Demoman *Super Sticky Jump -- 960

*Super Rocket Jump - crouch just before you do standard rocket jump.
*Super Sticky Jump - crouch just before you do standard sticky jump.
These are kind of difficult to pull off, you have to time it just right. I find the demoman more difficult to super jump.

Saturday, February 16, 2008

...latest TF2 map link and Pics [UPDATED - again]

On request :) Here is a link to the latest map Mars and myself have been working on. Place it in your tf2 maps folder then run it in-game.

http://www.megaupload.com/?d=A4VXM86Q

Newer Pics:

Newer, simpler spawn room.


New middle section has much better flow now. Intense battles take place along 3 levels of crossfire.


Buttons on boths building levels move the "elevator". Players can shoot from the windows on the second floor which face the sniper pits. Soldier can rockets jump into and out of the second floor.


View from new Flag area 3 floors up.


Back route shortcut for soldiers/scouts.

Sunday, November 25, 2007

...pics of the TF2 mod I'm working on

Me and a few other guys are working on a mod for TF2. Basically we want to add a character and a level. Here's some pics of the level that me and Mars have deen doing for a couple weeks:






Monday, November 12, 2007

...last night (we played our tf2 level)

Myself and Mars have been working on a Team Fortress 2 level as part of a mod we are making with others. We had an impromptu run through last night and people seemed to really enjoy it. I'll post pictures soon...

Saturday, October 27, 2007

...the relationship between making a TV pilot and making a level

Saw the movie The TV Set on dvd last night. Interesting, well-done movie. There are definite analogues in making a TV pilot and making a level. The amount and usefulness of feedback and the repercussions to quality are the main similarities. I cringed a couple times watching it...

Friday, October 05, 2007

...frustrations with the Simpsons game demo

Well just played the Simpsons demo at work. It has potential, but I don't think I'd buy it...too many frustrating issues - such as:

- walking in a straight line is hard! The camera starts turning with any rotation off directly forward.
- demo level is too hectic...too many krustys running around saying the same thing over and over.
- "lard lad" boss's pattern could be much better. One of the 2 spots he goes between is almost impossible to get onto his back from.
- ...and Homer is practically useless against him. I would like it better if Bart had to do one thing, then Homer had to do the next etc...
- too unforgiving in general...I'm talking about glide decent rate, double jump success rate, amount of time Lard Lad stays stunned, frequency of Krustys...
- camera is odd...R-stick can be used to look around, but pressing L1 to actually aim at things often has you pointing away from your intended target

A good focus test could really help...unfortunately I know sometimes even with well-run focus tests, it is all in how management reacts and fixes the problems that come up that make the difference...

Sunday, September 16, 2007

...article I wrote about game design

Check it out here: Tips for the Working Designer I hope it is of use to some out there. Some of the information is common sense, but I am sometimes surprised by the lack of effort I've seen from other designers. It's important to have a method to problem solving, even if it's not the same one I use.

Monday, May 21, 2007

...Gears of War Multiplayer Design

Me and a bunch of people have been playing a bunch of GOW multiplayer lately and it's been a blast - props to everyone at Epic. For the most part the maps and gameplay are very well done. There are definitely favorites and some with issues...we exclusively play annex so keep in mind a bunch of the maps weren't built with this mode in mind.

1. Recognizable level landmarks
For me this is one of the big things that makes it easier for me to learn (and therefore enjoy a map). I think too many of the gears maps fail to do this well enough. Take Garden. At least 2 or 3 times in a match I find myself running 2 or staying at the wrong greenhouse. Even a map that's generally good at this could use a little more clarification (the upper left and right mirrored spots - it would be better to be able to say "the balcony with the statue", or "red building" balcony. Some other levels that could use a little more clarity are Canals, and Mausoleum. In general while looking around, I should be able to tell my teammates where I am in a small sentence - sometimes I can use weapon spawns, but ideally this should be conveyed by the level architecture and texturing.

2. Level lighting
Perhaps this problem is exacerbated by my 27" standard TV (there are a lot of us out there still!), but on a few levels I have a very hard time telling the teams apart. In general this is an issue due to generally similar body sizes and next-gen-style lighting, but it really sticks out in a level like process which I like in every other way...on the grenade capture point (by the 2 long bridges) the 2 teams look pretty much dark black. I have similar issues in Bullet Marsh.

3. Running paths
Good paths to run (holding A) make playing in a GOW level much more fun. Ideally I should be able to traverse large distances in the map without unintentionally getting stuck too often and without having to come out of run too often. One thing I learned from Counter-strike design that applies to GOW is that having 2 ways -no more, no less- to go from start (and all spawn points if possible) is ideal...it allows your team to break up into a couple groups. Finally, there should be enough running room for 4 team members to run around. A good example of all these is Gridlock. Coming from start there is a large curved section which splits off on two sides of the railing. Running from here to any section of the map is a treat. Rooftops is a bad example of this and one of the reasons we don't play it much. The start has you running towards a linear section of thin L-shaped corridors. These sections would be better served if the were not 90 degrees (curved or sectional) and/or larger in size. As they are, you often bump into your comrades or get sucked into the walls. Additionally it takes 7 or 8 seconds before it branches off to a sectional area of hard turns and stairs that is very hard to run through...

4. Arg!- Dropoffs
Sometimes ledges and stairs don't let you walk off of them from certain angles. I also have issues rolling off them and running down them. This is not a level-only issue but it sure seems worse in some spots than others. In general, too many short stairs and ledges in close proximity and mixed in with short 90 degree turns make traversal less fun (see Rooftops). Certain geometry placed too nearby can make the problem even worse - like the pillars placed near the stairs in Canals.

5. Respawn spots
In general, most respawn points are well thought out and well-done. There are a couple instances where they aren't as good. In Raven Down, enemies can spawn directly behind you . When you have the jeep control point under control with a short dead end behind you..this feel extremely cheap. Also related is some of the points above. I want to know where I am (landmarks) and have a nice path(s) to run to where I need to go to. Finally, there is at least one occasion where a capture spot is near enough to a spawn point...in Fuel Depot, there is a capture right near the spawn point in the hangars which encourages spawn camping...

6. Long linear routes = bad
For multiplayer games, oftentimes it's often best to have a short to medium path to every other spot in the map. GOW does this particularly well. Most of the better levels are built like a series of interconnected Os that allow good meeting spots, and flanking enemies who don't watch there backs. There are a couple that don't feel as good. Bullet Marsh deserves some criticism for how long it takes to get from place to place. It takes extremely long to get from the top middle to the bottom. A couple extra routes or shortened lead up routes would've made this map more playable. Escalation has similar issues due to its extremely linear climb. Perhaps this level could have worked better half the height stacked next to each other with a couple paths between.

7. Variety in capture points
It's nice to have variety within a level's capture points. Most of Garden capture points give you different feeling, from the close combat of the middle spot, to the stairways leading to the boom, to the uneasy surroundings of the greenhouse. Process is really good in this regard as well. You have a wide open spot with massive death counts, a small round spot that's easy to flank and chainsaw, a long sniper friendly corridor that also has stairs to the side, a raised platform that is exposed on the sides and back, and the area behind it which is lower and exposed on the sides...each spot feels hard to defend in unique ways.

That's it for now....More thoughts as they come. I would love to try my hand at making a GOW multiplayer map, but currently there is no way...let's hope more maps are coming in the future :)

Sunday, March 11, 2007

... went to GDC this week

GDC is the Game Developers Conference. I find it both inspiring and informative at its best...Some highlights are hanging with people I haven't seen a while, meeting new peoplem a couple of the talks I went to (Gears of War, Agile game design, Kenji Inafune...though I think I missed the best one, from talking to my friend Nat by this man) and seeing one of my idols Mr. Miyamoto talk. Shigeru Miyamoto is basically to games what John Lennon was to rock....it existed before him, but noone before or since has perfected it as much.

Didn't buy any new game design books but that's ok...I just finished reading a couple (here and here) so I need a little break....

Besides that, still very busy finishing Lair at work and currently learning XSI so I can convert my CS brushes into props....fun fun...