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

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 (http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45) 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.]

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

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.