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

quote:
Original post by bishop_pass

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.

I still can't see this working as 100% data driven. Normal RPG engines built with a specific game in mind still have to use scripts for various design purposes. Actually, I can't imagine how would such a system work, except for a vague little idea: make it a code generator like yacc, so both the engine and the user have the same kind of access to game data.

One problem is that a general RPG engine must support custom stats generation (these change too much from game to game), but the algorithms provided by the engine need a consistent and not very complicated data input. So perhaps the engine user should have to supply the engine functions that translate from the custom statistics he chose to the limited stats set understood by the engine. So a fighting algorithm should only want to know about how dangerous a player/NPC is at various ranges, how fast, how resistant (general non-modifiable stats internal to the engine), but not need to know about the various damage, defense and speed modifiers of all the items of the player, and the multitude of skills involved.

Anyway, back to listing RPG elements, maybe a pattern will emerge.

• Artifacts
  
• Player/NPC Stats (including practical skills, levels, experience levels, weapon skills, classes, races)
  
• Player Distinctions (Guild membership, various medals, etc.)
  
• Story. Events that trigger story evolution.
  
• Relationships between different player/NPC classes (orcs hate elves, etc.).
  
• Quests
  

[edited by - Diodor on April 13, 2002 1:49:01 PM]

quote: Original post by Diodor
I still can''t see this working as 100% data driven.

But I never said 100%. I said use what aspects of it you want, and take responsibility to code the rest yourself with whatever language you want. I said the engine should not impose itself on the programmer, but rather the engine is available for whichever aspects the programmer wishes to use it.

quote:
Original post by bishop_pass

But I never said 100%. I said use what aspects of it you want, and take responsibility to code the rest yourself with whatever language you want. I said the engine should not impose itself on the programmer, but rather the engine is available for whichever aspects the programmer wishes to use it.

I think I start to understand.. Maybe. But right now it sounds like you're not talking about an engine, but about a collection of independent spare parts, and a developer would build his game by assembling these pieces alognside new pieces created by himself.

[edited by - Diodor on April 13, 2002 2:12:13 PM]

That''s closer to what I mean, if only to preserve flexibility. The idea is vague.

How about information discovery through conversation, notes, etc? Or is that covered by exploration?

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

quote: Original post by Wavinator
How about information discovery through conversation, notes, etc? Or is that covered by exploration?

I''m not sure that is covered by exploration.

In design terms, instead of items or weapons, I think of tools. Weapons are a subset of tools which are there to solve a subset of problems. Combat + Tools -> (implies) weapons. Keys are another type of tool. A tool would have preconditions for use (usually a situation, perhaps specific) and postconditions as a result of its use (usually a change of state in something other than the tool). Sounds familiar. Maybe that''s too abstract, but I think it could be achieved with a simple list of conditions to fulfill and a few basic instructions to execute if they are fulfilled. (e.g. Unlock, Damage, Move, Destroy, Create, etc.)

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

How flexable would the ''combat'' system be?

I meen maybe work at a ''conflict resolution'' module, rather then ''combat'' module...There are tons of genaric ways to resolve conflict, but combat is...well...combat. It imposes a sort of ''standard'' in RPG game design which can be limiting...A futureistic Cyberpunk type RPG where charactors hack into cyberspace...only to find that conflict resolution between them and the enemy A.I.s is basied on the same rules as physical world combat, sorta sucks (and limits the things that can be done in such an enviroment)...Then what happens in the same RPG where the players have another charactor who "jacks into" his car to race for cash? can''t really have car races basied on combat rules...