What are they? Can we quantify them and detail them without them defining a niche? Here are some ideas:

• Weapons.
• Combat.
• Bounty hunting.
• Treasure hunting.
• Highway robbery. (pirating, bandits, whatever)
• Exploration.
• Fitting together elements to gain a skill. (spells, science, etc.)
• Information passing.

So, how can a generic nonlimiting flexible all encompassing system be built which is not just skeletal in nature? In other words, the system would be fairly adroit at handling the inclusion of virtually any new type of thing without requiring much more than a simple definition of the new thing. [edited by - bishop_pass on April 12, 2002 4:18:01 AM]

Melee, Ranged

Melee:
*Weight: Affects speed of attacks. The heavier the slower.
*Length: Also affects speed of attacks
*Damage: Duh
*Damage type: Blunt/Cutting/Piercing

Ranged:
*Weight: Affects speed of attacks. The heavier the slower.
*Length: Also affects speed of attacks
*Damage: Duh
*Missile speed: Affects range (dependant of weight)
*Missile weight: Affects range (dependant on speed)
*Damage type: Blunt/Piercing/Energy (linghtning, fire etc. etc)
Melee Capabicity (for close combat fighting with the weapon)
*Weight: See Ranged/Weight
*Length: See Ranged/length
*Damage: Damage dealt in close combat with the weapon
*Damage type: Blunt/Cutting/Piercing

Obvously a ranged weapon with slow missile speed would NOT be suitable for the blunt damage type.

Perhaps this wasn''t what you were looking for?

quote: Original post by Ganryu
Melee, Ranged

Melee:
*Weight: Affects speed of attacks. The heavier the slower.
*Length: Also affects speed of attacks
*Damage: Duh
*Damage type: Blunt/Cutting/Piercing

Ranged:
*Weight: Affects speed of attacks. The heavier the slower.
*Length: Also affects speed of attacks
*Damage: Duh
*Missile speed: Affects range (dependant of weight)
*Missile weight: Affects range (dependant on speed)
*Damage type: Blunt/Piercing/Energy (linghtning, fire etc. etc)
Melee Capabicity (for close combat fighting with the weapon)
*Weight: See Ranged/Weight
*Length: See Ranged/length
*Damage: Damage dealt in close combat with the weapon
*Damage type: Blunt/Cutting/Piercing

Obvously a ranged weapon with slow missile speed would NOT be suitable for the blunt damage type.

Perhaps this wasn''t what you were looking for?

I think he wanted something more generic that suits all RPGs, not only those in medieval times (ie, the stats for Ranged weapons doesn''t suit guns and cannons etc).

quote: Original post by bishop_pass
What are they? Can we quantify them and detail them without them defining a niche? Here are some ideas:

• Weapons.
  
• Combat.
  
• Bounty hunting.
  
• Treasure hunting.
  
• Highway robbery. (pirating, bandits, whatever)
  
• Exploration.
  
• Fitting together elements to gain a skill. (spells, science, etc.)
  
• Information passing.
  

So, how can a generic nonlimiting flexible all encompassing system be built which is not just skeletal in nature? In other words, the system would be fairly adroit at handling the inclusion of virtually any new type of thing without requiring much more than a simple definition of the new thing.

[edited by - bishop_pass on April 12, 2002 4:18:01 AM]

In my personal opinion you should remove "Weapons" and replace it with "Items". Then you should replace "Treasure Hunting" with "Collecting and Gathering".... and add something called "Trading" or similar...

Just my personal opinion, of course

Khaile, if you look closely at what i have written you can very well create a shotgun, beretta, walther ppk etc. etc.

Just increase missile speed! :D

quote:
Original post by bishop_pass

So, how can a generic nonlimiting flexible all encompassing system be built which is not just skeletal in nature? In other words, the system would be fairly adroit at handling the inclusion of virtually any new type of thing without requiring much more than a simple definition of the new thing.

If I understand correctly:

A skeletal system has a fixed number of defined classes and it only allows the customization of instances of these classes. But the system you propose should allow the creation of new classes at runtime?

So, in theory, once such a system was developed, it wouldn''t need to know anything about the game entities. Things like players, NPCs, stats, items, map locations, scenery, monsters, actions even and the results of actions, etc. could be defined as input data to the system. If so, it looks like only an entire programming language would be general enough to accommodate all possibilities.

quote: Original post by Khaile
I think he wanted something more generic that suits all RPGs, not only those in medieval times (ie, the stats for Ranged weapons doesn''t suit guns and cannons etc).

Ranged weapons existed then, now, and in the future.

quote: Original post by Diodor
A skeletal system has a fixed number of defined classes and it only allows the customization of instances of these classes.

Skeletal means that it doesn't provide any details at all. In other words, the burden of fleshing out the system is mostly imposed on the designer. The idea is to try and remove some of that burden by making the system not just skeletal in nature.

quote: Original post by Diodor
But the system you propose should allow the creation of new classes at runtime?

Well, using the word classes is imposing a way of thinking. I wouldn't start using the word classes just yet. Read below.

quote: Original post by Diodor
So, in theory, once such a system was developed, it wouldn't need to know anything about the game entities. Things like players, NPCs, stats, items, map locations, scenery, monsters, actions even and the results of actions, etc. could be defined as input data to the system.

Not exactly true. Sure, it would not necessarily know about Joe the Beggar, but it should know about beggars, since they seem to show up in just about every RPG and could be considered a type of game element.

quote: Original post by Diodor
If so, it looks like only an entire programming language would be general enough to accommodate all possibilities.

No, I'm not sure about that. I said 'farily adroit' and 'virtually'. Naturally it would be data driven, which means that the algorithms are already encoded, and the data needs to be provided.

Examples include creating algorithms for handling combat, and let the designer build new weapons with new stats drawing from the built in types including: bladed weapons, projectile weapons, clublike weapons, energy emitting weapons, explosives, and others.



[edited by - bishop_pass on April 12, 2002 1:58:19 PM]

quote: Original post by Khaile
In my personal opinion you should remove "Weapons" and replace it with "Items". Then you should replace "Treasure Hunting" with "Collecting and Gathering".... and add something called "Trading" or similar...

I totally disagree. I do agree that ''items'' should be added, as well as ''collecting and gathering''. But specifics don''t hurt, because it gives the game system knowledge of particular scenarios that always seem to crop up in RPGs. The game designer should be able to tap into pre-encoded algorithms or intrinsic knowledge held in the program code about treasure hunting and weapons to more quickly build a rich world.

Don't think in terms of:

• Highly flexible but very generic.
  
• Highly specific but inflexible.
  

Those aren't good solutions. Instead, think in terms of:

• Highly flexible but providing huge amounts of prebuilt details.
  
• Highly specific but completely flexible.
  

The idea is to provide a great deal of prebuilt knowledge about all of the things which seem to exist in RPGs, so the designer can tap into that existing infrastructure. By the same token, any portion or all portions should be modifiable or removable.

Think of a DLL or static library plus a formally specified set of parameters defining a wide range of RPG elements which the DLL or static library uses. Additionally, the designer can access the database of parameters to modify the parameters, or add completely new items with new paramters. And lastly, the DLL or static library is linkable from the language of choice used by the programmer. If the programmer finds that only one set of functions in the entire library is what he is looking for, then he can use that one set of functions only.

I despise 'engines' which impose their class hierarchy on the programmer. I also despise 'engines' which impose an inflexible set of world parameters on the designer. Any engine should not impose anything on the programmer except an input protocol and an output protocol for the desired featureset the programmer wishes to utilize.

'Engines' should not wrap around the programmer's program and enforce a paradigm. Rather, 'engines' should be a tool linked into the program which the program can turn on and off at will.

[edited by - bishop_pass on April 12, 2002 2:35:27 PM]