Plan for Phil Carlisle

Man, Ive got soooo many things going on, so I thought I'd blurt them out in a .plan

So, first up, obviously after IGC I'm catching up again at work. That means getting all my project tutees up and running, making sure my admin is up to date, getting my email setup properly etc. Generally kind of "work" stuff.

Outside of that, Ive got a few pet projects to do. I really havent got time to do them properly yet, so they turned into student projects :)

My other email machine kind of died. Which is a bummer seeing as I need my mails, so I've got to put another video card in that machine sometime soon.

On the upside, Ive written the "indie guide to project disaster" with the help of Dave Myers, just needs some time to collect the screenshots and put it up on the scaryhead site.

I'm also back working on the AI pack. Currently working on the messaging system. This is actually something that is a major part of the games Ive worked on before that Ive felt has been missing from torque for a long time. So I decided to bite the bullet and complete it. I'll possibly create a resource or send the code along to ben once its done.

The idea is that you use a message to notify other objects *simobjects* that something has happened.

A typical example is something like:

player->sendMessage(MSG_EXPLOSION,&m_ExplosionPosition);

and you recieved it in a message handler:

crate->onHandleExplosionMessage(Msg explosionmessage);

I'm going to do my damndest to make it intuitive and easy to create messages and message handlers (believe me Ive been in message creation hell before). Also something I'm keenly aware of are issues involved when debugging, so I'll definitely add message trace functionality (on in debug, define MESSAGE_TRACE to trace messages etc).

Messages are great for one main thing. They reduce dependancies, which can help speed compile times a ton! Theyre also cool because you can notify multiple objects about something happening without having to know WHICH objects.

The message system will have a few key attributes:

Messages will be allocated from a pool, basically static pool so no allocations at runtime (helps consoles).
Messages will only be handled by objects which request to recieve them (opt-in)
Messages will allow re-entrancy (send a message, which sends another, which sends another etc), along with debug message stack tracing etc, to make sure you dont get into a "message storm".
Messages will be server side only (for now).
Messages are able to be sent from script.

But I think the main thing is that this AND the component system will basically make me a very happy bunny :)

On another note, Ive got plenty of business development to do. Contacting all the press I can find and letting them know about Scaryhead and our games.

In general, things are VERY busy of late. But thats a good thing :)