Subject:
|
Re: [rtlToronto] rtlToronto20 Draft Rules Posted
|
Newsgroups:
|
lugnet.org.ca.rtltoronto
|
Date:
|
Wed, 23 Nov 2005 05:24:43 GMT
|
Viewed:
|
656 times
|
| |
|
|
Calum Tsang wrote:
> In lugnet.org.ca.rtltoronto, Vitali Furman wrote:
>
>>I have three questions. First it says that the beacon light is on
when the robot
>>is stopped? Does that mean the it can't be on while the robot is
moving around
>>or what? Or is it that it can only go on when another robots has
stopped it and
>>is trying to transfer a brick?
>
>
> In my opinion (and the way it's written now) the light has to be on
ONLY when
> the robot is stopped. It should NOT be on while the robot is moving
around.
> Here's my reasons why:
>
Calum. I look forward to the group discussion so we may better get a
feel for how this may work.
Based on the mock up of 2 robots seeking each other I employed a beacon
light being on and off as one solution to how to seek a robot. This is
a copy of an email i sent to a few people to get robot feed back.
-----------snip----------
this is a BAD web cam compressed 320x240 AVI of 16 seconds (1/2 meg) of
robot seeking.
www.thepyroguys.com/videos/robot-seek.avi
what you might see, is that both robots are started at the same time.
they both are programed to have a 50/50 chance of either turning on a
beacon and waiting for x seconds, OR not turning on a light and seeking.
the robot on the left in this video is seeking, and the one on the right
has chosen to stay put, and turn on a beacon light.
-------------end--------
As you can see, in the above situation, the system works. This solution
is within my skill set. But, just like every other rtlToronto game, I
would like to see as few rules, and standardizations as possible.
So. In my opinion, I fully agree with standardizing a physical beacon
location; and suggesting that "on" for waiting, and "off" for motion
is a good suggestion. I DONT think we should disallow a robot for not
following that blinking pattern.
It might make the most sense to follow the "guideline" of on/off, but it
should not be the kind of thing were we disallow a robot.
We have only 4 people so far to commit to building a robot. (of which ,
so far, you are not on that list) So finding ways to get rid of
entries is counter productive.
Chris
Dave K
Derek
Janey
If you are planing to enter this game, please let either myself or Calum
know. Due to the cooperative nature of this game, knowing ahead of time
how many bots will be on the play area at once could affect how you
choose a strategy. So please give us a heads up if you want to add your
name to the list.
> 1. No provision has been made to stop a robot remotely (ie, there is
no method of stopping a robot you want to deposit into), so you need to
know when a robot is stopped, in the hope that you can align with the
stopped robot and drop out a block. If you don't know when the robot
is stopped, and you don't know how to stop a robot, then how are you
going to do anything with it?
>
You are correct, that we have not provisioned for autonomous stopping.
But I would like to keep to the spirit of the original rtlTronto games
and not stifle creativity with rules and design criteria, and allow the
builders to find a way to transfer blocks on there own. Derek claims he
can implement a transfer while in motion. Rob, might be able to mount
his gun block transfer to a turret.
> 2. If you keep the light on all the time, then there are many light
sources to
> chase around. The chances of chasing a MOVING light source around
may be very
> difficult.
>
> Now, that all said, some people, like Derek, feel the light should be
on all the time or up to you. I'd rather it be either on all the time,
or the way it's stated now. It shouldn't be up to you.
>
I think the OPTION should be up to the builder.
>
>>Second is regarding the colours of the brick that we transfer? Do we
just bring
>>any colour we want? Or will they be provided before each round, so
that two
>>robots don't have the same colour?
>
>
> Earlier on, participants were choosing the colours of bricks for
transfer. I
> think they were here:
>
> http://news.lugnet.com/org/ca/rtltoronto/?n=14684
>
> (Note that this is a great example of how "social experimentation"
can't be
> trusted for anything--is Dave right? Is Janey right? Who decides?)
>
Would it not be reasonable to look at the time stamp of the posts to
decide who "called" what colour first?
Dave dated Sept. 17
http://news.lugnet.com/org/ca/rtltoronto/?n=14681
Calum dated Sept 18
http://news.lugnet.com/org/ca/rtltoronto/?n=14682
I am sorry Calum, this is not an example of "social experiment."
Speaking of colours, I think it was Steve who suggested we could mix and
match colours and tiles, and plates to form a unique pattern. The idea
is that as as long as you can separate out whose block is whose at the
end of the game.
>
>>Lastly, the dimensions, can the robot expand to a bigger size then a
12” cube
>>after the round has started?
>
>
> Sure! That's a really cool idea!
>
>
>>Seems like an interesting game.
>
>
> I think it's worth a shot. I've spent quite a while trying to
de-louse any "up
> to chance" elements out of the basic game. Strategy, innovation,
that can all
> come above being able to find and pass a basic block.
>
> Calum
I thought the game was to be called "Project Why"
Chris
|
|
Message has 1 Reply:
Message is in Reply To:
30 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
