Thursday, November 08, 2007

Business Logic as a Solution for Game Scripting

What I would like to see are more projects where the developers don't hand the designers a database, a scripting language or a hybrid of the two. Instead, take a cue from big business, where this is a solved problem (or less disingenuously, an offloaded problem). Businesses use business logic packages (Drools, Jrules, etc) to handle information exchange between a database and a user interface. It's not even that hard to embed or implement a full declarative language, such as Prolog in a server and use that as the scripting layer that designers write code for.

2 comments:

Speaking as a game developer who's tried using both drools and jrules (amongst others), the main problem is that their performance sucks.

The second major problem I found was that declarative programming is an infectious bug that is hard to control, and either people get swept up by it and start making things declarative that really shouldn't be (causing modules and even whole systems to be written, fail their performance or feature criteria, and have to be rewritten), or else react by fighting declarative code at every turn, and doing stupid stuff at interfacing points which is deliberately or subconsciously designed to kill the declarative code (usually by making it appear to run even slower than it really does).

F, U, D, maybe; but a pair of real problems nevertheless. Suggestions for dealing with them would be gratefully received :)...

For various reasons, declarative tools/languages aren't going to match the performance of C++/Java/etc game code any time soon. The best way to avoid a performance problem is not to use them in performance-critical aspects of your application. Keep it completely out the client, both the client application and the protocol used to communicate with it. Restrict it to high-level descriptions/contracts of game behaviour.

Explicitly restricting it from the start should go a long way toward keeping it out of performance-critical sections and reducing any fear that it will take over the codebase.