FIRST Video Game: Cementing auxillary file formats

[Astronouth7303]

While there is still a debate in the other thread, I would like the programmers that have expierience in this or who are planning to pitch in to start discussing the file formats.

I believe we will be working in MS VC++, but this hasn't been finalized.

Since we are using OOP, we need to decide what interfaces any DLLs present. Also, we need to decide on what format the CADs will be in, how each section is packed, etc.

Assume we will have to do this, and try to remain Engine independent.

we need:

• Game files, likely to be most complex
• Robot files
• field files

My thought is renamed ZIPs.

[Ryan M.]

Originally Posted by Astronouth7303

• field files

For these, we could just have a simple txt file that gives the following information on each line, where a line represents a single object of the field:

• Location - this could be something like x, y, z cooridinates
• Orientation - angle from?
• Piece name - there could be another file that gives descriptions of many standard field elements, for instance PVC pipes.
• Piece modifiers - the particular piece you choose might have several modifiers specified. For instance, with PVC pipes there is length, radius, etc.

Just some thoughts.

--EDIT--
This format would also allow easy tweaking by the user, without the need of much of an external utility. Very nice at the beginning.

[Astronouth7303]

For a text format, we could try the LDraw format for objects, with some additions. Or the zip has an LDraw for the actual field and XML for the descriptors.

[Mike Ciance]

if we want a setting, we can make a "crowd" by taking a large spotted bitmap image and slanting it to look like filled bleachers

[Astronouth7303]

Right. In the field zip, add a png CrowdTexture.png, and use it as a texture for those polygons.

[Ryan M.]

Originally Posted by Astronouth7303

• Game files, likely to be most complex

Yeah, these will be the hardest. How exactly do we put all the rules into computer readable, understandable fashion without hardcoding them...? The fun of programming.

Originally Posted by Astronouth7303

• Robot files

These will have to not only include the robot shape and stuff, but also which game they belong to. This could be a simple year number at the beginning of the file... I'm into txt files because they're easy, and they can be edited by, say, Notepad. This would allow us to fine-tune stuff quickly.

[Astronouth7303]

Probably the easiest way to combine text and binary is a ZIP, like FIRST_Frenzy.zip, except it's named FIRST_Frenzy.fvg.

Probably a combination of INIs, XML, and various binaries (3DSMax, PNGs, DLLs, etc)

[Astronouth7303]

DEFINITION: Item - The actual CAD of something, for lack of a better name.

• The only required item in the root of the zip is Info.Ini

• Each directory in the ZIP has its own section.
• Every atempt should be made to make sure it is UNIQUE. It is also its ID.
  

  [DirName]
  Type= Game, Field, or Robot
  DisplayName= What is shown to the user
  Game= The ID of the game it is for (not for games)
  Year= The year of the item (optional)
  Description= An extended description of the item
  ThingID= The file name for an item (the ID being the entry), several of these. This may also be in code.

• A zip may contain multiple items
• Games should include a default Field and robot.
• Suggested Robot ID: year.team.name (year of game, team number, name of bot)
  
  Suggested DLL interfaces (in psuedo C++):
  

  #define RETURN_ERR bool
  //used for subs that return error info
  #define BOT_SCORES unsigned long[]
  the scores for a match
  #define CAD i3DSMaxObject
  //example, going to change
  
  /////////////////////////////////////////////////////////////////////////////////////////////
  
  iField Interface:
   RETURN_ERR SetFieldItem(long ID, i3DSMaxObject* Field); //Sets a reference to an actual item
   RETURN_ERR DoThing(long ID);                            //Year specific action
  
  /////////////////////////////////////////////////////////////////////////////////////////////
  
  iRobot Interface:
   RETURN_ERR SetRobot(i3DSMaxObject* Robot);  //Sets a reference to the actual robot
   long GetTeamNumber();                       //Gets the team number
   RETURN_ERR Update(lnog TimeStamp);          //tells it to update it's position
                                               //called after OI info is set
   RETURN_ERR BeginPrematch();                 //Begins the disabled mode before the match
   RETURN_ERR BeginMatch();                    //Begins the actual match
   RETURN_ERR EndMatch();                      //Ends the match
   bool CanAI();                               //Can this bot do AIs?
   long GetYear();                             //What year is it for?
  
   Properties:
    Operator_IO OI_Info(); //The structure with all the info sent to/from the OI
    ULONG Alliance();      //The current alliance, Actually an RGB color
    bool AI();             //Is it acting as an AI? Always returns False if CanAI is false
  
  /////////////////////////////////////////////////////////////////////////////////////////////
  
  iGame Interface:
   long GetNumBots();                         //The total number of bots required
   long GetNumAlliances();                    //The number of alliances required
   RETURN_ERR SetBot(long ID, iRobot* Robot); //Sets the reference to a iRobot
   RETURN_ERR BeginPrematch();                //Begin prematch
   RETURN_ERR BeginMatch();                   //Begin Match
   RETURN_ERR HaltMatch();                    //Field error, prematurely stops match
   RETURN_ERR SetField(iField* Field);        //Sets the reference to the iField
  
   Properties:
    BOT_SCORES CurrentScores(); //The current scores
  
   Events:
    void MatchFinish(UINT Winner, BOT_SCORES Scores); //Raised when the match finishes normally

• A DLL must present the apropriate interface
• The objects are not responsible for loading an item, it is loaded by the program and the reference set.
• An object may do whatever it wants, but emphasis is on speed. Multi-threading is encouraged.

[Astronouth7303]

To elaborate on the directory of the zips:

• Info.ini
• A_Game

• Game.dll
• A_Robot

• Robot.dll
• robot.3dsm <--3DSMax
• A_Field

• Field.dll
• field.3dsm
• thing1.3dsm
• thing2.3dsm
• thing3.3dsm

Info.ini contains entries for: A_Game, A_Robot, and A_Field.

[Ryan M.]

Ok, so let me see if I understand:
Each zip is divided into directories. Each of these holds one thing: a robot, field, or game desciption.

What exactly makes a single zip? Is there one zip per game?

[Astronouth7303]

The only thing that defines a zip is that it is a single package. So if you 'install' the '92 game, with it comes the default field and robot. when you 'uninstall' it, all three are removed. (the actual process of (un)installing is adding/removing files)

The zips are created by the person who wrote/packaged the contents. What is in a given zip is unimportant to most of the code (the exception being the part that actually gets the data/files).

Any section that does not contain necesities is not shown to the user. (special debug mode to show such sections?)

[Astronouth7303]

Ok, so here's my idea as of when sounds play:
Charge2 @ BeginMatch();
FogBlast @ HaltMatch();
Buzzer @ MatchFinish();
Charge2 @ (internal) EndAutonomous();
strike04 @ (internal) DropBalls();

Also: we need to finalize file names within the zip and how they are referenced.