 |
Mod Coding in Shogo
by Joost Schuur
The long term success of a 3D shooters these days can be directly traced back
to 2 things: stable multiplayer code and the ability to extend the
game using some kind of scripting or programming language to write addon mods.
In the case of the latter, the fan community has come to expect this from any
new title. Almost immediately after a game is released, people will begin to
ask how they can improve on it, maybe add a weapon that they think is missing,
rebalance the gameplay or even write entirely new gameplay variants (CTF anyone?)
For a developer, spending a bit of extra time and making mod coding easy will
pay out in the long run, when literally thousands of amateur (and some
professional) coders crank out a diversity of mods that they themselves would
never have had the time to developin house. Not to mention that out of this
same pool of talented coders on the Net, the commercial game developers of
tomorrow will emerge.
I spoke with Mike Dussault, lead programmer behind the LithTech engine about
some of the basicsbehind mod coding for Shogo and LithTech in general. First
a few comments on the what mods are coded in:
Shogo's based on DLLs written in C++. Each object type is simply a
C++ class, and you use macros to export properties so it can be edited
in DEdit.
The server-side smarts go in a DLL called object.lto. Currently, the
engine will only load that one DLL, but we gave it the .lto extension
because (hopefully) for a patch, the engine will load all the .lto DLLs so
people can add on behavior without having to recompile all the Shogo
objects.
The source for object.lto isn't on the shipping CD, but we'll be releasing it
along with some of our tools, hopefully by the time the game is on
shelves.
Next, he goes into more detail as I drew some comparisonsto similar
issues common to all of today's 3D shooter addon techniques:
To what extent will mod authors be able to modify the game? How much of
the gameplay lies in object.lto, how much is hard coded into the engine?
They will be able to modify anything on the server, and trigger client-side
effects as well, so they can basically modify the whole game. The engine
does the collision detection of objects, rendering, (optional) movement
physics, and provides messaging between objects. The game does all the
movement, collision handlers, special effects, etc.
Will it be possible to interact with and change the rendering engine of
LitchTech?
It won't be possible to directly change the rendering engine unless you're a
licensee. Something we'll be implementing in the near future for our own
games and licensees is a 'mini 3d api' that lets them make polies, texture
them, and animate them, but it'll only be available on the client side so
mod authors won't be able to use it.
How will level editors be able to interact with mod code, e.g. to trigger
scripted events?
Every class the mod authors make can have a bunch of properties that are
accessiblefrom the editor. There are a bunch of property types: numbers,
strings, vectors, rotations, colors, radius, etc. The mod author can set up
an object to send a trigger message to another object and the level designer
can just type in the message name.
Is there a security model in place to protect users from rogue mods?
No security model is in place currently, but everything happens on the
server so there's not much a client could do to mess things up.
Monolith is developing 2 LithTech engine at once with Shogo and Blood 2.
To what extent will mods be interchangeable Are you using the same base
classes for objects and actors?
It's hard to know how compatible mods will be. Blood2 and Shogo don't share
a lot of code, but new objects people write should work in both games as
long as they don't derive from a specific base class.
What got left out for LithTech 1 as far as mod coding goes? What is on the
drawing board for LithTech 2 that you can talk about?
For LithTech 2 (or halfway between 1 and 2), the API will be C++ only, which
will make a lot of things easier, especially messaging between objects.
We'll be splitting the engine's API interfaces into many smaller ones.
Right now, there is 1 interface with about 200 functions. We'd like to make
that more like 10 interfaces with 20 functions each. I mentioned earlier
the multiple .lto files to make it possible to mix mods with one another.
We'll be looking into COM+ which would allow the engine's interfaces to be
accessed from a bunch of languages.
Have you looked at other scripting systems for current and upcoming games
like unrealscript or Java? What made you stick with C++ DLLs.
We used to only support scripting in a language called DScript which was
very similar to Java. We ultimately ditched it in favor of compiled DLLs
because we were lacking complete professional tools. Being able to debug in
a debugger is a million times better than printf debugging, and with VC
6.0's ability to make changes WHILE DEBUGGING, people will be able to sit in
the debugger all day. DLLs also execute much faster than any scripting
language ever will. Losing DScript was the best decision we ever made.
Lastly, what kind of mods are you looking forward to the most?
I'm really hoping a CTF mod with runes is made. That was my favorite Quake
mod. There are a lot of Shogo levels that would be great for that. One
thing that's funny in Shogo multiplayer is players can stand on each other's
heads (they could stack up in a big pyramid if they wanted to) and they get
carried around when the bottom guy moves. This reminded me of the
multiplayer game Subspace where players could turret onto one main player so
that one player had a ton of firepower. I'd love to see something similar
in Shogo where 5 players could turret onto another player and provide a ton
of firepower! I'm sure anyone at Lith would be happy to answer any
questions people have if they're trying to write things like this (after we
release the source and they at least know how things work!)
Finally, see some examples of actual code
taken straight out of Shogo.
|
RSS Feeds
