Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Level! Objects!

Sign in to follow this  


I have my system to the point where I can log in (with a hard-coded password), it exchanges authentication cookies, and it can send messages back and forth and dispatches them. I'm now implementing the "LoadLevel" message, which just takes a string which is the name of a LUA script.

That script contains calls to MakeObject(), passing a table, which is the parameters for the object.

An Object is actually just a collection of components. Each component is a collection of properties, and behaviors that are written in C++ (I will probably add script components later). Thus, the definition of an Object looks like a definition of a number of components, with specific properties being set on the components.

I've implemented this pattern as a research prototype before, one or two summers ago, after reading a similar system in Game Programming Gems 5, and this time, I could crank it out (just the framework, no concrete components) in an evening. Yay! Properties are "live" (you can subscribe to them, and when they change you will hear about it), and daisy-chainable (the defined output of a property is set to the output of some other property).

I decided to forego asynchronous I/O in this effort. Usually, I know that I'll want it, and start out by putting it in, but the code structure becomes quite ugly, with deferred operations flying all over and it's hard to know what's going on, because everything is asynchronous. I'm not going to port this code to consoles; in fact, I'll be lucky to ship it on PC at all, so synchronous I/O is fine for now (and SOOOOO much simpler!). If and when I ship and have a working product, I can go back and make it better.

The executable can spawn any of two separate threads: a server thread, and a client thread (which is the main thread). This allows me to run a "full system" in a single process, which makes debugging easier. Running them in threads also simplifies code structure -- previous efforts have implemented a fully event and context driven system, which is very flexible, but also impedes progress. This time, it's progress or die! (warts and all)

The client runs Ogre, and already has CEGUI. It "should" be easy to bring up a simple level by writing a single "static mesh" component. I have no physics or collision yet -- that'll come later. (ODE? Just bounding spheres/boxes? we'll see)

It's time to sleep.
Sign in to follow this  


Recommended Comments

Aegia is great for physics/collision and is completely free even for commercial use on the PC now. I'm not sure if you looked at using that over ODE, but I use Aegia for all of my game physics. Really great documentation, samples, support, and tools as well. (Collada support, Maya/XSI, etc)

Share this comment

Link to comment
I agree that the PhysX SDK is really great!

I've actually used it for small research demos before. I hadn't thought of using it for this project, because it will not be physics intensive, but perhaps I should.

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!