.: WEREMSOFT :.

ATENCIÓN DEVELO DETALLES IMPORTANTES DE LA TRAMA, SI TENÉS PLANEADO JUGAR “PORTAL”, NO SIGAS LEYENDO.
Lea el resto »

A menudo escucho frases como “este lenguaje es una porquería, no permite XXX funcionalidad como lo hace el lenguaje YYY” y no puedo dejar de pensar que las personas olvidan el hecho de que la herramienta por si sola no hace una buena obra.

Vos elegís una herramienta para una determinada tarea porque es la que mas apropiada para construir lo que tenes en mente. Si la herramienta tiene una limitación, es quien ejecuta la tarea con ella el que debe utilizar su ingenio e intelecto para sobreponerse a esa limitación.

Tomemos el ejemplo de MC Giver, el tipo con una cortaplumas hacía milagros.

Tomemos como ejemplo lo siguiente: Necesitas hacer un juego que se vea en un explorer y que sea accesible hasta para un ama de casa, la mejor alternativa sería Flash. Si tenes la suerte de programar en ActionScript 3.0, no te quejes de que no soporta herencia múltiple o que el refactoring es limitado, es lo que hay! arreglate con lo que tenes y dale para adelante!

De ahora en mas, quiero que cada uno de ustedes imprima una foto de McGiver, la pegue en su lugar de trabajo al lado de los postits con los “TO DO’s”(tu dus) y que cada vez que tenga un obstáculo piensen “¿Que haría Mc Giver en mi lugar?”.

Saludos!

Implementando el modelo MVC en un juego multiplayer, noté que el framerrate fluctúa. Posiblemente en muchos de los juegos single player que haya hecho el framerrate fluctuaba, pero era despreciable o imperceptible o, lo que es lo mismo, no valía la pena preocuparse por eso.

En un juego multiplayer(hacho en flash o lo que se les ocurra), a diferencia del paradigma de flash en el que el juego corre “en el enterFrame”, todo depende del tiempo. En esta ocasión estaba trabajando en el movimiento de un personaje sobre un escenario “destructible” cuando noté que cuando explotaban ciertos elementos del escenario(barriles) estos desplegaban animaciones que tiraban abajo el framerrate, haciendo que el avance del personaje fluctúe con los picos de performance. Imaginense en un juego donde están muchas personas con distintas máquinas, con distintas potencias, tratando de matarse unas a otras(virtualmente). Si un evento desencadenado en el escenario hacia que su avance se viera afectado(caminando mas lento) como en el caso de los barriles, el jugador sería presa fácil de las balas enemigas por moverse a una velocidad inferior.

El resultado fué medir el tiempo transcurrido y multiplicarlo por la velocidad. Para esto, aparte de conservar el timeStamp de la ultima vez que se ejecutó el mainLoop del juego, también hay que guardar otros valores, como son los estados de las teclas.

Ténganlo en cuenta al programar sus juegos multiplayer, en la red todo depende del tiempo, de hecho, los clientes “sincronizan sus relojes” al conectarse al server.

Veré si en el futuro amplio el tema que es muy interesante.

Saludos!