Quote:
|
Originally Posted by afflictionblade
we need to define our objectives, so here is a list for starters: - creating an accurate representation of the FIRST competition
- increasing interest in robotics and FIRST
- bringing FIRST to a new medium
please give input on these
|
Well, you asked for it! It seems to me that the first objective just might be in conflict with the second objective. Personally, I'd losen "an accurate representation" to "an exciting game based on FIRST". It wouldn't be too easy to create a situation where you had 5 minutes to do a major hardware repair while simutaneously trying to track down a difficult software issue -- but that would be an accurate representation of the FIRST competition. To make the game fun, and also "codeable", you'll have to depart from faithfulness to reality at certain points. So, while "accurate representation" might be nice, I wouldn't say it should be an objective, so much as on a list of "if we can do it, fine, but don't do it to the detriment of our objectives" (that being the verbose name of the list).
But I do think that this a really important discussion that probably merits its own thread, just so it will receive more attention and not be distracted by the other discussion going on here. There are going to be tough decisions down the road, and if you don't have any guideing objectives, it will be that much harder to come to a decision -- that most everyone agrees to.
Quote:
|
Debate... And my debate is: I just don't like it; it seems like it will be hard to control in game, and might potentially inaccurate. Feel free to ignore me
|
It seems to me that the use or the dis-use of these "vodoo" controls isn't something that needs to be "finalized". If you design a system that controls the robot based on input (e.g., Robot is passed the data packet), then how that input is gotten is a side issue, -- there could be several pluggable modules, which, while perhaps involved in coding those modules, wouldn't affect in any way the rest of the design. Discussing random elements (controls, AI algorithms, etc.) is nice and all, but without any unifying design decisions, it seems rather futile, especially since many of these decisions could be affected by the overall design. In summary: control can be changed easily without affecting other elements of game; also, I strongly suggest to come up with a good and detailed, yet general, outline of the structure of the game itself from a programming standpoint (ignoring irrelevent side issues like "ijkl" steering).
Well, I promise not to say all that again, ... I do sound like a broken record. So you can rest assured I won't mention it again. Unless I change my mind. I might do that.
