View Single Post
  #13   Spotlight this post!  
Unread 14-06-2004, 18:36
Astronouth7303's Avatar
Astronouth7303 Astronouth7303 is offline
Why did I come back?
AKA: Jamie Bliss
FRC #4967 (That ONE Team)
Team Role: Mentor
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Grand Rapids, MI
Posts: 2,071
Astronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud of
Re: FIRST Video Game: Hammering out details

When you say class, do you mean an instance, or a template? (and I'm probably murdering OOP jargon)
Quote:
Originally Posted by Texan
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.
I think every physical object will be an instance of the respective class, while the Field controller will do what the real one does: trigger events on the field. The Engine will control physics, etc.

Anyone work at Id?
Reply With Quote