Thief/ Deus Ex design paper up

[GrandpaTrout]

I just stumbled on this Game Developers Conference presentation that discusses how to create emergent gameplay in a game. Written by some of the fellows who are working on Thief 3 and Deus Ex: Invisible War.

http://www.ionstorm.com/gdc2004/

(The Harvey and Randy Smith paper)

There is a power point viewer download at that site, if you don't have one.


[Edit]

Some thoughts on this paper. The basic thought is to link together little game mechanics, so the player can invent cool new strategies. I can see a few immediate examples from Iwar:

1. Cargo pods can be carried by player
2. Cargo pods can be undocked in mid flight
3. Objects in motion remain in motion....
4. Items can be destroyed by collision
5. Pods of antimatter explode.

None of these little rules explicitly creates a game of tossing antimatter pods at mega freighters, but together they make for a world of fun! If any of them were left out (say pods didn't coast) then you couldn't do it.

Another is hunting cargo ships by piling cargo pods in front of Lpoints. A strategy that comes from interactions the same simple rules above.

Another is sitting behind the lpoint and blasting the unshielded tails of ships as they fly in. They cannot see you right away, they have forward speed, they do not turn.

Using freighters as giant battering rams - via REM link, is another emergent gameplay idea.

Someone reported killing a cruiser by getting it to fire on a station (and letting the station take it out with reactive fire).

Any thoughts on other "mechanics" that would make interesting emergent game play in EoC?

Having those tanker ships explode? (using them to take out stations, or damage ships needing refule).

REM hacking cargo pods and stealing them as they emerge from the station? Driving cargo pods around?

Shooting ships causes them to signal for distress. Distress causes ship to leave station. Unguarded station is open to attack.

[jessica00]

once you create realistic rules, an economy (of supply or "energy exchange, aka weapon fire), and a quasi-communication network between AI's, you have interaction and dynamics.

[river]

"1. Cargo pods can be carried by player
2. Cargo pods can be undocked in mid flight
3. Objects in motion remain in motion....
4. Items can be destroyed by collision
5. Pods of antimatter explode.

None of these little rules explicitly creates a game of tossing antimatter pods at mega freighters, but together they make for a world of fun! If any of them were left out (say pods didn't coast) then you couldn't do it."

Hey, wasn't this in EoC? Not at freighters, though, but a station? :)


"Another is sitting behind the lpoint and blasting the unshielded tails of ships as they fly in. They cannot see you right away, they have forward speed, they do not turn."

Again, I remember this tactic from the second mission (non-training) in Iwar...

"Using freighters as giant battering rams - via REM link, is another emergent gameplay idea."

And then a Cruiser could use a cutting beam to finish the target off! Say, you're not trying to be sly and remind us how great the Iwar games are? :)

-river

[MajorTom]

This is the difference between "systematic" (standard OO programming) and "systemic" (use of system relationships) programming.

The developer or scripter needs to be intimately familiar with the game mechanics and use them in a way that the player can relate to 'logicaly'.


Driving cargo pods around?


Good example!: flying cargo pods is no fun and even rather boring: pods are slow, have no weapons and don't explode when you ram something (except newly found antimatter pods).

In Epic Online it is fun to fly pods because of the way game mechanics are used:

From a safe distance, you can rem connect to a pod outside an enemy base to steal it. The enemy base starts fireing at the pod immediatly when you connect to it and knocks you around so much that you have to concentrate very imersively to steer it. You are in constant danger of it exploding. (you don't die but the goodies are gone)
Nearby is a huge hollow asteroid with a small entrance. Obviously, You can stear through the small entrance, (which is kinda hard to do because you're being knocked around), where you will be protected from gunfire and can safely fly out the entrance on the other side to your ship. Alternativly you can scrape along the side of asteroid and just barely make it around the corner before the pod explodes. It is a fun challenge.

None of the properties needed to do the above are normal cargopod properties but by using the game mechanics you can create and link them:

- the pod takes on the players faction (enemy to the station) the moment he rems to it (not standard for Rem). So the station shoots at the pod.
- You need to alter the pods hit points to control it's lifetime under fire so it stays alive just long enough.
- you need a special deathscript to disconnect rem before the pod dies (else the game crashes)
- the surroundings (map objects) must be supportive to the objective and the players imagination
- you need a methodology to overcome hard coded 'features' that are not supportive to your objective.

Example: if you use the hard coded autopilot feature when in the pod, you'll have no problem steering it. But, it will go straight towards your ship and since you adjusted the hit points, get destroyed by the gunfire (or crash into the side of the asteroid constantly). The autopilot obviously won't 'think' to use the shelter of the nearby asteroid and can't 'find' the entrance to the asteroid anyhow.

Stuff like this requires lots of thought and lots of testing. It just don't work automagically. Thats why you don't see much of it in games to date.
Despite the work and effort put into it: There is no compelling reason to steal the pods in Epic online(yet). So, very few even know how much fun it can be to rem connect to cargo pods. One could say I went to a lot of trouble for nothing.
A lot of developers may think similarily about undiscovered functions they've designed into games previously.

Therefore we note:
The objective has to be there! In Deus Ex, opening doors is a "standard" and very primary objective. Lockpicks and multitools are fairly rare. That motivates the player to look for alternative solutions.

i.e. Sucessfull games don't play with themselves, people play with them!

[GrandpaTrout]

Say, you're not trying to be sly and remind us how great the Iwar games are? Oh no! Show how totally cutting edge these games were? Never, never :D

One of my favorite things about Iwar was the way it pushed you into using all of the games features. Right from the beginning when you have to rem link to get the dreadnaught hull.

But I remember one mission with an antimatter pod drifting and you had to catch it. And the key to that mission was to use the alternate view controls, so you could line up better. I mean, even the view control features made it into the missions....

Sucessfull games don't play with themselves, people play with them!

I guess I would amend this as "People play good games, great games play back!"

I totally agree with you that the game needs to be open to player involvement. It needs to be something the player can mess with. And it needs objectives the player wants to achieve. No argument there.

A game where the player cannot really interact is, well, a cutscene. There were moments of Halo where two sides were fighting it out, and you did not really have a role. Enjoyable moments, but passive.

Without wanting to start a flame war, I would argue that an improvement in Halo would be increasing the amount the game interacts with itself. It has two hostile factions - let the player lead them into conflict with each other. Give the AI the ability to call for help (and pull defenders away from places the player wants to go). But yes, keep it player interactive. If the game supports the AI calling for help, give the player a way to do it (maybe using a stolen transmitter).

and "systemic" (use of system relationships) programming
Yes, exactly. We could code a fight between rebels and a mega corporation as set of missions. Or instead as a set of rules, and let the player find an answer.

* Megacorporations can purchase warships that rebels cannot.
* Stations must sell goods to earn funds to buy warships
* Goods must be transported to sellers
* Transports can be attacked

In a normal game, the player would fight by defeating the warships in direct combat. Or perhaps destroying the stations. The above set of rules allows the player to wage a war of attrition.

* When a corporation siezes anothers property, they anger nearby factions.
* When a faction is angry enough, it can be recruited to attack.

With this set of rules wars of rebellion can be started. But it is very true, without giving the player some way to invoke, or use these rules, it would just be an extended movie sequence.

I guess finding the balance is the "art" part of the science.

[MajorTom]

* Megacorporations can purchase warships that rebels cannot.
* Stations must sell goods to earn funds to buy warships
* Goods must be transported to sellers
* Transports can be attacked


Coding that set of rules with all the stimuli and interaction possibilities between each other would be a lot of work, if you think about it in detail (with all the dependencies like a complete economic system, a trade system and a ship vs. faction class system). Perhaps, for very little gain too...

Why should a player want to conduct a 'War of Attrition' or a 'War of Rebellion'?

Generaly people don't just do something because they can.
They do things that seem meaningfull to them, where 'Meaningfull' is also defined by personality and charachter. Attrition and Rebellion may not appeal to some players.

If they were to get more points (motivation) for doing it that way than by using another approach, some players would probably complain about the point system.

I guess finding the balance is the "art" part of the science.


Agreed. I think in most games, the "enabler types" are the engine designers and the "provider types" are the mission designers. You need both for a good game.

The conflict is:
mission designers types want as much flexibility as possible and by nature: rules for something always have an exclusive component too. That is: they are automatically against something else.

The enabler types need rules but I dunno exactly why.. ?

[GrandpaTrout]

Thanks to reviews on this forum featuring "many possible paths", I picked up the game "Far Cry" (I swear you guys cost me more money....) And it has that feature I wanted in Halo - more interactive enemies. I found myself between two camps of enemies, monsters and mercenaries. So rather than fight, I encouraged some encounters.

The game makes it possible with a few extra rules
1. Gunfire attracts nearby enemies.
2. Enemies move toward the last place they hear sound.
3. The player can use cover to hide.

So I would fire a really noisy gun, like a shotgun, and then run for another location and hide. The two camps would send some scouts, and then a feeding frenzy of combat would happen, with more and more opponents drawn in.

The real key is that last item. The player can break contact and hide. The levels are large enough that there are places to flee toward. (It reminds me of the game "Outcast").


Xcom was a game that made good use of missions and a strategy component. The overall strategy game was not spectacular, but linked to the missions it was very fun. A simple economy, base design, and letting the player choose which missions to take and when are not much. But they really made the game addictive. Even though most of the missions were similar over and over.

A game like Halo, or Far Cry could be structured in a similar manner. Let the player pick the targets, and order of attack. Let the player scout the enemy, spot weakpoints, avoid radar bases. Choose when and where to defend, or run. (I suppose that would just about be a first person Jagged Alliance).

[MajorTom]

Originally posted by GrandpaTrout
The game makes it possible with a few extra rules
1. Gunfire attracts nearby enemies.
2. Enemies move toward the last place they hear sound.
3. The player can use cover to hide.

So I would fire a really noisy gun, like a shotgun, and then run for another location and hide. .......

Rules are fine (my Dad used to make em up all the time) but I find the implimentation more interesting and a lot more challenging (particularily if I think about my youth ). ;)

Do you suppose the game has some kind of Bot sfx so they can actually 'hear' the loudness and source direction of a sound?
I wonder how they made the rules work?

[GrandpaTrout]

Not sure how Far Cry is structured. I did find this article: "A General Purpose Trigger System" by Jeff Orkin of Monolith Productions. It is in the book "AI Game Programming Wisdom" by Steve Rabin.

Here is a slice of the intro:

"A trigger can be any stimulus that a game designer wants an agent to respond to. In an action game, triggers might be anything audible or visible that affects the behavior of agents, such as gunfire, explosions, nearby enemies, or dead bodies. Triggers might also emanate from inanimate objects that agents need to know about, such as levers and control panels. Triggers can be generated from a variety of sources, including game code, scripts, console commands, and animation key frames. Agents can specify which types of triggers are of interest to them."

Basically a trigger ends up being a kind of message that gets sent out from objects in the game. It has a source, and position. Radius and time to expire.

The player keeps sending these messages as he moves around. When he gets close enough to a guard - the messages fall inside the radius, and get delivered to the guard. The guard then changes behavior (maybe moves closer, or becomes more watchful).

An alarm button is always sending out messages - press me - press me. But guards ignore the messages, until they go to fight state, then they throw an internal switch that says - accept alarm messages. Once they do, the get the press me message, and so they run over to the button and press it.

Pretty good book overall. It has another article by Paul Tozour of Ion Storm Austin, who discusses Thief's First Person Shooter AI Architecture (basically the same kind of trigger system, and how that fits into movement and animation).

I think I bought it on Amazon.

So in multiplayer, does a bullet basically work like one of these messages? A bullet is fired, it gets sent to all clients, the clients check if it hits. They take action based on the hit. Something like that?

[Rurouni Storm]

Originally posted by GrandpaTrout
So in multiplayer, does a bullet basically work like one of these messages? A bullet is fired, it gets sent to all clients, the clients check if it hits. They take action based on the hit. Something like that?

Sort of, but in most games all the calculations are done by the server to prevent cheating. It's more like the server is handling a bunch of client objects and reacting with them while they also react with eachother.