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