I'm starting a new thread, since the other one got so long and off the objective path. Hopefully Khawk and everyone else will support me, and maintain strict adherence to the topic at hand (its gonna get long enough without flaming tangents): ... An Exercise: As an exercise, lets determine what reasonable patterns you could use to handle players (which I will refer to as avatars to prevent ambiguity with RL game players). From what I've read of most design patterns not contained within the title book, I always seem to feel that they were really just a combination of patterns define therein, or too specific to really be considered a pattern. To truely be a game design _pattern it needs to apply to multiple types of games. Further, I wish to (eventually) adhere to the format layed out in our bible (may as well acknowledge our zealousy) and provide a few simple examples, the pros/cons, and credit other utilized patterns. Application: The Avatar pattern can apply to any RPG, SpaceSim, RacingSim, or Sports game (no tetris here). In the RPG your avatar is your player character, the guy you run around the world and camp stuff & collect uber gear with. In a racing game your avatar is your car, in the case of a masterful game like Gran Turismo, you can customize your car with virtual RL components for the races. In the space sim, you might have two avatars, the pilot & his space ship, as the case is with some StarWars games. In a sports game you can have many avatars, each with varying degrees of responsiveness and talent, these qualities can even change during a game or season. A good avatar patten should be able to hanlde all of these cases. I feel, such a pattern will be generic enough to be of utility, and specific enough to not get lost in gross generalization (no GUPies!). Minimalistic: First, let's define the necessary & sufficient characteristics of an avatar. Later, we can add optional admonishments to handle particular cases (like dead reckoning capabilities for networking or 'bones&joints' for skeletal animation etc...) Magmai Kai Holmlor - The disgruntled & disillusioned Edited by - Magmai Kai Holmlor on January 10, 2001 8:26:35 PM

The Avatar Pattern:
Avatars represent adaptive or customizable alter egos
All avatars must:
Present feedback & view of the world (set the camera/place the ear)
Respond to events (bare with me)
Generate events from player input (kb/ms/jy/sb/voice?)
React: Accept events from the world & other avatars
Act: Send events to the world & other avatars
(almost sounds like a window! especially in the sports game case!)
Store state information for determining outcomes when acting or reacting

I wasn’t quite sure how to tie in the worldview. It seems like it belongs in here somewhere, but ‘Present … to the player’ doesn’t seem quite right because they avatar itself does not provide the feedback – consider the 3rd person perspective of many 3D games. !Ah, I have falsely set my avatars eyes & ears within its game world body; such mundane limitations do not exist in our virtual worlds.

I seems that I have not yet defined enough, games like Master of Orion or Panzer General are on the verge of being sucked into this category. I think they represent a different model, in those games you control a large number of relatively static pieces, not adaptive alter egos. Let us call them Tokens and give them an attaché pattern of their own.



Magmai Kai Holmlor
- The disgruntled & disillusioned

Hey! Tabs don't work anymore! It was hard enough to layout the text before!

Edited by - Magmai Kai Holmlor on January 10, 2001 8:28:56 PM

Is it just me who believes that a ''Pattern'' is not really a pattern without a sample implementation? Otherwise, I''d just call it an idiom, which isn''t nearly as useful...

Hmm. I think you''re mixing game design patterns with programming patterns. Game design patterns might have a single game token for the avatar, I would use several programming patterns to make up the avatar game token.

For example, I would use a composite pattern for player inventory (if the avatar had one).

I would probably use a singleton for the avatar if the other agents were dissimilar enough.

The graphics would be kept entirely separate, with a simple facade or maybe a bridge, I think (haven''t really thought about it yet).

The interactions with other objects would either be an observer implememented at someplace higher in the object tree or a mediator attached to a map object- > so nothing unique for the avatar.

The UI would also be separated from the core avatar, using whatever works for the graphics (again, haven''t really thought about this one).

Well, that''s how I might slice it up. The point being that the game design element, the avatar token, gets chopped up and spread around - I don''t think you can make an avatar pattern.

Just my $0.02

PMFJI,

quote:

---

Original post by JSwing

...I think you''re mixing game design patterns with programming patterns. Game design patterns might have a single game token for the avatar, I would use several programming patterns to make up the avatar game token....
...The point being that the game design element, the avatar token, gets chopped up and spread around

---

Perhaps we should start by defining terms, here''s my suggestion to start things out:

Idiom: Specific logical operations used to transform a small amount of data. Example: To exchange A and B without using additional memory: A xor B xor A

Element: A grouping of data and the transformations that can be applied to it. Example: Avatar.

Pattern: Specific logical operations used to manage an element.

Idioms can be applied to specific data elements of an element, a grouping of idioms can form a pattern, various patterns can be applied to a single element, etc.

Whadya think?

Mike :-)

My goal was to assimilate the notions of game patterns and a formal design pattern You you find an avatar pattern unreasonable?

I do not expect the avatar pattern to be very unique, and do intend to give solid code examples at the conclusion.

Has anyone else given any thought to such a pattern?

Magmai Kai Holmlor
- The disgruntled & disillusioned

I don''t find an avatar pattern unreasonable from the point of view of game design (the set of rules that define gameplay). I just don''t agree that it makes sense to treat it as a programming pattern.

The book design patterns focuses on programming patterns, on implementations. Unfortunately it uses the vague title Design Patterns which is, IMO, confusing.


Game rules (which I''ll call game designs) are a different beast. Where programming deals with objects, and methods and whatnot, game design deals with game tokens. Going from game design to program design you translate one to the other, but I consider them separate.


Example: Racing game. From a game design point of view, I could say that each car (avatar) has an engine with a handful of data (power, fuel consumption, etc). When the player commands the car to accelerate, it does so according to its engine power and weight. We now have a simple game design (Drag Strip Racing).

I can point to the above paragaph in my design document as the definition of the avatar. None of which spells out how the guts of the program are assembled.

For the progamming patterns, I might separate the engines into a separate class so that cars can share the same type of engine. Now the avatars (cars) share a component! The Element (per MStripe''s defn) is the engine, no longer the avatar.

The lines that delineate avatars (alter egos) in the game design are different from the lines that separate Elements in the program.

More to the point, you can use a different programming pattern for the engine (such as storing the data directly in the Car class) without changing the game rules (avatar definition).

The Design Patterns book is about solid ways to organize the programming bits. In my opinion avatars, representing alter egos of the player, fall firmly in the game design realm.


MStripe: I think your definitions are pretty good, I''m not sure how inheritence fits in.

quote:

---

Original post by JSwing

MStripe: ... I''m not sure how inheritence fits in.

---

Inheritance is a pattern. Supported by the syntax of some languages, possible in others with a little extra work. Applicable to designs where "chunks of data" (object) share hierarchical sets of operations (class). Under this definition the use of inheritance loses usefulness as the hierarchy of operations becomes less nested (requiring multiple inheritance)

An avatar pattern where all the avatars in the game share the same attributes, but in different quantities (a squad game where all the player can fire a rifle, but some better than others) would not require inheritance. A strategy game where some avatars have _different_ attributes, some of which are shared (a general can fire a rifle just like a corporal, but can also give orders that the corporal cannot) would make use of inheritance.

An avatar pattern would make use of lots of patterns, depending on the nature of the game, so perhaps the term "pattern" is too restrictive for an avatar. An avatar could be a "pattern container" in that it would aggregate, manage and dispatch amongst a variety of patterns. So maybe what we need is a "container of patterns" pattern that could be applied to high level concepts like an Avatar.

Whadya think?

Mike :-)

quote:

---

The Design Patterns book is about solid ways to organize the programming bits. In my opinion avatars, representing alter egos of the player, fall firmly in the game design realm.

---

I see your point, I suppose Avatar needs a different name, something other than pattern.

I would still like to define an interface and example implementation for a generic Avatar though.

I''m cool with that. Having a set of patterns that make a good avatar and interface for it makes sense.

But I suspect that a lot of the patterns will depend on the particulars of the game.