[FVG]: High-level design

[Ryan M.]

In response to Mtrawls pleas (whines ), I've decided to create this thread. We need to decide on a high-, top-level structure. This includes things like class relationships, general program flow, etc.

I'm not sure how much we can discuss yet. I've just started to read the CS documentation, and we'll be slightly forced to work with however it does. But, if you have any input, go ahead, say something... I'll try to create some stuff after a while.

[Mike Ciance]

Originally Posted by Texan

In response to Mtrawls pleas (whines ), I've decided to create this thread. We need to decide on a high-, top-level structure. This includes things like class relationships, general program flow, etc.

I'm not sure how much we can discuss yet. I've just started to read the CS documentation, and we'll be slightly forced to work with however it does. But, if you have any input, go ahead, say something... I'll try to create some stuff after a while.

i know only a small amount of C, and i dont have thatmuch programming experience all together, but i guess the program flow would be something like:
>get player 1 input
>getdata robot 1 stats
>move robot 1
>calculate AI 2
>getdata robot 2 stats
>move robot 2
>calculate AI 3
>getdata robot 3 stats
>move robot 3
>calculate AI 4
>getdata robot 4 stats
>move robot 4
>getscore
>display score

of course many of these are really sets of commands, but still, a basic structure is what we need right now. also i'm sure there is stuff i missed.

hey, look who listed stuf without the code for once

[mtrawls]

Well, seeing as the thread was started in my honor, I guess I'll respond (or maybe it was just to get me to shut up? )

But, it seems to me so long as you ignore the graphics for now, and just concentrate on how the simulation will proceed, knowledge of CS is mostly irrelevent. I'll try to get things started off.

One of the most obvious elements you will have is Robot. What must Robot include, i.e., how does your game define a robot? Does it need a DriveTrain, or will you just hardcode certain speed parameters into it? Should it have a Color type, controlled by Match, to determine what alliance it is on? Should it keep a record of its past success, or its score -- or maybe you want some larger Score object to keep everybody's score? There are different design decisions like this, that all depend on how object oriented you want it, your tastes, and how you design the rest of the system. So most of this process will have to change as it evolves, if that sentence makes any sense, which is doubtful.

Okay, then you'll need a Match element. afflictionblade has detailed some of what could be Match->Step (). (Oh, and keep in mind that how you have it, the AI for robot 4 gets to decide his move after everyone else has made thiers, meaning he always has more information than the others.) But Match will need other things. It will need some control like what is provided by FIRST, e.g., to disable robots who break certain rules, to start and stop matches, etc. A Timer. Something akin to a Ref. ...

But rather than start from the robot like I did, you need to also start from the top. So let's think about the Tournament structure for a moment. Like I mentioned earlier, it will need some Scheduler. Some larger Score element perhaps. Etc.

Also, now that I think of it, -- how do you plan to handle autonomous mode? It seems it would be vastly easier to just forgo that formality, since programming it would be quite difficult indeed, at initial inspection. Well, I don't want to do all of this, afterall it is your project. This is just a tiny start to get you thinking along the lines I think you should be thinking in ...

/end whine (and by the way, whine hardly is not effective)

[Mike Ciance]

Originally Posted by mtrawls

(Oh, and keep in mind that how you have it, the AI for robot 4 gets to decide his move after everyone else has made thiers, meaning he always has more information than the others.)

>get player 1 input
>getdata robot 2 stats
>calculate AI 2
>getdata robot 3 stats
>calculate AI 3
>getdata robot 4 stats
>calculate AI 4
>getdata robot 1 stats
>move robot 1
>move robot 2
>move robot 3
>move robot 4
>getscore
>display score

this way all decisiosn have been made before any robots move, and AI also takes robot stats into account

[Joshua May]

Would it be poswsible to use multithreading to allow for each of the four robots to think at once?

[Ryan M.]

Originally Posted by HHSJosh

Would it be poswsible to use multithreading to allow for each of the four robots to think at once?

Theoretically. I'd really like to, however, refering to my "I don't know CS very well yet" thing: at least what I've read so far, you actually have to call a certain function which is part of CS. This function then takes control of program flow, and the only way I currently know of when it gives it back to you is when a key is pressed. There must be other ways to get it, I just don't know them yet. Using multithreading, we could always initialize the robot threads before giving CS control of the parent thread. The only thing we'd have to figure out then is how to tell CS what the updated positions are. Hopefully that's not hard...

==EDIT==
Oh, yeah. This was to make you stay our of our discussion...

jk

[Astronouth7303]

Multi-threading would be cool, if we can keep them sync-ed.

In a game, here's what we do:
#Load objects, robots, fields, etc.
#check everything to make sure it's OK
#initialize
##check connection (if applicable)
##check server (if applicable)
##send robot model to other players (if applicable)
#begin pre-game
#wait for OK from players
#begin game
LOOP1 {
#Auton (if applicable)
}
LOOP2 {
#Send Pos data to AIs (if applicable)
#Get input (from players or AIs)
#Check input
#Create robot pos data (from CS)
#Send data to robots
#robots do their thing
#Get pos data from robots
#Run engine
##Physics
##Render
}

I'm also thinking that if voodoo controls are going to happen, we're going to need a radically different object model than what we currently have.

[Ryan M.]

Originally Posted by Astronouth7303

I'm also thinking that if voodoo controls are going to happen, we're going to need a radically different object model than what we currently have.

?

What was the "current" model we had? And what was wrong with it that it won't work with voodoo?

[Astronouth7303]

The current object model. Under "Cementing Auxillary File Formats". The Vodoo controls are robot-specific, which means that they must be provided in an object by the robot DLL and/or have a 3ds file.

[Ryan M.]

In the interest of posting more... jk

Hey, somebody (meaning Mike/someone commisioned by him), sketch up what the UI should look like. Just as a general idea.