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

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!

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

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...

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...

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





"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

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

That _was_ me, btw

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.

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