Awesome i tells you my current game would have taken me twice the time to tweak and get playing how i wanted
if i didn't use the excellence of data driven design.

For anyone who doesn't know data-driven design is designing your code to read in data, values, filenames and basically
anything from a text file, also you can have it write out text files with data you need to use.
What really makes data driven design so good is it takes away the need to continuously re-compile your project
and instead you can simply change the data in a text file and it will be read in while the game is running, and what about your artists or gameplay designers who's brains almost explode at the sight of your mesh reading function, what if they could choose through there various meshes, manipulate scale,position, speed, anything via a text file
sounds great right

problem is that implementing all of this to work this well can be a real pain, old habits die hard so I'm told and if your used to having global variables and other such hard-coded styles then breaking the habit can take a while.

does anyone have any tips and help on how to design for data-driven from the offset? would rather personal findings than links to the wikipedia definition of data driven design

This post has been edited by stayscrisp: 23 Jul, 2008 - 08:39 PM

Well historically the idea of Data Driven design wasn't the concept of using text files as merely your inputs and settings to a program. It was the idea that you could build a program based on the data, not on the objects of a system. So instead of creating an object like a "car" and then feeding it data to tell of the cars color, number of wheels etc it would focus on the data you have like car information and manipulate that data through processes to achieve the desired output.

The problem with the idea is that it ties applications to the data. If the nature of your data changes, then you are left having to rewrite processes that manipulate that data which could be a lot more than simply modifying a class in an OOP approach.

Taking your example of providing textual input for a game and pulling data to and from files may appear to be a good idea for small games and such, it can be quite a hindrance in the long run. Giving users access to such data makes that data unreliable, it can become corrupted much more easily, and for bigger projects could turn into quite a chore managing multiple files and keeping it all straight.

Plus the slow access of hard drive file access may be faster than connecting to a database, but it is still slower than direct memory access. No use to read in and out of files when you could read in and out of memory. Reading files of the hard drive is always an expensive task for games and that is why you will typically find games "trying" to stay away from this as much as possible.

But I guess whatever works for you.

more for development than finished product

a lot of the mods you see would not have been possible to do without the inclusion of data driven design, as with it the game makers can give you there own version of scripting without exposing any of the games low level programming, i feel that with processors getting faster and the expense of reading data becoming almost unnoticable more games have gone down this approach and with user generated content being the in thing at the moment data driven design is becoming more and more popular, i dont think typically games try to avoid this its just time consuming to get right.

i have read many articles from top game programmers stating that they would prefer to have not one thing hard coded into there game, they would rather this be decided at runtime.

For my games I'm going to write a databaser .dll and .lib which works with a tool for me to define things like items, characters, ect. like you do in RPG Maker. It's a good tool for the RPG programmer. That way I can have data right off the bat and a way to easily write it and load it.

I had another version which was just macros. I stored all my data in text files, which actually macroed to actual programming code which loads those values into arrays. Pretty slick and I simply put #include "items.txt" right where I wanted it to be in the middle of a function I use called data_load_items(). This is the anti-mod version though since it gets compiled and smashed into the programming code so only hackers can modify it. Even then it's hard for them to do it since I use Acknex and it has built-in anti-modification measures.

WeaponSoul isn't going to do that though because not only is the main story line long, but it will have lots of replay value through quests just like Oblivion, so I'll want to design it so it can be easily mod-able and have ways to prevent mod clashes. But if I do this I can't really use Acknex and thus I'm at a general loss because I don't want to sit there for weeks to learn DirectX... Seems like the option though. I might just use OpenGL. While I won't spend the time to make a Linux port since I'm not insane, I'll separate the sound, graphics and input libraries so they can be modified easily to support the target system port.

If I finish it I'll upload the .lib version for all of you... IF I finish it


EDIT:
In that case I'll try to use generic file instructions so it works in lunix.


This post has been edited by WolfCoder: 25 Jul, 2008 - 09:48 AM

Porting things to Linux isn't all that much work as long as you stay away from system dependent APIs...

Except for I don't have Linux nor do I want it, and I'll leave it up to the Linux nerds to program 80 different copies of my wpnvideo.dll

Linux distributions are binary compatible.

If you want a port, get in touch with me and I'll help you out.

I never said anything about switching to Linux, I just said that porting things usually involves little more than a recompile if you're lucky.

This post has been edited by Tom9729: 27 Jul, 2008 - 12:21 PM

The good thing about data driven design is that it makes things a lot more flexible, and often offers an extra layer of both flexibility and abstraction.
All that 'work' to make the functions that read and parse the various data you need, well, you need to make that once. Then you will be able to reuse them for a long time and it will save you a lot of effort in the medium/long run.