Gente,
Estaba hoy ojeando un paper sobre el lenguaje scala y un framework para
concurrencia que tienen ellos, y lei algo interesante:
"""Virtually all approaches [for event driven programing] based on
inversion of control suffer from the following two problems: First, the
interactive logic of a program is fragmented across multiple event
handlers (or classes, as in the state design pattern ). Second,control
fl ow among handlers is expressed implicitly through manipulation of
shared state """
En castellano (con licencias): Casi todos los modelos de programacion
basada en eventos que utilizan incersion de control sufren de los dos
siguientes problemas:
Uno: La logica de un programa esta fragmentada entre muchos manejadores
de eventos
Dos: El control de flujo esta expresado de manera implicita por el
estado compartido entre los manejadores de eventos.
Esto me hizo acordar al codigo que hicimos para manejar escenas en los
primeros juegos de pyweek. Basicamente, el enfoque mas normal es pensar
las escenas como una maquina de estados. Donde cada escena sabe las que
siguen. Pero eso termina siendo molesto. Por ejemplo, si tenemos una
secuencia de 3 escenas distintas, que se repitan en secuencia 1-2-3,
pero dependiendo de un valor de la segunda escena para que paren de
repetirse, cada una tiene que saber la escena que sigue y los parametros
para inicializarla y el estado compartido para definir la secuencia. Y
la logica de esta secuencia queda dividida en tres lugares (uno para
cada escena). Cuando evidentemente lo mas razonable seria hacer:
while True:
runScene(Scene1())
cont = runScene(Scene2())
runScene(Scene2())
if not cont: break
Queda super claro, todo en un lugar y no hay estado implicito!
Bueno, pero lo motivador del post, a pesar de la larga introduccion que
parece mas bien un intento de dar catedra, fue una pregunta que tengo:
Hoy en dia la logica de juego se expresa con inversion de control. Pasa
un evento, guardarmos el estado, la fecha y cuando vuelve a pasar lo
comparamos contra nuestras variables y todo eso, enroscandonos
completamente en el modelo basado en eventos, con manejadores de eventos
cortos.
Haria sentido armar algo que evite la inversion de control para definir
la logica de un juego?
Como podemos averiguar? (aparte de probando en el proximo pyweek)
Que dudas les trae? Que les parece?
Trate un rato de hacer un ejemplo pero no me sale nada suficientemente
claro. Posiblemente porque no tengo todavia del todo claro como seria el
api de la contraparte de event based. Pero si recuerdo haber usado 5mil
variables de estado y boludeces que molestan y hacen las cosas poco claro.
A fin de cuentas, mientras mas contenido se pueda poner a un juego,
mejor. Y si esto hace mas barato poner mas contenido, mejor.
Bueno, masacren la idea por favor :)
Saludos,
Lucio.
---------------------------------------------------------------------
Para dar de baja la suscripción, mande un mensaje a:
pyar-unsubscribe@???
Para obtener el resto de direcciones-comando, mande un mensaje a:
pyar-help@???
PyAr - Python Argentina - Sitio web:
http://www.python.com.ar/
(text/plain)