FIRST Video Game: Cementing auxillary file formats
 

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.

Re: FIRST Video Game: Cementing auxillary file formats
 

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. :)

Re: FIRST Video Game: Cementing auxillary file formats
 

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.

Re: FIRST Video Game: Cementing auxillary file formats
 

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 :)

Re: FIRST Video Game: Cementing auxillary file formats
 

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

Re: FIRST Video Game: Cementing auxillary file formats
 

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. :D

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. :)

Re: FIRST Video Game: Cementing auxillary file formats
 

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)

Re: FIRST Video Game: Cementing auxillary file formats
 

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.
  
  Code:

  ---

  [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++):
  
  Code:

  ---

  #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.

Re: FIRST Video Game: Cementing auxillary file formats
 

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.

Re: FIRST Video Game: Cementing auxillary file formats
 

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?

Re: FIRST Video Game: Cementing auxillary file formats
 

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?)

Re: FIRST Video Game: Cementing auxillary file formats
 

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.