I've decided to change my terminology of how I describe my project a bit.

I've been saying that there's four main area of my project: The underlying architecture, the game engine itself, the virtual machine, and the scripting language.

This is all fine and dandy till you actually mention "virtual machine" and the first thing that pops into most people's minds is "Java." While Java is a Virtual Machine, it's not the type of VM I'm aiming at.. my hardware abstraction is done at the game engine level.. it's pointless doing it a second time once it reaches the scripts. So, I've decided to call that area the "Sandbox."

Since I haven't explained my Honours Project yet, here is a recap of what I'm up to.

I'm looking at ways of abstracting game logic from the engine itself. Of course, the main way to do this is via use of a scripting language and in my case, I'm using Lua in my demonstrations. Other ways include doing just what Java does and creating a full virtualised environment to play in, as well as running pre-compiled byte code, amongst other ways of loading in external logic.

As stated in my previous post, I've been writing the engine recently, so that I can have a short break over Christmas (hurrah!) with a working test engine under my belt to break and otherwise mangle during the course of my demonstrations and research.

Should you be unaware as to how important scripting actually is in regards to games, take a look at the ever-popular Counter-Strike. It was a modification to Half-Life originally, and was created by using the SDK that Valve kindly supplied with the game to play with the game logic. That's one form of scripting that I'll be looking at in the course of my research.
You also have "internal scripting" that you can't access at the end user level. What do I mean by that? All your RPGs and Adventure games feature insane amounts of scripting. Every Quest is in effect a small game script that ticks over and keeps track of it's own variables until you complete it.
Going further still, First Person Shooters feature a lot of scripting in level design, such as getting far enough along a corridor before all hell breaks loose and a fireball throwing imp jumps from behind a wall to flame you.
So you see, scripting is very important in games.

I'm going that bit further though and will be explaining that if your engine is portable as well, the games you write for the engine should work on any platform you port the engine to. Look at LucasArts with their SCUMM engine, which powered the best adventure games of it's time. It was ported to several platforms and brought the games with them. From DOS to Amiga and ST, all the way to more obscure platforms like the FM Towns and Sega CD.

This is rather topical as in the current Games Industry, there is a need to reuse as much code as possible due to every game requiring to be bigger and better than the last in every way, and the public wants it NOW! (*cough*Duke Nukem Forever*cough*)

So, back to the Sandbox/VM thingie at the start.
What do I mean by sandbox? Quite literally what the image conjours up. The Game Engine gives the Sandbox the functions and entities that are available for the Scripts to play with. It's job is to filter out any nonsense the Script may try to do, and convert it to something the Game Engine will understand.

The current method that I'm doing to hold all this together is a convoluted Event System. Every subsystem within the engine has access to the Event System and can create Events whenever they like. The Events are then polled by the Game Interpretor which sits in the middle of it all, and throws each subsystem tasks to perform when it's not sitting about being lazy and eating CPU time for the hell of it (something I need to fix ;) )

To further explain the whole complex spaghetti mess of it all, here's a picture :)

As you can see, the crux of the system is in the Interpretor area. It deals with Events, Scripting and Networking. It will send Events off to either the Client or Server depending on what the event is. For example, an event to move an object would do two things - tell the Server to update the object's position, then tell the Client to render it at the new position.
This abstraction means that neither Client nor Server cares as to where they are, they are being fed Events and nothing more which is also why the Network layer is within the Interpretor - multi-player gaming can be achieved fairly easily as all the Server or Client cares about is receiving an Event from the Interpretor, send the Event data over the Network and you're doing. Distributed Interactive Simulation :)

As you've probably noticed, this project has a slant towards two coursework assignments I'm doing, my Honours Project itself, and my Networking Project. I felt that both of them could be integrated in the same way ( a fancy event handling system ) and so far, I've been proven right.

Anyway, I've a lot of work to get done as I thought I had three weeks of classes left, not two!

Eep...