CeibalJAM4

1 view
Skip to first unread message

Alejandro Segovia

unread,
Aug 26, 2009, 12:28:49 PM8/26/09
to ceibal...@googlegroups.com
Estimados, cómo han estado?

Ha pasado mucho tiempo desde nuestro último mensaje en esta lista. Como algunos de ustedes ya sabrán, este sábado es la primer sesión del CeibalJAM 4. Me gustaría aprovechar esta oportunidad para retomar el proyecto y avanzar con el refactoring del código base. Creo que veniamos con una serie de cambios interesantes, promovidos principalmente por los parches de Santiago, y me gustaría aprovechar las dos sesiones que vienen para avanzar con el proyecto y liberar una nueva beta.

Durante el Jam anterior tuvimos bastante feedback afortunadamente, los dos puntos que me gustaría destacar fueron primero: el poder hacer que el código se enfoque principalmente a Sugar, de forma de poder brindar features innovadoras sin tener que apuntar al mínimo común denominador de todas las plataformas para las que el Chess está disponible (hoy en día: windows, mac y linux) y avanzar con el desarrollo a un paso acelerado. Segundo: el poder configurar el set visual de piezas. Para esto debemos contar nuevamente con la ayuda de nuestra excelente diseñadora.

Me gustaría poder continuar con estos temas, tanto en la lista como en el Jam mismo, para quienes puedan y quieran asistir.

En Setiembre nuestro proyecto cumple su primer año y quiero celebrarlo con un release que apunte al público general, incluyendo maestras y niños y, en particular, usuarios de la XO.

Saludos,
Ale.-

Santiago Aguiar

unread,
Aug 26, 2009, 1:15:15 PM8/26/09
to ceibal...@googlegroups.com
Si, creo que esos dos puntos son clarisimos.

Respecto al refactoring, lo que estaba faltando funcionalmente para que
fuera usable era poder detectar el jaque mate. Para esto, habia una idea
por ahi (sugerido en el codigo) de tener tableros 'hipoteticos' sobre
los que evaluar si un movimiento X dejaria al oponente en jaque, y si
todos los movimimentos posibles dejan al oponente en jaque, entonces es
jaque mate.

El tema es que en el refactoring hice algunos cambios en los cuales se
agregaba estado a las fichas (ahora no recuerdo bien, pero por ejemplo
si se habian movido o cosas asi para evaluar luego si un enroque es
valido, etc.). Esto por un lado esta bueno porque el codigo queda mas
claro e intuitivo (en mi opinion), pero por otro lado generar tableros
hipoteticos es mas complicado/costoso porque implica hacer copias 'en
profundidad' de las piezas, y no solamente copiar su posicion (como era
antes). En definitiva, me dejo pensando si fue una buena idea agregar
estado a las piezas en lugar de dejarlo en el tablero. Ademas, tengo la
sensacion que la posibilidad de hacer tableros hipoteticos es bastante
util, mas alla del caso de jaque mate...

En fin, al igual que Alejandro, desde el jam pasado que no miro el
codigo, pero solo lo comento por si alguien se mete sobre el problema...
por otro lado, capaz que ahora cuando lo lea me doy cuenta de que era
una chotada solucionarlo ;), pero bah.

saludos!

Alejandro Segovia

unread,
Aug 26, 2009, 2:00:41 PM8/26/09
to ceibal...@googlegroups.com
2009/8/26 Santiago Aguiar <santiag...@gmail.com>

El tema es que en el refactoring hice algunos cambios en los cuales se
agregaba estado a las fichas (ahora no recuerdo bien, pero por ejemplo
si se habian movido o cosas asi para evaluar luego si un enroque es
valido, etc.). Esto por un lado esta bueno porque el codigo queda mas
claro e intuitivo (en mi opinion), pero por otro lado generar tableros
hipoteticos es mas complicado/costoso porque implica hacer copias 'en
profundidad' de las piezas, y no solamente copiar su posicion (como era
antes). En definitiva, me dejo pensando si fue una buena idea agregar
estado a las piezas en lugar de dejarlo en el tablero. Ademas, tengo la
sensacion que la posibilidad de hacer tableros hipoteticos es bastante
util, mas alla del caso de jaque mate...

Ugh, confieso que no he mirado el codigo desde que aplicamos tu patch. No tenia presente que se hubiese roto lo de los tableros hipoteticos. Quizas no sea tan costoso copiar las piezas en profundidad, o quizas pueda hacerse un compromiso y clonar solo la parte del estado de las piezas necesarias para detectar el mate.

Estaria bueno juntanos el sabado a charlar estas cosas. Te parece que tengas un momento free como para juntarnos a diseñar esto?

Saludos,
Ale.-

Santiago Aguiar

unread,
Aug 26, 2009, 3:41:38 PM8/26/09
to ceibal...@googlegroups.com
Solucion quick n' dirty:

def king_is_checkmated(self, owner):
moves = self.get_all_moves(owner)
for move in moves:
move.perform(self)
checked = self.king_is_checked(owner)
move.undo(self)
if not checked:
return False
return True

O al menos pasa el caso de prueba de checkmate que antes no pasaba ;) (y
lo detecta en un jaque pastor).

Igual imagino que eso agrega otro problema (que era para lo que creo que
se usaba el flag 'hipotetical' en alguna version pasada), y es recursion
cuando se quiere filtrar movimientos. Alternativamente, se podria
filtrar movimientos para asegurarse de que no dejen al rey en jaque
(haciendo el movimiento, chequeando por jaque, y deshaciendolo) y luego
determinar si es jaque mate si no quedan movimientos validos. No deberia
ser dificil.

Imagino que hacer el movimiento y deshacerlo es mas eficiente que copiar
el tablero N veces para determinar si cada posible movimiento termina en
jaque.

saludos!

Alejandro Segovia

unread,
Aug 26, 2009, 4:15:17 PM8/26/09
to ceibal...@googlegroups.com
Me gusta tu idea :)

Habria que ver si no cae en loop infinito. Leo sugeria que lo que se puede hacer para evitar caer en eso es utilizar un parametro que corte la recursion de manera temprana.

Mas alla de eso, la idea me parece genial. Lo que le cambiaria, en principio, seria agregarle como primer linea  "if not self.king_is_checked(owner) return False", ya que si no esta en jaque, no importa si no se puede mover.

Habria que probar meter esto en el HEAD y ver si no se cuelga :P

Abrazo,
Ale.-

2009/8/26 Santiago Aguiar <santiag...@gmail.com>

Santiago Aguiar

unread,
Aug 27, 2009, 9:48:47 AM8/27/09
to ceibal...@googlegroups.com
Al final agregue un parametro para indicar si se quiere filtar los movimientos por aquellos que generarian jaque o no para cortar la recursion.

Esta "andando", pero igual le vendria bien un clean up general al codigo ;). Por ejemplo, ahora no me queda tan clara la utilidad actual de tener todos los metodos de clone y el flag hipotetico (por mas que me imagino que seran utiles a futuro). Podriamos borrarlos por ahora.

Tambien existen N metodos distintos para obtener movimientos, y no tengo del todo claro que hace cada uno... habria que revisarlos.

Tuve que actualizar algunos casos de prueba porque al filtar por jaque mate es necesario que el rey este en el board, y algunos casos no agregaban al rey.

Ya hice commit de estos cambios.

saludos!
Reply all
Reply to author
Forward
0 new messages