Question for the Developers (Working with original source release)

[kage]

kamaze is the webmaster, iirc.

[Chojun]

Update:  Check out my site (the dev log).  I got a generic application framework going for warzone, heh.  It is a set of C++ classes that calls just one of warzone's init functions just for testing purposes.

Anyway, as I was writing up the dev log for this morning, I realized something from my senior project that I could drop into warzone.  It would be FREAKING SWEET.  No other game out there would feature the same capabilities as warzone if I were to put it in there.  But I'm not sure if this specific API is free or not so I'll have to look into it before I do any work on it.

[Giel]

Firstly what kind of features would this "something from your senior project" offer? I'm genuinly curious and interested.

As for that "generic application framework" what aspects of Warzone are you trying to caputure in C++ classes with that ? E.g. just utility code, like stuff that currently resides in lib/* mostly? Btw, you might want to try and make them compatibile with the current Subversion trunk as well. I'm really interested in how you would want to "port" parts of Warzone to using C++ in a modular approach. Especially since WZ's code is rather non-modular, whereas good C++ code usually is modular. So not only will you have to wrap the stuff in classes, you'll also have to make large parts of the code modular before you can even start using C++.

PS [me=Giel]loves the idea of porting (parts of) Warzone to C++[/me]

I just think this will be a non-trivial task (I'm currently rewriting the sound code in C++ btw, see the sound branch for that).

[Chojun]

Firstly what kind of features would this "something from your senior project" offer? I'm genuinly curious and interested.

My senior project involved creating a home automation interface for windows Media Center.  It allowed you to turn on/off any light in the house, as well as adjust the thermostat from your TV.  ;D  But the cool thing about it, the thing that I could roll up into Warzone, is that our project featured a Voice Recognition API that would allow you to turn lights on/off and set the temperature with your voice.  It worked pretty well.  It is the Nuance Vocon3200 API and it was written in C.

So you could, for instance, say "Research" and the game could open the research menu.  Or you could select some units and say "Assign to Group 1", etc.  You could select a damaged unit and say "Repair" and it will go repair.  The possibilities would be amazing and endless.

One of the problems is that the API is NOT free.  I'm currently talking with the Nuance people and I'm going to see what kind of license I can negotiate.  They haven't given me a price yet..  In my experience, if they (any company) don't tell you the price up front then you're going to be paying through every orifice you can think of.  Hopefully they will reduce the license fee drastically for a non-profit open-source project.  If I'm able to get a license for the API, I'll have to go through a lot of effort to build up the voice recognition for Warzone into a .dll that can be distributed without the source code.  So, for instance, your project could interface with the .dll in a modular way that would allow the source to still be distributed among debian style groups, and also not break the GPL.  But this all depends on what kind of license I can get and how much it is going to cost.  I'm willing to pay up to a maximum of a few hundred bucks for it.

As for that "generic application framework" what aspects of Warzone are you trying to caputure in C++ classes with that ?  E.g. just utility code, like stuff that currently resides in lib/* mostly?

Just the application layer right now.  But when I say "layer," I guess that doesn't mean much currently as Warzone's code resembles a giant tangled mass of sweaty hair, much like what you'd find in the drain of a public shower.

Btw, you might want to try and make them compatibile with the current Subversion trunk as well. I'm really interested in how you would want to "port" parts of Warzone to using C++ in a modular approach. Especially since WZ's code is rather non-modular, whereas good C++ code usually is modular. So not only will you have to wrap the stuff in classes, you'll also have to make large parts of the code modular before you can even start using C++.

Yep, untangling said sweaty mass is the 2nd step.  The easiest way to start is with the Application stuff, and by that I mean initialization routines, shutdown routines, main loop, and windows-specific stuff.  This process will actually, in some ways, make the code even uglier at first since you have to take into account the different linkages between C and C++ code.

I'll explain how I plan on shuffling everything around a little later after I have a more complete understanding of the structure of everything in Warzone.  But a general overview would be this stupid picture that I've drawn up:

The application Gateway Interface is non-OS-specific and portable.  The windows or linux specific stuff would go in the Application Layer.  No more #ifdefs.  Just include the linux or windows project into the solution.  Stuff like the audio and graphics engines will work similarly, but I'm not even going to THINK about doing that right now.

Now as far as your subversion tree goes, I have never even taken a single look at it (ever) and I have no idea what has changed.  So that is one reason why I am starting from scratch.  I've studied the vanilla Warzone code ever since it was released, so I know more of what is going on with that code.  Another reason is that in my opinion, any further work on warzone, with as badly as it was designed (in a component/module sense), is coding it into a corner.  The game was only capable of so much, and as it was, NEWST and pumpkin-2 pretty much tapped out the engine even without being able to make changes to the source code.  This is why I am making an effort to release it from its constraints, and then I'll work on updating the various other components of warzone.

PS [me=Giel]loves the idea of porting (parts of) Warzone to C++[/me]

I just think this will be a non-trivial task (I'm currently rewriting the sound code in C++ btw, see the sound branch for that).

I've always been a strong supporter of Warzone's complete conversion to C++ (except the graphics engine).  Even before the source was released.  But I've always been criticized for it, so now the time has come for me to stick my money where my mouth is and do it myself.

[Giel]

So you could, for instance, say "Research" and the game could open the research menu.  Or you could select some units and say "Assign to Group 1", etc.  You could select a damaged unit and say "Repair" and it will go repair.  The possibilities would be amazing and endless.

I'm not sure this will be as intuitive or as fast as just pressing F3 or clicking the research reticule. I think that in Warzone just mouse&keyboard has the potential to be much faster to work with.

So, for instance, your project could interface with the .dll in a modular way that would allow the source to still be distributed among debian style groups, and also not break the GPL.  But this all depends on what kind of license I can get and how much it is going to cost.  I'm willing to pay up to a maximum of a few hundred bucks for it.

I'm pretty sure that all this licensing stuff will be a pain in the ass. You might want to look at something like Julius as an alternative.

Just the application layer right now.  But when I say "layer," I guess that doesn't mean much currently as Warzone's code resembles a giant tangled mass of sweaty hair, much like what you'd find in the drain of a public shower.

[offtopic]I still prefer "spaghetti" as a title above "tangled mass of sweaty hair" since the former doesn't make me want to use gloves while working on it.[/offtopic]

The application Gateway Interface is non-OS-specific and portable.  The windows or linux specific stuff would go in the Application Layer.  No more #ifdefs.  Just include the linux or windows project into the solution.  Stuff like the audio and graphics engines will work similarly, but I'm not even going to THINK about doing that right now.

It's always a good thing to abstract away from your target OSes. As for #ifdefs we don't have them a lot in the current code either, at least not in "user-code" only in utility code. Anyway, as for abstracting certain APIs, especially OS specific APIs, you might try the "Wrapper Facade" design pattern. At first glance, this article looks like a good description of it. I've got a book "Pattern-oriented software architecture Volume 2: Patterns for Concurrent and Networked Objects" that gives an IMO very good description of it. So if you could find that book in say your library I advice you to look it up.

Now as far as your subversion tree goes, I have never even taken a single look at it (ever) and I have no idea what has changed. So that is one reason why I am starting from scratch. I've studied the vanilla Warzone code ever since it was released, so I know more of what is going on with that code.

Well apart from being more readable (some of us just love cleaning out code) and being ported to OpenGL, OpenAL, SDL as replacements for Direct*, the difference with the original source should be more to your advantage (in understanding it) than making it lots more difficult. I suggest you just glance over some parts of the current development trunk to get an idea of what has changed.

Another reason is that in my opinion, any further work on warzone, with as badly as it was designed (in a component/module sense), is coding it into a corner.
...
This is why I am making an effort to release it from its constraints, and then I'll work on updating the various other components of warzone.

Well, that's sort-of exactly what we've been doing and are still doing: redesigning parts of Warzone (step by step) to make the code more manageable, readable and modular. (That's what I try to do at least, and I know some, if not close to all, others do as well.)

I've always been a strong supporter of Warzone's complete conversion to C++ (except the graphics engine).  Even before the source was released.  But I've always been criticized for it, so now the time has come for me to stick my money where my mouth is and do it myself.

Well you'll have to admit that it's a heck of a job to get done. I would suggest you start with porting the stuff in the lib/* directory as that is probably the most modular code you'll find in Warzone (and as such the fastest to port to C++). As for sticking money in your mouth: I suggest you leave it in your wallet instead and grab a Cola instead to fill your mouth with . But doing it yourself (i.e. porting (parts of) Warzone) to C++), is most certainly the best approach, especially if you don't pay anyone else to do it for you.

[Chojun]

OK.  Just another update.  I was able to successfully drop Warzone's main application stuff into my Application Layer Framework.  It all resides within one C++ class right now so not much has changed besides some organizational stuff under the hood.  So I'd say phase 2 is complete, and now I'm off to phase 3.

Phase 2 involved converting probably about 1-2, maybe 3% of the code to support C++.  I also had to change a lot of little things here-and-there, as well as change the project structure around a little bit.  The end result is basically just an executable that is about 12.1% smaller, and it builds about 30-40% faster. 

Phase 3 will involve disseminating everything I moved around and dividing the WZ App stuff from the Windows app stuff.  The WZ App stuff will go into the AGI while the windows-specific stuff will go into what I am calling the Outer Tier of the App Layer.  The outer tier will be completely modular and all the linux folks will have to do is stick a linux-specific project in in place of the windows-specific project.  The interfaces will all be known and available (and I'll be sure to have them well-documented) so that the porting process will be so easy it'll be mind numbing.  But keep in mind this is only the Application framework and there is a LOT of other stuff to warzone.  This is going to be a long process, as Giel has already explained

OK.  So I have a second, and I'll explain a little more about what the Application Framework entails (or, system core as the project is called, but that description doesn't quite fit so I'm going to think up a better name for it).  I built this framework a long time ago (2-3 years) specifically for Warzone, but I never had a chance to integrate it into Warzone.  Here are its basic functions:

Application:  This handles the windows-specific stuff.  Windows messages, the main game loop, etc.  When I get it fixed up all nice the portable AGI will handle only the main loop, and the Outer Tier will handle windows messages, etc.
State Manager:  Warzone has a number of different states that it can be in at once.  Most notably are video playback, main menu, normal gameplay, etc.  The state manager acts like a stack where you can push and pop different game states onto it.  So, for instance, you're at the main menu.  The state manager only contains the main menu state.  But then, you start a skirmish or campaign game.  The game pushes the normal gameplay state onto the stack and its associated functionality.  If you pause the game, a pause state is pushed.  If you unpause, the pause state is popped, etc.  Once the last state is popped from the stack, the game exits.
Process Manager:  Warzone has a number of functions that it calls every pass through the loop, depending on what state it is in.  For instance, the rendering passes, audio updates, frame updates, etc.  So refer to the state manager above.  If we're in the main menu, we don't have to worry about bullets flying everywhere and we don't have to worry about drawing fire and buildings and you get the idea.  But if we're in the game, we do have to worry about all that stuff.  So depending on what state the game is in, it'll push a number of functions into the process manager, which will in-turn be called every game loop.

It probably won't be limited to these different functionalities.  I'll probably also include a Data Manager class that will replace the WDG stuff, but I haven't written said class at all.  Actually I have, but it ended up being such a mess that I stopped work on it (that was about 2 years ago).

Anyway, that's it for now.

[Giel]

Phase 2 involved converting probably about 1-2, maybe 3% of the code to support C++.  I also had to change a lot of little things here-and-there, as well as change the project structure around a little bit.  The end result is basically just an executable that is about 12.1% smaller, and it builds about 30-40% faster. 

I guess by "converting code to support C++" you mean making sure all links as C++ code (i.e. without extern "C" stuff)?

State Manager: Warzone has a number of different states that it can be in at once. Most notably are video playback, main menu, normal gameplay, etc. The state manager acts like a stack where you can push and pop different game states onto it. So, for instance, you're at the main menu. The state manager only contains the main menu state. But then, you start a skirmish or campaign game. The game pushes the normal gameplay state onto the stack and its associated functionality. If you pause the game, a pause state is pushed. If you unpause, the pause state is popped, etc. Once the last state is popped from the stack, the game exits.
Process Manager: Warzone has a number of functions that it calls every pass through the loop, depending on what state it is in. For instance, the rendering passes, audio updates, frame updates, etc. So refer to the state manager above. If we're in the main menu, we don't have to worry about bullets flying everywhere and we don't have to worry about drawing fire and buildings and you get the idea. But if we're in the game, we do have to worry about all that stuff. So depending on what state the game is in, it'll push a number of functions into the process manager, which will in-turn be called every game loop.

I think this really is an intruiging approach. I think I would make the state manager nothing more than a simple std::stack of (smart) pointers to states. Then I'd make an abstract base class which provides an interface for the Process Manager's duties. Then I'd implement different states simply as derived classes of this abstract base class. So switching to another state would become as simple as (pseudocode):

Code: Select all

Switching state:
smart_ptr<ProcessingState> nextState(new MainMenuState);
stateManager.push(nextState);

Using "current" state:
void ProcessManager::Process()
{
    stateManager.top()->Process();
}

I'll probably also include a Data Manager class that will replace the WDG stuff, but I haven't written said class at all.  Actually I have, but it ended up being such a mess that I stopped work on it (that was about 2 years ago).

You might want to try to use PhysicsFS instead of WDG (search for "doxygen" on that page to find a manual). After you've initialized the PhysFS library you can use std::ifstream and std::ofstream like PhysFS wrappers. You can find my implementation of PhysicsFS file based streams rather useful (it's entirely template based, so you'll only need that file). The classes PhysFS::ifstream and PhysFS::ofstream derive from std::istream and std::ostream respectively (just like std::ofstream and std::ifstream do). This should enable you to transparently use both the PhysFS variants as well as the STL variants of the file based streams. Just declare a function that needs to read from a file with an argument list like (std::istream& input), and for functions that need to write use (std::ostream& output).

[Chojun]

Quick Update:

I've had a busy week, but I've still been able to get some stuff done with the WZ Original Source

I don't want to double-post on myself so go check out my Development Log on my site:

http://www.cs.utah.edu/~gilmore

In brief, check out the screenshots section.  I turned on the radar scan from the PSX version of the game..  It is a nice effect   There are some other things from the PSX version that I would like to re-enable but I'll get to them as they come, down the road.

Quickly, regarding FileSystems...  I haven't decided what sort of file system I'm going to use.  I like how this project has essentially supported use of Zip files for the archives.  I bet the compression alone is nice since most of Warzone's data files are human-readable text...  I will probably end up providing interfaces that will allow each individual OS developer use whatever they would like.  All the game cares about is that it gets the data it's looking for.  But I like the Zip idea though.  It's a great idea, and one of the things that I DO like about this project.

[Per]

I turned on the radar scan from the PSX version of the game..  It is a nice effect

Any idea why they removed it from the PC version?

Where in the source is this located? I would love to see how it works, since I never played the PSX version.

[Chojun]

Any idea why they removed it from the PC version?

No, no idea.  There are actually a number of small differences between the PSX and PC versions.  There are even subtle differences between the Glide and DirectX versions, too   But I'll have to get my old computer out and fire up warzone on its 3dfx card, because I can't remember all of the differences off-hand.  But I do remember that the Glide graphics looked better than the DirectX graphics.  It was pretty obvious that Pumpkin Studios paid more attention to Glide than DirectX.

Where in the source is this located? I would love to see how it works, since I never played the PSX version.

Radar.c, DrawRadarExtras().  But if I remember correctly, you guys removed all of the PSX and glide stuff so you may want to consider reviewing what you actually removed because a lot of it enhanced the game.  Or, you can wait for me to uncover it and I'd be happy to point you guys to the changes and where to find them if you are interested in any of the PSX-/Glide-unique functionalities as I implement them in my project.

[Chojun]

In case you're curious, I stumbled across this video on youtube.  I'm not even sure why (or how) I got onto youtube, but here you go.  This is a german game review of the Retail Version of Warzone.  At least I think they're speaking German, correct me if I'm wrong.  Anyway, I bring this to your attention because they're playing the Glide version of the game.  How do I know, you ask?  Because...  I do   See if you can spot what's different about it.  The differences are subtle  

http://www.youtube.com/watch?v=FyBNMQ8C ... ed&search=

Also, I noticed on the dev list that you are planning on removing the screen shake option.  Such a shame...  Especially since I fixed it on my end to be quite a bit less annoying, and quite a bit more realistic.  Also, I fixed a bug where the screen shaking would become disabled after some time of game playing.  Anyone ever notice that one?  Where it would stop shaking after a while?

[lav_coyote25]

In case you're curious, I stumbled across this video on youtube.  I'm not even sure why (or how) I got onto youtube, but here you go.  This is a german game review of the Retail Version of Warzone.  At least I think they're speaking German, correct me if I'm wrong.  Anyway, I bring this to your attention because they're playing the Glide version of the game.  How do I know, you ask?  Because...  I do   See if you can spot what's different about it.  The differences are subtle  

http://www.youtube.com/watch?v=FyBNMQ8C ... ed&search=

Also, I noticed on the dev list that you are planning on removing the screen shake option.  Such a shame...  Especially since I fixed it on my end to be quite a bit less annoying, and quite a bit more realistic.  Also, I fixed a bug where the screen shaking would become disabled after some time of game playing.  Anyone ever notice that one?  Where it would stop shaking after a while?

the cursors were quite colorfull as compared with the ones we now use.

yes but only after a long..... game. ;D

[Deathguise]

Also, I noticed on the dev list that you are planning on removing the screen shake option.

That's a shame - I really like the screen shake, anyway i thought it could be turned off in the options.

[Giel]

Also, I noticed on the dev list that you are planning on removing the screen shake option.

Actually we just disabled it by default.

Such a shame...  Especially since I fixed it on my end to be quite a bit less annoying, and quite a bit more realistic.  Also, I fixed a bug where the screen shaking would become disabled after some time of game playing.  Anyone ever notice that one?  Where it would stop shaking after a while?

If you could post that fix here we could try & see whether this bug also exists in the current development trunk. A patch file against the original source tree should work.

[Chojun]

If you could post that fix here we could try & see whether this bug also exists in the current development trunk. A patch file against the original source tree should work.

Any good tutorials on how to make a patch?

Also, quickly, here is another video of the PSX version of the game:

http://www.youtube.com/watch?v=ipF0B54b ... ed&search=

Toward the end of the video you can see the minimap with the radar sweep line that I was talking about.  Also, notice the mission briefings...  ???  If you guys don't want to include the FMVs, then you could probably do something like that...