gamedevlists-design — List for discussing game development design

Re: [GD-Design] Indie Getting Started

[y o g i w p <yo...@gm...>]

Thanks for the input.

I'm wondering if anyone have good experiences with Dexterity Software?
(http://www.dexterity.com/)
They're focused to good quality games, but they take quite a significant
cut (we 'only' get 35% of the selling price).

Btw, anyone know a better place to discuss this topic?


Yogi Wahyu Prasidha

Re: [GD-Design] Indie Getting Started

[<cas...@ya...>]

y o g i w p wrote:
> Specific recommendations (e.g. good electronic distribution services) are
> welcomed. Any thoughts, experience sharing, or pointer to relevant sources
> would be very appreciated too.

I'd recommend eSellerate:
http://www.esellerate.net/

It's very easy to setup, their service is very good, you can evaluate it for
free and their royalties are quite low (10% for starters).



Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

[GD-Design] Indie Getting Started

[y o g i w p <yo...@gm...>]

Suppose I have these cool small/puzzle games, how do I sell it?

I've worked as a programmer for a game company for several years, and
now decided to go Indie. So, I know how to make games, it's just I know
next to nothing about selling them ;)

Specific recommendations (e.g. good electronic distribution services) are
welcomed. Any thoughts, experience sharing, or pointer to relevant sources
would be very appreciated too.

Thanks in advance.


Yogi Wahyu Prasidha

[GD-Design] mesh design issues

[Dan T. <da...@cs...>]

Hello all,

A couple friends and I are designing a rendering engine and we ran into =
a problem. The issue is this. When you are rendering meshes with =
different effects on them, how do you generalize the rendering? When we =
looked at it, it seemed like the best solution was a base class =
DrawableMesh, with various subclasses that do different things, such as =
a BumpMapMesh, a LightMappedMesh, etc. Each one of these subclasses =
would know how to set up the rendering for themselves based upon how =
many textures were allowed per pass on that card, and the various caps =
of the card. These meshes would have their verteces, textures, and =
shaders abstracted through a manager that handles reference counting for =
those objects, and that sort of thing.

The main issue we were having is the huge amount of subclasses required. =
I mean, to us it seemed you would wind up with a class for every =
permutation(combination?) of effect. e.g. you could conceivably(don't =
know *why*, per se) wind up with a =
LightMappedBumpMappedSpecularMappedSkinnedMesh, and that would have to =
reimplement the aspect of light mapping, bump mapping, specular mappng, =
and skinning. This seemed...wrong..to us. Does anyone have any better =
ideas?

This does seem a bit general for this list, so I'm ccing the GD-design =
and GD-general lists..please reply there if you feel it more =
appropriate.

Apologies for a duplicate if any...i sent it from the wrong accoutn at =
first and the list servers didn't like that.

Any help greatly appreciated.

Dan

RE: [GD-Design] Persistency and PvP

[Jamie F. <ja...@qu...>]

of course you can throw in various caps on abilities, which means eventually
even the players with less time can catch up.

my main concern with mmorpgs is that they seem to have an emphasis on graft
rather than fun.

j


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jaek Smith
Sent: 18 January 2003 10:14
To: gam...@li...
Subject: RE: [GD-Design] Persistency and PvP


> For individual competition (i.e. not team based), this is even worse --
> what happens when you join the game late?  Do you rely on social
> engineering such as guilds (effectively informal teams) to protect you
> while you gain power?  Or are you just screwed?

The problem seems to be time vs experience.  It would be the same whether
you joined the game later than other players or whether you are unable to
play the game as much as other players.

In most of the current games you really spend 'time' to gain 'experience'.
Unfortunately the time you spend is real-world time (the time in which you
physically allocate to playing the game).

Even a player that does not spend every second of online time improving his
stats can still quickly out-rank a player that does if the first player is
online much more than the second player.

So:

-> We spend real-world time to gain in-game experience.

-> There is an imbalance in the amount of time various players have to spend
in game.

-> An imbalance in in-game experience is an imbalance in
character-capability.

This means that there is an imbalance (across time) in the ability of
players to gain in-game experience which leads to an imbalance (across time)
in character-capabilities.  (Thus, the effect is continuous).

If real-world time is the resource, then those of us with less real-world
time to spend are 'just screwed'. :P

An interesting comparison to make would be this:

Imagine a game where, instead, you spend real-world money to gain in-game
experience.  In this case, the imbalance would give more weight to those
that had more money.

I'd suggest that those with less time often have more money (think working
people vs non-working people).  Thus, the imbalance would be the same but
the opposite group (in general) would have the advantage!

So the problem seems to be that real-world based imbalances affect
persistent (continuous) world type games.  Is it possible to get rid of the
real-world based imbalances?

Possibly - though it would be game dependent.  For instance you could make a
game where, every so often everyone in the world gets X number of resources
that they can spend on various attributes.  A person that does not log on
for a week will just have a buildup to spend when they do finally log on.

This would (ideally) solve the time-based imbalance without relying on
another real-world resource (such as money) to replace it.  However, you
still have the late-comer problem...  (As well there are other problems -
experience is a major element of the RPG model, but becomes more or less
worthless in this design).

Theoretically the best thing to do would actually limit every player to
exactly the same amount of online game time - but in the end this would mean
that everyone gets no game time. ;)

Other possibilities have to do with limiting the interactions of imbalanced
players.  (This doesn't remove the overall imbalance, but might remove the
omni-powerful-player stomps newbie problem).

Tangentially: In my own mind, a get-stuff/do-stuff gaming model would be
much more fun than a work/do-stuff model...  I find that too many games
require un-fun tasks (i.e. work) in order to let you do fun tasks (i.e.
play).  (Interestingly a friend once told me that my ideas are not really
games... thus I guess I'm really looking for the virtual equivalent of toys
and activities (skiing is not a game either)). ;)

Later for now
--Jaek


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556

Re: [GD-Design] Game Interface Design

[Richard B. <rb...@ea...>]

I may be biased, but there's some pretty cool visual themes going on in the
"Clive Barker's Undying" shell.

Richard Benson
Software Engineer
Electronic Arts Los Angeles

----- Original Message -----
From: "Matt Newport" <mat...@ni...>
To: <gam...@li...>
Sent: Thursday, January 09, 2003 5:06 AM
Subject: [GD-Design] Game Interface Design


I've got a friend who's planning to do his dissertation on Game Interface
Design. He's looking for sources (web, magazine, journal, book, anything) to
do some initial reading. I've given him a few suggestions (Gamasutra,
GameDev, and a couple of other links I had sitting around) but thought you
guys might be able to suggest some other useful resources. I think his focus
is primarily going to be on the visual aspects of interface design but
material on control methods, use of sound in interfaces, etc. is welcome as
well.

Matt.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU6

RE: [GD-Design] Persistency and PvP

[Jaek S. <smi...@cs...>]

> For individual competition (i.e. not team based), this is even worse --
> what happens when you join the game late?  Do you rely on social
> engineering such as guilds (effectively informal teams) to protect you
> while you gain power?  Or are you just screwed?

The problem seems to be time vs experience.  It would be the same whether you joined the game later than other players or whether you are unable to play the game as much as other players.

In most of the current games you really spend 'time' to gain 'experience'.  Unfortunately the time you spend is real-world time (the time in which you physically allocate to playing the game).

Even a player that does not spend every second of online time improving his stats can still quickly out-rank a player that does if the first player is online much more than the second player.

So:

-> We spend real-world time to gain in-game experience.

-> There is an imbalance in the amount of time various players have to spend in game.

-> An imbalance in in-game experience is an imbalance in character-capability.

This means that there is an imbalance (across time) in the ability of players to gain in-game experience which leads to an imbalance (across time) in character-capabilities.  (Thus, the effect is continuous).

If real-world time is the resource, then those of us with less real-world time to spend are 'just screwed'. :P

An interesting comparison to make would be this:

Imagine a game where, instead, you spend real-world money to gain in-game experience.  In this case, the imbalance would give more weight to those that had more money. 

I'd suggest that those with less time often have more money (think working people vs non-working people).  Thus, the imbalance would be the same but the opposite group (in general) would have the advantage!

So the problem seems to be that real-world based imbalances affect persistent (continuous) world type games.  Is it possible to get rid of the real-world based imbalances?

Possibly - though it would be game dependent.  For instance you could make a game where, every so often everyone in the world gets X number of resources that they can spend on various attributes.  A person that does not log on for a week will just have a buildup to spend when they do finally log on.

This would (ideally) solve the time-based imbalance without relying on another real-world resource (such as money) to replace it.  However, you still have the late-comer problem...  (As well there are other problems - experience is a major element of the RPG model, but becomes more or less worthless in this design).

Theoretically the best thing to do would actually limit every player to exactly the same amount of online game time - but in the end this would mean that everyone gets no game time. ;)

Other possibilities have to do with limiting the interactions of imbalanced players.  (This doesn't remove the overall imbalance, but might remove the omni-powerful-player stomps newbie problem).

Tangentially: In my own mind, a get-stuff/do-stuff gaming model would be much more fun than a work/do-stuff model...  I find that too many games require un-fun tasks (i.e. work) in order to let you do fun tasks (i.e. play).  (Interestingly a friend once told me that my ideas are not really games... thus I guess I'm really looking for the virtual equivalent of toys and activities (skiing is not a game either)). ;)

Later for now
--Jaek

[GD-Design] Persistency and PvP

[Brian H. <bri...@py...>]

Sleepless night, so I thought I'd blather on this otherwise dead=
 mailing list.

Every successful persistent on-line game effectively sits on a=
 player-vs-environment (PvE) model with additional, optional=
 player-vs-player (PvP).  Ultima On-line is the closest I can=
 think of where there's prevalent PvP, however it can be ignored=
 if you choose (aside from the occasional PK) -- you don't have=
 to engage in PvP in order to advance, you can still advance in=
 other axes of gameplay (trade skills, socializing, PvE).

The popular games that provide PvP as their main source of=
 entertainment are not persistent.  Game play is limited to a=
 session, a level, or until some end-game scenario is reached. =
 This is true whether we're talking about a shooter with 10=
 minute levels or a turn based play-by-mail strategy game that=
 spans 30 days.  The point remains the same -- players are=
 competing until some fixed, known limit is reached and a winner=
 is declared.

This differentiation never dawned on me until very recently,=
 primarily because I never put much thought into it.

The reason for this is obvious now that I think about it --=
 persistent games that stress PvP will tend to favor players that=
 have been playing longer.  This is true in a PvE level treadmill=
 as well, but the difference is that in a PvP environment=
 stronger players are actually detrimental to the newer players=
 instead of somewhere between neutral and beneficial as you find=
 in PvE oriented games.

In a PvE game, with or without minor elements of PvP, the player=
 has one key ability going for them at all times -- the ability=
 to avoid conflict with other players.  They can do this by=
 pursuing the PvE aspect and, when necessary, logging out to=
 avoid the PvP elements.  When you're logged out of a PvE game,=
 you're not put in a position of "losing".

Contrast this with a persistent PvP game.  Either there is a=
 winning scenario, at which point your absence will be=
 detrimental to you or your team's chances, or there is no=
 winning scenario, at which point the PvP element feels rather,=
 well, pointless.  Do you artificially constrain things so that=
 all out victory is impossible so instead everyone is simply=
 jockeying for some kind of temporal superiority (similar to team=
 PvP in an RPG where they may try to capture an artifact or=
 stronghold for as long as possible).

For individual competition (i.e. not team based), this is even=
 worse -- what happens when you join the game late?  Do you rely=
 on social engineering such as guilds (effectively informal=
 teams) to protect you while you gain power?  Or are you just=
 screwed?

So based on my whopping hour of thought on this, I just don't see=
 any obvious or simple solutions to these problems.  The proposed=
 solutions I've seen in various interviews are cumbersome hacks=
 that don't address the core problem, instead they try to fix the=
 symptoms.  For example, a massively multiplayer RTS that=
 "turtles" logged out players can prevent some of the obvious=
 problems, but it sure doesn't actually make the game any better=
 for casual players or latecomers.

I guess there's a real good reason why we've yet to see a popular=
 persistent on-line game that supports PvP as its core experience=
 (or have I overlooked something?).

Anyway, no real point, just typing up some thoughts while I try=
 to get a better grasp on some of these issues.

-Hook

[GD-Design] Game Interface Design

[Matt N. <mat...@ni...>]

I've got a friend who's planning to do his dissertation on Game =
Interface Design. He's looking for sources (web, magazine, journal, =
book, anything) to do some initial reading. I've given him a few =
suggestions (Gamasutra, GameDev, and a couple of other links I had =
sitting around) but thought you guys might be able to suggest some other =
useful resources. I think his focus is primarily going to be on the =
visual aspects of interface design but material on control methods, use =
of sound in interfaces, etc. is welcome as well.

Matt.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
=20

[GD-Design] Admin: Reply To Change

[Tom H. <to...@3d...>]

Hi again folks!

As of this email, we're changing over the following mailing lists to 
reply-to-list:

gdalgorithms
gd-consoles
gd-design
gd-general
gd-linux
gd-windows

A vote was conducted on the algorithms list since that has the highest 
number of subscribers (~2000) and most of the people on the other lists are 
also on the algorithms list. Of the responses I got, 30 wanted us to change 
and 4 wanted us to stay the way we were. I haven't gotten another vote for 
10 hours, so I figure that's probably all the votes we're going to get.


Thanks for your time!

Tom

Re: Cross-posting was RE: [GD-Design] simple economic game design

[J C L. <cl...@ka...>]

On Fri, 27 Sep 2002 11:29:36 -0700 
Brian Hook <bri...@py...> wrote:

> Sorry, this is really, really bad, because if there are a flurry of
> responses from the other list, they get put into "purgatory" until the
> admins (Tom and me) can get around to manually rejecting them because
> they're not subscribers.
...
> Resident Fascist List Cop

ObNote: This is a technical constraint, not a social constraint, and is
fairly easily resolved as a technical problem thru technical means --
such as via TMDA-based filters.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Cross-posting was RE: [GD-Design] simple economic game design

[Brian H. <bri...@py...>]

> PS. Sorry for the crossposting for those who are subscribed 
> to both lists... but both are so devoid of traffic these days 
> I figured it won't be too bad.

DO NOT CROSS POST TO MULTIPLE LISTS!

Sorry, this is really, really bad, because if there are a flurry of
responses from the other list, they get put into "purgatory" until the
admins (Tom and me) can get around to manually rejecting them because
they're not subscribers.

Instead of cross-posting, please try posting to one list, gauge the
response, and if you're unhappy with the response, post to the next list
a day afterwards.

There are a LOT of subscribers to this list.  To put things in
perspective, the algorithms list has close to 2000 subscribers and yet
still has fairly minimal traffic until a new thread is spawned.

Thanks,

Resident Fascist List Cop

[GD-Design] simple economic game design

[Ivan-Assen I. <as...@ha...>]

Hello,

I'm looking for pointers for designing a very simple economy-oriented
game - something along the lines of the older Sim-games, a somewhat complex,
unstable system with a few parameters you can control.

Can you recommend something in that general direction?

regards,
Assen

PS. Sorry for the crossposting for those who are subscribed to both lists...
but both are so devoid of traffic these days I figured it won't be
too bad.

FW: [GD-Design] Off-line vs. on-line play and cheating

[Freeman, J. <jfr...@so...>]

From: Brian Hook
> Using the MUD paradigm, some aspects can obviously be considered
> solitary, e.g. crafting.  You could do that all off-line, but if given
> the choice, wouldn't you prefer to do it on-line so that you can see
> what's going on outside of your solitary activity.

Oh, I agree.  The online game is ultimately going to have an impact on the
offline game - I think this is desirable in the sense that you really don't
want the player to feel like these are two separate games anyway.

Just looking at it strictly from game-mechanic standpoint:

Like say, if you were to sit down to a blank page and start listing the game
mechanics, setting each game mechanic into a column for "online" or
"offline":

If you write "chat" as one of the things they do, then that goes in the
"online" column, because it can't be done offline.
 
> In my mind, off-line playing is only there if you don't have a choice in
> the matter, e.g. tying up a phone line or you're on a plane.

Ah, gotcha.  I was of the impression you wanted the offline play to be a
bigger part of the overall design.  If you just want *some* things to be
done offline, that makes it a lot easier.

> Using the MUD example again, if you couldn't log-in but all you wanted
> to do was craft, there's no reason (other than hacking/cheating concerns) 
> that you shouldn't be able to do that on a limited local server.

Right, and it's the hacking/cheating concerns that you want to address:  So
maybe crafting can be broken-down into a set of processes and again, you can
identify which ones fit into the offline column, which fit into the online
column.

Using EQ's crafting system as an example:

1. You decide what resources to use.
1a. You decide what to make (in EQ deciding which resources to use *is* the
"what to make" selection).
2. Click *combine*.
3. There's a skillcheck.
4. You either get a widget or
5. You fail and lose nothing or
6. You fail and lose some/all of the resources.

With that crafting system, the only thing you can really move offline is
step 1/1a.

But, you could do a more "offline friendly" crafting system.  Say, maybe
there's a design-phase to the crafting process like:

1. Decide what resources to use.
2. Decide what to make.
3. Decide how to make it (wicked sharp sword with low durability, or heavy
durable sword that isn't as sharp?)
3a. Some other fun/interesting choices about what properties you want it to
have.
4. Store your "design" and use it later, when you've logged in (at that
point, you gather the required resources, point your design at them, there's
a skillcheck (or not), and if you're successful then you get the thing).

> The other problem with the above is that you effectively write two
> games.  We went through this on Quake 2, where there was a huge amount
> of time devoted to writing the single-player portion, and then a huge
> amount of time writing the multiplayer portion, so it ended up being two
> games.  In fact, you'd often meet players who only played one or the
> other part.

Heh.  I thought that's what you wanted. :P

> > Yep, that's it.  Separate characters playing the same game.
> 
> Blech.  I've always disliked this, especially with advancement oriented
> games.  PSO did this as well.  You lose net access for a week, and you
> now have a Level 28 Super Warrior, and then you login and find that
> you're stuck with your Level 4 Wimpy Dude.  It feels like completely
> wasted effort.

Yah, I don't much like that either.
 
> That makes sense, and is a different approach than just separating it
> into two games.  Having them interleaved, but with the option of always
> playing on-line, makes sense.  It makes more sense if you have a linear
> story like Diablo's.

Yeah, I'd take that approach even if you *did* want to make two games that
people could play with a single avatar, as sort of a second-pass once the
core game(s) were designed.  To go back over and see "Ok, where can these
games fit together?"  And especially to integrate the games so that they
don't feel like two seperate games to the player (although, in my mind, they
really would be two separate games at a low level).

But if you're wanting the basic game experience to be Online, with just some
stuff to do offline, then I think I'd approach it on a more granular level:
Visit each game mechanic and see which aspects of it could be moved offline
- even if that requires redesigning the game element so that it *has* an
offline component, as with the crafting example above.

Even things like chat can be given an offline element - compose messages to
your friends offline, and when you connect they'll be delivered.

Or guild politics - voting for the Clan Master or granting titles to
guildmembers or sending (well, composing anyway) orders for your underlings,
and so on.

RE: [GD-Design] Off-line vs. on-line play and cheating

[Brian H. <bri...@py...>]

> I think I'd start by trying to divide the game into online 
> and offline functions - and seperate those into "multiplayer 
> activities" versus "single player activities".  Standard 
> approach has been sort of "Different world/characters, same 
> gamesystem", but you could do "Same world/characters, 
> different gamesystem".
 
Interesting idea.  Skies of Arcadia had a kind of gimmick like this in
that you had the regular game, then mini-games that could be played
independently on the VMU (for DreamCast) which weren't vital to the main
game but were minorly helpful at times.

> Socializing with other players is multiplayer only, by 
> definition.  So that's easy.  You don't include it in the 
> list of single-player activities at all (exception being 
> maybe to compose email or the like, which will be delivered 
> the next time you connect), and don't worry about its 
> "impact" on the single-player game, since it doesn't have one.

But there IS an impact -- you can't ask for help or advice or just see
if a friend is around.  For example, go to www.gamehouse.com and play
Text Twist as a registered user.  There's no way anyone else can play
your game with you, but people sit in the chat rooms and post their
puzzles and others chip in and try to help them find the 6 and 7 letter
words.

The social aspect can't be chalked up as just a "game element", because
it's really an aspect of the milieu and overall flavor of the game, even
if it's not fundamentally core to the game mechanics.  Using EQ as an
example, many people log in even if they don't plan on adventuring.
Similarly speaking, it's like going to a coffee shop to read a book vs.
reading it at home.  Sometimes you just prefer a certain ambience for an
ostensibly solitary activity.

Using the MUD paradigm, some aspects can obviously be considered
solitary, e.g. crafting.  You could do that all off-line, but if given
the choice, wouldn't you prefer to do it on-line so that you can see
what's going on outside of your solitary activity.

In my mind, off-line playing is only there if you don't have a choice in
the matter, e.g. tying up a phone line or you're on a plane.  It
provides a non-optimal playing experience, but one that is still better
than being denied play time at all.  Using the MUD example again, if you
couldn't log-in but all you wanted to do was craft, there's no reason
(other than hacking/cheating concerns) that you shouldn't be able to do
that on a limited local server.

Separating the game play styles based on off-line/on-line is a valid
direction, but it has the side effect of, well, separating the play
styles =)  I'd rather not make a distinction to the player other than
what is available to them and personal choice.

> Yah, or there again, can be different types of resources 
> depending on whether you're online or off'.  In the case of 
> single-player type resources (which help you to craft 
> single-player type tools which help you to complete 
> single-player type adventures), say, fictionally justify them 
> as resources the player doesn't so much discover as 'invent'. 

The other problem with the above is that you effectively write two
games.  We went through this on Quake 2, where there was a huge amount
of time devoted to writing the single-player portion, and then a huge
amount of time writing the multiplayer portion, so it ended up being two
games.  In fact, you'd often meet players who only played one or the
other part.

> Yep, that's it.  Separate characters playing the same game.

Blech.  I've always disliked this, especially with advancement oriented
games.  PSO did this as well.  You lose net access for a week, and you
now have a Level 28 Super Warrior, and then you login and find that
you're stuck with your Level 4 Wimpy Dude.  It feels like completely
wasted effort.

> So, a different approach is to have a single character 
> playing two different games, in the same world-space.

Right, which goes back to the whole, "Ugh, we're writing two different
games" thing =)

> So with that, you'd play and explore online for a bit, 'til 
> there was no where else to go.  Then hop online and kills 
> some things to unlock "Sector 7".  Then go back offline and 
> explore sector 7.

That makes sense, and is a different approach than just separating it
into two games.  Having them interleaved, but with the option of always
playing on-line, makes sense.  It makes more sense if you have a linear
story like Diablo's.

Brian

RE: [GD-Design] Off-line vs. on-line play and cheating

[Jamie F. <ja...@qu...>]

<snip>
I'm procedurally generating a BIG universe -- millions of star systems
and millions of planets.  The odds of two players claiming the same
piece of rock are very, very slim.
</snip>

this, of course, assumes players are equally likely to hit any piece of
rock. if you have a Frontier style system where everybody starts at one of a
few locations, the places close to the starting points are likely to be
claimed many times.

<snip>
I'm not too worried about this part, it's actually things like "Hi, I
just logged in, check out my Armada Buster Level 999 Battleship that I
acquired after hacking my data files"
</snip>

no accompanying replay, no ship :) still hacking a data file, but trivially
generated by the game, and very hard to hack, i believe.

i agree with Jeff, that we really need to know more about what the players
do offline and online to be able to attempt to solve the problem in design.

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 22 July 2002 19:21
To: gam...@li...
Subject: RE: [GD-Design] Off-line vs. on-line play and cheating


> one issue of balance here has to be: can you play the game
> offline and _never_ come online?

In theory, yes.  Take a game like Elite, StarFlight, etc. then imagine a
menu item that says "Go on-line".  That's basically what I'd like to
achieve -- make the game fundamentally interesting and playable for
single person, but allow for a social aspect as well with on-line play.
I think this is what Blizzard accomplished with Diablo, although I'm
aiming for something with a larger scale in terms of universe.

> irritating to have everything you'd ever discovered
> permanently listed as 'claim pending'.

I'm procedurally generating a BIG universe -- millions of star systems
and millions of planets.  The odds of two players claiming the same
piece of rock are very, very slim.

> possible solution, but maybe too intensive: part of the claim
> verifying process downloads a replay of the claim, and plays
> it back to make sure it's not a complete fib.

I'm not too worried about this part, it's actually things like "Hi, I
just logged in, check out my Armada Buster Level 999 Battleship that I
acquired after hacking my data files" that have me more concerned.  But
in the end, it's all the same thing -- hack the data files locally,
connect on-line, and then throw the universe out of whack.

So as stated in another post, I don't think solving this with technology
is going to be tenable in the long run, I think something with the
design should arbitrate this.

Brian



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556

RE: [GD-Design] Off-line vs. on-line play and cheating

[Freeman, J. <jfr...@so...>]

(Apologies if this is a double post.)


From: Brian Hook

> We're working on a game design that, at its core, is just a vast space
> exploration RPG, but which happens to have the ability to connect with
> other players at a central server so they can interact, trade, adventure
> together, etc.

I think I'd start by trying to divide the game into online and offline
functions - and seperate those into "multiplayer activities" versus "single
player activities".  Standard approach has been sort of "Different
world/characters, same gamesystem", but you could do "Same world/characters,
different gamesystem".

Socializing with other players is multiplayer only, by definition.  So
that's easy.  You don't include it in the list of single-player activities
at all (exception being maybe to compose email or the like, which will be
delivered the next time you connect), and don't worry about its "impact" on
the single-player game, since it doesn't have one.

Trade is trickier, in that you're presumably trading things that will be
useful in the offline game - so then, hrm... don't do that.  You can limit
what sorts of things can be traded to what sorts of things are useful to the
multiplayer (only) aspect of the game.

And "adventure" is the trickiest yet, unless there are two distinct types of
adventuring to be done.  If you do that, then it makes it easier to divide
what sorts of tools are beneficial to which type of adventuring, and there's
your guideline for trade as well.

> The only problems will be when two players compete for the same resource, 
> and one "claims" the resource off-line.
> This is easy enough to solve by simply stating that the first player
> on-line gets to take their claim, e.g. you discover and name a mineral
> rich planet, now you want to log-in to "lock in" your claim.  Other
> issues like this can also be solved the same way.

Yah, or there again, can be different types of resources depending on
whether you're online or off'.  In the case of single-player type resources
(which help you to craft single-player type tools which help you to complete
single-player type adventures), say, fictionally justify them as resources
the player doesn't so much discover as 'invent'.  I go to planet-X and
discover a resource which I call resource-X and I turn it into the X-gun
which I use to fight crime, when I'm playing offline.  I can't trade any of
this stuff with anyone else.  'Doesn't impact other people's play experience
even if I do cheat, because we'll never Fight Crime together, and my ability
to Fight Crime doesn't help me to do whatever it is we do together in the
online environment.

> I'm not sure how Battle.net handles it, but I presume that on-line 
> players can't bring off-line characters with them.

Yep, that's it.  Separate characters playing the same game.

So, a different approach is to have a single character playing two different
games, in the same world-space.

Coming up with adventure types that feel different (e.g. "The offline game
is a game of exploration.  The online game is a game of killing.") would be
important though, I think.

Over simplification:

I play the Offline and Online games with the same avatar, in the "same
space".
	* Offline:
		* I explore.
		* I acquire exploration-related skills.
		* I acquire exploration-related tools.
		* I acquire resources which enable me to craft
exploration-related tools.
		* I cheat. :P

	* Online:
		* I kill stuff.
		* I acquire killing-related skills.
		* I acquire killing-related tools.
		* I acquire resources which enable mem to craft
killing-related to tools.
		* I socialize.
		* I trade killing-related resources and tools with other
players.

Additionally, the offline and online games can be webbed-together in other
ways (other than the shared-character aspect, that is):  Such as

	* Offline:
		* Exploration unlocks new areas of the Online Space
		  (in which I kill things).
	* Online:
		* Killing things unlocks new areas of Offline Space
		  (for me to explore).

So with that, you'd play and explore online for a bit, 'til there was no
where else to go.  Then hop online and kills some things to unlock "Sector
7".  Then go back offline and explore sector 7.

Or vice versa.  Or divide it so that whatever people spend the most time
doing is what's done offline, just for the sake of bandwidth.

RE: [GD-Design] Off-line vs. on-line play and cheating

[Daniel C. <dan...@an...>]

Three techniques the come to mind:

- Balanced Characters
- Social validation
- Statistical validation

*Balanced Characters*
Balanced characters are the easiest conceptually.  You set up the game =
so that every character has tradeoffs.  There is no linear character =
growth, where a final character is more powerful than an advanced =
character.  Instead Character A has bigger weapons, but is slower and is =
taxed heavily by the local police force.  Character B has smaller =
weapons, but they aren't taxed so they can make more money as traders.=20

In the single player or multi-player game, you quest in order to adapt =
your character to your particular style of play. If you cheat, you are =
just changing your character around.  You aren't gaining an advantage =
over anyone.=20


*Social Validation*
Social validation is a process of storing data on your character =
throughout all the other existing player machines, not based off the =
local machine.  Imagine you play with 5 other people and you win.  The 5 =
other machines record encrypted versions of your win.  A central server =
can generate an individual's 'reputation' score based off who is playing =
at any one time.  This system is difficult to hack assuming a large =
number of players.  You can use player ranking as part of this.  "I =
enjoyed playing with him.  I didn't enjoy playing with him"  This can be =
reported as well. =20

What happens to a new player who logs on with an uber character and no =
history?  They are marked as newbies.  (There is nothing more damning to =
a cheater than to be marked as a newbie. :-)  The only way they can make =
a name for themselves is by playing and having their reputation =
propagate throughout the network.=20


*Statistical Validation*
This is the most theoretical, but I'd love to see it done.  Imagine a =
peer-to-peer network and a statically derived model of player =
advancement.  The player ends up generating a character history based =
off playing the game.  This history is then submitted to a central =
server that does a statistical comparison to other histories.  Anomalies =
tend to pop out.  When combined with a social validation system, it =
becomes far more difficult for a user to 'suddenly' get an uber =
character.  Unfortunately, this particular system does not work with the =
offline-online system you described.=20

-Danc.=20



-----Original Message-----
From: Alain Hamel [mailto:ah...@re...]
Sent: Monday, July 22, 2002 12:34 PM
To: Brian Hook; gam...@li...
Subject: Re: [GD-Design] Off-line vs. on-line play and cheating


> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.

Attempting to solve via design. I have to say that I don't see how it =
can be
done. I mean if you want some items in your game to have value (eg: the =
ub3r
starship) then I don't see how it won't be trivialized by hacks. But =
that
doesn't mean it can't be done, I'm about as far from omniscient as one =
can
get.

> Hackers have more time than game developers, so it's a
> losing battle when you try to fight them on their turf.

I don't know if they will always win. For example, I think, but I'm not
sure, that intertrust has not been hacked yet. Of course that could have
something to do with no one adopting their technology... And you have a
somewhat easier problem. If, for example, you required that the client =
log
in (for a new binary) every month or so you could make things much =
harder on
the hackers.

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, July 22, 2002 11:15 AM
Subject: RE: [GD-Design] Off-line vs. on-line play and cheating


> > Wow. Attempting to make an always on line game cheat free is
> > already VERY hard.
>
> I am aware =3D)
>
> > However you are attempting to solve a much harder problem:
> > off line games.
>
> Correct.
>
> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.
>
> > Oh, and I would change my binaries as frequently as
> > economically feasible. And make sure that each biniary is
> > different in some fundemental way (eg: automate the process
> > that changes the structures).
>
> This is why I don't want to solve it with technology: the time =
committed
> to trying to fix it is usually disproportionately longer than the
> benefits gained.  Hackers have more time than game developers, so it's =
a
> losing battle when you try to fight them on their turf.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D556
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D556

Re: [GD-Design] Off-line vs. on-line play and cheating

[Alain H. <ah...@re...>]

> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.

Attempting to solve via design. I have to say that I don't see how it can be
done. I mean if you want some items in your game to have value (eg: the ub3r
starship) then I don't see how it won't be trivialized by hacks. But that
doesn't mean it can't be done, I'm about as far from omniscient as one can
get.

> Hackers have more time than game developers, so it's a
> losing battle when you try to fight them on their turf.

I don't know if they will always win. For example, I think, but I'm not
sure, that intertrust has not been hacked yet. Of course that could have
something to do with no one adopting their technology... And you have a
somewhat easier problem. If, for example, you required that the client log
in (for a new binary) every month or so you could make things much harder on
the hackers.

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, July 22, 2002 11:15 AM
Subject: RE: [GD-Design] Off-line vs. on-line play and cheating


> > Wow. Attempting to make an always on line game cheat free is
> > already VERY hard.
>
> I am aware =)
>
> > However you are attempting to solve a much harder problem:
> > off line games.
>
> Correct.
>
> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.
>
> > Oh, and I would change my binaries as frequently as
> > economically feasible. And make sure that each biniary is
> > different in some fundemental way (eg: automate the process
> > that changes the structures).
>
> This is why I don't want to solve it with technology: the time committed
> to trying to fix it is usually disproportionately longer than the
> benefits gained.  Hackers have more time than game developers, so it's a
> losing battle when you try to fight them on their turf.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
>

RE: [GD-Design] Off-line vs. on-line play and cheating

[Brian H. <bri...@py...>]

> one issue of balance here has to be: can you play the game 
> offline and _never_ come online?

In theory, yes.  Take a game like Elite, StarFlight, etc. then imagine a
menu item that says "Go on-line".  That's basically what I'd like to
achieve -- make the game fundamentally interesting and playable for
single person, but allow for a social aspect as well with on-line play.
I think this is what Blizzard accomplished with Diablo, although I'm
aiming for something with a larger scale in terms of universe.

> irritating to have everything you'd ever discovered 
> permanently listed as 'claim pending'.

I'm procedurally generating a BIG universe -- millions of star systems
and millions of planets.  The odds of two players claiming the same
piece of rock are very, very slim.
 
> possible solution, but maybe too intensive: part of the claim 
> verifying process downloads a replay of the claim, and plays 
> it back to make sure it's not a complete fib.

I'm not too worried about this part, it's actually things like "Hi, I
just logged in, check out my Armada Buster Level 999 Battleship that I
acquired after hacking my data files" that have me more concerned.  But
in the end, it's all the same thing -- hack the data files locally,
connect on-line, and then throw the universe out of whack.

So as stated in another post, I don't think solving this with technology
is going to be tenable in the long run, I think something with the
design should arbitrate this.

Brian

RE: [GD-Design] Off-line vs. on-line play and cheating

[Brian H. <bri...@py...>]

> Wow. Attempting to make an always on line game cheat free is 
> already VERY hard. 

I am aware =)

> However you are attempting to solve a much harder problem: 
> off line games.

Correct.

But, I think the approach is to solve by design, not by technology
(which is why I posted to design instead of say algorithms), since
trying to solve it technologically is a losing proposition since the
client is inherently untrustworthy.
 
> Oh, and I would change my binaries as frequently as 
> economically feasible. And make sure that each biniary is 
> different in some fundemental way (eg: automate the process 
> that changes the structures).

This is why I don't want to solve it with technology: the time committed
to trying to fix it is usually disproportionately longer than the
benefits gained.  Hackers have more time than game developers, so it's a
losing battle when you try to fight them on their turf.

Brian

Re: [GD-Design] Off-line vs. on-line play and cheating

[Alain H. <ah...@re...>]

Wow. Attempting to make an always on line game cheat free is already VERY
hard. Well, of course it's impossible, but always on line games can make
things very unpleasant for the hackers.

However you are attempting to solve a much harder problem: off line games.
Off line games have the same problem that DRM (Digital Rights Management)
developers face: a lack of trust. Without any seed of trust there is simply
nothing you can do. Most DRMs attempt to get a kernel of trust started by
employing "tamper resistant code." Normal code (in which a few extra
precautions are taken) is usually converted into "TR" code via a specialized
(usually in house written) compiler.

Once you have a kernel of trust the world is your oyster (at least until
your TR is broken). Your game state (in memory) should be "encrypted" (I use
quotes since due to performance concerns your encryption may not be up to
AES standards). You can use full strength encryption on your save files.

Note that TR usually imposes a very heavy performce penalty. The performance
penalty is almost directly proportional to the security gained.

Note sure what the heck blizzard does. Perhaps they have some other tricks.
I'd love to hear about them!

Oh, and I would change my binaries as frequently as economically feasible.
And make sure that each biniary is different in some fundemental way (eg:
automate the process that changes the structures).

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, July 22, 2002 10:32 AM
Subject: [GD-Design] Off-line vs. on-line play and cheating


> Preface:
>
> Probably the #1 problem people complain about with on-line gaming are
> potential cheats, hacks and exploiters.  As most people know, the only
> way to "prevent" this is to make the server final arbiter on all
> important decisions.
>
> Question:
>
> We're working on a game design that, at its core, is just a vast space
> exploration RPG, but which happens to have the ability to connect with
> other players at a central server so they can interact, trade, adventure
> together, etc.
>
> The thing is, there's nothing inherently multiplayer about the design --
> much of the gameplay could be done by hosting a loopback server on a
> player's system, just like Quake, etc.  The problem, of course, is the
> ability to cheat.  Even more severely is that cheating can affect your
> persistent persona, possibly ruining the game for others if you hack
> your local character descriptio then connect on-line with an overpowered
> character.
>
> So while I intellectually recognize this as a mostly unsolveable
> problem, it bothers me somewhat that the game can't be played "safely"
> as a single player game while at the same time allowing you to interact
> with others when the ability arises.
>
> A classic example is that you want to explore, do some spaceship
> upgrades, and perform other non-social activities.  You can do all this
> sitting on an airplane if necessary, and in theory won't need a net
> connection.  When you do get a chance to login, you "diff" your state
> with the server's state, and then continue on your merry way.
>
> Since the universe is procedurally generated from a pre-determined seed,
> by definition everything your local server generates will be in sync
> with whatever the persistent server generates, so there won't be any
> synchronization issues.  The only problems will be when two players
> compete for the same resource, and one "claims" the resource off-line.
> This is easy enough to solve by simply stating that the first player
> on-line gets to take their claim, e.g. you discover and name a mineral
> rich planet, now you want to log-in to "lock in" your claim.  Other
> issues like this can also be solved the same way.
>
> Instead of chalking this up as impossible because of practical
> constraints having to do with cheating, local files being open to
> countless attacks, etc. I'm curious if anyone has thoughts on the
> problem and possibly a look at it from a different direction.  I'm not
> sure how Battle.net handles it, but I presume that on-line players can't
> bring off-line characters with them.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
>

RE: [GD-Design] Off-line vs. on-line play and cheating

[Jamie F. <ja...@qu...>]

i'm not absolutely sure what you're asking for here, brian.

one issue of balance here has to be: can you play the game offline and
_never_ come online? in that case, it would be irritating to have everything
you'd ever discovered permanently listed as 'claim pending'.

possible solution, but maybe too intensive: part of the claim verifying
process downloads a replay of the claim, and plays it back to make sure it's
not a complete fib. it would be much harder to generate a convincing replay
than a hacked file </claim> (and even if they've hacked the exe in some way
for it to be easier for them to win in a fight, it'll stop them claiming
half the universe in one go, which they could do if they've cracked the file
format)

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 22 July 2002 18:32
To: gam...@li...
Subject: [GD-Design] Off-line vs. on-line play and cheating


Preface:

Probably the #1 problem people complain about with on-line gaming are
potential cheats, hacks and exploiters.  As most people know, the only
way to "prevent" this is to make the server final arbiter on all
important decisions.

Question:

We're working on a game design that, at its core, is just a vast space
exploration RPG, but which happens to have the ability to connect with
other players at a central server so they can interact, trade, adventure
together, etc.

The thing is, there's nothing inherently multiplayer about the design --
much of the gameplay could be done by hosting a loopback server on a
player's system, just like Quake, etc.  The problem, of course, is the
ability to cheat.  Even more severely is that cheating can affect your
persistent persona, possibly ruining the game for others if you hack
your local character descriptio then connect on-line with an overpowered
character.

So while I intellectually recognize this as a mostly unsolveable
problem, it bothers me somewhat that the game can't be played "safely"
as a single player game while at the same time allowing you to interact
with others when the ability arises.

A classic example is that you want to explore, do some spaceship
upgrades, and perform other non-social activities.  You can do all this
sitting on an airplane if necessary, and in theory won't need a net
connection.  When you do get a chance to login, you "diff" your state
with the server's state, and then continue on your merry way.

Since the universe is procedurally generated from a pre-determined seed,
by definition everything your local server generates will be in sync
with whatever the persistent server generates, so there won't be any
synchronization issues.  The only problems will be when two players
compete for the same resource, and one "claims" the resource off-line.
This is easy enough to solve by simply stating that the first player
on-line gets to take their claim, e.g. you discover and name a mineral
rich planet, now you want to log-in to "lock in" your claim.  Other
issues like this can also be solved the same way.

Instead of chalking this up as impossible because of practical
constraints having to do with cheating, local files being open to
countless attacks, etc. I'm curious if anyone has thoughts on the
problem and possibly a look at it from a different direction.  I'm not
sure how Battle.net handles it, but I presume that on-line players can't
bring off-line characters with them.

Brian



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556

[GD-Design] Off-line vs. on-line play and cheating

[Brian H. <bri...@py...>]

Preface:

Probably the #1 problem people complain about with on-line gaming are
potential cheats, hacks and exploiters.  As most people know, the only
way to "prevent" this is to make the server final arbiter on all
important decisions.  

Question:

We're working on a game design that, at its core, is just a vast space
exploration RPG, but which happens to have the ability to connect with
other players at a central server so they can interact, trade, adventure
together, etc.

The thing is, there's nothing inherently multiplayer about the design --
much of the gameplay could be done by hosting a loopback server on a
player's system, just like Quake, etc.  The problem, of course, is the
ability to cheat.  Even more severely is that cheating can affect your
persistent persona, possibly ruining the game for others if you hack
your local character descriptio then connect on-line with an overpowered
character.

So while I intellectually recognize this as a mostly unsolveable
problem, it bothers me somewhat that the game can't be played "safely"
as a single player game while at the same time allowing you to interact
with others when the ability arises.

A classic example is that you want to explore, do some spaceship
upgrades, and perform other non-social activities.  You can do all this
sitting on an airplane if necessary, and in theory won't need a net
connection.  When you do get a chance to login, you "diff" your state
with the server's state, and then continue on your merry way.

Since the universe is procedurally generated from a pre-determined seed,
by definition everything your local server generates will be in sync
with whatever the persistent server generates, so there won't be any
synchronization issues.  The only problems will be when two players
compete for the same resource, and one "claims" the resource off-line.
This is easy enough to solve by simply stating that the first player
on-line gets to take their claim, e.g. you discover and name a mineral
rich planet, now you want to log-in to "lock in" your claim.  Other
issues like this can also be solved the same way.

Instead of chalking this up as impossible because of practical
constraints having to do with cheating, local files being open to
countless attacks, etc. I'm curious if anyone has thoughts on the
problem and possibly a look at it from a different direction.  I'm not
sure how Battle.net handles it, but I presume that on-line players can't
bring off-line characters with them.

Brian

Re: [GD-Design] Scripting Engine and C++ Games

[Mickael P. <mpo...@ed...>]

> Yes, you've hit on a big part of the reason for ICE. We wanted a
> language that end users could use. But we also wanted a language that
> could support a robust, object-oriented coding style, because we
> expected to write huge portions of our game in it. We shipped 40K
> lines of ICE code as part of the game.
>
> I do think you should think seriously about your programming language
> design. You can design for simplicity, but just make sure it's the
> right kind of simplicity. All too often, simplicity of implementation
> is confused with simplicity of language design. There are a lot of bad
> scripting languages around that were easy to write but are not so easy
> to use.

As usual it's a matter of requirements. Before deciding for any kind of
script language you have to know who will be using that language. So far
I've worked on two projects where 100% of the game logic was made using
a scripting language: "Little Big Adventure" (LBA) and "Time Commando".
We know from the start for both those projects that a part of game coding
will be done by people with almost no experience in programming, so we
decided to make something very simple (and well, it was in 1995...) that
even a non programmer would be able to understand. And I have to say that
the result was ok. The game itself is perhaps not that good, but almost
everybody was capable of pointing out bugs in behaviors by looking into
the source code.

For those interested, here is the complete source code (I just translated
the french names in english for understandability) of the behavior of the
"Sabertooth tiger" encountered in the level 1 of Time Commando:

=====================================

StartProgram Tiger      // Last update Mike: Sun  02/06/96
    //
    // While the hero is not around here, do nothing
    // if the hero arrived at less than 2 meters of
    // distance, start roaring.
    //
    DoAnimRepeat    Nothing
    If GetDistance(Hero)>3000 AND !TestTouched
        SetBeta 460
        WaitDistance 6000
        DoAnimRepeat Walk
        Wait GetDistance(Hero) < 2000 OR TestTouched
        If GetDistance(Hero) > 2000 AND !TestTouched
            DoAnimRepeat Guard
            FollowHero
            DoAnimOnce Roar
            WaitAnim
        EndIf
    EndIf

    //
    // The hero is now in the fight area.
    //
    Loop
        FollowHero
        DoAnimRepeat Guard
        While TestAlive(Hero)
            distance_hero=GetDistance(Hero)
            If GetSameHit > 2 AND GetDifficulty <> 0
                Fury  Furie
                WaitAnim
                ResetSameHit
            ElseIf distance_hero > 3200
                //
                // At more than 3.2 meter, approach slowly
                //
                DoAnimRepeat Walk
            ElseIf distance_hero >= 3000
                //
                // Between 3m et 3.2m, use the long jump
                //
                DoAnimOnce GetValueList(-1, LongJumpAttack, Roar)
                WaitAnim
            ElseIf TestBetween(distance_hero,700,900)
                //
                // Closer, try to bite
                //
                DoAnimOnce GetValueList(-1, BiteAttack, Guard)
                WaitAnim
            ElseIf distance_hero < 700
                //
                // If too close for efficient hitting, get back or bite
                //
                If GetRandom(1)
                    DoAnimOnce Recule
                Else
                    DoAnimOnce GetValueList(-1, BiteAttack, Guard)
                EndIf
                WaitAnim
            ElseIf distance_hero > 1900
                //
                // At more than 1,90m, stay on guard
                // and from time to time launch a roar.
                //
                DoAnimRepeat Guard
                If !GetRandom(10)
                    DoAnimOnce GetValueList(-1, Roar, LongJumpAttack, Guard)
                    WaitAnim
                Endif
            Else
                //
                // Hand to hand distance
                //
                If TestHeroAttacking & GetRandom(1)
                    DoAnimOnce Recule
                Else
                    DoAnimOnce GetValueList(-1, ClawAttack, Guard)
                Endif
                WaitAnim
            Endif

            ExitProgram
        EndWhile
        UnFollow
        DoAnimRepeat Nothing
        DoAnimOnce Roar
        Wait TestAlive(Hero)
        ExitProgram
    EndLoop
EndProgram



=====================================

It will certainly not win any award for engeeniering quality, but
it was easy to code, easy to maintain, easy to extend.

Please note that the language as a very special notion of case
sensitiveness, that helps us a lot during production: It's case
sensitive in the meaning that when you write something in a certain
form, you have to use this form later. So it avoids people writing
"Hero", "hero", "HERO" to indicate the same thing... but there is
also a case insensitive check on each new encountered symbol, so
you cannot have to variable/keywords/functions/objects that have
the same name differently only by the case.


    Mickael Pointier