Sign in to follow this  
pTymN

The limits of data drivenosity...

Recommended Posts

Hello, I've written an XML loader that consumes an XML file. I can create physics bodies, outlines, joints, springs, buttons, doors, link various events together, and link the graphics to the physics bodies. It seems too easy. How far can I go? At what point could things get complicated enough that it is simpler to write the bulk of something in code rather than use XML? I'm just a little confused, because I have always thought that the boundary between "best represented as data" and "best represented as code" was much more towards the code side of things. However, since my gameplay behavior is 90% setting up physics and letting it do its thing, I think that my assumption was wrong. How wierd it is to see an actual black box device like a physics engine doing its job without a leaky abstraction. I would appreciate any thoughts that you guys might have, especially if you encountered a situation where you had to drop a 100% data driven method of level designing, to a method that used a scripting language. I know that I'm being clear as mud, but work with me here. It just seems too easy... -Tim Kerchmar

Share this post


Link to post
Share on other sites
The data/code ratio of your game should be approximately the same as the teamsize/engineer ratio.

Share this post


Link to post
Share on other sites
Data can be code and code can be data (scripts). In representing everything as XML, you might be selecting a poor choice of data representation (a scripting language might be more expressive and more easier to understand beyond a certain point).

In other words, it's somewhat erroneous for you to be considering "scripts" as "code" here; they're just another form of data. The benefit to data-driven approaches are that they allow modification of the behavior through alteration of the data (scripts), not the "mother code" (code that requires extensive build cycles to change and redeploy).

Now, there may be issues regarding ease-of-modification if your scripts aren't simple enough or the people modifying them aren't technical enough. That's sort of a different issue though. On that front, I've never found it practical to use things like XML to describe things that are transitory or otherwise "in motion" (such as the thought process of an AI entity). XML and data files of its general kind have always felt too clunky or verbose for that; I prefer to use them purely for static-state data.

Share this post


Link to post
Share on other sites
Usually data driven doesn't work when you have a situation where the number of options is huge. For example in an rts game I'm working on you need to specify what happens when one unit attacks another and 90% of the time this is strait forward subtrack damage from targets hitpoints but its not always that way a worker mining gold is still techinicly attacking the gold mine and has a very different effect. To handle all the different unusual options with out a script would require an amount of data that would be unwieldly.

Share this post


Link to post
Share on other sites
There's no distinct boundary between data and code.

Compiled C++ is clearly code, and a graphics file is clearly data; however, the C++ code can contain a binary string that represents an image, and an image can be interpreted as code (different colors can be different op codes). Using the tool for what it is designed to do is a lot more productive.

A scripting system is usually more specialized than compiled code, designed to describe interactions between entities in the game that are themselves described by data and scripts. Usually scripts are used as code that is loaded at run-time like data. I think there is a smooth transition between scripts and data driven editors in that an even more specialized language can be represented with components that connect to each other and can be presented visually through an editor, providing a variable amount of flexibility depending on its design.

Edit in response to below post: A finite state machine could be described in XML as long as the actual processes were encapsulated in the states or components of states. An editor could allow a non-programmer to set state transition conditions and tweak the behavior produced by each state. Code would still be used for adding new types of conditions and behaviors.

[Edited by - Vorpy on August 1, 2007 3:48:03 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Data can be code and code can be data (scripts). In representing everything as XML, you might be selecting a poor choice of data representation (a scripting language might be more expressive and more easier to understand beyond a certain point).


Agreed, but I couldn't convince my team to use lisp, and the people that will be doing level designing are poor/non-programmers. I feel OK about them hooking things up in XML, which are then updated each frame in C++.

Quote:
In other words, it's somewhat erroneous for you to be considering "scripts" as "code" here; they're just another form of data. The benefit to data-driven approaches are that they allow modification of the behavior through alteration of the data (scripts), not the "mother code" (code that requires extensive build cycles to change and redeploy).


A full scripting language is an order of magnitude more work for me than the XML loader. All I'm doing there is grabbing values and feeding them to constructors and sticking the created objects into various update lists. That's easy enough, but providing Python bindings to my game engine and allowing things to cross reference each other may create not only headaches for engineering, but ultimately just be a slower version of what I can do easily enough in C++. Since the gameplay is mostly physics driven and the level designers are non-programmers, I want to present a simplified "widget A goes into slot B" kind of paradigm, where the code is a black box, but high level behaviors are defined easily enough.

Quote:
Now, there may be issues regarding ease-of-modification if your scripts aren't simple enough or the people modifying them aren't technical enough. That's sort of a different issue though. On that front, I've never found it practical to use things like XML to describe things that are transitory or otherwise "in motion" (such as the thought process of an AI entity). XML and data files of its general kind have always felt too clunky or verbose for that; I prefer to use them purely for static-state data.


I'm explicitly avoiding describing processes in XML. For example, if you hook up two objects to a spring, nothing in the XML describes how a spring works. The spring code is a black box that takes in k, rest length, and damping, and from the XML level editing guy's perspective, he only cares about adding/tweaking springs. I'm looking at useing the XML only for setting up initial state of the world, and for a basic hooking up between various kinds of objects, so that you can say which door this button opens.

You do raise a good point that I will keep in mind, which is that I should be alert to avoid decribing processes in XML. Maybe that's why its working out well for me, because up til now, I've not been trying to describe processes in XML, just initial state, which is really just data. I suppose that you are also implying that even trying to set up a finite state machine in XML would be wandering into the dangerous territory.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this