• Advertisement

Archived

This topic is now archived and is closed to further replies.

The Fulcrum - part 2

This topic is 6242 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If one was to observe the basic mechanical structures for the ruleset of a game there are many differing structures like combat system, economics models, technology systems and the like. But do all of these differents systems and models fit into specified game design purposes. I''ve come up with 3 purposes so far that seem to encompass all the different constructs we game designers think up. These are: 1. Internal to external - a game module that produces information/data internally only which is then sent to the game front for the player to use and understand etc. 2. External to Internal - reverse of point 1 3. Internal - A game module responsible for co-ordinating and handling the changes to the game. Commonly used in balancing. I was thinking of exteral only as well but i can''t work out how such game systems function. Any thought or errors that i''ve made would naturally be welcome. Cheers 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

Share this post


Link to post
Share on other sites
Advertisement
Not trying to be mean or anything but i really dont undestand the point your trying to make here. It seems as if your taking models or more specifically systems and abstacting them even further towards how they are used in a game. Why? Your converting a system such as an economics system and just saying everything it does "in" the game is input, output, or input/and/output. Anyways, thats about all i got out of what you said and i have a hard time where your going with it..sorry.

aka John M.
Never give up. Never surrender!


Share this post


Link to post
Share on other sites
quote:
Original post by GalaxyQuest

Not trying to be mean or anything but i really dont undestand the point your trying to make here. It seems as if your taking models or more specifically systems and abstacting them even further towards how they are used in a game. Why? Your converting a system such as an economics system and just saying everything it does "in" the game is input, output, or input/and/output. Anyways, thats about all i got out of what you said and i have a hard time where your going with it..sorry.

aka John M.
Never give up. Never surrender!





It all comes down to how much you want to know about game design Niphty. Using abstract or psudeo names is just one method i''m using to understand the disapline of game design. Much in the same way you could say an artist improves their skills by learning or teaching themselves new techniques.



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

Share this post


Link to post
Share on other sites
Going abstract is fine as long as you don''t go too far. Otherwise you lose any advantage to understanding that you gained in the first place.

After all, probably the most abstract programming language there is is Assembly...

Share this post


Link to post
Share on other sites
Paul,

I like abstract. I analyze abstract. But I''m afraid you''ve lost even ME here on what you''re talking about.

Maybe if you could provide examples of what you''re talking about? I''d love to get into the discussion, but like with the original Fulcrum concept I''m having trouble connecting what you''re asking about w/ real world examples. (Sorry)

--------------------
Just waiting for the mothership...

Share this post


Link to post
Share on other sites
I feel much better because I didn't quite get what he was trying to say either. Now I don't feel quite so stupid.

I usually don't mind abstract either, but I am really not getting the significance. Like Galaxy it seems to only to convey the concept of I/O systems. I'm sure there's more to it than that, but I just am not getting it



http://www15.brinkster.com/nazrix/main.html

"All you touch and all you see is all your life will ever be --Pink Floyd
Need help? Well, go FAQ yourself.


Edited by - Nazrix on January 12, 2001 1:31:39 AM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The point of abstracting things is that we can study the abstract concepts in isolation, see how they work, and how we can use them. Hopefully we are able to define some rules for the concepts, then apply those rules back to the concrete. Those rules also help us when designing these systems: if we understand the basic, or abstract, concepts behind the system, we don''t have to work from scatch all the time.

Back on topic, an external construct may be the way we intend players to respond: how they go about solving a puzzle, emotional responses, motivation. Things that make the _player_ tick. Yah, this is starting to make sense (so I''m making this up as I go along, sue me). The external part is the intended result of the game: what we want the player to get out of it. The other three constructs (ext->int, int->ext, int) work to produce an external effect, on the player. So yes, the external construct could be useful as a design concept.

Abstract enough for everyone? ;p

Morbo

Share this post


Link to post
Share on other sites
I''m inclined to agree with Morbo except that I''d change it a bit to say that "External" would be more the thought processes that are in the players head rather than the thoughts we want to be in the players head. I say this because "Internal" as described is the processes going on in the computer, not what we want to be going on in the computer. However emmergent effects would be like the internal equivilent of what Morbo described. Something that you want to happen, but can''t 100% guarentee. Internal systems you have absolute control over and in all likelyhood as you progress to more and more external you have less control untill eventually you have none.

Interesting.

If this is on the right path then someone else can come up with names as needed. I suck at that and don''t want to limit the idea to a single word myself.

Share this post


Link to post
Share on other sites
Might this be the key difference between external and internal? One we have complete control over, the other only indirect control. Otherwise, we just have two modules talking to each other through interfaces. If we recognize the unpredictable nature of the external construct, we can take it into account when trying to guide it in a certain direction. Whoa...this IS getting abstract. Oh well, that's what I like.

Under this model, we could monitor player inputs to see if we're getting the desired reaction, maybe? Then adjust the output accordingly; Turn the entire game into a big closed system where we vary the output (game events) to get a certain input (player reaction).

But anyways...I think this has possibilties. Want to see what Paul has to say when he gets back in. Would be interesting to see what kind of rules and premises would could get from this.

Morbo



Edited by - Morbo on January 12, 2001 2:53:08 PM

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
This assumes your game really is alive, Paul, which it isn''t. The program will react precisely how it has been told to react, so I wouldn''t wander off on this whole "the game is artificial life" tangent just yet. Not until you''re ready to program the beast.

In lieu of this, I also think player actions cannot be declared as part of the game environment, although I could just as easily argue my own declarations. After all, what the player does will have an effect on the game, right? Well, not always. Remember recursive dialogues? You can say "no" until the end of time, but the game won''t continue until you say "yes."

So, in a railroad story, player actions are not considered in the game''s design. Therefore, they can barely be considered an external factor since they don''t even affect the game''s outcome. However, if you write a game with forks in the plot and multiple endings, then I think you can safely regard the player as your external factor, and thus you''ll have to plan for it accordingly.

Just my two cents.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement