Hi everyone,
Here are some random thoughts about the future development of Warzone.
Things about the code that need changing imo:
- The graphics engine, including the GUI
As I said, I don't think it's useful to keep the current one. As far as
I could see there are four open source engines that run on Windows,
Linux and MacOS: OGRE, Irrlicht, Crystal Space and OpenSceneGraph. The
first three are of the "everything and the kitchen sink" variant (with
different renderers, file handling...) and include more than just the
graphics engine. The fourth, OpenSceneGraph, is just that - an OpenGL
scene graph library without much else (and thus my favorite).
One problem with an external engine is availability. OGRE in Debian
unstable is at version 1.0.6 (current is 1.2.4) and the last time I
tried, wasn't straightforward to compile. Irrlicht is not in Debian, but
was easy to compile. CrystalSpace in Debian is at 0.99, while 1.0rc is
available, don't know about compilation. OpenSceneGraph is current.
That's for Debian, I don't know which other distros include which
version of those libs, but if we use an external lib, it has to be in
lots of distros, and easily compileable for the rest, or we'll get no
end of questions like "i cant compile teh 3d engine help plz or ur teh
sukz". Or we include the engine (at least in releases), then we have to
keep it current and integrate it into the build system.
A new graphics engine needs the models in a compatible format which is
dependent on the engine used, of course. There's a format called
COLLADA which is intended as an interchange format to transfer data
between 3D apps, and so should be supported by most newer 3D apps. This
can be loaded directly by OpenSceneGraph (and I think OGRE as well), and
is supported by Blender (so transferring the old models to a new format
is no problem, once someone finds Rodzilla's Blender importer for PIEs
or I finish mine). For faster loading the models could be converted to a
binary format for releases (OpenSceneGraph has a converter for that,
don't know about the others).
For the GUI there's CEGUI, which is supposed to be quite good, but as it
includes other renderers as well (like Direct3D), it's perhaps a bit
too large.
- The network code
I have seen the discussion on the forum about this, I just want to
address two points: 1. There are libraries that do the stuff you have
talked about, so there's no need to rewrite that (but has all
disadvantages as listed with the graphics engines). One of those is
RakNet. Unfortunately the author has changed the license from GPL to a
CC license, which might or might not be compatible to the GPL (hard to
say, since the CC licenses were written for artwork, not code;
additionally, there are references to both the GPL and CC in some source
files). But there are older GPL versions available (if you search for
them). At least in Debian there seem to be no usable networking libs, so
we'd need to do something about that (like including the RakNet code).
And 2. The float issue. This doesn't only apply to networking, but could
be very important there. As floats are not accurate and can lead to
different numbers on different machines, _no_ part of the game state
should use floats (else the game state drifts apart between the machines
and the game desyncs - perhaps that's the problem right now, I don't
know the network code). Well, that the ideal case if you want to stay
deterministic, I don't know if that's easily doable with any graphics
engine...
- All game data should be externalized so it can be changed easier
All the magic numbers that are scattered throughout the code should be
migrated into data files and loaded on startup. If the scripting engine
is fast enough, even vehicle behaviour could be scripted, so the engine
just loads the data and executes it, and adding new units etc. just
needs new data files without any code changes. (So we have an engine
with a Warzone mod, and the possibility for completely new mods that
feel completely different - not just the same with different models.)
- General structure
The general structure of the code leaves a lot to be desired... I am
wondering if it's easier to start a new engine from scratch with a good
design, and make a Warzone mod for that than to change the existing
code...
Anyway, that's the development part. The other part is the community -
people that want to play and mod the game. How is it possible to keep
them interested while doing all those changes? Right now a lot of
questions are answered "this will change", so people will wait for those
changes to happen, and if they don't happen soon enough, they'll lose
interest.
Well, that's it for now. It's just talking again, and I have absolutely
no idea how much time I'll be able to spend actually doing something,
but I hope at least for a constructive discussion.
--
Harrison's Postulate:
For every action, there is an equal and opposite criticism.
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
