Unit & UnitType classes

Coordinator
Dec 12, 2008 at 2:05 AM
One of the issues I'm currently tackling is the basic design of the Unit and UnitType classes (prototype versions).  I need the classes to contain basic Panzer General (PG) data, such as type, name, owner, location, status (moved, attacked, finished turn), ammo, fuel, movement points, strength, etc.

I've posted an unfinished prototype of the Unit class (browse the Source Code for the Unit.cs file).  I'd appreciate feedback on it and any proposals for the UnitType class (which seems to be the trickier of the two).

Troy

Coordinator
Dec 20, 2008 at 9:20 PM
I'd like to know people's thoughts on initializing the various unit types (PzIIIJ, Pioneer, BT-7, etc).  A simple way would be to write each UnitType's values (ammo, fuel, spotting range, etc) to a text file and load them upon game launch.  Another way would be to hard-code the values in the game code (quick but dirty).  Another option is to somehow read the data directly from the PG data file(s).  I'm open to other suggestions.

If I go with the first version, it would be nice if someone wrote a quick editor where the user can select a unit from a DropDownList and edit its values.  To go with the third option we'd need thePG data file format and/or existing method.

Troy
Dec 21, 2008 at 12:42 AM
I'd do an XML file. It's got the virtue that it's easy to work with.

Someone should be able to write an export routine from the old program or an editor.

Ralph

Coordinator
Dec 21, 2008 at 2:34 AM
XML...good idea, Ralph.  I'll have to look into that.  I've handled XML before but it's been a while.

The game's UnitType import routine would need the name of the UnitType data file, which would be scenario-specific (since not all units types are available in all theatres/time frames).  I believe there would be one unit spritesheet bitmap file containing all the unit icons, though custom scenarios/campaigns could specify alternate unit bitmap files.  Not sure if the main unit bitmap filename would be in the UnitType XML file or not.

I'm currently fleshing out the UnitType class.  One of the UnitType properties I'm working on now is a ulong variable denoting special abilities/characteristics, like paratrooper, aircraft (flying), bridging, etc.  In conjunction with this is a ulong enum containing all the special abilities.  I plan to post what I have thus far tomorrow.

Troy
Dec 21, 2008 at 3:26 AM
Sounds good. I'm doing something similar with a master 'graphics' directory for the main files, and 'altgraphics' directory for game customization and scenario specific directories for any customization people want to do. It's worked out fairly well so far. I made the mistake fo going with custom resource DLLs for some things, but that's going to be fixed in the next patch. They're too difficult to work with.

XML has the advantage that you can work with it pretty easily in C#. The other huge advantage is that it's in UTF-8 so avalable in several languages.

You're also going to want things like the Icon and the Sound in the unit structure.

Ralph
Coordinator
Dec 21, 2008 at 1:29 PM
> You're also going to want things like the Icon and the Sound in the unit structure.

All the unit images reside in a single Spritesheet file (just like PG).  Scenario developers could create their own unit spritesheets.  The upper left X,Y coords for an individual unit's image is contained in the UnitType class (not the Unit class, since all instances of a particular type, e.g. Pz IIIJ, will use the same image).  Does this sound right?

> I made the mistake fo going with custom resource DLLs for some things

What kinds of things?  Me no comprendo.

> scenario specific directories for any customization

Do custom scenarios each have their own directory or is there a single "custom" directory?  Are custom scenarios installed in the file system by running an installer program OR is it a manual xopy process OR is there an in-game utility?  What happens if a scenario name is already taken?  Does the previous one get overwritten?

Troy
Dec 21, 2008 at 6:00 PM
> All the unit images reside in a single Spritesheet file (just like PG).  Scenario developers could create their own unit spritesheets.  The upper left X,Y coords for an individual unit's image is contained in the UnitType class (not the Unit class, since all instances of a particular type, e.g. Pz IIIJ, will use the same image).  Does this sound right?

Sounds good.

> > I made the mistake fo going with custom resource DLLs for some things

> What kinds of things?  Me no comprendo.

Right now, the language elements are all in custom resource DLLs. Unfortunately, I found out that there are several resource editors (including the VS one) that would corrupt my resource files when editing. Because of that, I'm moving to XML files for the separate languages instead.

> > scenario specific directories for any customization

> Do custom scenarios each have their own directory or is there a single "custom" directory?  Are custom scenarios installed in the file system by running an installer program OR is it a manual xopy process OR is there an in-game utility?  What happens if a scenario name is already taken?  Does the previous one get overwritten?

I got supidly complicated with this one<g>.

I've got a Graphics directory and an AltGraphics directory. If you've got a scenario named 'Test', then I also look in the ScenarioDirectory/Test then the AltGraphics/Test and Graphics/Test then AltGraphcis then Graphics directories. I do this for all resources. I actually went a step further and check the scenario name for a vX.X string and strip it off to allow for smaller deployments of sceanrio file only. That is, Test v1.0 and test v.1. both use the Test resources. I'm not sure that anyone is actually using the v features, and most sceanrio are deploying to the Graphics/Test directory.

It's an XCopy deployment. I'm thinking of including the extra text/graphics/equipment in the save games since that would let me deploy to the ScenarioName directory isntead of the Graphics directory, but I'm not sure what it would do to the file sizes. This would make PBEM easier, since only one person would need to have the scenario installed. I'd have to provide some method of verifying that the person didn't cheat if I did this, though.
 
When you save something in the editor, I generate a checksum of the numeric fields so that I can validate it everytime it's loaded so that I can warn people if the scheckcums don't match, which indicates that the equipment file doesn't match. I don't validate the string fields to allow for people to play with different languages.

Way more complicated than you need for the first release, and if you're not doing PBEM, it gets even simpler.

Ralph
Coordinator
Dec 21, 2008 at 7:21 PM
I'm moving to XML files for the separate languages instead.

Makes sense.  Sounds like the easier path.  I haven't begun to consider language support.

> This would make PBEM easier, since only one person would need to have the scenario installed. 

That sounds interesting but I'm skeptical.  I would think the app would need to compare the save game's data checksum with the installed scenario's data checksum (or similar mechanism).  Plus, putting all the briefing text/etc in the save game sounds like bloatware (perhaps for good reason, though).  I'm probably just missing the positive aspects.

What exactly encompasses a scenario?  My hunch is there is always custom briefing text, custom parameters (start date, victory conditions, etc) and custom order-of-battle.  A scenario may or may not also consist of a custom map, custom unit images and/or custom unit data.  If any of these are custom then the scenario file must contain filenames for the custom items.

Troy
Dec 21, 2008 at 7:47 PM
> > This would make PBEM easier, since only one person would need to have the scenario installed. 

> That sounds interesting but I'm skeptical.  I would think the app would need to compare the save game's data checksum with the installed scenario's data checksum (or similar mechanism).  Plus, putting all the briefing text/etc in the save game sounds like bloatware (perhaps for good reason, though).  I'm probably just missing the positive aspects.

Right now, I need to have both people install the scenario. If I copied over all the data, then only one person would need it installed.

> What exactly encompasses a scenario?  My hunch is there is always custom briefing text, custom parameters (start date, victory conditions, etc) and custom order-of-battle.  A scenario may or may not also consist of a custom map, custom unit images and/or custom unit data.  If any of these are custom then the scenario file must contain filenames for the custom items.

Since I'm creating a subdirectory based on the scenario name, all the filenames are the same, I don't need to store the filenames. ClearTerrain.bmp always has the same name no matter which scenario it is in.

Ralph
Coordinator
Dec 21, 2008 at 7:52 PM
Anyone have thoughts on how to handle nationality?  I currently have a UnitType instance variable (private int m_Nationality) with the thought that there would be a class/struct containing nationality info (id, name, flag image, team#).  When a user goes to buy new units, UnitTypes tagged with his team# would be listed (e.g. German + Italian for the Axis player).  Not sure if this is the way to go.

Thoughts?

Troy
Coordinator
Dec 21, 2008 at 8:02 PM
Here are the current member variables within the UnitType class.  Feedback solicited.  Note: not all the PG attributes are included (e.g. naval ratings).

        #region Member Variables

        private int m_AirAttack;                                        // anti-aircraft combat strength
        private int m_AirDefense;                                       // combat strength vs attacking aircraft
        private int m_Ammo;                                             // ammo supply points
        private DateTime m_AvailabilityEnd;                             // last availability date
        private DateTime m_AvailabilityStart;                           // first availability date
        private ulong m_Characteristics;                                // e.g. Bridging, air transportable
        private int m_CloseDefense;                                     // close-combat strength vs. infantry
        private int m_CombatRange;                                      // 1 for most units
        private int m_Cost;                                             // prestige cost to buy
        private int m_EntrenchmentRate;                                 // e.g. inf types are better at entrenching than tanks
        private int m_Fuel;                                             // fuel supply points
        private int m_GroundDefense;                                    // defense rating
        private int m_HardAttack;                                       // combat strength vs. armored ground units
        private int m_ID;                                               // unique ID number
        private int m_Initiative;                                       // first to shoot, wins
        private GroundMovementClass m_MovementClass;                    // e.g. Wheeled, Tracked
        private int m_Moves;                                            // no. movement points
        private string m_Name;                                          // e.g. Psw 233-8r
        private int m_Nationality;                                      // 0=German, 1=Italian, etc
        private int m_SoftAttack;                                       // combat strength vs unarmoed ground units
        private int m_SpottingRange;                                    // hex range for spotting enemy units
        private int m_SpritesheetX;                                     // leftmost coordinate
        private int m_SpritesheetY;                                     // topmost coordinate

        #endregion Member Variables

Coordinator
Dec 21, 2008 at 8:29 PM
Edited Dec 21, 2008 at 8:29 PM
Another quick question: what is a good tool to create an XML file containing a sampling of several unit types?  I don't want to have to type all the tags by hand.  I want to be able to enter all the property names/types of the UnitType node and then create a few instances.  Ideas?

Troy
Dec 22, 2008 at 12:14 AM
Here's an article on a simple way to serialize a class.
http://support.microsoft.com/kb/815813

XMLPad is a free tool for editing XML that seems to work well.

Coordinator
Dec 24, 2008 at 1:25 AM
Thanks Ralph.  I'm combining your reference with http://www.ziggyware.com/readarticle.php?article_id=150 and http://jamesewelch.wordpress.com/2008/04/17/how-to-use-xnacontent-xml-files/ to utilize the xml content reader/writer classes.  Utility programming sure is boring.
Dec 24, 2008 at 5:39 PM
I agree about utility programming. The good part about it here is that you can make a basic workable one, and maybe someone can pretty it up later!
Coordinator
Jan 11, 2009 at 3:42 AM
After a couple of weeks or so bashing my head against the LCD monitor, I finally figured out the problem with the Unit's xml reader/writer: the order that the properties are listed in the Unit class (unit.cs) must match the order that the properties are listed in the XML file (UnitList.cs).  This makes no sense to me--I would think the properties must match between the reader & writer methods, but that isn't the case at all.  I now understand why the latter doesn't matter but I still do not understand why the properties' order between the class and XML files must match.  I'm still Googling to find an answer.

Anyway, I am once again fleshing out the Unit class/reader/writer/xml files to include all the properties originally created (though I am adding a few at a time to ensure I don't run into any other weird anomalies.  Then, I can finally get back to making progress on the project.

Troy