pdidoi

Pointer to a direct input device object instance.
No actual name, just 6 characters of notation.


class GameObject
{
    Vector3 Position;
    char* Name;
    Geometry *Renderable;
    //etc etc etc
    virtual int Use();
};


Which leads to classes like this:


class PickupObject : public GameObject
{
    float PickupRadius;
    virtual int Use() { /* special pickup code */ }
};


And this is a perfectly valid approach that's worked well for thousands of games. It also seems to be a very natural way of thinking about the way to structure your data.

The main difficult with this approach is that it's difficult to keep your objects both lightweight and easy to refactor.

The approach we're taking:

Build a very simple lightweight database. Take all your data, divide it up into logical units (hitpoints, position, model name, physics data, etc) then each object gets an integer identifier. If an object needs a position an entry is added to the position database with the object's GUID. Property inheritance is done through a parentage/archetype database.

Restructuring data becomes a data problem. Use of data goes through a common query type interface.

There are known performance issues if you're looking for data that isn't there. This should be solvable with a combination of caching and strict rules governing archetype construction.

It's a bit like turning all the data on its side, but it seems to cause a few difficult problems (massive refactoring, inflexibility, data bloat, etc) to become a number of simpler problems (simple database design, simple reference counting).

--

Note: Other games (especially the Thief series) used this approach before we ever thought of it. Our work has been significantly helped along by presentations by: Doug Church, Michael Doherty, Alex Duran, and others.

So, somewhere, sometime in the future, something bad might happen to someone within a couple thousand miles of you.

Not that we should ignore this, but it's idiotic to have CNN blowing the FUD trumpet.

Unless you happen to be in Iraq, in which case it's more of a "how many today" type of situation.

But it's bad to think about real people getting blowing up. It's much more productive for people to be randomly afraid of nonspecific threats so that they'll be happy when authority figures abuse and harass them because then the authority figure is Doing Something.

Ignorance is strength.
Fear is happiness.

I pull into the underground parking lot, take my ticket to make the gate open and a guy promptly pulls about 4 feet out of a parking space, blocking my way. He then sits there for about 2 minutes before backing his car straight into a bright yellow post. Fortunately, he went back into his parking space before he got out and started alternating between swearing and asking how to get out of the garage.

On my way out I got to see someone make a 5 point turn in order to turn left around a corner.

Just one of those nights...

And meetings.

Endless meetings.

Now, if you'll excuse me, I'll go write that command console that we're supposed to be sharing with the other team.

All SKUs of my project have been approved and I'm on vacation.

Good thing I went out of town for Thanksgiving, it was easier to not-do stuff while I was out of the office.

That was so relaxing.

No worrying about race conditions, or code executed during an interrupt, or running out of memory, or having a cascading failure that produces gradual fragmentation over the course of several hours. Just input data and output data.

So relaxing.

Broadcast message from root (pts/2) Tue Nov 2 16:38:27 2004...

go out and rock teh vote!!!!

Broadcast message from root (pts/2) Tue Nov 2 16:38:27 2004...

go out and rock teh vote!!!!

(and yes, I voted. My cubemate didn't, but that's because he's a Canadian citizen, and it's against the rules for him to vote.)

I can now safely and legally send my ex-wife ebola or black death.

I think I would've preferred the security cameras.

There's a lot of it, it's full of garbage, no one person controls it. It seems like it could make an interesting random number generator.

One of the old tricks for randomizing gameplay is to use the low bits off the analog inputs (or the disk seek times) to seed your random number generator. Seems like you could do the same sort of thing through statistical analysis of spam.

It's probably an intrinsically bad idea to allow an external source influence your security, but the idea of using spam to improve the security of commercial transactions seems deliciously ironic.