What exactly will a player control? Will they be able to design their robot/controls and run it against the many AI robots, will it be an online type thing (cool, although maybe hard), will they just be able to pick one of several predesigned robots, possibly unlocking new ones as they do better?
–EDIT–
Pardon my ignorance if this has already been mentioned in the other thread. Don’t read chit-chat much.
----EDIT-----
Some of this was already mentioned. Don’t bother with those parts…
Either a robot or act as human player (depending on game modeled)
not in-game. Probably an utility for that. The controls probably will not be visible, but the LEDs will be. Dashboard?
probably, though maybe not ‘many’.
probably, but not this version
I don’t think so.
Currently, I’m thinking about framework (Make a cheapy for debugging). I say come up with a robot standard, draw them later.
My goal for v0.1A is to be able to take a demo bot and drive it around a field, fairly realisticly.
*Include physics engine
*Import bots/fields from files
*render/control interfaced
*no configs, no AIs, no web/lan play (but framework for this should be in place, just values hard coded.)
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.
yes to both, but not initial releases, which will primarily be framework, a skeleton.
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.
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?
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.
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.
-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.
When you say class, do you mean an instance, or a template? (and I’m probably murdering OOP jargon)
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.
I just took this and said what I thought he meant.
Personally, I feel that “good” graphics and sound are easier to figure out and add after the main, supporting stucture is made. I’m one the guys who likes to get it running, then make it cool.
Look at Robot Arena 2, its been done pretty well for a robot game.
I would love to see something like this:
We play peer to peer with other FIRSTers about the present game
If we can get a whole bunch of clever programmers to create the game soon after the kickoff and play it online(or something), that would be simply awesome. We would actually be able to see the game. Then Fantasy FIRST might have to create a separate division for Online FIRST game? This rocks. Good job, see what you can do.
I don’t mean to be too pessimistic, but this seems to be quite a big project especially without any experience with 3d graphics. Even if you do some people with that kind of experience on board, writing a 3d game is hard to say the least. I suggest you review the possibility of making a mod for an existing 3d game first. Specifically, UT2k4 engine is now available for free for use in developing mods. The scripting abilities of UT2k4 are amazing, basically everything outside of rendering, physics (another awesome feature), and sound generation is done in a scripting language that is similar to java.
After rereading the license, I think it is very possible that we could release this for free provided it is not a “game”. Speaking of which, I think it is unlikely that this will ever be made fun. Making a game is hard enough, making it fun is even harder. So, we can make a FIRST “simulation”.