Después de mucho trabajo finalmente hemos finalizado la primera versión de Running Fred y ya se encuentra disponible en App Store!  :)

Pueden acceder al  sitio oficial para ver el trailer y videos tutoriales.

El juego es gratis y se puede descargar desde  aquí (versión iOS para iPhone 3GS, iPhone 4, iPhone 4S, iPad, iPad 2, iPod 4)



Espero que les guste!

Estamos en la recta final del desarrollo de nuestro nuevo juego (Running Fred) y queríamos compartirlo con todos ustedes.

El mini sitio ya deja ver algunas screenshots y pusimos el teaser online, se puede acceder desde aquí.

El juego es una secuela de Falling Fred, sólo que con bastante mayor valor de producción y profundidad en gameplay.



Pensamos publicarlo en iOS y Android en un principio y luego en otras plataformas como PC, Mac y otros dispositivos móviles.

Espero que les guste.

En Dedalord tenemos el gusto de anunciar nuestro tercer juego: Falling Fred Z. Un spin off del popular Falling Fred. Con nuevos settings y modos de juego. Es gratis! (soportado por ads)



Key Features

* Challenge and survival game modes
* Two different settings
* Plunge through over 20 different hazards
* Watch  the replay of your "landing"
* Share your fall with your friends over Facebook and Twitter
* Dismemberment and gore galore for the whole family (assuming that all your children are 21)
* Amazing 3D sounds!

Video de gameplay

AppStore link

Falling Fred es un juego para iPhone/iPad (universal) súper adictivo y que se encuentra gratis sólo por hoy!!!

Descargarlo ahora


El señor Ogama Ben Ladder es un personaje jugable que cuesta 99 centavos de dólar extra.

Aquí pueden acceder a un video del gameplay: http://www.youtube.com/watch?v=laFTu8L12VE

Falling Fred, el nuevo juego de Dedalord, ya está disponible en el AppStore!

Manejá a Fred en su intento inútil por esquivar el piso! Gran variedad de obstáculos y de modos de "golpearse". Compartí tus caídas con tus amigos por Facebook o Twitter!

Para plataformas iPhone, iPod Touch y iPad (se recomienda dispositivos de 3era generación o superiores).









Link al AppStore: http://itunes.apple.com/ar/app/falling-fred/id414729389
Sitio Oficial: http://www.fallingfred.com
Twitter: www.twitter.com/fallingfred

Queríamos compartir con ustedes el lanzamiento de nuestro primer juego para iPad, el Psychoban HD.

El gameplay se basa en el juego sokoban pero con un twist al 3d (el nivel no es totalmente plano, sino que hay escalones y es posible montar cajas sobre otras). Esta versión posee 60 niveles, mejoras en calidad de texturas, iluminación y perspectiva. Además está integrada con Game Center (leaderboards y achievements).

El juego fue publicado en español e inglés.





Video de gameplay

Link al AppStore

Link al AppStore de la versión iPhone

Gracias! :)

Acabo de finalizar mi primer proyecto iPhone y quería compartirlo con esta gran comunidad.

El juego está desarrollado en Unity. Ofrece 50 niveles (alrededor de 2 horas y media de gameplay), diferentes ambientaciones, diálogos entre personajes, contenido desbloqueable, etc.

El gameplay se basa en el juego sokoban pero con un twist al 3d (el nivel no es totalmente plano, sino que hay escalones y es posible montar cajas sobre otras).

El juego fue publicado en español, inglés y francés.

Cualquier duda o pregunta, aquí estoy :)





Sitio oficial del juego
Link al juego en AppStore
Facebook Psychoban Page
Psychoban Twitter

Video del trailer en YouTube

Hola, quería presentarles mi nuevo sitio dedicado al desarrollo de videojuegos:

http://www.fuzzygamedev.com

El sitio está en español y tiene tutoriales, artículos de opinión, postmortems de juegos salidos en Argentina (pero quisiera ampliarlo a juegos creados por esudios latinamericanos y españoles), humor, la sección "glorias de ayer" y demás.

Sugerencias y críticas son bienvenidas. También si tienen alguna herramienta, lib. o juego que quisieran promocionar, avisenme que agrego la noticia.  :wink:

 Tengo claro como acceder desde C# a funciones dentro de una DLL escrita en C++.

Por ejemplo, si yo tuviese la siguiente función en C++ dentro de una DLL (pepe.dll):

Código [Seleccionar] Expand


int foo(unsigned short num)
{
   // ...
}


Podría declarar en C#:

Código [Seleccionar] Expand


class LoQueSea
{
 [DllImport("pepe.dll", CharSet=CharSet.Auto, SetLastError=true)]
 public static extern int foo(ushort num);
}


Luego para acceder a la función debería escribir:

Código [Seleccionar] Expand


int valor = LoQueSea.foo(1);


Lo que no entiendo y me estoy  (nooo) es como acceder al método (no estático) de una clase en C++ dentro de una DLL (not managed):

Ej:

Código [Seleccionar] Expand


class Clase1
{
  void foo(int num);
}


¿Como escribo el DllImport en este caso? ¿Acaso esto no se puede hacer?

Desde ya muchas gracias.

 En una época cuando sólo hacía uso de vertex buffers (y no Index Buffers), los objetos grandes (con muchos vértices) se procesaban de a partes en ellos. Para esto aplicaba un algoritmo que MS recomendaba, lockeando el VB de a partes y todo marchaba bien; podía procesar objetos de n vértices en vertex buffers de capacidad arbitraria y de una manera muy eficiente.

Ahora, utilizando Index buffers estoy ante un dilema, para procesar los índices de un objeto debo sí o sí enviar TODOS sus vértices y meterlos dentro de un vertex buffer lo suficientemente grande ya que podría ser posible que el primer triángulo que describan los índices hagan referencia al primer y último vértice del objeto.  (grrr)

Esto es un gran problema para mi ya que estoy creando una aplicación que construye mallas a partir de heightmaps, donde la cantidad de vértices de la malla es especificable, podría tener tantos vértices como al usuario le parezca adecuado.

Redimensionar el vertex buffer cada vez que el usuario lo especifique no me parece una buena idea, pero tal vez no me quede otra solución.

¿Como debería proceder?

 Quería compartir con ustedes un proyecto en el cual estoy trabajando hace tiempo.

Su nombre es Football Stick y es un juego de fútbol en el cual se juega sólo con un jugador al cual se le pueden subir las características como un juego de rol (en este caso son: fuerza, destreza, precisión, resistencia y velocidad).

Los jugadores son "sticks" (muñequitos de madera como los que usan los dibujantes para sacar poses).



El estado de desarrollo actual, el motor en un 90% y el juego en un 15%. Ya se puede manejar al jugador por la cancha, pero todavía hay pocas animaciones y todavía no hay colisiones.

Un screenshot del estado de avance:



Un screen de un stick corriendo, mostrando sus bounding boxes:



El objetivo que tengo es llegar a la fase 0 para Marzo de 2005 (aunque puede que esté antes). La fase 0 consiste en una prueba al gameplay del juego, o sea doble-click y arranca el partido. Es díficil saber si el juego será divertido o no, por lo tanto me estoy concentrando en lo importante que es el testeo de jugabilidad (corazón del juego).

Me es importante para mí, sus comentarios y sugerencias, que pondrían y que no. En el sitio oficial del Football Stick ( http://www.footballstick.com.ar ) hay un diario de desarrollo y un foro en el cual puede participar.

También se puede descargar el doc. de diseño brief y una versión vieja del doc. de diseño completo (que actualmente está en revisión y modificación).

Muchas gracias a todos y espero sus comentarios.

 Siempre en mi vida pensé que el siguiente código era erróneo:

Código [Seleccionar] Expand


void foo (int i)
{
   int aiNums[i];

   // ...
}


Debido a que el valor encerrado entre corchetes debería ser una expresión constante, así fue siempre y así lo enuncia la página 89 del libro "El lenguaje de programación C++ " de Bjarne Stroustrup (tercera edición).

Sin embargo el código anterior es compilable por el DevC++ (que utiliza el gcc 3.2) y funciona a la perfección.

¿Qué es lo que pasó? ¿Hubo una modificación en la especificación del lenguaje que permite ahora dicha expresión?  :blink:

Muchas gracias.

 Me preguntaba si es posible realizar una colisión pixel-perfect utilizando el stencil buffer.

El procedimiento sería así:

Teniendo que verificar la colisión pixel-perfect del Sprite A y el Sprite B:

1. Limpiamos el stencil buffer con un Clear.

2. Fijamos el render state relacionado al stencil a:

Código [Seleccionar] Expand


m_pD3DDevice->SetRenderState(D3DRS_ALPHATESTENABLE, TRUE);
m_pD3DDevice->SetRenderState(D3DRS_ALPHAREF,  iuColorKey); // uiColorKey color transparente de los sprites.
m_pD3DDevice->SetRenderState(D3DRS_ALPHAFUNC, D3DCMP_NOTEQUAL); // Acepta pixels distintos al valor de referencia (uiColorKey)

m_pD3DDevice->SetRenderState(D3DRS_STENCILENABLE, TRUE);
m_pD3DDevice->SetRenderState(D3DRS_STENCILFUNC, D3DCMP_ALWAYS);
m_pD3DDevice->SetRenderState(D3DRS_STENCILPASS, D3DSTENCILOP_INCR);


De esta manera todo lo que dibujemos debería incrementar el valor del stencil (en todos los pixels a excepción de los rechazados por el aphatest).

3. Dibujamos el Sprite A y el Sprite B.

4. Y ahora viene la parte que no sé:

¿Como haría para leer el Stencil buffer de manera eficiente para verificar si los pixels de los sprites se han superpuesto?

Me imagino que habría que obtener el puntero al buffer del stencil (por medio de un GetDepthStencilSurface) , luego realizarle un Lock (¿se puede trabar el stencil?) y luego recorrerlo en busca del valor deseado (un doble incremento), finalmente destrabarlo y retornar con el resultado de la verificación de colisión.

Claro que todo esto es válido si el alphatest se hace antes del stenciltest, pero creo que esto es así.

No encontré una implementación de este tipo en la red, imagino que los juegos 2d no están muy de moda y el uso del stencils suponen una placa de video que lo soporte, por lo que usar esta técnica en juego 2d sería requerir cierto hardware normalmente es esperable en un juego 3d.

 ¿Alguien sabría decirme alguna aplicación directa en programación de juegos de los siguientes temas de Álgebra lineal?:

Transformaciones lineales
Espacios vectoriales

Muchas gracias.

 Estoy implemetando un sistema de ventanas dentro de mi motor utilizando DirectX8.1 y para evitar que el dibujado de algún texto se escape de la ventana quería setear lo que en OpenGL haría con glScissor, que es una zona fuera de la cual todo se clipea.

No encontré una función similar en DirectX. Si fijo un viewport (con SetViewport) generaría también una zona fuera de la cual todo se clipearía pero también tendría que alterar la matriz de proyección para evitar un reescalado. ¿Existe otro método alternativo bajo en costos de CPU?

 Si creo una textura con el "DirectX Texture Tool", cambio el formato del bitmap que le introduzco a DT1 y luego cargo la misma en mi motor con la función D3DXCreateTextureFromFile ¿estaría utilizando compresión de texturas o hay que meter mano en algo mas?

 Estoy buscando algún formato de sprite que se pueda crear desde algún editor gnu o shareware.

O al menos la documentación de algún formato de sprite para poder tomar como base, mi motorcito utiliza uno creado por mi que consta de distintos archivos (uno con la info del sprite en XML y el restos son bitmaps tradicionales), pero no quiero darme cuenta dentro de tres meses que olvidé algo fundamental.

El siguiente es un ejemplo de mi formato:

<!-- AnaConda Sprite File -->
<!-- Sprite header        -->

   
 
 
   

Tiene una posición por defecto, propiedad de visibilidad chequeo de colisiones, layer y luego la info de animación.

 Utilizando DirectX9 ¿qué formato de vértice sería mejor utilizar para todos los objetos 2D (indicadores del estado del juego, menúes, etc)


1. D3DFVF_XYZRHW | D3DFVF_TEX1 : Vértices ya transformados que no pasan por el pipeline. De este modo la traslación de los sprites debería realizarse modificando la posición de los vértices.

2. D3DFVF_XYZ | D3DFVF_TEX1 : Utilizando una matriz de proyección ortogonal. De este modo la traslación de los sprites se realiza modificando la matriz de mundo.

¿Qué es mas rápido? Alguno de los dos acarrea alguna pro o contra extra.

Según leí la primer opción es mejor para quienes estén portando su juego desde algún API 2D, debido a que la manipulación de las posiciones de los objetos se basa en modificación directa sobre las propiedades de posición y no existe la manipulación de matrices.

 En un motor de juegos ¿qué es mas conveniente?

1. Que cada objeto dibujable posea su vertex buffer.
2. Que exista un vertex buffer único y muy grande reutilizado para todos los objetos.


Sinceramente creía que la opción 1 era la lógica, pero recientemente leí en un libro de programación de juegos que utilizaban la opción 2, y decían que era lo mejor. ¿Ustedes que piensan?

Muchas gracias.

 ¿Alguien sabe cuál es la razón técnica por la cual las APIs 3D solicitan que el tamaño de las texturas sea una potencia de 2?

Entiendo que debe ser por como trabaja la placa de video, pero me gustaría conocer mas detalles al respecto.

Desde ya agradezco cualquier tipo de información.