After spending the entire night working on this, I've come up with what I hope is a workable plan. Instead of making a game engine and tagging on a script language to control it, I want to rework the entire engine to focus primarily on the script language, then adding functionality to the language by way of APIs. This would reshape the entire project to wrap all the game engine elements around the scripting language; I think this may be the best way to build the game engine.
Anyway, I'm working on a language syntax definition document, and as soon as it's ready, I'll post it here for comments and suggestions. I will also be putting together an API so the script language can control things in the game engine.
As it is now, XNA gives us two important functions, Update, and Draw. Update is where all the game logic is supposed to take place, and Draw is where all the game rendering happens. Initially, I wanted to run the scripts in the Update function, and have a fully built and updated world object that the Draw function can quickly render to the screen. However, I recognize that there are two completely different paradigms here I am trying to balance: procedural, and event-driven programming.
In a procedural design, there would be one script running at a time. It would be responsible for loading, controlling, displaying/using, and disposing of all game resources. This means that a game script would basically create a bunch of objects and loop through them every frame update processing game logic and what-not. This is the easiest to implement I think. Scripting would happen exclusively in the Update function, and any rendering APIs would build a world object that the Draw function would then render. After Draw finishes, Update would be called again, and the script would pick where it left off last frame. The scripting language would need a command to indicate when it is ready to sync, thereby pausing execution so the prepared game scene can be presented to the user.
In an event-driven design, I can imagine a "master" script creating game objects, and attaching scripts to each object. As the game runs, users click on objects and type on the keyboard, objects collide, or one object sends messages to other objects. These actions trigger messages to be dispatched to each object. Objects can bind certain message types to functions, thereby creating event handlers. Think of windows programming, where you click on a button and the program executes code in response to that. The same sort of thing is going to be happening in the game. One strength of this is that independent agents can be running from their own namespaces, meaning that a player can be controlling their character, while an enemy stalks that player down or plans a strategy. These sections of code can inherently be run in parallel, meaning the game can take advantage of modern multi-core processors. Unfortunately, there are two big downsides here. 1) designing a game to run in such an environment is extremely difficult and complex. When bugs creep in, finding them and fixing them can be very challenging, and as the complexity of the game goes up, you begin to see emergent behavior in the independent agents. The goal of programming this way is to create the emergent behavior to be exactly what you want, and have a very good game. 2) designing a game engine to work this way seems to be extremely complex. Instead of having a script interpreter, and a few classes for handling custom user data, now we have a full inter-process messaging system and process queue. It's kind of like developing a mini-operating system instead of just a single program.
So for now, I'm going with the procedural programming paradigm, but I'm always open to comments. If you have an opinion one way or the other, feel free to share them and discuss below!
No comments:
Post a Comment