![]() |
Re: [Official 2005 Game Design] Game Elements and Subtasks
One things I'd like to see is a much simpler game, where there is only one way to score. Now don't get me wrong, I don't mean that there is only one way to win, just that the audience only needs to keep track of one thing, and the winner is obvious at a glance. In other words, one things needs to be done to win, but theree are multiple ways to do it.
A good example of this was the 2001 MIT 2.007 competition, where the "field" was a giant teeter-totter, and the winner was the robot whose side was lowest at the end of the match. There were a wide variety of strategies, from extending weights to mobile jacks, but it was clear who won. I'm posting this as an element because I have no idea how to design a game like this. Perhaps a giant teeter-totter in the middle of the field that had to be loaded up with objects from around the field that robots had to acquire in different ways (a heavier object might be high up and hard to get, for example). On a completely seperate note, I'd like to see more electronics componants available, not just those from Digikey. Parts like the CMUCam could be used to make awsome autonomous modes that do things like score balls or grab moving objects. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Quote:
|
Re: [Official 2005 Game Design] Game Elements and Subtasks
I was talking with my advisor Fred and he suggested that it would be interesting to see a sort of chasem in the middle of the field, where robots would have to either be a bridge, cross on another robot, or do both and thier points were on the other side also there would be a risen pole one could also cross over be.
|
Re: [Official 2005 Game Design] Game Elements and Subtasks
I've been waiting for a week to find the time to write this up properly. It doesn't look like that is going to happen, so this will have to do. I'm assuming a two against two game, but it can be easily modified for other scenarios. This is just one element of a game, there would have to be other scoring methods added.
GeneF talked about some similar ideas a couple of pages back in this thread. Near the center of the field are a set of pedestals 30 inches square and 72 inches tall. Half of the pedestals are blue, the others are red. The top surface of each pedestal has a one inch wide white border. The pedestals have a net of 3 inch square mesh 18 inches down from the top and extending out 12 inches from the vertical walls. Each team builds two robots. One is the usual 130 pound behemoth. The second robot is built from the parts in the Robovation (I think that's what they call it these days) kit and must fit in an eight inch cube. The maxumum weight of this dozer is three pounds. The dozer is strictly autonomous, no operator control allowed. The Robovation kit would need added sensors for this to work. An alternative is to develop a narrow list of additional electronics that can go into the dozer. At the start of the match the behemoth is carrying the dozer. At any time during the match the behemoth can place the dozer on one of the pedestals. The dozer is activated when released by the behemoth. The scoring pieces for this element of the game are hockey pucks or air hockey pucks. The pucks on top of a blue pedestal are worth points to the blue alliance, red pedestal pucks give points to red alliance. One of the tasks for the behemoth is to collect pucks and put them on top of the pedestals. The task for the dozer is to push pucks off or keep them on. Keeping pucks on the pedestal may involve pushing another dozer off. The net will let pucks fall to the floor while keeping dozers off the floor where they might get crushed. The behemoth can't hold on to the dozer and use it to sweep the top of the pedestal. A behemoth holding a dozer while knocking an opposing dozer off the pedestal would draw a stiff penalty. The only time a behemoth can contact the top of a pedestal is while placing or picking up its dozer. Using air hockey pucks would reduce the chance of a dozer being damaged by a puck dropped on the pedestal. It would also increase the challenge of picking a puck off the floor. Yes, it sounds a lot like robot sumo. The idea is to increase the emphasis on electronics and autonomous programming. Making more of the main game autonomous has a certain appeal, but I don't want to go that route. One of the most interesting aspects of the competition is watching the field team adapt their strategy to changing situations on the field. Taking away driver time will necessarily reduce this aspect of the game. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
I would really like to see the robot giving some feedback to the drivers that is essential to the game. The current control setup limits this a bit, as you can only transfer 1 or 2 bytes of data back. I would like to see a dedicated wireless RS-232 stream. This would also help in that teams could use it for debugging their code wirelessly.
What if there were several zones on the field and at the end of the match, one field was randomly selected and started beaconing (ir). The robots would have to autonomously move into that zone for bonus points. This would move the auto portion to the end of the game, add an element of randomness and uncertainty to the game, and provide a great challenge to the veteran and rookie teams alike. -Bill |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Quote:
[Official 2005 Game Design] OK, so YOU design the 2005 game... and saerch for Canyon Crossing. There you will find including the above element. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Its time
3 vs. 3 Or 2 vs. 2 vs. 2 More time in the field, 2:30 LIGHTER Robots. 130# is alot to ask 2 high school students to carry. A field that has a barrier all along the center (long way) you can't cross it, all scoring options are on the barrier(I love the idea of the colored balls in the goal, who is ever on top gets all the points) So little robot contact, no slamming etc. Could be specktator unfriendly but I'm curious how a less Combat robot type game would look like. Later |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Good ideas, ones I wish could be done--the only issue comes up with frequencies, especially at the championship. There's 20. That's enough to have four per field. Up that to six, and we magically are shrunk to three.
2v2v2 would be interesting, but then we have the issues that came up during 1v1v1. The lower teams gang up on the higher, knocking them out of contention. Game time would be nice, except it would involve either cutting matches or extending the day. Not that any of us sleep anyway. (24-hour regional, anyone?) As for lighter robots, I see two sides. One is that you've got to keep students' backs healthy, the other is that you've still got to build a robot. 1293 pushed the limit with our arm and such, but then shrunk well once we removed it at Palmetto. Cutting weight could be done, but then I fear we'd see a fair amount of overpowered R/C cars (excuse the expression, it's the only way I could think to describe it). Just a question on the field idea--would there be one red and one blue robot on each side, or both reds and both blues on each side? Where they sit either makes it 2v0+2v0 or 1v1+1v1. Either would be interesting, but I'd just like to know what you were looking for. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
The robot needs to be able to load itself into the back of a pickup truck.
So, a platform that is about the same height as a pickup truck that needs to be climed for additional points. Wetzel |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Some ideas and comments: (scroll down for the annotated version)
I've seen some discussion in the main thread about a bumpy playing field and, from personal experience, I know that packing up a field is difficult work. Doing something like that might be interesting, but would make the field squares take up too much space because they would not lie flat on one another (unless two squares meshed, but matching them all would bring words forth that I cant post, and the squares extend under the booth, so I feel that it is impractical). One of daves rules was easily storable. I also saw a suggestion for a 4v0 co-op game instead of a 2v2. 4v0 games are inherently tedious and not "TV-friendly". Though I am not speaking from personal experience here, I have been led to understand that there was very little contact between the robots. This also rules out the divided field idea because it also prevents contact. Robot contact taken to an extreme is always bad, and any team that purposely aims to disable or harm another robot should always be red-carded, but pushing another robot (for example out from under the ball chute this year if they had a goal hooked to them, or had a net ball-catcher) to achive an objective or prevent them from doing so (I really liked the King of the Hill idea in Stack Attack and how robots crossed back and forth multiple times so the choke-point promoted game-friendly contact) is a good thing. I know that unless a team has a design that is so overwhelmingly powerful in some objective (i.e. 365, MOE in the year previous to Stack attack), a large part of the game comes to rest on how well your drive-train preforms in a dynamic situation. For example, Team 25 had a hook design this year that (I only saw them once at competition because I was in the pits other matches) sometimes got bent and prevented them from hanging, but they also have an incredibly strong high-speed and high-torque drivetrain, so we would for the most part steer clear of them while we worked. This makes 25 a very "TV-worthy" robot even if it didn't have its hanging arm at all. Lastly, autonomous mode was huge in stack attack and not so big this year. That is because there was actually an advantage in most designs to get position, then let the balls drop. Having a game where this doesn't occur (in Stack attack, hitting the boxes later was never a good thing) means that there is no possibility that auton won't be a big part of the game. See my other post in Dave's other thread for a more complete reading on my view on the auton and what should be done with it (keep it). So if you didn't feel like reading that: 1) Multi-level fields like Stack attack are good. 1b) bumpy fields have cons that outweigh the pros for me and my back by the end of the day at Ramp Riot [plug]Which is coming up soon if you haven applied to play, go to our team website! [/plug] 2) I'm against 4v0 games, and for 2v2 or 3v3 games (maybe a third robot might be interesting because it means that two robots could start on either side of a (i.e. ramp) like stack attack, and a third robot could start in an unusual location (i.e. the other side of the field) 3) Good contact is good, bad contact is bad. 4) Keep the autonomous mode (I like the beginning of the game for it myself) Michael "Greenleaf, Pokey, The Crate Guy" Greenley P.S. Brandon, I have another word for Amanda to put in the spell checker, storable. (Add to to-do list ;) ). P.P.S. I like sterelite boxes. I do not like cleaning up bits of box. this has no relation to the above post. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
its a little late for this post but whay not?
i feel the game this year should have several different games or objectives to do. for instance, you could have capture the flag, 'shoot hoops', bowling. and end it all with a hang on the bar. team could choose to do one, or all of these tasks. the harder the task, the more points its worth. all of these tasks should be simple things that everyone understands, (flip a switch, shoot hoops, bowl, etc.) not something hard to understand (like: grab 2point balls and put them in one of 2 goals and put a 2x ball on top). i should be able to explain it to a 5 year old and he should be able to visualize the game. this would also make PR with little kids easier. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
I'd like to see a walking challenge!
|
Re: [Official 2005 Game Design] Game Elements and Subtasks
Alright, I know alot of people are going to extremely dislike me for this, but I have a few suggestions.
I agree with Mr. Lavery that FIRST should have more improvising. When Mr. Lavery came by our robot at VCU, he enjoyed seeing our robot made of shelving, lamps, plastic bins, bungee chords, a lawn mower wheel, and a bicycle. First should encourage more scrounging, improvising, and dumpster-diving. (We found a large sheet of steel in a dumpster behind a Wal-Mart once ) I hope there can be more of that in the future. There should be an optional autonomous mode, in addition to the regular autonomous mode. Teams that opt for the XAuto, will have their points doubled, or added onto, depending on the type of game. All teams will have to comply with some form of ID system, so all robots can know who's where. There should also be some form of Rookie/2nd-Year team points for completing, or almost completing, the XAuto. Autonomous programing is tough. Believe me, I know. FLL has been tougher than FRC for me. You can't custom-fit a LEGO. Everything is autonomous. It's smaller scale. you have to work with a less-powerful programming system, and fit everything into 5 slots. And that doesn't even include the presentation, which is harder to work on than the Chairman's Award, at least now that it's been restricted to paper. FLL is much less strict then FRC regarding the build time, which is not as good as you might think! I almost wish I could be on a FLL team this year. :] I would also like to see something with water. I saw that somebody mentioned ice, and that's also unique, but I think water would present an ultimate challenge! (I'm serious here.) Thank you for taking the time to finish reading my post! If you have any comments or flames, you can just PM me. |
Re: [Official 2005 Game Design] Game Elements and Subtasks
Differering layers of carpet would work, like the robot has to "wade" through a section to get to the scoring zone? maybe?
|
Re: [Official 2005 Game Design] Game Elements and Subtasks
Quote:
|
| All times are GMT -5. The time now is 07:18. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi