February 10th, 1999

weapon design ---- as you probably know, deus ex is not a shooter. but in talking about game weapon design and encountering the same problems time and again, some things have occurred to me that might be interesting. as always, i'd love to hear outside opinions. 3d shooter game-play, in its simplest form, comes down to moving through the game space, interacting with environmental objects, using inventory items (like a jet pack) and using weapons. obviously, the set of weapons and how they function determines a lot of the game-play because these are the game effects, over which the player has direct control, that affect the other players and/or AI enemies. the weapons are the players ways of reaching into the game world in a shooter and interacting. some are simple: deliver damage. others are more tactically interesting: drop the det-pack and wait for an enemy to come into position before detonating. sometimes it's difficult to talk about what the difference is or how to arrive at one type versus the other. a lot of people on a development team will just say, "that game's weapons sucked" or the opposite. and pinning them down on 'why' can be a source of great frustration (for everyone involved). the problem is related to the design process that is often undertaken. as an alternate to the way i've normally seen people tackle weapon design, i'd like to draw from one of the previous cauldron updates (december) and again apply the 'game-play first, context later' concept. next time you attempt to design a weapon, do this simple thing: do not allow yourself (or your design partners) to use any description of graphics, sound effects or fictional context whatsoever. that is to say, you are banned from saying things like, "there's going to be this totally badass green ball of lightning that flies up and splits into four flaming monkeys!" or, "first we'll play this deep humming sound, followed by an electrical crackle." those things will eventually be important, but in the earliest stages, they just hamper the process. once freed of graphics, sound and context, you will find it easier to come up with a weapon that is actually game-mechanically different from all the other weapons out there. a weapon that will function in such a strategically unique way that it actually changes game-play and creates a dynamic that the players can use tactically in the game. that's all fine in theory, but what about some working example. so, after thinking this through, i challenged myself to actually use the process to create something i had not seen in a shooter before. what i came up with, in 10 minutes, was this: weapon X, when selected, projects a targeting indicator of some sort flat on the ground at a certain distance in front of the player. the player, by mouse-looking slightly up or down, can move the indicator close or farther away from himself. when the player fires the weapon, the indicator leaves a copy of itself locked onto its current spot. the player is free to position the indicator at a second spot. then, when the player 'fires' for the second time, a field is set up between the two points. in other words, the player designates two points on the ground and anything between these two points is affected in some way (probably damaged). one of the distinctions of this weapon is that it would be more effective against targets at a lower elevation than the player (because of the way the indicator is positioned on the ground in front of the player). another distinction is that it could be used to affect multiple targets. it could effectively be used to wall off an exit for a second or two, by firing it across the opening. there are multiple parameters that could be tweaked to make it more interesting: after it's fired, how long does the effect last? how much damage does it do? what if the player could (via modifier key) set up more than two points? (imagine a 3 point version of the weapon--every time the player fires it, a triangular area is affected.) obviously, then someone would have to come up with a fictional context (what is this weapon? who made it?) and a flashy animation (balls of lightning, walls of flame, flying monkeys?). also, the new weapon's rate of fire and damage would need to be balanced out. but regardless of what gets decided at that phase, i think that the weapon that goes through this process has a better chance of being fundamentally different on a mechanical level. ----

February 1st, 1999

design lamentation & thinkingoutloud ---- you want to make a CRPG because you love them. and, really, it's great fun. but there are numerous design problems to be solved. some are less than obvious. what follows are notions that have occured to me recently, working on Deus Ex, our dark SF conspiracy CRPG. ---- rpg skill systems a) you want enough skills to make character differentiation cool b) you want each skill to be strong enough on its own (these two, a & b, are somewhat at odds--without enough skills, the player feels too constrained and does not feel like he can customize his character enough. however, the more skills you try to express within the game, the harder it is to make each skill worth the player's attention/selection.) c) you have to populate the map with uses of these skills (believe it or not, this is somewhat hard to do--it can be difficult to come up with enough places to use the "medic" skill, for instance. each 3d map must support enough instances of all the skills you decide to include. add too few and the player who chose a specific skill gets ripped off. add too many and the game starts to feel ludicrous: "i had to heal 16 people just to walk down this one city block.") d) use of the skills has to matter in the game e) you cannot invalidate one player because he lacks a certain skill (these two, d & e, are somewhat at odds--you cannot, for instance, make a plot critical door that must be lockpicked, since some players might not have taken the lockpicking skill. obviously, if every door/area can be bypassed in multiple ways, the problem becomes easier to cope with. but it still requires thought and flexibility.) ---- all these problems are solvable. (and solve them we will!) but really they stem from a larger problem--designing the game's context first. many of us set out to make a cool computer gaming experience that is connected to the cool paper RPG experiences we know and love. this of course leads to thinking in old paper RPG terms, which leads to designing features that are difficult (but not impossible) to express in a CRPG. i feel like i've had a recent realization that is meaningful to me personally (mostly because of the stylistic course i feel like i'm on as a designer). most CRPG developers know so well what their game's context is that they develop the game by trying to make it meet that context. in other words, i know what a mage is, therefore i will design some mage-like CRPG features, like 'charm person,' so that playing a mage in the game will feel like it does in paper games. then you start hitting problems--what can i do with a charmed victim? certainly i cannot do as much as i could in a paper RPG. his conversations alone in a computer game will be severaly limited. plus, what happens if another mage casts charm person on my character and i lose control of him? is that fun in a CRPG? so it now seems painfully obvious to me that this is a problematic move. perhaps instead, you should figure out a list of things the computer/engine can do well, pick the ones that work well together then wrap your context around those elements. for instance: i know that we can do player-character flight well, so levitation, free-fall and flight become a branch of magic. the sequence--game expression first, context second--lends itself to more elegant game dynamics...things that actually work better in a CRPG. then, of course, with the 'smoke and mirrors' elements, like the way the game looks and sounds, you complete the context and fill out the fantasy world (or whatever your world is). sure, this is a simple concept, but i think i once missed it entirely, rooted in my old ways. the console people and old school programmers get this i think better than "designers." anyway, my hope is that being armed with this knowledge we can make everything work in our game, making all the cool CRPG elements of Deus Ex as much fun to play with as possible.