Hola (hacía tiempo que no pasaba por aquí), alguno de vosotros tenéis experiencia portando código nativo de por ejemplo PC a android usando NDK.

He mirado los ejemplos y en principio si usaste opengl ES (incluso opengl antes de la 1.5) en tu implementación original parece bastante sencillo, pero todos sabemos que los problemas vienen con los detalles.

Si tienes algo de experiencia sólo con el NDK también me vale vuestra opinión

Bueno, aquí está el juego que he presentado a artfutura. Casi estoy seguro de que no va a ganar XD (cuando veais el video lo entendereis), pero me ha servido como fecha límite para tenerlo terminado.

Primero las imágenes:




Se trata de un juego procedural <96kb típico de naves, hecho exclusivamente con cubos. Los efectos de sonido son malos, pero son generados tambíen, la música son un par de xm creados por wonder.

el video: http://vimeo.com/6671092 (no se escuchan los efectos de sonido, sorry)
podeis bajaroslo de http://github.com/javisantana/cubyshot/raw/master/exe/cubyshot.exe
o ver el código en:  http://github.com/javisantana/cubyshot

Queda menos de una semana para la deadline del vonvurso de videojuegos y no he encontrado como hacer el envío de forma telemática. Alguien sabe como funciona? he enviado un correo a la organización, pero no me han respondido aún.

"Quoteo" de la página de la navarparty, en la parte de talleres: http://www.navarparty.org/content/view/139/200/
Navarparty es una party que se celebra en pamplona, del 24 al 27 de este mes (septiembre 2009 para los despistados y futuros visitantes)

6. Introducción a la programación de videojuegos en Fenix/Bennu

por Iria Prieto Suárez y Santiago Garcia Jimenez, investigadores del grupo de Redes, Sistemas y Servicios de la UPNa

En este taller se enseñara la base para construir un videojuego de plataformas. Desde el movimiento del personaje y la forma de programar su animacion, hasta el sistema de durezas que permitira generar los niveles a partir de imagenes generadas con un editor de dibujo cualquiera.

Por si interesa.

Si alguien va que avise :)

Se han publicado las charlas de la assembly (party demoscene) y entre ellas hay una charla de la tecnología del aquel juego que se comentó por aquí:

Os dejo el link a todas las charlas (por si os interesa alguna más)

http://assemblytv.org/vods?year=2009&category=Seminars&subcategory=All&commit=Search

Unas preguntas para los que teneis web de las cuales sacais pelas y/o teneis usuarios registrados:

- Dónde puedo conseguir información sobre lo que tengo que hacer para que legalmente sea correcto. Entiendo que si tengo usuarios registrados, con sus datos e información personal sobre ellos tengo que seguir ciertas leyes, pero realmente no sé cuales.

- Qué sistema usais para el cobro ?

- Qué información legal tengo que incluir en la página sobre la empresa? Avisos legales y todo este tema?

PD: realmente no sé si este post va aquí o en offtopic :)

Apenas he visto fotos del CDV, he puesto en mi blog algunas que hizo un compañero (sí, le molaban las azafatas).

http://blep.blogspot.com/2009/01/fotos-fiesta-del-cdv.html

Nadie más tiene fotos?

==== Test Plan =====

== introducción ==
Para empezar voy a hacer una pequeña introducción acerca del testing para luego pasar a plantear los temas de discusión. Tengo que decir que es una visión bastante técnica, quizás alguien pueda aportar una visión un de diseñador.

El testing, sobretodo en los últimos años ha tomado una mayor importancia en el proceso de desarrollo. Parece lógico, a medida que las aplicaciones crecen - un juego no deja de ser una aplicación más - aumenta su complejidad y por tanto son necesarios mecanismos de testing más avanzados. Atrás quedó cuando el mismo desarrollador probaba su software o había una serie de personas, mal llamados testers, que se "comían el marrón" en la búsqueda de bugs. Cada vez está más visible la figura de la persona de QA, muy cualificada, que es capaz de automatizar cualquier tipo de test.

Existen diferentes tipos de test, que se pueden diferenciar por su forma de ser ejecutados (manual, automático) o por las diferentes partes que queremos probar. Enumero los más interesantes:

- Test unitarios: son test que se ejecutan sobre pequeñas partes del código para asegurar su correcto funcionamiento. Son los primeros que se deben desarrollar (que no plantear), y normalmente es el propio desarrollador el que los desarrolla. Estos test son súmamente importantes porque avisan al desarrollador, el primero en la cadena, que algo puede estar funcionando mal. Ver [1]

- Test de integración: Son similares los test unitarios, pero esta vez prueban si el funcionamiento de unos módulos con otros es correcto.

- Smoke Test: Es un test de integración de alto nivel. Como curiosidad el nombre viene de los test que se hacen a las placas electrónicas, si se enchufa y sale humo... malo. Es, por decirlo de alguna forma los test mínimos que debe pasar un juego para que se tenga en cuenta. Por ejemplo, si estamos haciendo un juego de naves un smoke test podría ser tal que así:
  - el juego debe arrancar correctamente
  - la nave debe moverse cuando se pulsan los cursores
  - debe haber enemigos que disparen
  - se debe poder pasar de fase
Este tipo de test debe ser automático

Son cosas muy simples, de muy alto nivel, que permiten discernir rápidamente si esa versión está suficientemente madura como para iniciar un proceso de pruebas más serio, esto es, hacer un proceso manual. De otra forma estaríamos perdiendo el tiempo.

- Test de historias de usuario: en el comienzo del juego se deben hacer marcado una serie de requisitos, marcados en el documento de diseño y acordados con el cliente (si lo hubiese). Cada uno de los requisitos que se plantean deben tener una serie de test cases asociados que certifiquen que se cumple. Por ejemplo, pongamos que uno de los requisitos es que se pudiesen escoger 3 tipos de naves. Por tanto un test asociado debería ser: Cuando el usuario está en la pantalla de selección de nave debe poder escoger azul negro y blanco. Cada vez es más común acercar estas historias de usuario al un nivel alto usando lenguajes intermedios, ver el framework rspec[2]

- Test de usabilidad: El juego además de cumplir todos los requisitos debe poder ser jugable y estar equilibrado. Este es un proceso continuo que debe empezar en el prototipo del mismo y es uno de los más importantes. Este test es habitualmente manual :)


== planificación de un test plan ==

Hay que tener claro algo, el testing DEBE comenzar en el mismo momento que se escribe la primera linea de código y debe ser un proceso continuo. (en mi opinión, aquí comienza el debate)
Mi planteamiento de un test plan debe ser más o menos así:

- Toma de requisitos y redacción de los primeros test de historias de usuario de muy alto nivel
- Comienzo del desarrollo: test unitarios + test de integración
- En el momento que haya una primera versión jugable tener un smoke test, si puede ser automático mejor que mejor
- SI el juego pasa el smoke test ENTONCES y solo entonces pasa a ser testeado manualmente para ver se van cumpliendo los requisitos
- Además se debe ir dando feedback sobre la jugabilidad y otros detalles que quizá sea necesario modificar en el documento de diseño, nadie es perfecto :)

En general ese debe ser el planteamiento para cualquier juego, sin embargo, una vez terminadas esas pruebas debemos centrarnos en detalles más enfocados a producción:
- En juegos para móvil probar que funciona en los terminales deseados,
- En juegos flash probad que funciona en las versiones de flash más habituales, etc.
- Comprobar que los shaders son compatibles con ATI y nVidia
- requisitos de sistemas, etc, etc

Además existe un testeo de mantenimiento. Pongamos que hemos terminado una versión y hemos sacado a producción, llega un bug, el desarrollador lo corrige, entonces deben pasar todos los test automáticos, el smoke test y luego una pequeña prueba manual para comprobar que efectivamente todo está ok. Por ejemplo, en el caso de móviles sería comprobar el juego en las 3 resoluciones y marcas más comunes.

== conclusiones ==
Lo ideal es mantener un proceso de test lo más automático posible, cosa bastante difícil y hacer que sea un proceso continuo [3] y no un testing final donde se encuentran muchísimos problemas que hace que la corrección sea un verdadero infierno.

Me dejo en el tintero muchísima información técnica, pero tampoco es cuestión de abusar, creo que ha quedado un poco coder-style. Mañana veo si puedo poner un test plan de un juego para móvil de desarrollo corto.

- referencias
  [1] http://es.wikipedia.org/wiki/XUnit
  [2] http://rspec.info/
  [3] http://es.wikipedia.org/wiki/Continuous_integration

== preguntas ==
- ¿ crees que el proceso de testing debería empezar al comienzo del desarrollo del proyecto o lo consideras una pérdida de tiempo? qué opinas del TDD (test driven development)
- ¿ un tester debe tener un perfil técnico o un perfil de jugador ? ¿ qué tipo de jugador ? ¿ un hardcore ?
- ¿ se debe implicar a un posible cliente en el proceso de test?
- ¿ qué porcentaje de tiempo de un proyecto debería irse en testing manual ? por ejemplo en un desarrollo corto de un juego flash o desarrollo de un juego para móvil (2 semanas)
- ¿ cuándo es el momento de sacar a producción un juego? ¿ se deben tolerar ciertos bugs ? Si es así, qué tipo de bugs
- ¿ Te gustaría ser tester? ¿ crees que es un trabajo divertido? :)
- ¿ Te da miedo sacar tu juego a la calle por que no vaya a funcionar ?

Los que vais de fuera sabeis donde os vais a alojar?

Últimamente veo muchos puestos de trabajo libres para gente de juegos y también veo mucha gente por los foros, con mucho nivel, que está por ahí suelta, no sé si buscando o no trabajo, pero interesada en por lo menos saber lo que hay seguro.

Se supone que DOID tiene empresas, profesionales y amateurs y una de las labores debería ser poner en contacto a los interesados. Qué mejor forma de  saber como es un trabajo preguntando a una persona que conoces de los foros, irc o similar?

En resumen, espero que DOID sea capaz de unir extremos.

De paso comento que si alguien está interesado en trabajar de programador de juegos para móvil me pregunte :) (spam!)

Dejando a un lado la calidad de las imágenes me gustaría saber que configuración de materiales usa para sacar cosas como la siguiente imagen (me refiero a la piel del marrano)



Más de estas en:

http://www.boring3d.com/daily_archive.htm

sin más os pego aquí las ofertas porque sé que muchos no mirais la portada :P

programador:
-
http://www.stratos-ad.com/trabajo/detalle.php?vtipo=1&vfecha=2007-09-14&vhora=12:54:18

- director de arte
http://www.stratos-ad.com/trabajo/detalle.php?vtipo=1&vfecha=2007-09-14&vhora=12:38:02

Aparte de lo que se comenta en la oferta, que se ponen muchas cosas, os animeis a echar el currículum y si estais interesados y os pilla cerca esteis atentos a la KDD que estamos organizando. Es una buena oportunidad para hacer una entrevista sin hacer una entrevista, conocer la empresa, la gente, etc, cosa bastante interesante teniendo en cuenta lo que suele haber por ahí.

La "desventaja" es que hay que estar en Salamanca, pero en no está mal, los de madrid lo teneis cerca y además se paga bien (no han puesto el sueldo en la oferta pero os lo digo de primera mano).

Mi experiencia aquí es muy buena: llevo unos 7 meses, el ambiente es bueno, el nivel de la gente es alto, se aprenden cosas que en otros sitios n o he visto (trabajar en equipo, tracking de proyectos, etc), etc.

Ya avisaré para la KDD.

Hoy he posteado un nuevo código de la semana enviado por bnl, pero me surgía el otro día una duda cuando me lo envió. El código en si estaba en su blog con una buena introducción, descripción del algoritmo y código perfectamente formateado. Viendo eso me planteaba si reproducir el código en el foro o poner un link. Finalmente he optado por una solución intermedia, pero la pregunta de fondo que me planteo es la siguiente:

¿qué validez tiene ahora mismo el código de la semana? Una gran parte de la gente que anda por aquí tiene un blog donde colocar sus contenidos donde se puede comentar, etc. Eso sin cuestionar la tasa de COT[W] que hemos tenido los últimos meses.

No sé si no tenemos tiempo para enviarlos, somos vagos, no tenemos COTW, todos los códigos que tenemos están mil veces puestos en internet o qué. Y no quiero meterme en los que me envían código a piñón, les escribo con preguntas y no me contestan XD.

Lo cierto es que mirando el foro sí que hay cosas útiles y tampoco creo que quitarlo sea la solución.

[Punto contenido dentro de un polígono]

        Punto contenido dentro de un polígono        

Copio directamente del blog de bnl:

Una necesidad muy común en el desarrollo de videojuegos es la de determinar si un punto esta contenido dentro de un polígono irregular. Por ejemplo en el caso de una aventura gráfica es necesario para averiguar si el usuario ha pulsado sobre una determinada región que podría ser un objeto, otro personaje, etc.

Dentro de la librería matemática que he creado se encuentra la clase polígono que implementa dicha funcionalidad. Así como una serie de clases que también son utilizadas en el algoritmo como la clases Vector o la clase Angulo

El algoritmo para determinar si el punto esta incluido dentro del área del polígono es bastante sencillo, pero requiere algunos cálculos.

Inicialmente se une el punto que se quiere averiguar si esta dentro o fuera del polígono con cada uno de los vértices del polígono, con lo cual se obtendrán tantos segmentos como vértices tenga el polígono.
Después hay que ir sumando los ángulos que forman esos segmentos. La suma hay que realizarla en orden, es decir primero sumar el ángulo que forma el segmento del punto al vertice1 con el segmento del punto al vertice2 con el ángulo que forma el segmento del punto al vertice2 con el segmento del punto al vertice3. Y así sucesivamente en orden hasta terminar sumando el ángulo que forma el segmento del último vértice con el del primer vértice.
Si el ángulo total resultante de la suma de ángulos es 0 grados entonces el punto estará fuera del polígono, si es 2PI entonces estará dentro.
Al realizar los cálculos probablemente se acumulen errores de redondeo así que a lo mejor el resultado no es exactamente 0 o 2 PI, por lo que no se debe comparar con 0 o 2PI si no ver si esta cerca de esos valores.

El código, en VB.NET, lo podeis ver perfectamente formateado en el blog de bnl

Si quieres enviar un COTW, envia un PM a ethernet.
[/list]

Símplemente esto:

http://eskasiunblog.blogspot.com/2007/09/quedada-de-desarrolladores-en-salamanca.html

Alguien de cerca que se apunte ? :)

juego de esquivar caracoles en una carretera.

Está programada en 3 horas, no espereis mucho :)



(ya lo subiré)

Os pego directamente del blog:

Buscamos nuevos diseñadores gráficos para nuestro equipo de desarrollo.
Estamos ampliando nuestro equipo de desarrollo, si eres un diseñador gráfico, con un perfil de 2D pixel art, y te apetece venirte a Salamanca, envia tu CV y un resumen de tus trabajos a jobs@unkasoft.com. Ofrecemos contrato fijo y un buen ambiente de trabajo. ¿Te atreves?

http://eskasiunblog.blogspot.com/2007/05/unete-nosotros.html

Más dudas en el correo electrónico: jobs@unkasoft.com o en el mismo blog.

Hola, contactó conmigo una persona de argentina, agricultor, para comprarme un sistema de guiado. Le he propuesto que él compre el hardware y yo le envío el software por mail, sin embargo no sé si en argentina podrá encontrar el hardware que uso para el sistema.

Podríais indicarme alguna tienda online en argentina para echar un ojo?

Alguna recomendación más?


PD: qué raro hablais ... :D

No estoy nada puesto en los juegos que hay para DS, tengo el mario kart que me regaló mi novia (tranquilos, no me ha llegado la fiebre del matrimonio :P) y estoy pensando en pillarme otro.

Alguna recomendación?

Qué algoritmos se usan para reconocer primitivas (rectángulos, esferas,etc) simples? He estado buscando y aparte de modelos ocultos de markov, no he encontrado un método algo más simple. Alguno conoceis algún método "simple"?

Hasta ahora he probado con detección de ángulos que no funciona del todo mal, pero que no funciona para, por ejemplo, los rectángulos. También había pensado en normalizar y hacer la correlación con primitivas ya conocidas...