#360 Gracias. Estoy usando stb_image y me va perfecto (bueno, he tenido un problemilla al principio porque no sabía que automaticamente cambiaba el formato de los targa de BGR a RGB al cargarlos y se veía todo azul xD). Y que buena pinta tiene SFML, me han entrado ganas de hacer algo con eso
me voy a apuntar a eso de mostrar nuestras chapucillas:
http://www.mediafire.com/?xaw78gxf2fjdb2m
estaba echo en c++ con SDL y inspirado en los tipicos tamagotchis
te mueves con las flechas por el menu, y con "a" seleccionas.
esta a medias, ya que la pet no muere ni evoluciona, y el entrenamiento esta mal echo y corre a distinta velocidad en cada ordenador, cosas que arreglare en el futuro, ya que ahora quiero ponerme con otra cosa, que me ayude mas a aplicar lo que voy aprendiendo en SDL
#362 Reviviendo momentos traumáticos de la infancia cuando jugando en un parque se rompieron los botones de mi tamagotchi y tuve que contemplar como se moría de hambre y rodeado de mierda -incapaz de hacer nada- el bichito al que tanto tiempo había cuidado... xD
El entrenamiento me va a la velocidad de la luz prácticamente 
Has usado algún tuto para aprender c++ con SDL? En caso afirmativo, podrías rular el enlace para que eche un vistazo?
Yo aprovecho para colgar los avances de mi action mierder defense xD
http://www.mediafire.com/?gjipb92g6677ai7
Ayer fue un día productivo! 
Nueva versión con algoritmo de generación de monstruos, el cual hay que perfeccionar mucho para crear una curva de dificilutad pepins.
Y además! Se pueden comprar metralletas y escopetas.
Hay un menú simbólico abajo, a espera de ser diseñado. Con la rueda del ratón movéis el selector. Una vez elegido el item, click con el botón derecho y compráis una mejora.
Sólo funcionan la opción 2 y 3 (empezando por la izquierda), que son:
2 - Metralleta
3 - Escopeta
La escopeta tiene un bug, y es que al disparar hacia arriba no se dispersan bien las balas, pero bueno, work in progress ;P
#363 yo me acuerdo que siempre habia alguien a quien le pitaba en clase y estaban los profesores hasta los cojones xD
#363 Está bastante bien! ejejeje, es muy dificil girar el personaje cuando cambias de direccion?
Quedaria un poco más profesional!!
#365 Qué va! Es facilísimo! Pero son imágenes prototipo a espera de que los artistas empiecen a producir lo que toca. Este martes tengo reunión con ellos para ver si empezamos a darle forma a todo el apartado gráfico.
Va a tener un estilo bastante característico. Estará hecho todo con recortes de revistas De ahí su nombre, Brutal Collage. Y los enemigos al morir, soltarán trocitos de papel, que es lo que el prota usará para construir sus mejoras :3
#364 Gracias! 
hola a todos
quiero empezar con esto de la creación de videojuegos y tal pero la verdad es que no se muy bien por donde empezar. Me interesaría crear juegos de pc pero no se ni que motor emplear ni nada ...
si alguien me pudiera aconsejar para ir empezando se lo agradeceria muuucho
#368 no si ya me lei el post y estuve viendo los motores y tal pero entre tanta variedad pues no se que elegir la verdad, y para empezar diría de 2D xD
#369 pero sabes programar?
presentate poniendo información sobre ti, como si fuera un curriculum, porque sino poco te vamos a poder ayudar.
#370 no, no se programar por eso mismo estoy pidiendo ayuda para empezar, con tutoriales y el lenguaje mas facil para ir empezando y asi
#371 Ufff.. pues lo primero entonces es aprender a programar. Para eso creo que sirven las carreras y los años de estudio xD
Puedes intentar tirar por una alternativa que no sea tan hardcore gamer y usar Game Maker o Stencyl que permiten, o eso dicen, el desarrollo de juegos sin tener ni papa de programación :S
#371 Yo te recomiendo que te bajes el pdf de "Thinking in C++" que es gratuito y vayas capítulo a capítulo, cuando sepas programar bien en C++, empieces a estudiar UML y a traducir UML -> C++.
Entonces ponte a hacer juegos
#376 Suerte con el aprendizaje si vas a ir en plan autodidacta. Te recomiendo mirar una semana python, aunque no vayas a programar nada en él, pero debido a su simplicidad te ayudará a entender de qué va la cosa. Luego aprende a programar de forma estructurada (yo empezaría por C), y después de forma orientada a objetos (el concepto de clase y tal se aprecia mejor en java, en mi humilde opinión, pero lo suyo es aprender C++ antes o después).
Todo esto no se aprende en una tarde.
¿Tutoriales? Huye de lo que te diga "copia esto para que haga esto". Aprende de verdad, un manual muy simple de C puede ser el de Nacho Cabanes. Descarga ese, el tío se tira 3 párrafos para explicar qué significa int main(){}. Tienes ejercicios y todo eso.
Consejo: Nada de "yo me entiendo". A las cosas por su nombre (tranquilo, cuando sepas el nombre). Que en mi ciclo había uno así y cada vez que preguntaba una duda sacaba de quicio a cualquiera xD.
Tengo una pregunta en cuanto detección de colisiones...
En Indielib, únicamente se puede detectar una colisión entre 2 objetos, comprobando si hay colisión uno a uno. Así que cuando meto un nuevo elemento en el juego tengo que actualizar tooodos los demás objetos para que detecten si colisionan entre ellos.
Hasta ahora sólo tenía balas y no me costaba añadirle al update de cada objeto que comprobara si alguna bala le tocaba y así le restara vida.
Pero claro, ahora estoy implementando minas antipersona. Entonces claro, me veo en la tesitura de incluirlo en el update de todos los enemigos, generándome mogollón de curro.
Me pregunto... ¿Hay algún engine que gestione """automáticamente""" la detección múltiple de colisiones? De no ser así, ¿Me recomendáis alguna buena práctica para el tema de las colisiones? A mí me parecía buena idea meter en el update de cada malo que mirara si recibía algún impacto, pero claro, me pasa lo que he explicado.
La otra opción que se me ocurre es meter la detección de la colisión dentro del Update de la mina antipersona. Pero entonces me quedaría un trocho enorme dentro de la mina, iterando sobre todos los objetos de los enemigos y decidiendo qué hacer con cada uno (en principio todos extendienden de una superclase enemigo así que el atributo Vida es común...)
¿Qué me recomendáis? Actualizar cada enemigo para que detecte minas? O enviar un mega-array de objetos a la mina para que itere sobre ellos?
Se aceptan ideas alternativas creativas xD
#378 Sin tener ni p... idea, no podrías gestionarlo en plan "roles" es decir, que el objeto del rol X impacte con los objetos Y, Z, F
#378 el tema de colisiones es tan amplio que no te lo puedo resumir en un post.
Si quieres ahorrar trabajo, tira a una librería de físicas a lo Box2D. Recomendado 100% porque así tienes la física y las colisiones, 2x1.
A lo simple no hay otra que hacer la comparación de los N objetos (es O(n2) lo mires por donde lo mires) o implementar algún tipo de sistema complejo de colisiones como el que implementa Box2D: una fase "ancha" con AABB (Axis-Aligned Bounding Box) por ejemplo y luego mini-fases para las colisiones perfectas.
Si no, vas a tener que entrar a montarte estructuras de datos como quadtrees (muy útiles para cuando se te desmadra el número de objetos que pueden colisionar.)
#380 Muchas gracias, siempre estoy esperando tus respuestas que de momento me han ayudado el 120% de las veces xD Te voy a tener que poner en los créditos y todo
Como lo que estoy haciendo ahora no pasará de minijuego me montaré un iterador de colisiones y palante. De cara al próximo me estudiaré esas alternativas más complejas que me has mencionado.
Me estoy leyendo ahora el segundo manual de C++, sabía 0 del mismo, pero en poco tiempo me estoy haciendo con él. Programar ya sabía, pero necesitaba reorientar la filosofía de trabajo, el Thinking in C++ me ha ayudado un montón. Eso sí, el tema de punteros me sigue pareciendo magia, y voy peleándome con él a machete, pero lo voy sacando. Me molaría encontrar algún manual que entrara muy en detalle con el tema de punteros, o alguno con dibujicos para tontos si hace falta xD Que me parece muy abstracto todo ese tema de momento, no sé muy bien lo que hago, simplemente copio metodologías.
#378 Yo en el ultimo jueguillo (y el primero) que hice use este sistema (el juego era de muy baja escala, un copter en c++ con OpenGL xD):
En ved de meter el codigo de las colisiones en cada clase, cree una clase aparte para encargarse de las colisiones, con un metodo que se llamaba cada frame para gestionarlas. Esta clase tenía un vector con todos los objetos del juego, y en cada frame iteraba por cada uno de ellos y comprobaba si colisionaba con alguno de los otros. Si colisionaba, llamaba a un metodo en clase de ese objeto pasando el objeto con el que colisionaba como parametro. Y luego cada objeto implementaba ese metodo haciendo lo que necesitara en funcion de con qué había colisionado .Todos los objetos del juego eran subclases de otro objeto, y el vector era de esos objetos. Ademas en la superclase tenía un enum para saber que tipo de objeto era realmente y lo casteaba al tipo de la subclase segun necesitaba.
Seguramente habrá formas mejores pero bueno, asi es como yo lo hice
#382 Mmmmm.... vectores. Sería una manera, de hecho he visto en el foro de Indielib que uno lo resuelve así, pero es una ciencia deconocida para mí de momento. Me pondré a estudiarla
De momento lo he implementado en el update de las minas, y si las toca alguien PUM, balas pa tos... así que ale, nueva versión. Ahora con un 100% más de minas antipersona!
Se Plantan con la primera opción del menú -> botón derecho
Te lo han resuelto más arriba, quadtree.
Para que lo entiendas rápido:
- Tienes un árbol de 4 ramas, que cada rama a su vez otro quadtree.
Qué implicaciones tiene esta estructura de datos? que las colisiones no se calculan por objetos sino por zonas del quadtree. Tienes dos planteamientos:
Haces zonas suficientemente pequeñas como para que 2 objetos en una zona = a colision o calculas para cada zona que se haya variado las colisiones interiores.
Cómo saber que una zona se ha modificado es uno de los problemas de programación más bonitos que tiene la programación de videojuegos, como pista daré que hay varios métodos, el más simple es hacer un hash de esa zona y comprobar si es la misma.
De todas maneras, vamos a hacer cálculos.
Sabiendo que todos los objetos se comprueban contra todos, tener N objetos implica O(n2) comprobaciones, un tiempo computacional muy elevado.
Si tienes un quadtree de 16 zonas, cada zona con un máximo de 4 elementos, haz cálculos:
TODOS CONTRA TODOS:
162 = 256
16 zonas de 3 elementos:
32 = 9
9 * 16 < 256
Otro punto:
Los cálculos no se hacen TODOS contra TODOS, es lo mismo hacer A contra B, que B contra A, así que sólo algunos tipos de objetos realmente calculan colisión, no todos.
#384 Hostias, esto parece de hackers ya. Abro una puerta y aparecen 5 más... ·_· Aún así no voy a desistir. Muchas gracias por la introducción a quadtree! Buscaré información al respecto y lo intentaré aplicar al siguiente juego!
#385 Deberías estudiar un pelín de algoritmia. No te lo digo a malas. Tienes que saber cuando algo no es óptimo y es obvio que el comparar todo con todo no es óptimo, O(n2) en el peor de los casos como te han dicho arriba. Con tan pocos objetos y con los procesadores de hoy en día el juego no se va a resentir, pero si piensas en algo más grande y luego resulta que no consigues el procesamiento todo lo rápido que quisieras te vas a dar cabezazos contra la pared teniendo que levantar todo desde la base.
Aunque te cueste, implementa ese sistema en tu juego. Vale que de cara al usuario no se va a notar nada y q es más bonito una mina que algo por detrás, pero a la larga te darás las gracias a ti mismo.
Y esto no es un consejo aplicado al campo de videojuegos, en cualquier campo de este mundo, que algo funcione no quiere decir que esté bien hecho.
#386 Por qué me lo iba a tomar a malas? :o
Cuanto más optimizado esté todo por mí mejor, coñe. Tú pareces ser un árduo fan de la algoritmia, ¿me recomiendas algún manual o guía para zamparme? Llevo unas semanitas de lecturas de órdago, modo esponja. Tengo en camino el Accelerated C++ para cuando termine de leerme el segundo manual de C++ con el que ando.
MOAAAAR
#387 Yo la verdad es q lo aprendí todo en la universidad, 2 duros años de MTP, si desempolvo los apuntes buscaré referencias de libros q ahora mismo no recuerdo ninguna, pero por aquí seguro que te recomiendan bien.
#387 yo empecé a aprender algoritmia y gestión de recursos con concursos de programación.
Uno de los mejores y menos conocidos es el de ACM
hay miles de ejercicios por resolver, y resolverlo y ver que has quedado entre los 100 primeros no tiene precio.
Otra de las páginas en las que participo bastante es codechef
en el que quedé primero en uno de los concursos, sea dicho xDD
y luego el más conocido a nivel mundial dado que no sólo es de programación, sino de TDD, etc es
--
Extras:
Hay concursos de programación muy específicos:
Hacer la IA de un equipo de futbol
http://javacup.javahispano.org/
Programar la inteligencia artifical de un "juego", el año pasado, de un grupo de hormigas
http://aichallenge.org/
--
En estos concursos no sólo aprenderás a programar, sino a programar bien, a utilizar multi-threading en algunos casos, a optimizar memoria, a saber cuando utilizar short, int o long, a cuando merece la pena utilizar un dijkstra, un BST que te de en O(log n) un objeto, etc, a utilizar tablas de hash, etc etc etc
He encontrado una pregunta en la pagina de desarrollo de videojuegos de stackexchange bastante buena sobre el tema:
http://gamedev.stackexchange.com/questions/10202/quad-trees-grid-based-collision-putting-logic-into-action
El tío que responde deja bastante claro como dividir el espacio del juego en un grid normal y en un quad tree (en un numero predefinido de subdivisiones) para comprobar colisiones solo entre objetos de la misma area.
Lo que no entiendo muy bien es eso de adaptive quad tree. ¿Como determinas cuantas veces tienes que subdividir cada espacio?
