Warzone 2100 Forums

i'm looking through the code at the moment, and some stuff isn't making sense to me based on what i remember (and any times i've looked up this kind of language stuff on google, i'm often left hanging):

so i'm seeing UBYTE types and UWORD types... fair enough, but i though a WORD was 8 bits for x86 systems, and for nearly all architectures, a byte is also 8 bits. i'm guessing i'm way off.

also, is there not some kind int8 or int16 types, etc, that can be used, that are more portable since they are not architecture dependent (on an x32 machine, something like a int8 would just use 8 bits, whereas on the x86-64 compilation, it would still use 8 bits). if this is the case, how many problems would i cause if the first thing i did was to go through the source bit by bit (at least the parts that aren't entirely degenerate, if any), and change them over to platform-independent but equivalent types (using 32-bit machine compilation as a reference)? or if those types don't exist, how about doing a set of typedefs within a set of ifdefs in an include to provide those types, or via makefiles?

huh... now i'm running into SDWORD, which i don't think i've ever used before...

is there some list or reference anyone knows of that shows all the datatypes based on architecture, so that i don't have to run sizeof on each of these?

finally, are we pushing for c++ or staying with c, just so i know

also, what does the {"string", int} shorthand syntax do? does it create a type-map?

BYTE is 8 bit, WORD is 16 bit, D(ouble)WORD is 32 bit in the x86 world (the S/U is for signed/unsigned). Those are defined to the platform independent SDL types (Uint8, Sint8, Uint16...) in lib/framework/types.h, and in new code, using those types directly is preferred.

{"string", int} initializes a "struct { char*, int }".

The code should compile with "g++ -fpermissive" (it's quite impossible to make the current code strictly C++-compatible, with all the casting and stuff), but no C++ features are used. I think converting some things into classes will make the code more readable and modular, and Chojun(?) posted something about that a long time ago on rts.net, but there was never any code to integrate.

okay, cool. thanks for the tips. heh, and i thought signed variables were implicit.

even though i'm not great with c or its derivatives, i have done a lot with other languages, and one tip i can give for any given programmer:

if you don't need inheritance, than don't use a class (use a struct instead, as those also support functions, for example) except for a few cases were you really want to make sure nothing is messing with the data types without doing it properly: even then, a struct with a data-handling set of functions is just as good in this case, as long as you make sure that no one directly alters the data members that are to be handled via functions (you can grep for that).

one thing i see too much of is using inheritance when it isn't needed, and ending up having something less flexible than when you started, and wherever possible, use interfaces instead of inheritance, as it's signifigantly more flexible, as interfaces are almost always preferable to multiple inheritance.

EDIT: out of interest , do we have any online code documentation?

kage wrote: is there some list or reference anyone knows of that shows all the datatypes based on architecture, so that i don't have to run sizeof on each of these?

http://svn.gna.org/viewcvs/warzone/trun ... iew=markup

cybersphinx wrote:The code should compile with "g++ -fpermissive" (it's quite impossible to make the current code strictly C++-compatible, with all the casting and stuff), but no C++ features are used. I think converting some things into classes will make the code more readable and modular, and Chojun(?) posted something about that a long time ago on rts.net, but there was never any code to integrate.

That's right, when the code first came out, I went through it front-to-back and decided that it was just a big tangled mass of sweaty taco vomit.    IMO the playstation, not Eidos' inferior marketing strategies, was to blame for Warzone's shortcomings and ultimately, its demise.  I could see the general form of the orignal code that Pumpkin had brought into the project.  Sorta like a human skeleton.  However, the original code resembled more of a very morbidly obese man who was consumed by cancerous growths that had eaten away his flesh into a very remotely recognizable mass.  Anyway, what I'm saying is that Pumpkin had a good product, but when they started to integrate it into a form that could be run by the PSX, the code became just plain unmanageable.

The reason why we didn't see a Warzone sequel is pretty clear to me...  There is no way they could've created a new product from the old code, judging by what a sorry state it was in at its release.  Someone early on in the redevelopment project estimated that Warzone's 250,000 lines of code and 4 years of development may have cost around $8,000,000.  This is paying the software team a modest wage.  Warzone "2" would've needed to be built from the ground up.  As the redevelopment or "resurrection" team has probably seen full well, the code will only go so far; a bubble-sort algorithm, no matter how highly optimized it is, is still a bubble-sort algorithm.  There is no way a downsizing publisher such as eidos, at the time, would've been on board with Pumpkin Studios spending a few more years dabbling on a brand new project for a game that, dispite its revolutionizing the RTS genre, provided very sub-standard profits (the PSX release, which had apparently been pushed by Eidos, was an utter failure).

Early on, I did in fact suggest the entire code-base (except for the lower level things, such as memory-management and rendering routines) be converted into a C++ application framework.  Modular, object-oriented, portable, and moddable.  This would require Warzone to be torn down and rebuilt piece-by-piece, from the ground up.  The four attributes are a must for any continued success.  Let me explain.

Modularity:  Currently, if you pluck out a system in warzone's code, the entire thing breaks down and crashes.  Warzone was built like a house of cards.  One wrong move, even during runtime, and the whole thing comes plunging down to the ground.  This situation cannot exist (and does not exist) in any successful game to-date.  The most impressive feat in game-software development is Unreal Tournament (GOTY to 2004).  With a game such as this, no super algorithms and so-forth are needed to create a good application.  I've seen the source code to Half-Life 2.  There is nothing special in there that you won't see anywhere else.  What is special, is how the framework was designed.  With Warzone, modularity would entail being able to completely isolate the game's systems, and have it still function properly.  That is, for instance, being able to completely yank out the sound subsystem and all of its components, and have the game work completely normally, just without sound.

Object-Orientation:  This builds on the above...  The game's components function as objects, so why not be coded as objects?  A tank in Warzone is an object, is it not?  It has code, data attributes, functionality, and physics associated with it, doesn't it?  Then why not provide them data encapsulation (classes, interfaces, etc)?  Currently it is a nightmare trying to add functionality to the game because it requires a myriad of changes to the REST of the game!  In the application domain, C is a dead programming language.  It is only useful for very low level applications, such as Operating Systems.  I've done Operating System programming, and I know.  C is useless for the higher-level stuff, and it only causes problems for that kind of stuff.

Portability:  This is for our Linux friends.  In the early days of the Redevelopment project (NEWST, Pumpkin-2), we had no idea that Linux developers would even take an interest in the game.  It wasn't even a thought.  Not even an infinitessimally small one.  So, the source release was announced on slashdot, in the Linux section, and we were innundated with Linux hopefuls who were sick of twiddling their thumbs and toes and wanted to develop the first cool game for Linux (sarcasm).  So at this point, there were those associated with the Pumpkin-2 society, the talkers, and those who came in from Linux society, the doers.  The project forked (more appropriately, it changed directions) from where we in Pumpkin-2 had hoped to lead it.  Coyote (bless your heart, I love ya man! ) was busy pulling his hair out in large chunks while a few linux folks tinkered around with the code and got it to compile under linux.  Anyway, long ramble short, portability is more important to keep the current development society cohesive, and to be able to target as many platforms as possible.

Moddability:  Ok, so the debian purists are squabbling with people over whether or not the content on the CDs are covered by the game's release license.  Basically, they're not because the majority of the CD's content was not included in the source download.  But no-one has ever answered the question I've asked from time-to-time since the source release:  Will we get sued if we use (or distribute) the game's CD content?  I think they dance around this question bec-- well, nevermind.  I'm not going to speculate because it really doesn't make any sense.  Eidos is *NOT* going to sue us over a game that was a disappointment to them, and Pivotal Games/SCi are *NOT* going to sue us for something that they're *NOT* going to use in the future, nor for something they're *NOT* currently producing or even making a profit from!
Anyway, without the game's content, a requirement then stands such that we need to provide content for a content-less game.  Got it?  Warzone was scriptable, but only to a certain extent.  It was difficult to add custom units into the game.  There was only a very rudimentary map editor.  And, people just plain get bored of playing the same game, over and over again.  There are many "magic numbers" and so-forth hard-coded into the game (I'm not sure how it stands currently), but Warzone needs to have two domains:  The application domain, and the data domain.  The data drives the application.  Modifying the data modifies the application (nearly everything about it, too).  More work must be done to externalize from the game as much as is humanly possible.

Any work that is being done that don't move toward these goals is simply just work being done to code it into a corner.  Anyway, these are just some of my feelings.  But again, like I said above, there are those, like me, who like to talk, and there are those, like DevUrandom and Per, who like to DO.

(I'd do if I weren't taking so many classes every semester, but alas...)

i entirely agree with chojun, but with the following addendums:

modularity: you can almost never have too much modularity/granularity -- this can be as simple as isolating a section of code in a code block

object-orientation: object orientation is great, but i've seen it abused so many times: do not overclassify... as an example, do not create a track object and a half-track object when the only thing that seperates them is speed and ability to go over rough terrain... try to keep it data centric at all times, as chojun mentioned in the "moddability" section: if you start making it so that tracked units can go over certain types of terrain than wheeled units cannot, do not make a seperate class for that, since both objects still do the same thing (they both either can or cannot go over certain types of terrain), so instead, in the common "vehicle" class, just add something like a "terrain_speeds" array.

from my experiences in computer science courses, far to often i've found they teach action-centric approaches to object-orientation, which is usually really horrible and inefficient for game design: they might teach you to create a "person" class, with the methods "walk" and "run", even though walking and running are really the exact same type of action, whether or not they look different. in other words, use object orientation, but never create a subclass to add new functionality when similar functionality is found in sibling classes -- just use the base class with a shared datatype.

i'm all game for ripping out and rewriting granular (and where needed, modular) code for this game piece by piece, but i am thus far the kind of person who talks but does not do... we'll see if i can manage to change that.

wz is object-orientated imo,though it's implemented using C:

all 'objects' including units and buildings in wz are BASE_OBJECT,they just convert it to/from other forms such DROID,PROJ_OBJECT,STRUCTURE using type casting with a pointer pointing to non-base_object data instead of C++ inhertance and derivation...

Besides,I think global update functions:global droid ai update,droid move update etc is more efficient than loop through droid list and calling different functions/measures of a class  in a rts games with massive amount of dynamic 'objects'.,e.g:

Procedure orientated:
for(droidlist->psCurr;PsCurr;PsCurr->Next)
{
updatemove(droidlist->psCurr);
updateai(droidlist->psCurr);
updateorder(droidlist->psCurr);
}

Object orientated:
for(droidlist->psCurr;PsCurr;PsCurr->Next)
{
droidlist->psCurr.updatemove;
droidlist->psCurr.updateai;
droidlist->psCurr.updateorder;
}

you also need these for object orientated:
droid::updatemove
droid::updateai
droid::updateorder
all these 3 will end up calling updatemove(this) updateai(this) updateorder(this)

Watermelon wrote: wz is object-orientated imo,though it's implemented using C:

all 'objects' including units and buildings in wz are BASE_OBJECT,they just convert it to/from other forms such DROID,PROJ_OBJECT,STRUCTURE using type casting with a pointer pointing to non-base_object data instead of C++ inhertance and derivation...

right. it's a common misconception that you actually have to use classes to have object oriented code, and using a pointer like that is equivalent to using interfaces, which is often as good as inheritance in most places inheritance is strong, and better than inheritance in a lot of other places.

Watermelon wrote: Besides,I think global update functions:global droid ai update,droid move update etc is more efficient than loop through droid list and calling different functions/measures of a class  in a rts games with massive amount of dynamic 'objects'.,e.g:

indeed, anything that reduces the number of function calls is inherently more efficient from a runtime performance standpoint, so loops are often better left as loops, as you're showing, instead of a loop calling some action method on each object.

Chojun wrote:Moddability:  Ok, so the debian purists are squabbling with people over whether or not the content on the CDs are covered by the game's release license.  Basically, they're not because the majority of the CD's content was not included in the source download.  But no-one has ever answered the question I've asked from time-to-time since the source release:  Will we get sued if we use (or distribute) the game's CD content?

No, we will not, but that is not what this issue is about, and that is probably why they have been "dancing around the question"

The problem lies with the existing distribution infrastructure in the open source world: vulentweers and companies donate servers, disks and bandwidth, so that the users of all the Linux distributions that makes use of remote package repositories, can apt-get|yum|emerge|cvsup|gem|pacman all the software they need.

And the core of the problem is that they cannot distribute anything without explicit permission, such as a GPL.

kage wrote: from my experiences in computer science courses, far to often i've found they teach action-centric approaches to object-orientation, which is usually really horrible and inefficient for game design: they might teach you to create a "person" class, with the methods "walk" and "run", even though walking and running are really the exact same type of action, whether or not they look different. [...]

I'm sorry that your CS courses weren't that great   OOP can be easily abused...  It sounds like your experience is that they subclass attributes instead of functionality.

wz is object-orientated imo,though it's implemented using C:

all 'objects' including units and buildings in wz are BASE_OBJECT,they just convert it to/from other forms such DROID,PROJ_OBJECT,STRUCTURE using type casting with a pointer pointing to non-base_object data instead of C++ inhertance and derivation...

Besides,I think global update functions:global droid ai update,droid move update etc is more efficient than loop through droid list and calling different functions/measures of a class  in a rts games with massive amount of dynamic 'objects'.,e.g: [...]

I think you're confusing objects in the in-game object sense with application (and lower) level objects, such as renderers, widgets, sound/network/input managers, memory manager, WDGs, etc...  Also, C++ objects don't hinder performance as much as you think.  Consider how the game stores the in-game units.  In a list, which is no different from how you would store the objects in a C++ OOP setup.  Currently, instead of simply referencing a pointer that is associated with an in-game object, you call the global "update" functions on the objects in the list.  Its not any slower in C++ than in C, and it's a whole lot more maintainable through objects.  Sure, not having function call overhead is nice, but calling an update function on a maximum of 800 (+/- some) in-game objects per frame really isn't THAT bad, especially in a game such as Warzone that is lean on resources anyway.

The problem lies with the existing distribution infrastructure in the open source world: vulentweers and companies donate servers, disks and bandwidth, so that the users of all the Linux distributions that makes use of remote package repositories, can apt-get|yum|emerge|cvsup|gem|pacman all the software they need.

I took a lower-level computer systems course this semester, which was doing development on *nix systems.  I partitioned my computer and put FC5 on it.  The coolest feature I think is yum-extender...  Being able to just connect to a microsoft-update-like server and download all updates possible for your computer is pretty nifty.  It was a pretty cool class...  I implemented a shell, learned how to implement buffer-overrun attacks, did some assembly programming, and finished up the semester by implementing my own version of malloc, realloc, and free.

Anyway, from what you say, which is what I firmly believe to be the situation with the linux folks here in this community, they want to keep the code under a clean GPL license, which is perfectly fine with me.  However, it was my understanding that, without GPL coverage with the CD content, they were going to remove all exo-GPL stuff from the game completely (for instance, the big thing for me, removing the ability to play the .rpl FMVs).  Is this true?  Does the latest WZ build still support CD content?  If so, then there is no issue, except for some kind soul forking over the bandwidth and server space to host the CDs for people to download.  I'd consider seeding some modified "data only" CDs on Bit-Torrent so that people can at least grab the files that they can't already get from the SVN/CVS servers.  "Data only" so that they can't have a fully working game from one download.  They'd have to come here to grab the remaining executables and so-forth from this community, which will preserve this community's integrity (integrity in a cohesiveness sense).

Chojun wrote:Anyway, from what you say, which is what I firmly believe to be the situation with the linux folks here in this community, they want to keep the code under a clean GPL license, which is perfectly fine with me.  However, it was my understanding that, without GPL coverage with the CD content, they were going to remove all exo-GPL stuff from the game completely (for instance, the big thing for me, removing the ability to play the .rpl FMVs).  Is this true?  Does the latest WZ build still support CD content?

No.

• WDG was scrapped in favor of WZ files
• The source code to the RPL player wasn't GPLed, so support for RPL was removed

See http://wz2100.net/wiki/faq#i_have_the_r ... om_the_cds

Chojun wrote: I'm sorry that your CS courses weren't that great   OOP can be easily abused...  It sounds like your experience is that they subclass attributes instead of functionality.

i'm sorry too, but in many ways, it was extremely helpful, as i found out first hand out bad oo-misuse turns out to be. "best-practice" is something i cringe at, as many programming classes in high-schools and colleges teach this in such a way as to lead students into full-blown code-monkeydom who create code that tries to do everything, but does none of it well (it'd almost not be false if i were to assert that some of these students, through supposed "best-practice" methodologies would aim to create a 2d image manipulation library that ends up being able to run artificial life simulations. that might sound good to some of you, but when you consider that their code takes 45 seconds to add a watermark to the corner of an image, you start to tear up.

Chojun wrote: Sure, not having function call overhead is nice, but calling an update function on a maximum of 800 (+/- some) in-game objects per frame really isn't THAT bad, especially in a game such as Warzone that is lean on resources anyway.

even though inefficient code might not have bad performance now, it does have bad synching problems in multiplayer games, and relying on currently small performance footprint will be as would a bullet in our gut if we ever decide to do something beyond small tweaks, such as replacing the tile system with some kind of free-form point-map terrain mesh.

Chojun wrote: I took a lower-level computer systems course this semester, which was doing development on *nix systems.  I partitioned my computer and put FC5 on it.  The coolest feature I think is yum-extender...  Being able to just connect to a microsoft-update-like server and download all updates possible for your computer is pretty nifty.  It was a pretty cool class...  I implemented a shell, learned how to implement buffer-overrun attacks, did some assembly programming, and finished up the semester by implementing my own version of malloc, realloc, and free.

interesting... most people remark on the package-retrieval systems: just type the name of the software you want, and it automatically installs and configures it... no more opening of a web-browser to find your software. that, combined with the performance -- in most cases i get 20% higher framerates running ut2004 on *nix than i ever did on windows, and when i up the anti-aliasing and aniso to 8x and 16x respectively, somehow it's still playable on linux (18-25 fps), while having had about 4-9 on xp, regardless of the renderer used in xp, but maybe that's in part because i have the flexibility to start an x-server that's running literally nothing other than the game itself.

Chojun wrote: Anyway, from what you say, which is what I firmly believe to be the situation with the linux folks here in this community, they want to keep the code under a clean GPL license, which is perfectly fine with me.  However, it was my understanding that, without GPL coverage with the CD content, they were going to remove all exo-GPL stuff from the game completely (for instance, the big thing for me, removing the ability to play the .rpl FMVs).  Is this true?  Does the latest WZ build still support CD content?  If so, then there is no issue, except for some kind soul forking over the bandwidth and server space to host the CDs for people to download.  I'd consider seeding some modified "data only" CDs on Bit-Torrent so that people can at least grab the files that they can't already get from the SVN/CVS servers.  "Data only" so that they can't have a fully working game from one download.  They'd have to come here to grab the remaining executables and so-forth from this community, which will preserve this community's integrity (integrity in a cohesiveness sense).

what you suggest isn't all that far out there -- many gpl'd games do this: the code is gpl, but all data must be obtained, *wink*, from somewhere else, that way we have no obstacles standing in the way of the project getting into distributions such as debian, or hosted by something like gna -- only issue is we'd need install scripts or something similar to allow the user to easily integrate non-gpl or ambiguous-license data with the gpl-based install.