FIRST Video Game: Hammering out details

[Pat McCarthy]

A few questions..
Will the user be able to assign commands to keys they chose?
Will the game support joysticks? ex: Microsoft Sidewinder

A suggestion..
Would it be possible to simulate an innovation first robot controller to control a robot in the game? And if the previous is possible, could a user plug their team's control station (directly from the innovation first tether port) into their computer to control the robot on screen? This would include the use of pots. in the control station.

Thats my $.02 I can't wait for the first release of the game!
-Pat M.

[Astronouth7303]

Originally Posted by PCPat

A few questions..
Will the user be able to assign commands to keys they chose?
Will the game support joysticks? ex: Microsoft Sidewinder

yes to both, but not initial releases, which will primarily be framework, a skeleton.

Originally Posted by PCPat

A suggestion..
Would it be possible to simulate an innovation first robot controller to control a robot in the game? And if the previous is possible, could a user plug their team's control station (directly from the innovation first tether port) into their computer to control the robot on screen? This would include the use of pots. in the control station.

yes, no. Half the point is to simulate a given FIRST game (the rest is to create another FIRST thing ). The joystick ports on the OI are mostly standard; If you plug in a custom box, the 4 analog and 4 digital inpusts will work, but LEDs will NOT (of course, this can be remmedied with a RS-232 box). As for directly plugging in the OI, probably not.

Originally Posted by PCPat

Thats my $.02 I can't wait for the first release of the game!
-Pat M.

[Ryan M.]

Would the game have an (possibly optional through settings) autonomous mode? IE, sort of like PCPat suggested, we would give the user the ability to program the robot is some way?

Maybe way too hard for now, but maybe in the future...

--EDIT--
Feel free to ignore me. I'm not helping much, am I?

[Astronouth7303]

Originally Posted by Texan

Would the game have an (possibly optional through settings) autonomous mode? IE, sort of like PCPat suggested, we would give the user the ability to program the robot is some way?

Depends on the target game. through your favorite IDE (translation: you need source code).

Originally Posted by Texan

Maybe way too hard for now, but maybe in the future...

Not hard so much as a lack of anything to work off of.

Originally Posted by Texan

--EDIT--
Feel free to ignore me. I'm not helping much, am I?

some.

My last discussion on this.

[Devin L.]

any idea on when this might come out? i can't wait to see it

[Astronouth7303]

Originally Posted by Devin L.

any idea on when this might come out? i can't wait to see it

When? I'll tell you when the SourceForge site goes up.

[mtrawls]

Hrm ... sounds like a pretty darn big goal. Some points that might be helpful to ponder.

• Do you plan to let the user "build" his robot, or just have a few basic structures with room for light modification?
• If you allow modification, how do you try to "level" the playing field (since you're not spending real money or real time doing it, something has to limit the robots and make them competitive)?
• Do you plan on having AI bots to play against? Connect to other computers to get other human players in the game?
• I assume this'll be real time. What type of physical simulation do you (realistically) expect?

With that said, I would refer you to Crystal Space, a very nice graphics/gaming engine that has cross-platform support, 3ds max import abilities, and MS VC++ work files (which all sound like it would be useful with what you have planned ... aslo, they use to have a rudimentary physics support, but I don't know what's happened to it). And you might want to consider ODE, a pretty serious open source physics engine (for rigid bodies, which robots happen to be).

I'd take a good long hard look at the project, and try to come up with a reasonable set of goals. Remember that successful projects start out small and grow from there. The projects that start out with unrealstic aims tend to fail, as those contributing become disillusioned. Also, some sage advice from my limited experiences -- before you write a single line of code, have a very detailed outline of what the system will be like, to include class hierarchy and interaction, and other such details.

Edit: in regard to Texan's post, which happened to beat me ... I think it's a bit early to begin thinking about specific design issues. Start with a general outline of the project, to inclue non-coding issues too (e.g., a game's nice and all, but nothing without art ... and sound is pretty darn important too, and a whole slew of other issues). Then, work from there. Specific implmentation like what will be a class, etc., will come from the general design, and it's too early to say how you want to design the system. Or that's the way I see it, at least.

[Ryan M.]

Ok, so, since you are using VC++, I assume you'll use classes. So, some ideas:

• Individual classes for all robots. You can do fun things with these, such as pass in the robot spec file in the constructor, and the class could read it in and configure itself.
• Class for the game. This class would hold information on what teams which robots are on, where each robot is (maybe this could be a robot class function?), where balls are on the field, make sure robots follow rules, etc. Maybe even it could even read in rules/field structure from a file?
• Depending on how you do the physics engine, you could have classes for various field components, such as balls, goals, etc. For example, with the balls, they could keep track of bounces and other movement, relaying it on to the game controller.

Just some ideas. And some of that is rough obviously, like who gets to keep track of where robots/other moveable field objects are.

Yeah! I was helpful (or I tried).

[Joe Matt]

Here's some of my thoughts....

-Focus first on the robots. Have a few robot types to choose from, then hammer out the kinks and other problems. Then add a custom robo feature, then add human player.
-For a first game, I'd either do Stack Attack or Zone Zeal, but mostly Stack Attack. The game has more action and less moving 'parts' to it.
-Use a language that is supported and can be ported to, Windows, Mac, & Linux.
-Start small, then go big. Don't have many textures or other things, then keep adding things till it's a great game.

[Bcahn836]

I would put a few already assembled on the game, but also let the player build their own. For example maybe model a robot off the championship alliance or something or a robot we all know. And as the game progresses allow the player to add different parts to play different strategies. I also like the idea of the sponser logos, i would also consider a mode to create logos.

The biggest thing is to show what FIRST is all about and what we the teams go through during a FIRST Robotics season.

This only my opinion as a gamer, i really don't know about all of programming and stuff like that. sorry

[Astronouth7303]

Here's how I imagine the final program will be:

• The primary EXE will contain no data about speeific robots, fields, games, etc. it will just contain the framework to run it.
• Every robot will have it's own file(s). This may (or may not) include driver's station, program, textures, and/or bot.
• every game will have it's own file(s). this may (or may not) include the field, the mobile parts, the field control code, and/or textures.
• every field may have it's own file(s). this may (or may not) include the field, the mobile parts, and/or textures.

This also allows for custom fields; like a street practice, the wood field, a brand-new field, or a well used field.

I think there should be seperate utilities for creating/editing these files.

[I personally do not like the 'earn stuff by winning' idea.]

[Ryan M.]

Originally Posted by Astronouth7303

Here's how I imagine the final program will be:

• The primary EXE will contain no data about speeific robots, fields, games, etc. it will just contain the framework to run it.
• Every robot will have it's own file(s). This may (or may not) include driver's station, program, textures, and/or bot.
• every game will have it's own file(s). this may (or may not) include the field, the mobile parts, the field control code, and/or textures.
• every field may have it's own file(s). this may (or may not) include the field, the mobile parts, and/or textures.

Hear, hear! Kinda what I said. It will read it in from some sort of file.

This helps to keep everything nice and clean.

Originally Posted by Astronouth7303

This also allows for custom fields; like a street practice, the wood field, a brand-new field, or a well used field.

That's something I hadn't even thought of, fields that aren't "official."

Originally Posted by Astronouth7303

I think there should be seperate utilities for creating/editing these files.

Definetly at the beginning. Maybe there would be an editor built in at a later point, but for now a simple external utilitie will work.

Originally Posted by Astronouth7303

[I personally do not like the 'earn stuff by winning' idea.]

I don't like it much either. One reason would be that it doesn't simulate the real FIRST experience well. And, I don't like having pressure...

[phrontist]

The way I see it you have two options:

1) Slave away, doing everything from scratch, and if you don't kill youself out of frustration produce a crappy game.
2) Use ut2k4!

Seriously, thats a very, very good suggestion. You're not going to top their physics!

Actually, for the ultimate in pimp-age, use Half-Life-2, which is/will be mind boggling. Ragdoll physics for human players

[Astronouth7303]

Or use a open-source engine.

[Heretic121]

i know i have said this before and others have brought it up also... with UnrealTournament 2k4, you get an editor to make maps and script with... the physics is already there, all you have to do is tweak it... everyone who used 3dsMax or Maya for the FIRST animation can make thier teams robot... the only problem with this is making a hook work or ball grabber or ball collectors... this would be coded in, which wouldnt take to much time when you learn it... Fields are easily made and can be configured in many ways... yes the robots would be diffrent files as would the fields... but i dunno how you would implement the human elemnt... its just something to throw around if things become to (something) in making your own proggy and physics... i could make the field/fields (i make maps atm for ut2k4) and show you what it would look like in game if you all want to see how it looks visual wise =D