Wow, this is great thinking material. Incase some of you don''t know this is related to this article:http://www.gamedeveloper.net/html/articles/000023/000023a.html
It may go into a rewrite or second article.

The original post here was merely about the mechanical aspects of game design. You people have opened up the pandora''s box of game design psychology on me, thanks . Hmmmm.

quote: By Morbo
Under this model, we could monitor player inputs to see if we''re getting the desired reaction, maybe?

Morbo, this already occurs in games i believe. Its where game design and ai intersect. Ai could also be part of the "Axle" of game design, have to think about it - i''m putting it in the backburner.

The way i''m percieving External is as a product produced by the game internally then outputed to the player. eg the player spends 2 game credits on a sword. The swords properties are an external game element(because they are on the players plate). Now the game know that''s the player is using a good sword and it comes up with a better one but doesn''t show it for 1/2 an hour. This better sword and the act of creating it is Internal. The act of the game creating things is always Internal but the item or what created becomes External when it gets placed on the players "Plate" (plate = video monitor, speakers, smellovision etc in the usual forms text, graphics, sound (data)).

I''ve got to think some more about this before i continue with this raving. Please feel free to ignore what i''ve said so far. I''m only thinking about the mechanical aspects of game design not psyc stuff.

I guess the players actions could or should be considered part of the game design. That''s a tough one.

A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

I think i just realised something. If the players actions are a part of game design then that would point to an obvious flaw in this model/theory. As the theory does take this act as being a structure instead it treats it as part of the game design environment. Environment, Game Design environment?!? Map design is a game design environment yes? so the players actions would also be considered Game Design Environment which is external to game design.

Although the players actions are external the actual game design itself participates in the environment. Agg my brain hurts. So the game acts very much like a living organism in this respect. It thrives in the right environment and shivals in the wrong environment.

A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

Edited by - Paul Cunningham on January 12, 2001 12:38:23 AM

No problem, Paul. Always here to confuse...

Phsyc stuff aside (don't do phsyc in the morning), your ideas for External would turn it into a sort of player avatar: the internal representation of the external player. Now only to figure out what that means...

Damn, I keep ending up trying to turn this thing into a block diagram. Been doing too much software design lately.

Ok, how about this: add another module to the mess, the Avatar. It sits on the inside edge of the Internal module. Then we leave the External module to represent the player. This allows us to distinguish between the actual player (which is beyond our control), and their avatar (which abides by the rules of the game, because it's part of the internal structure). External (player) controls Avatar, Internal (game) influences Avatar, which is percieved by External. Now we can separate the user interface rules from the player interaction rules. Think I need to make a picture of this now...

Comments? Am I on the right track?

Edited by - Morbo on January 13, 2001 1:18:51 PM

Just a small point and i do agree with most of what you said Morbo but the problem is is does it "the avatar" fit into all game designs. Does blackjack or 500 have an avatar structure/module in it? Need i say more. The avatar is a very low level "Specialised" game design "concept", i''m after highly generalised abstract "structures" for this theory to work. Nice though, very nice. But then again hmmmmmm i''ll have to think about it too. Monopoly has avatars, chess, strategy games but i just can''t work out where the avatars in card games have gone. Any thoughts? Maybe they aren''t just concepts, maybe they are structures.

Tom, so what you''re saying is that if the environment can not affect the the game then its not environment?

Ok hang on, i think its time to redefine the stuctures we''ve talked about so far and see what we have.

The Fulcrum:
1. Internal
- game systems and engines
2. External
- avatar
3. Environment
- the player (age, sex, country, culture etc)
- the game base (program(computer), board, card, dice etc)
- accessories (mouse, chips, dice, graphics, sound etc)

-------------
What i need to work out here is where does programming or board or cards fit in. Is this the environment? Becuase what i''m thinking the environment is is things like the mouse, player, video monitor. So i guess programming fits into environment sort of because if you were making a board game then you would consider the limitations of the "Environment" first wouldn''t you so programming is the same thing?!
-------------

But this doesn''t seem to fit into the whole theory (fulcrum, lever and axle). It needs to be tempered a bit i think.

The axle holds elements like the gui. Now the gui is an external structure for the axle so the axle must also have an internal stucture or something completely different. No my brains amess again. Most of this probably doesn''t make sense but i can''t bring myself to delete it becuase there could be something mentioned so far i don''t want to forget.



A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

My name is not niphty nor was i mean or intended fealings of hurt towards your thread. I LIKE OTHERs who replied didnt see your point...so dont go starting things with me.

quote:
by paul:
It all comes down to how much you want to know about game design Niphty.

aka John M.
Never give up. Never surrender!

quote:Original post by GalaxyQuest

My name is not niphty nor was i mean or intended fealings of hurt towards your thread. I LIKE OTHERs who replied didnt see your point...so dont go starting things with me.

Sorry about that GalaxyQuest. My screwup.


A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

It''s starting to sound to me, Paul, that you''re loosing sight of your original theory. If the game is the fulcrum, lever and axle which is a lever machine, then the player is the force that pushes down on the lever. That force could be human or some other mechanical force, (Human or machine). Whatever you do, don''t modify the machine to fit the theory. It''s been awhile since I read the article and I''m not sure if I got my head around it completly, but I''m getting the impression that the theory is falling appart when you try to include the player. A game doesn''t come packaged with a player. It certainly comes with a variety of ways for a player to interact with the game though. But that''s the lever part. The player isn''t what supports the game, although the game servers no purpose without a player.

Or am I way off base and out of line?

Not to put too fine a point on it, but do levers even HAVE axles? Aren''t those parts of an entirely different class of simple machine?

Well the way its ment and i should have explained this sorry. The fulcrum/lever theory explains game design for a macro view point. The fulcrum - internal/external theory (here) is ment to be micro game design. This internal/external stuff is only ment to explain in more detail how the fulcrum operates - bad writing on my behalf. I think i''ll dump the micro theory or what i''ve done on it so far and start from scratch with a clear mind.

quote: by annon
Not to put too fine a point on it, but do levers even HAVE axles? Aren''t those parts of an entirely different class of simple machine?

The theory is a model of which you''d have to go to the link i mentioned earlier to fully understand what i''m talking about. Here it is again.

http://www.gamedeveloper.net/html/articles/000023/000023a.html

Back to brain racking. Cheers people for the thoughts and umm you havn''t heard the last of this

quote: By kseh
It''s starting to sound to me, Paul, that you''re loosing sight of your original theory. If the game is the fulcrum, lever and axle which is a lever machine, then the player is the force that pushes down on the lever. That force could be human or some other mechanical force, (Human or machine). Whatever you do, don''t modify the machine to fit the theory. It''s been awhile since I read the article and I''m not sure if I got my head around it completly, but I''m getting the impression that the theory is falling appart when you try to include the player. A game doesn''t come packaged with a player. It certainly comes with a variety of ways for a player to interact with the game though. But that''s the lever part. The player isn''t what supports the game, although the game servers no purpose without a player.

True, people have made bots that make aiming and the like easier to do in fps games which is the same a putting a robot of machine in control of the game Lever so some extent. Although every game must have "something that allows the player to interact" - that in an abstact view is a lever. I hope that helps.




A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew