To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.org.ca.rtltorontoOpen lugnet.org.ca.rtltoronto in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Organizations / Canada / rtlToronto / 9421
9420  |  9422
Subject: 
Re: [rtlToronto] rtlToronto15a/b Tentative Rules Posted
Newsgroups: 
lugnet.org.ca.rtltoronto
Date: 
Tue, 30 Sep 2003 14:40:19 GMT
Viewed: 
507 times
  
In lugnet.org.ca.rtltoronto, Calum Tsang wrote:
Hi guys,

I've put together an initial draft of the rtlToronto15a/b rules for the event on
January 31, 2004:

http://peach.mie.utoronto.ca/events/lego/lego-013104/lego-013104-rules.html

Looks good. I like it. Finalizing the arbitration = either one wire or two. And
two wires boils down to every bot requiring two RCXs.

I will put up any core logic code anyone wants to share (Derek, Michael, Steve).

Determining a win condition isn't that hard, so depending on whether you're
comfortable with dynamic memory allocation (pointers), you can either use loops
or a node tree to determine which of the current moves leads to the 'best' board
to have in terms of win opportunities down the road.

If you do it with loops, then you simply decide ahead of time how many levels
deep you want to 'check', and then nest as many FOR loops. Say it's two levels:

FOR mymove = 1 to 7
FOR hismove = 1 to 7
   FOR mynextmove = 1 to 7
     /* In here put code that adds those three pieces to the game board, and
quickly checks for win conditions around the new pieces. If there's a win for
us, then increase boardscore(mymove) or whatever the variable is. If there's a
win for the other guy, decrease it. And the best situation, of course, is when
there's a win after _two_ of his moves -- cause that means it was a trap. A
check for that situation would have to be worked in at the end of the mymove
FOR.
      */
   NEXT
NEXT
NEXT

As far as doing it with pointers and node objects... ah well. That type of algo
can check a good deal farther, because it avoids looking at moves that can
quickly be determined to be pointless and doesn't waste processor cycles or
memory on them. And if a 'tree' five moves into the future is constructed, it
can be reused and expanded in the following turns, rather than reconstructed
from scratch each time. (which is what the loops do, in effect)

Anyhow, there's some ideas for anyone interested.



Message is in Reply To:
  [rtlToronto] rtlToronto15a/b Tentative Rules Posted
 
Hi guys, I've put together an initial draft of the rtlToronto15a/b rules for the event on January 31, 2004: (URL) are two games: 1. Connect Four 2. Marble Sorting The latter is pretty much DaveK's deal. I've basically taken his previous post of (...) (21 years ago, 30-Sep-03, to lugnet.org.ca.rtltoronto)

5 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR