Ceibal Jam/Juegos

From OLPC
< Ceibal Jam
Revision as of 05:27, 19 August 2008 by GBalbuena (talk | contribs)
Jump to navigation Jump to search

GoogleTrans-es -English -български -中文(中国大陆) -中文(臺灣) -hrvatski -čeština -dansk -Nederlands -suomi -français -Deutsch -Ελληνικά -हिन्दी -italiano -日本語 -한국어 -norsk -polski -português -română -русский -svenska


Ceibal Rol

Ceibal rol es un proyecto comunitario de Ceibal-Jam en el que todos podemos participar, creando, diseñando, programando... El objetivo es lograr un potente motor de alto nivel para facilitar a maestros y docentes a crear juegos a través de esta plataforma.

Requerimientos

  • Python 2.5
    • PyGame
  • Perspectiva isometrica/ortogonal en 2D.
  • Mantener documentación en esta wiki.
  • Licenciar a través de GPL v2 o equivalente. http://es.wikipedia.org/wiki/GNU


Análisis y Diseño

Introducción al análisis

A pesar de que las técnicas en que se basara el diseño son muy antiguas o mejor dicho clásicas, es justo ahí de donde radica la belleza de utilizarlas, son muy probadas y demostraron ser casos de éxito en un pasado y lo serán ahora.

El código ejemplo propuesto aquí sera inicialmente meta-código, esperamos a futuro implementar código en python Creemos que es la forma de ejemplificar lo mas posible su claridad para toda la gama de voluntarios sean idóneos a la programación informática o no.

Abstracciones

Partiendo desde el requerimiento de desarrollar un motor capaz de desplegar desde una perspectiva isometrica/ortogonal, nuestro argumento es justificar el uso de coordenadas enteras y limitar los cálculos flotantes(float, etc...) por que estos agregan una carga extra a los procesos y demorar los cálculos mas importantes del juego en si como serian la interaccio'n continua y un flujo dinámico de información ínter-comunicada entre diferentes XO para actualizar la información de el entorno y sus relaciones a otras entidades dentro del juego.

Mapas o Universo

Crear las fronteras de adonde puede ir cada jugador es primordial para llegar a algo. Necesitamos un limite para concentrarnos en su implementación.

La representación de nuestro universo se limitara a un vector y su representación en un array bidimencional. Las ventajas en velocidad y trato de información sin necesidad de grandes complejidades se denotan por su forma.

map[x][y]

El tipo de información de que hay en ese lugar del mapa estará contenida en un entero sin signo (unsigned int), cada bloque (coordenada) de información vector pocicio'n(x, y) tendrá' un numero y este representara su imagen.

clase map
  x : entero (sin coma, sin signo)
  y : entero (sin coma, sin signo)
  getvalue : (enero) --> este entero representa que dato existe en el vector.

Supongamos entonces que deseamos crear un mapa / nivel del juego del tamaño 3 x 3 bloques, entonces tendríamos 9 bloques donde cada uno representa un lugar posible o no donde nuestro jugador podría estar.


map[3][3]
      [0][1][2]
   [0] 0  0  0
   [1] 0  1  0
   [2] 0  0  0

   1 = libre
   0 = obstruido
map[0][0].getvalue = 1
map[1][1].getvalue = 0

Donde cada numero en cada casillero representara de una forma mas amplia el tipo de objeto que estará situado ahí.

Extendamos un poco nuestra tabla de posibles valores para nuestro mapa/nivel con el limite 1024.

desde         hasta     descripción
---------------------------------------------------
0                       vació
1     <=      200       obstáculos
201   <=      400       pisos
401   <=      600       players/jugadores.
601   <=      800       objetos/items.
801   <=      1024      eventos
---------------------------------------------------

El motivo de el gran rango de posibles tipos de objetos en cada valor se debe a que fácilmente podríamos crear a futuro una extensión en caracteres o códigos donde el rango se aumentaría potencialmente facilitando mas recursos.

Por ahora nos limitaremos a utilizar 1024 atajos a diferentes representaciones en nuestro juego.

Ahora concentrémonos en el orden de cada objeto, donde 0 es vació del '1' al '200' inclusive tendremos obstáculos, entonces en estos lugares no se podrá ni mover ni estar nuestro personaje, es ahí donde nos encontramos con una propiedad para cada rango de valores.

"caminable" o "no caminable"... suena un poco extraño pero utilizaremos un valor boolean (verdadero / falso) y le pondremos un nombre en ingles porque queda mas lindo, walkable.

Como es notable cada valor necesita un campo externo donde definirse, por ello apartir de ahora nos referiremos estos elementos como sprite, un sprite es simplemente un dibujo de algo, un personaje un objeto u cualquier cosa, en este caso seran objetos donde el personaje otro sprite no puede moverse, entonces definamos estos objetos graficos(sprite).

clase floor  sub-clase sprite
  + walklable : (true or false)


Desarrollo

Herramientas

Tiled a generic tile map editor

http://mapeditor.org/

Pruebas