Sign in to follow this  
Norman Barrows

best methods: data driven code

Recommended Posts

Norman Barrows    7179

best methods: data driven code 

 

data driven is a way to reduce iteration time by eliminating re-compiles when constants change. but true data driven software would be able to read in both constants and code from an external source such as a hard drive, network connection, etc. code would be in some form such as interpreted scripts, p-code for a built-in VM, etc.

 

given the various ways to get data driven code into a piece of software and execute it, what tends to work best for games? 

 

A. interpreted scripts?

 

B. a VM and compiled p-code? if the VM compiler is fast, the impact on iteration time would be negligible. my own experiments with VM based games have shown this. Aside: i stopped that avenue of exploration when it came time to implement parameter passing. i concluded that a macro processor built on top of c++ gave you pretty much all the advantages of both a custom language plus a standard c++ development environment (debugger, profiler, lint, optimization, etc) with MUCH less work  - although it does not reduce compile times. As for VM's - their use in mission critical code is still questionable at the current performance level of today's PCs.  Someday we may all be able to use VM interpreted code and pretty much eliminate compile from the development iteration cycle (like basic and dos back in the day <g>), but it seems that that day is not today - at least for games of any significant size.

 

C. something else entirely?

 

D. all of the above ? <g>

 

E . non of the above ? <g>

 

- sorry i couldn't resist, it looked too much like a multiple choice test! <g>.

 

but seriously, what tends to work best?

 

i don't have any specific cases in mind, this is more looking towards the future as how to handle possibilities going forward - always think ahead!

Share this post


Link to post
Share on other sites
Zipster    2365

Aside: i stopped that avenue of exploration when it came time to implement parameter passing. i concluded that a macro processor built on top of c++ gave you pretty much all the advantages of both a custom language plus a standard c++ development environment (debugger, profiler, lint, optimization, etc) with MUCH less work  - although it does not reduce compile times.

 

Unless I'm mistaken, it sounds as though you're just dressing up C++ with some macros, which isn't really scripting. At that point you might as well have an engineer write the C++ directly. Plus I'm not sure whether or not we're to infer that you load and execute arbitrary assembly code at run-time, which scares me!

 

You want something that runs inside a VM because it provides you with a nice, safe sandbox you can easily control and maintain. You can provide users with the exact data and interface they should have to the game and isolate them from touching things they shouldn't and breaking the game (or worse). It's also typically easier to control their lifetimes independently of everything else, since many VM-based languages allow you to place them into their own island of memory that you can toss away wholesale when you're done with them. We've also used this to our benefit in the past as a simple error recovery mechanism -- if someone writes some broken script that puts the VM in a bad state, you can often just tear down and rebuild the VM on the spot and keep going (if you've already reported the issue and can't debug it immediately yourself, of course wink.png). Granted you need to be able to write such scripts in a way that they can auto-recover when re-loaded, but my point was to highlight another potential advantage of a VM. As to whether or not you're interpreting script directly or compiling them into a bytecode first, is more of a optimization and obfuscation thing than anything else.

Share this post


Link to post
Share on other sites
Norman Barrows    7179


'Norman Barrows', on 23 Jan 2015 - 6:16 PM, said:
Aside: i stopped that avenue of exploration when it came time to implement parameter passing. i concluded that a macro processor built on top of c++ gave you pretty much all the advantages of both a custom language plus a standard c++ development environment (debugger, profiler, lint, optimization, etc) with MUCH less work  - although it does not reduce compile times.
 
Unless I'm mistaken, it sounds as though you're just dressing up C++ with some macros, which isn't really scripting. At that point you might as well have an engineer write the C++ directly. Plus I'm not sure whether or not we're to infer that you load and execute arbitrary assembly code at run-time, which scares me!

 

that VM experiment i referred to was a test of the feasibility of a pure p-code VM game. while i was able to get 60fps no problem, the additional work required to create a fully functional VM language, suspicions that it might not be fast enough as project size grew, and the loss of things like compiler optimizations made me abandon the project. but its possible i did so prematurely.  instead i opted for a macro processor that translates to c++ code. this was ok, because one of my primary motivations in creating a vm language was to reduce the number of keystrokes required for code entry. and a macro processor did this while still giving me the power and benefits of c++.

 

my question today is more about how to do things going forward.  

 

so it seems it boils down to interpreted scripts or p-code, with p-code executing faster, but requiring a compiler.  i'd probably opt for p-code personally - but then again, i'm a performance junkie! <g>.

Share this post


Link to post
Share on other sites
SmkViper    5396
Having done the script-compiled-to-pcode thing I can tell you from experience that it was the only way we were going to get our design team to actually be able to customize interactions and provide fast iteration on game systems and features. Sure, sometimes we needed to move a scripted system into code for speed reasons, but by that time we had a blueprint to follow and most of the questions and problems with said system were known and overcome.

A scripting language can also do a lot of crazy stuff that you'd never want to do in C code by hand. Like hot-loading changed scripts and patching up the object data at runtime, all while the script itself is waiting for a function that takes 10 second to run to return.

In our case, scripts were used in places where the player wouldn't notice small delays in interaction ("small delays" being anything from a single frame to a second or two, depending on the system) and where iteration time was key to being able to make something fun. Edited by SmkViper

Share this post


Link to post
Share on other sites
Norman Barrows    7179


Having done the script-compiled-to-pcode thing I can tell you from experience that it was the only way we were going to get our design team to actually be able to customize interactions and provide fast iteration on game systems and features.

 

so p-code let you put more hands to the task of writing scripting/coding behavior - AND it let those hands work without the delays of a re-build.

 

it seems that so many things come down to whether you have non-coders on the team or not - and build times.

 


A scripting language can also do a lot of crazy stuff that you'd never want to do in C code by hand.

 

goto anyone? <g>.

 

self modifying code?   

 

FYI: as part of the anti-crack protection, caveman includes a small p-code VM that uses self modifying p-code, and is part of the main game loop! needless to say,its a very small bit of code for performance reasons, and the entire vm is coded in a RISC type manner. but its got all the basics, memory and fetch and IP, arithmetic and logic instructions, etc.

Share this post


Link to post
Share on other sites
kytoo    181
Most of the game to achieve data driven is through configuration files and scripts to do, but I think it would increase the programmer's maintenance costs.
In my project, I designed a virtual logic class module, as follows
 
this website is the cpp code:
 
Then I add any configuration dynamically through this file without the need to change any c + + code, but it can capture increases the configuration of the c + + code any changes.
The 'cpp class' implement a set of mechanisms through XML configuration files.  you can get calls by registering callback function when these properties changes at run time and not just a static configuration file.
 
This technology has been used in my game, if u r interested u can download and have a look.

Share this post


Link to post
Share on other sites
Norman Barrows    7179


When offered the choice of cutting features to improve the tool, designers preferred the annoyance.)

 

good for them!

 

users generally prefer more features to more/better un-released in-house tools.

 


Some built all the data through tools. There was no hot-loading of data. Designers could make changes, but in order to see them in game they needed to save their stuff, stop the game, build the game, and re-launch the game.

 

Caveman uses this for some of the stats for animals. newer parts of the animal (monster) type definitions are data driven, older parts are still hard coded.

 


Some have had built-in systems that allowed live tuning of data.

 


In this case designers could view and modify the data on the console but needed to write them down and hand-enter the final values.

 

Caveman has that, but in the form of a generic editor that can be hooked up to up to 10 objects at once with just one line of code each, then used in-game to adjust things.

 

Later i discovered i could do the same thing with the built-in rigid body modeler/animator.

Share this post


Link to post
Share on other sites
Norman Barrows    7179

I was thinking about this the other day, and it seems to me the biggest problem is passing data back and forth between game and VM code. or perhaps the fact that you have to define an api (param list) for each vm function.

 

for example:

 

in Caveman, there's an action called "inspect hut". its an action like an action in the Sims such as "water plant" or "Kick garden gnome".  in this case, the action handler code increments a counter. when the counter hits a limit, it displays a message saying what the quality of the hut is. 

 

so i was thinking about how to write the action handler using vm code.  the game code owns the counter. so it would have to pass that by reference, and the vm code would increment it and return it.  the vm code would also need access to all the other game variables required: hut quality passed by value, and current action passed by reference, so it can be set to NONE when the action completes. the string would be in the vm code.

 

so that's counter, hut quality, and current action that have to be passed between the game and VM. three params, not so bad.

 

but i also have much more complex action handlers that use as many as one to two dozen parameters, many of which are constants stored in global tables. i suppose that if access were non-global, they'd have lots of parameters too.

 

to get around this passing of lots of info between game and VM, you implement more and more in the VM. 

 

so you'd implement start_inspect_hut_action AND inspect_hut in VM code, and it would store the counter, limit, and message string in VM code. only the current action would be a parameter. and you could simply make it return 1 if the action completed, and zero otherwise and set current action accordingly in the calling code, eliminating parameters entirely.

 

but following this trend, more and more code becomes vm. at some point, performance may become an issue. and the project becomes less "data driven" and more "written in a language that compiles faster".   the ultimate evolution of this would probably be a game done almost entirely in VM code, with just mission critical stuff done with c++ (or whatever). or perhaps even a pure VM game where the vm language included high level mission critical routines such as builtin_render_queue.render_all.

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