Feudo
31Jul/140

Como no me pescaron ni en bajada…

bueno, como al parecer no llegamos a convocar a nadie para  la parte de los dibujos decidí tomar cartas en el asunto, así que supongo que va tener que ser en colaboración con lo que tengamos a mano.

le hice un poco de re diseño al personaje y probé algunas cosas y la verdad pienso que quedo mejor que como estaban, este seria para la clase aldeano, le falta en todo caso sobre todo en la textura, (trabajo para alguien con wacom diria yo), bueno eso y espero les guste.

 

aldeanot1 aldeanot2 aldeanot3

Archivado en: Feudo No hay comentarios
7Jul/140

Actualización Julio

Aunque no me ha dado el tiempo para ir anotando las actualizaciones semanales, dejo ahora un resumen de los avances del último mes. En resumen se ha estado avanzando en la parte gráfica, implementando algunos terrenos nuevos, como montañas, o lagos.

En la parte de programación, he terminado el gestor de armadas, ahora es posible crear los grupos, asignarle unidades y designar el capitán de dicha unidad.

He programado un "control" tipo listbox para gestionar los equipos (o cualquier lista seleccionable, como la raza).

Está programada la interface de las clases y programada 3 de las 11 clases básicas que tendrá el juego, aunque falta programar el sistema de requerimientos, ya que antes de poder asignar una clase a un aldeano se deberá cumplir ciertos objetivos, por ejemplo, tener una barraca de soldados para poder asignar la clase de guerrero, etc. (una vez que este terminado publicaré una lista completa).

Programado un sistema de niebla de combate, no solo que oculta las zonas aún no exploradas (esto ya lo tenía hace tiempo), si no, con línea de visión.

Agregado un sistema de lista de mensajes cuando se cambia de turno.

Un sistema de alerta antes de cambiar de turno,  por ejemplo, avisos de que no aún no movemos todas las unidades o por ejemplo que tenemos una construcción en la cola de producción, pero no tenemos puntos de producción asignados.

Dejo algunas imágenes de algunos avances y para el par de lector que hay, les recuerdo que salgo fuera del país por un proyecto, con lo cual en Julio los avances serán muy lentos, tal vez si tengo tiempo, iré escribiendo de forma más detallada sobre el desarrollo del juego, ya sea a nivel de programación o a nivel de gameplay.

imagebam.com

imagebam.com

imagebam.com

Archivado en: Feudo No hay comentarios
23Jun/140

Sobre las clases de personajes.

Bien, creo que esta es mi primer a publicación, así que tengan paciencia que voy a tratar de explicarme lo mejor posible, a los artistas que aun estén interesados en participar, tenemos una tarea en la que necesitamos ayuda,  en el videojuego necesitamos visualizar 11 clases de personaje, las que debemos modelar y renderisar estilo cartoon para luego hacer animaciones, pero antes necesitamos unos placeholders  de los personajes, el estilo está definido y se los mostrare a continuación, serian dos diseños por clase, hombre y mujer, en total 22 diferentes diseños.

Zapador (ingeniero constructor) = hombre y mujer.

Barbaro = hombre y mujer.

Bardo = hombre y mujer.

Clerigo = hombre y mujer.

Druida = hombre y mujer.

Explorador = hombre y mujer.

Guerrero = hombre y mujer.

Hechicero = hombre y mujer.

Mago = hombre y mujer.

Paladin = hombre y mujer.

Picaro = hombre y mujer.

 

Para tener una idea de lo que necesitamos, adjunto imagen de ejemplo.

prueba

y este seria el diseño básico.

 

2

Archivado en: Feudo No hay comentarios
27May/140

Unidades sobre el mapa

Primero. Sé que estoy bastante atrasado respecto a escribir la documentación de diseño, pero no me ha dado el tiempo para todo y he preferido seguir avanzando en la programación del juego. Sin embargo tengo pendiente el resto y tengo cosas escritas, así que trataré de colocarme las pilas para ir liberando información técnica respecto al diseño gráfico del juego.

Por hoy, y para mostrar que el proyecto sigue avanzando aunque no me haga el tiempo de ir colgando los avances por acá. una imagen del juego en el modo mapa, con diferentes unidades sobre él, con un cursor para seleccionarlas y con niebla de guerra y aunque acá no se aprecia el cursor está animado.screen00

El cursor es una imagen de 512x512 dividida en cuadros de 128x128, lo que da 16 pasos para la animación.

Cursor feudo.

Cursor feudo.

Archivado en: Feudo No hay comentarios
9Feb/141

Feudo. formato imagen

Antes de comenzar a desglosar cada parte del juego, es necesario definir algunos formatos.

El juego está programado sobre una librería gráfica llamada dxlib32 (pueden acceder a la página de la librería desde el enlace al costado derecho) que usa DX. Todo el proceso gráfico ocurre sobre la GPU, por lo cual las imágenes que vamos a utilizar deben ser tratadas como cualquier otra textura y eso significa que deben ser múltiplos de potencia de 2 y por compatibilidad con equipos viejos o modestos, es mejor que las texturas no sean superiores a 1024*1024.

Aunque es posible usar diferentes formatos de imagen, el más utilizado es un PNG con canal alpha (ARGB) y en algunos casos especiales alguna imagen en JPG (RGB) debido a que su carga es más rápida (pero carece de canal alpha).

Al momento de hacer animaciones o texturas para el juego, es importante remarcar la regla de que la dimensión de la imagen deben ser múltiplos de potencia de 2 (2,4,8,16,32,64,128,256,512,1204), básicamente debido a que la librería si intenta cargar una imagen que tenga otra dimensión, hace un ajuste automático que puede deformar ligeramente la imagen original y cuando se tienen animaciones o objetos de solo unos pocos pixel (por ejemplo, los tiles del juego son de 96 pixel) un solo pixel fuera de lugar basta para que el resultado final se vea mal.
Además, esto también se aplica a la hora de obtener subtexturas, por ejemplo, es normal cargar una textura grande que en su interior contenga varias imágenes. Para evitar sorpresas, debido a como funciona la librería, es mejor que cada imagen este contenida dentro de un rectángulo que cumpla la regla de ser múltiplo de potencia de 2. Es mejor perder algo de espacio dentro de la textura, pero tener la seguridad que la librería va a dibujar el recurso tal cual lo diseñamos.

Por ejemplo, las texturas usadas por los tiles haxagonales del juego, son de 96x96 pixel, sin embargo, se encuentran contenidas dentro de un rectángulo de 128x128 pixel, habría sido más eficiente que las tiles estuvieran más cerca, de esa forma se aprovecha mejor la superficie de la textura, pero debido a esta "maña" de la librería es mejor perder un poco de espacio, pero tener la seguridad de que el tile se verá tal cual fue diseñado y que calzara hasta el último pixel, sobre todo a la hora de hacer animaciones.

texturas_ejemplo

La parte de audio no es diferente de otros juegos, los efectos de sonido en formato WAV y la música en OGG con una calidad decente, a parte de eso, no hay mucho que agregar.

Archivado en: Feudo 1 Comentario
9Feb/140

Feudo. Resumen

Para comenzar a ordenar el proyecto me gustaría colocar una explicación general de como está estructurado el juego (a través de las pantallas del juego) para luego ir creando las entradas especificadas, en las cuales habrá una explicación detallada, así como los enlaces para descargar los recursos gráficos que actualmente se están usando, de esa manera la gente que sabe de diseño tenga claro como crear contenido.

general

-Carga y menú principal: El juego inicia con pantalla de carga, la cual se muestra mientras se cargan en memoria los recursos a usar (gráficos, sonidos, textos, etc), al finalizar la carga de recursos se muestra el menú principal, donde se puede crear un juego nuevo o cargar uno existente.

-Creación avatar / mapa: Si se crea un juego nuevo, se procederá al menú de creación de personaje/mapa, en el cual se puede personalizar la unidad que representará al señor feudal y es la única unidad que podremos personalizar a este nivel (el resto de la población se genera al azar) y algunas opciones para personalizar el mapa.

-Mapa del mundo: La ventana principal del juego, es donde se muestra el mapa general del mundo, desde esta ventana se puede acceder a los castillos o a los ejércitos.
En el costado derecho se encuentran algunas ventanas de información general (como la fecha dentro del juego), y el botón de pasar de turno.
En la parte inferior se mostraran los iconos de acciones de la unidad que se tenga seleccionada.

Menú de castillo: Si desde el mapa del mundo se selecciona un castillo, se abrirá este menú, donde se encuentran las estadísticas del castillo (lo que se produce, lo que se consume, un resumen de sus habitantes, etc).
La sección de construcciones, donde se muestran las edificaciones, así como sus efectos (por ejemplo, la cabaña de leñador convierte árboles en troncos, etc).
Una ventana con información de cada aldeano existente dentro del castillo y otra para administrar los ejércitos.

Menú de ejércitos: similar al menú anterior, pero focalizado solo en el apartado militar, sirve para editar un ejército que se encuentre en el mapa del mundo, pero no sobre una ciudad.

Mapa de batalla: Cuando 2 o más ejércitos enemigos se enfrenten en el mapa del mundo, se despliega un segundo mapa que representa el tile donde se encuentra los ejercitos en el mapa de mundo.

PD: Recuerden que esto es un resumen general y es sobre la versión alpha, es posible que el juego final sea diferente y tenga más o menos opciones.

Archivado en: Feudo No hay comentarios
3Feb/142

Feudo, historia

La idea original de hacer un juego sobre administrar un castillo feudal, es una idea que me viene rondando hace bastante. Sin embargo por diversos motivos, entre ellos la complejidad de plasmar la idea completa, no me habían dejado ponerme a programar seriamente este juego.

El año pasado, para un concurso, comencé a programar esta idea, pero de una forma sencilla, sobre todo por los plazos de tiempo que imponía el concurso, y el resultado no estuvo mal, aunque el juego no tuviera la profundidad que me habría gustado.

ImageBam image upload

ImageBam image upload

Una vez finalizado el concurso, comencé a agregarle más opciones al juego original, como por ejemplo, niebla de combate, cambiar el tipo de mapa de tiles cuadrados a tiles hexagonales, etc. Lentamente comencé a modificar el juego para que se adaptara más a la idea original que tenía de feudo y es el proceso en el cual me encuentro actualmente,  he reprogramado ya varias partes de este "motor" para permitir que el jugo sea modular y expansible de forma sencilla, como por ejemplo, podría ser el sistema de edificios, en la versión original estaba limitado a unos 10, en una pantalla fija, ahora el sistema permite agregar todos los que quiera de forma simple.

Lo que se viene es cambiar el sistema de clases y combate y tal vez un rediseño gráfico (acá estamos solicitando ayuda), ya que mucho del diseño actual lo hice yo con placeholder, y como suele ocurrir en este mundo, le programado sabe de programación pero no de diseño, y así, aunque me puedo comprometer a reprogramar el sistema de combate para que sea más parecido a un juego de rol de mesa, no puedo comprometerme a cambiar el diseño gráfico del mismo si no es con la ayuda de otras personas.

Modificando el sistema actual de clases y combate, el juego estaría en condiciones de ser jugable (como versión alpha eso si), de ahí en adelante, comenzaría la etapa de ir mejorando el juego, ya sea agregando o equilibrando las clases o ciertas mecánicas, como podría ser el sistema de combate, etc.

Espero que el juego siga gradualmente avanzando, como ha venido haciendo estos últimos meses, sobre todo por que el proyecto comienza a atraer a otras personas  interesadas en ayudar, actualmente en la parte de diseño y arte esta colaborando Christian Muñoz (heunithen) y esperamos dentro de poco, contar con alguien dedicado al área de arte, con lo cual podría ir cambiando todos los gráficos placeholder que estoy usando y hacer que el juego tenga su estilo propio desde el punto gráfico.

Archivado en: Feudo 2 Comentarios
3Feb/140

Feudo, inicio

El juego en si, es un juego de estrategia y tácticas por turnos del tipo 4X, pero con un fuerte énfasis en el recurso humano, ambientado principalmente en D&D y las reglas D20, eso significa que nos encontramos en un mundo medieval con elfos, orcos, enanos, etc.
El juego, al igual que otros 4x nos permite gestionar un pueblo con sus construcciones, de forma similar a juegos como el Civilization, pero la gran diferencia es el concepto de que la base de todo el sistema económico y militar son las unidades, en este sentido el concepto es más similar a Dwarf fortress o Gnomoria, por lo cual me atrevería a decir que Feudo Tácticas es una mezcla de conceptos entre el CIV y el Dwarf (ojo, hablo de conceptos no de la jugabilidad).

Por ejemplo, inicias el juego con 20 aldeanos (unidades) donde cada una es única, con sus propias estadísticas, ventajas y desventajas, cuando construyes un edificio, necesitas asignarle los trabajadores, por ejemplo, mientras mayor sea la fuerza, más rápido van a talar los árboles, también hay bonos por razas, por ejemplo, el elfo tiene un bono de +2 a la carpintería, un enano a la herrería, etc.
El problema, es que el recurso humano se hará poco, así que es necesario invertirlo de forma sabía, por ejemplo, cada trabajador que asignes a un edifico, será necesario pagarle, pero aquellos que no estén asignados trabajan por su cuenta y pagan impuestos, así que es necesario buscar el equilibrio si no te quieres quedar sin oro.

Como todo buen juego 4X, dispones de un mapa para explorar y donde puedes explotar diferentes recursos que encuentres. pero claro, no es un mundo amigable, así que necesitas un ejercito para poder salir a explorar y a diferencia de otros juegos donde por generación espontanea obtienes soldados genéricos, acá tienes que enseñarles a combatir a tus aldeanos, esta área es donde el juego se inspira bastante en D&D, por lo cual las unidades pueden obtener niveles como guerrero, bárbaro, clérigo, paladín, etc. Y donde cada unidad tiene su propia experiencia que le permite subir de nivel, así que nuevamente, el juego está centrado en el recurso humano, siendo más importante centrarse en la calidad de cada unidad, que en la cantidad.
Y si hablamos de calidad, entonces es necesario hablar de que cada unidad tendrá su equipo, así que es necesario ver como lo obtenemos, ya sea, comerciando, entrenando artesanos y encantadores que los fabriquen o explorando dungeon.

Para finalizar, y aunque en términos generales el juego se puede expresar como una mezcla entre un CIV y el Dwarf Fortress, nunca intenté que el juego fuera una mezcla de esos títulos (ni lo intento, aunque si me inspiro en algunas de sus mecánicas), la verdad es que hace años, cuando jugaba AD&D recuerdo una parte del manual que hablaba sobre los personajes retirados y de como era posible que esos personajes se convirtieran en señores feudales que administraran sus propios castillos y este juego viene a ser básicamente eso, convertir en un juego de PC aquella rama "olvidada" de los antiguos juegos de rol.

ImageBam image upload

ImageBam image upload

Archivado en: Feudo No hay comentarios
23Nov/100

Re-estructuración de Feudo

Por suerte no soy el único interesado en juegos de estrategia/administración medieval, y hace unos días se ha unido al proyecto Cristian Muñoz, con quien voy a trabajar tanto en el diseño del juego como en la parte gráfica, con lo cual el proyecto va a sufrir una completa remodelación como muestran las siguientes imágenes:

Ahora el proyecto pasara a ser 3D, con todos los cambios que eso significa. Igual no voy a perder lo hecho originalmente y pienso usarlo para armar algo mucho más simple, al estilo de un mini zelda 2D o más similar a un RPG clásico.

Archivado en: Feudo No hay comentarios
1Nov/100

Input

Como siempre, deben recordar que todo lo que escribo proviene de mi propia experiencia y de lo que he ido leyendo por la red y que no soy un profesional del tema.

El input
El input es parte fundamental de los juegos, pues consiste en conectamos todo el hardware que interactua con nuestro usuario y en convertir dichas señales en ordenes o información relevante para nuestra aplicación, actualmente los dos grandes hardware para PC son el teclado y el mouse, aunque de seguro iremos viendo cada vez más opciones, como pantallas de multitoque (Las pantalla de monotoque, aunque como hardware son diferentes, a nivel lógico su input es exactamente el mismo que el del mouse.), capacidad de reconocer ordenes vocales y de seguro que en algunos años más veremos sistema que reconocen los impulsos eléctricos del cuerpo para convertirlos en señales directas para nuestro PC.

Hay por lo menos 2 formas de manejar estos input, una consiste en crear un ciclo que se encuentre escaneando de forma permanente los valores de los hardware de entrada (Keyboard, mouse o gamepad) , la segunda consiste en agregar las ordenes a ciertos eventos que nos entrega nuestro lenguaje, como puede ser el caso de flash, donde en vez de tener un ciclo de input, lo que tenemos son eventos disparados por el usuario. Sobre cuál es mejor, creo que es mejor considerar que ambas son herramientas y que la elección debe responder a nuestro gusto y a nuestras necesidades (y a nuestro lenguaje, pues no todos disponen de ambas opciones).

En mi caso, voy a optar por la clásica estructura de tener un ciclo de input que lee el hardware, que le entrega la información al ciclo lógico y la salida será el ciclo de dibujo.

Ciclo

Lo primero, es contar con alguna herramienta que nos permita leer las entradas del teclado o del mouse (o del gamepad), por desgracia no podemos usar la entrada normal de windows, ya que ésta cuenta con un retardo que haría injugable nuestra aplicación.

Abran el Notepad o cualquier aplicación que les permita escribir, presionen y dejen presionada la tecla “A” y vean que ocurre. En el instante en que presionan la tecla, va a aparecer la letra “A”, si mantienen presionada la tecla, verán que luego de aproximadamente un segundo el notepad empieza a escribir toda una línea de letras “A”, el tiempo que transcurre entre que se preciosa por primera vez la tecla, hasta el momento en el cual se comienza a escribir la línea de letras es un retardo que aplica nuestro sistema operativo y no el notepad, si programamos un juego y usamos el input normal de windows para leer la entrada del teclado vamos a tener el mismo problema. Imagen jugar Mario bros de ésta forma, al presionar la tecla izquierda el personaje se movería un poco, para luego quedar quito durante un segundo, sería algo bastante desagradable.
Para solventar el problema podemos programar nuestra propia aplicación para que lea de forma directa el hardware o usar alguna librería que haga esto. Yo voy a usar la librería dx_Lib32. La cual incorpora toda una clase dedicada a la lectura del hardware de input.

¿Qué hacemos con el input?
Lo que yo recomiendo es separar el input en ordenes que le pasaremos a nuestro ciclo lógico y que sean lo más independientes posibles del hardware, supongamos que tenemos un juego de plataformas, donde tenemos a nuestro héroe de turno, lo primero es definir que ordenes puede ejecutar y al ser un juego de plataformas, nuestro héroe debería ser capaz de saltar, caminar a la izquierda y caminar a la derecha. A nivel lógico tenemos 3 eventos independientes del input, cada uno de estos métodos debe estar enlazado con el input, pues la decisión de saltar, caminar a la izquierda o la derecha no depende de nuestra aplicación, si no, que depende del jugador (Recuerden que la única forma de interactuar entre el jugador y nuestra aplicación es mediante el input). Al hacer ésta separación, es posible asignar cualquier entrada a cualquier acción dentro del ciclo lógico, en otras palabras, la acción es saltar, y luego enlazamos el input del keyboard, la tecla “W”, a la acción de saltar; la ventaja de ésta separación, es que si el día de mañana queremos agregar a nuestro juego la opción de usar un gamepad no tenemos que reprogramar la acción de saltar, simplemente agregamos un enlace.

Input

Ordenes por nivel y por flanco.
En mis proyectos, yo suelo utilizar 3 eventos por cada botón o tecla que son el momento en el cual se presionan (flanco de subida), mientras se mantiene presionado (nivel 1) y cuando se suelta (flanco de bajada), si volvemos al ejemplo anterior, saltar es una orden que sólo se debe efectuar una vez, por lo cual obedece a una acción de flanco, es similar a prender una luz, porque al hacerlo sólo deben presionar el interruptor una única vez y no es necesario mantener el dedo en el interruptor para que la luz quede encendida (técnicamente existe una memoria mecánica, pero no viene al caso explicar ese concepto). En cambio, caminar a la derecha o la izquierda son ejemplo de ordenes por nivel y son parecidas al acelerador de un automóvil, para que el automóvil se mueva es necesario mantener presionado el acelerador, cuando lo sueltan, el auto comienza a detenerse. En nuestro juego queremos que pase el mismo fenómeno, queremos que se salte una única vez cuando se presione el input “W”, pero queremos que se camine a la izquierda mientras se tenga presionado el input “A”.

Flancos
Para evitar que se puede saltar en medio de otro salto es necesario usar algún flag que nos limite la acción de saltar, pero no viene al tema ahora.

Para poder reconocer un flanco es necesario almacenar el valor de nuestro input en el ciclo anterior, como ven en el dibujo, un flanco de subida es el momento en el cual el input tiene valor 1, pero que en el ciclo anterior tenía valor 0. Un flanco de bajada, al contrario, es aquel que actualmente tiene valor 0, pero que en el ciclo anterior tenía valor 1.

Pseudocódigo:
ValorW = ActualizarInput(“W”)
Si ValorAnteriorW = 0 y ValorW = 1 Entonces
#Flanco de subida
Heroe_Saltar
Fin del Si
Si ValorAnteriorW = 1 y ValorW = 0 Entonces
#Flanco de bajada
Fin del Si
ValorAnteriorW = ValorW

ValorA = ActualizarInput(“A”)
Si ValorA = 1 Entonces
#Nivel 1
Heroe_Izquierda
Fin del Si
ValorAnteriorA = ValorA
Es muy fácil crear los flancos, simplemente debemos almacenar en algún lugar el valor que tenía el input en el ciclo anterior.

Algo que puede ser confuso para los nuevos es el termino de los ciclos. Mi juego, al igual que muchos otros, tiene un ciclo principal que se repite n veces por segundo (30 en mi caso), ese es el ciclo principal del juego y dentro del cual yo llamo a los ciclos de input, de lógica y de dibujo, en mi caso he optado por tener todo sincronizado, con lo cual, todo mi hardware de entrada se actualiza también 30 veces por segundo, cada una de estás actualizaciones es un ciclo, ésta no es una única manera de hacerlo pero no me da ahora el tiempo para entrar en detalles sobre eso.
Mi ciclo principal parte leyendo el estado actual del keyboard, del mouse y del gamepad (si corresponde) y me entrega los valores en variables, luego yo reviso si en éste ciclo está presionada la tecla “W”, lo comparo con el valor que tenía en el ciclo anterior (previamente guardado en alguna variable como muestra el ejemplo) y con el if determino si corresponde ejecutar la acción de saltar o no y así ocurre en cada ciclo, manteniendo conectado al jugador con la lógica.

Archivado en: Feudo No hay comentarios
FireStats icon Con la potencia de FireStats