Nuts and Bolts

[Riel]

I've been wishing for an article like this for a long time. Your lists (and links) for various systems have already proved very useful in determining what it is that I need to learn. Clearly, every project will make different choices about which programs to use, but if I become familiar with one set, I assume it would help with the others?

[mikedsc]

Undoubtedly, I think, Riel. While I have no real experience in large-scale projects that'd require borrowing engines, I've noted that the real differences in engines are typically on a level of abstraction you aren't supposed to need to adjust anyway. The rest is ease of tool usage.

When I checked out ICE, for example, they apparently have their own scripting code (Slice) and utilities (IceUtil) to make modifications to suit your personal needs without mucking around in the original source.

I've checked out Crystal Space before (I read about it elsewhere.) and I'm familiar with SQL as is, so my interest was what Rickey meant by Architecture.

And, to echo Riel, thanks for providing the many links. I'm going go to and read the documentation for ICE now. :)

[MahrinSkel]

Just got back from State of Play, so I'm sorry if I'm a bit late responding.

By "architecture", I mean the lowest possible level of world behaviours. Every MMO needs certain things, the ability to define geometric regions, independant agents capable of various levels of awareness of actions/events around them and ability to take actions, influence tracebacks so that various effects can be traced back to their original triggers, and so on. And all of these need to happen in an efficient, scalable fashion, ideally with smooth scaling across multiple physical boxes.

At least theoretically, this low-level behaviour is independant of game type, physics, or anything else that actually makes a game distinct, just as a graphics engine doesn't have to be suited only to RTS games, flight sims, or shooters.

--Dave