#389 Wo.. menudo mundo se abre ahí. Muchas gracias!
#390 Genial ese post, me lo imprimiré para leerlo tranquilamente en el bus. Pero así, en una lectura diagonal para bastante chachi.
Para todo el que le interese, añado a #1 este post sobre Crowdfunding que he abierto, que creo que puede ser una parte importante de cara a lanzar nuestros proyectos una vez hayan madurado.
http://www.mediavida.com/foro/9/crowdfunding-recompensa-buenas-ideas-445091
Una pregunta sobre c++, seguramente sea un poco tonta, aún estoy aprendiendo. En un juego que estoy haciendo tengo un problema, cada vez que creo un nuevo objeto el juego pega un tironcillo. Creo que es porque creo los objetos dinamicamente. Pero necesito crearlos dinamicamente, porque los creo dentro de un metodo de una clase y sino cuando se acabara ese metodo se liberaría la memoria de ese objeto. Sabeis alguna forma de optimizar esto? Se me ocurre crearlo estaticamente y asignar el objeto a una variable para que no se liberara la memoria o algo así, pero me parece una solución bastante sucia.
Perdonad si algo de lo que he dicho esta mal, todavía estoy aprendiendo c++ y todo lo relacionado con la gestión de memoria no lo tengo muy claro
#393 puedes poner el código?
es ue por la explicación mal andamos, la creación de un objeto (reservar memoria) debería ser siempre transparente
#393 ¿Qué motor utilizas? A mí también me daba tirones y para solventarlo (hay una discusión sobre lo que dices unos posts más atrás) lo que hice fue reservar un array de memoria antes del bucle del juego para cada tipo de objetos. En plan... el array Balas, Enemigos, Minas, etc... y con un índice voy iterando sobre la tabla inicializando el objeto que necesito y librándome de él cuando haya acabado (i.e. una bala impacta con algo).
En #345 tienes una buena apreciación del tema.
Por otra parte, siguiendo con el rollo de las colisiones, en el newsletter semanal de stackexchange he visto un tema precisamente sobre colisiones que resume de forma bastante compacta lo que son los motores de colisiones y los tipos que puede haber.
http://gamedev.stackexchange.com/questions/26501/how-does-a-collision-engine-work
Y para terminar, sobre mi proyecto decir que ayer fue un gran día, ya que mi idea y mi espíritu cuajaron entre la pareja de artistas que he engañado para llevarme a la fama y fue una sesión de brainstorming bastante productiva e inspiradora. El minijuego parece que va a tener un aspecto bastante más chulo de lo que se merece xD Espero pronto tenerlo listo y ponerme con el siguiente juego, que ya lo tengo en fase de preproducción mental. No desvelaré muchos detalles por eso de no gafarlo (supertition everywhere), pero diré que es una especie de... simulador.
Este es el codigo:
void ObstacleManager::obstacleDidFallOffTheScreen(int objectID)
{
int random_integer;
int lowest=-3, highest=13;
GLfloat maxY,minY;
minY=app->limitsManager->top->minY;
maxY=app->limitsManager->bottom->maxY;
int multipliedMinY=minY*100;
int multipliedMaxY=maxY*100;
highest=multipliedMinY-20;
lowest=multipliedMaxY+20;
int range=(highest-lowest)+1;
random_integer = lowest+int(range*rand()/(RAND_MAX + 1.0));
GLfloat random=((float)random_integer/100.0f);
app->idsToRemove.push_back(objectID);
GLfloat obstacleVerts[12]={
-0.1f,-0.2f,0.0f,
0.1f,-0.2f,0.0f,
-0.1f,0.2f,0.0f,
0.1f,0.2f,0.0f
};
boost::shared_ptr<StandardObstacle> obstaclePtr(new StandardObstacle(obstacleVerts,1.2f,random,4));
obstaclePtr->manager=this;
app->characters.push_back(obstaclePtr);
app->objectsNeedToRemove=true;
app->idsNeedUpdate=true;
}
Todo lo del principio es para calcular una posicion aleatoria para el obstaculo. Las unicas lineas importantes son en las que creo un shared_ptr y lo meto en un vector. El tirón lo da en la linea en la que creo el shared_ptr (lo he comprobado).
EDIT: Si quereis tambien pongo el constructor de StandardObstacle.
EDIT2: Vale, parece que el tirón era por una cosa que hacía en el constructor de StandardObstacle. Una funcion de una librería que creía que era barata ( se dice así? xDD, vamos, que se ejecuta rápido) y resulta que no jaja. Tendre que buscar una alternativa. Gracias por la ayuda
- vas a acceder con multi-threading a ese objeto creado?
- Si la respuesta es NO, xq usas shared_ptr de boost?
- boost es MUY potente, pero has de saber usarlo, si no sabes usarlo y lo usas al tun tun... mal andamos.
edit
#396
El constructor de un objeto no tiene porque inicializarlo, depende de varios factores, mírate patrones de creación de objetos
http://en.wikipedia.org/wiki/Creational_pattern
e insisto, boost es muy buena librería para algunas cosas, pero bastante lenta para otras, intenta leerte la documentación, creo que en un simple juego sin multi-threading utilizar un shared_ptr es una CAGADA 
#397 Y que me recomendarías usar como sustitución? Uso shared_ptr porque es muy comodo y no tengo que ocuparme de deletear el objeto, pero si tan lento es puedo prescindir de el. Alguna forma de sustituirlo con algo parecido o tengo que encargarme yo de deletear el objeto cuando no lo necesite?
#398 mejor encárgate tú, es la ventaja que tiene C++ frente al resto de lenguajes, si quieres olvidarte del destructor, usa java
Es que piensa que utilizar una librería cualquiera sin saber qué hace, simplemente "de gratis" es uno de los mayores pecados que tienen los programadores, está bien no querer reinventar la rueda, pero esto sería abusar
#399 Ok, es verdad que pensaba que tendría que acabar haciendolo yo, pero en el momento en que lo puse estaba vago y quería algo para salir del paso, y como en un juego pequeño ni se nota, pues eso. Pero voy a implementarlo bien que por muy pequeño que sea mejor tenerlo bien hecho. Muchas gracias
#397 lo de multithreading no tengo muy claro a que te refieres, en una aplicacion singlethreaded no tiene sentido usar smartpointers? Creo que en un juego simple que no va a tener calculos pesados, no usar smart pointers es ganas de complicarse la vida. De hecho, en juegos "no tan simples" se suelen usar smart pointers de algun tipo y no hay mucho mas problema que tener cuidado donde usarlo.
Luego en C++ la inicializacion de un objeto DEBERIA ocurrir en el constructor (para eso esta! ). Si tienes la tipica funcion de inicializacion separada del constructor, al final acabas con objetos vivos que puede que esten mal construidos, asi que tienes que poner un flag en todas las funciones para asegurarte de que el objeto fue inicializado correctamente. Vamos, un jaleo del quince. A menos que tengas una muy buena razon para no tener la inicializacion en el constructor (por ejemplo, no usar excepciones), no deberias hacerlo.
#398 Olvidarte del manejo de memoria es una de las legitimas razones por las que usar shared_ptr (aparte de compartir recursos facilmente, ayudar a que tus disenios sean "exception safe", no tener leaks de memoria, ....). De hecho, en c++11 es parte del standard. Ahora ya ni si quiera es necesario usar new o delete, usas make_shared y ya se encarga de hacer el delete cuando no se use. Ademas, que los shared_ptr los tienes en un vector y de esa forma no tienes porque preocuparte de hacer el tipico bucle para liberar la memoria. Mi recomendacion: sigue usando smart_ptrs, para tu caso la penalizacion de rendimiento por usar smart pointers no te va a importar. Por cierto, la reserva de memoria si que es muy cara, normalmente lo que quieres es mover toda la que puedas al stack y si necesitas el heap si o si, usa pools de memoria que reservas al arrancar el juego.
#399 precisamente en c++11 se han aniadido cosas como smart pointers para que no nos tengamos que encargar nosotros a no ser que sea estrictamente necesario y este caso claramente no lo es. Echale un ojo a esta charla que esta interesante: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond
#400 No, no. Si te ayuda en varias formas y no tiene importancia en el rendimiento, porque no vas a usarlo? Repito, lo estabas usando perfecto y muy justificado.
Edito: Creo que faltan referencias al manejo de memoria en juegos. Ahora mismo no me acuerdo de articulos especificos (en gamasutra tiene que haber). De todas formas, aunque son tres paginas, en este libro en el apartado 5.2 hablan del manejo de memoria: http://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135
Ademas, si quieres trastear con pools de memoria y no quieres implementar una (aunque te lo recomiendo 100%! es un test muy habitual en las entrevistas de trabajo en videojuegos) en boost tienes www.boost.org/libs/pool
Buenas!
Primero quisiera dar las gracias a #1 por el hilo y a todas las personas que han participado en él.
Estoy interesado en hacer algún nivel simple de plataformas bidimensional, a lo Mario de toda la vida.
Encontré el programa GameMaker, no se si hay mejores o peores, pero este en concreto me parece bien. Lo que no he encontrado es un buen tutorial.
Alguno tiene experiencia con juegos 2D? Recomendáis otro programa?
Edit: #403 Ok, me pondré a investigar ahora 
Gracias.
#402 No he probado GameMaker, ni ningún otro framework de desarrollo de juegos en plan "no hace falta saber programar". Tengo intención de hacerlo en cuanto termine el primer jueguecito con el que ando, para ver como es el desarrollo desde la otra cara de la moneda, pero de momento poco más sé sobre ellos que los videos donde enseñan juegos hechos con su herramienta.
Te puedo ofrecer alternativas como http://www.stencyl.com/ y su lema "Design award winning games faster, without code". Que se han mencionado anteriormente.
Y también he visto otro hilo por el foro de desarrollo que hablaba sobre "Creación de juegos en Unity en 4 horas". Así que Unity puede ser un factor a examinar también.
En otro orden de cosas, no sé si seguís GamesAjare, pero el caso es que llevan eones desarrollando su propio juego y de vez en cuando cuentan sus experiencias en cuanto a desarrollo independiente y demás. Hoy ha salido un artícuo que habla sobre el exceso de "ambición" que puede ser interesante.
http://www.gamesajare.com/2.0/por-favor-no-den-de-comer-a-los-programadores/
#1 Si fueras a ser un gran pastelero, por donde comenzarias ?
La primera opcion seria plantar tu propio maiz, cultivarlo, cosecharlo, molerlo, tamizarlo, amasar la harina etc...
La segunda opcion, mucho mas facil, seria comprar los ingredientes en una tienda y hacer una sencilla receta de magdalenas o galletas, y a partir de ahi ir realizando recetas mas y mas complicadas hasta llegar a la raiz de todo.
Como crees q es mas facil trabajar y comprender todo el procedimiento ?
Crees q los grandes directores de cine se fabrican su propio material cinematografico ?
No tiene da malo usar frameworks, y se aprende muchisimo mas rapido con ellos q empezando de cero.
#404 cuanto mejor conozcas como funciona lo de abajo mejor sabrás como hacer lo de arriba.
La informatica se puede parecer a la arquitectura mas que al cine. Un arquitecto técnico sabe como se hacen los ladrillos, los tipos de ladrillos , temperaturas de cocción y así con todos los meteriales. Sabe exactamente como tienen que colocarlos los albañiles, saben como tiene que ser absolutamente todo, desde 0 en una obra. Luego es muy posible que nada de eso lo usen porque se lo den hecho o lo que sea, pero si surge alguna duda la sabrá resolver.
saludos
#405 gracias, venía a poner algo parecido.
#404 el problema de la metáfora del panadero es que todo el munda sabe cómo es una buena harina, pero NO todo el mundo sabe cómo es un buen framework.
Por no hablar de lo diferente que es usar "materias primas" de usar frameworks. Una materia prima no te abstrae, el panadero sigue sabiendo de dónde viene la harina y cómo se ha hecho (aunque se la haga otro) mientras que el framework te abstrae tanto que crea lo que yo llamo la "Linea de Merlín" por debajo de la cuál todo resultado es indistinguible de la magia.
Por poner otro ejemplo.
Yo antes de usar Eclipse y su auto-completado me picaba mis aplicaciones java en vim, notepad++ o alguno que no tuviera autocompletado y me hiciera recordar e investigar la javadoc de sun (cuando era sun).
Una vez comprendido y asumido este proceso, a utilizar autocompletado a saco.
--
Sobre los gráficos, alguna vez has hecho sombras utilizando STENCIL_BUFFER de OpenGL? Yo si, y es mucho más sencillo utilizar una librería que ya te lo hace, pero siempre viene bien saber como está hecho, para cagadas que te puedas encontrar y COÑO, porque somos ingenieros y lo que nos gusta es investigar!!!
Iba a poner este link hace unos días pero CREO que se me olvidó:
http://cowboyprogramming.com/2007/01/05/blob-physics/
Blob physics (como en Gish o LocoRoco) y verlet integration. Imprescindible.
#408 Mu rico este artículo! Creo que sería bueno crear una nueva sección en #1 para recopilar estos tutoriales más avanzados y hablar de físicas, deltatimes y todas estas cositas, ¿qué os parece?
En cuanto a la metáfora del panadero... no sé a qué venía, pero todas las respuestas lo han dicho todo. Y además, recalco que hay una diferencia muy grande entre aprender y producir. Yo mismo cuando desarrollo páginas web utilizo mil frameworks, instalo CMS y vamos, todos los plugins que me quieran echar. Pero gracias a haber destripado y asimilado las bases de los lenguajes de programación que utilizo puedo, si hace falta, meterme dentro del código de un plugin y arreglarlo, ampliarlo, modificarlo, o lo que me haga falta, cosa que me estoy viendo cada día en el curro últimamente en una web sobre wordpress con chorrocientas funcionalidades. Es una frase muy manida pero: "El saber no ocupa lugar".
A mí por lo menos, el haberme metido estas semanas a sacar por mi cuenta delta times, físicas, gravedad, velocidad uniforme, detección de colisiones... me ha hecho comprender mucho mejor la lógica de un juego, y donde pueden estar sus potenciales y limitaciones. Ahora bien, cuando tenga que mover algo hardcore para alante, tengo claro que no voy a hacer un motor de colisiones o de físicas mejor del que llevan años perfeccionando muchas empresas.
P.D.: Me ha molado el concepto "línea de Merlín" xD
#408 Que buena pinta el articulo. La verdad que lo que mas me jode en los juegos es mi falta de conocimiento en mate y fisica. Pero bueno, para los pequeños proyectos que hago, consigo apañarmelas.
#409 Yo tambien para mis primeros proyectos prefiero hacerlo todo yo. Para los proximos probablemente empiece a usar un motor de colisiones como Box2D por ejemplo, pero una vez me he quedado a gusto haciendo yo uno propio xD. Es mucho mas satisfactorio que hacer un juego sin tener ni pajolera idea de que esta pasando en realidad.
¡Buenas! He estado estos días dándole más caña al juego, preparándome ya de cara a implementar el arte que vayan a pasarme la semana que viene así que pretendo tener prácticamente todas las características listas para entonces.
Las novedades son:
El menú de mejoras está completo,
1 - Mina antipersona
2 - Metralleta
3 - Escopeta
4 - Escudo (Da un toque extra de vida, esencial, ya que sólo tienes 1 vida)
5 - Time Shifter (Ralentiza a los enemigos durante 15 segundos)
(elegir slot con botón rueda del ratón y comprar mejora con botón derecho)
Además... llega un tipo de enemigo nuevo:
¡GATITOS! Van saltando de forma aleatoria siempre en dirección al protagonista, así que son impredecibles Se pueden invocar con la letra F, por si queréis ver una fiesta de gatitos.
Aquí tenéis el juego actualizado. Tengo fe en que con el arte pepins y mejorando el algoritmo de generación de monstruos quede algo medio decente 
http://www.mediafire.com/?mars9yv9aarb6zu
¡Gracias a todos los que me estáis echando un cable!
#412 no está diseñado, es así provisionalmente... no quería hacer curro de más si luego tengo que reajustarlo todo para adaptarlo al arte definitivo xD Lo mismo le meot un dibujillo provisional para q no sea tan abstracto. Gracias por jugar! : D
#411 Esta cogiendo buena pinta, yo creo que quedara bien con el arte nuevo. Por cierto, es intencionado que en el menu de abajo (el que mueves con la rueda del raton) solo se vean cuadrados azules semitransparentes o se supone que tienen que estar texturizados? lo digo porque igual se te ha olvidado meter alguna textura en el rar o algo.
Yo probablemente postearé dentro de poco mi primer juego semi-terminado, que será un copter tipico hecho en OpenGL
Los chicos de CodiGames nos hablaron de "The Mordis" y nos enseñaron unos videos con el proyecto a punto de caramelo. Ahora están lanzándolo y necesitan una manita extra para hacerlo subir en un concurso de videojuegos de la UPC.
http://www.mediavida.com/foro/9/codi-games-busca-apoyo-concurso-445253
:palm: Vaya tela con la bronca de codigo que teneis. Yo despues de pascua empezare algo nuevo, aparte de apartir de esa fecha voy a empezar de nuevo a buscar un grupo de desarrollo ya que la iniciativa que se puso no dio un fruto que yo pudiera ver con claridad. Voy a intentar buscar un grupo bastante dispar que toque varios temas en su rama editorial, ya sea de terror, aventura, o accion. O Manga Comic.
Joder tengo un fallo rarísimo. Ya he dejado el juego como quería, y ya iba a subirlo, pero me he dado cuenta de que si ejecuto el juego desde visual studio (que al fin y al cabo ejecuta el exe) funciona perfectamente, pero si ejecuto el juego desde el exe (copiando los archivos de las texturas a la carpeta donde esta el exe primero) funciona, pero tiene unos fallos rarísimos. Por ejemplo, cuando un objeto sale de la pantalla, llama un metodo de un objeto que crea un nuevo objeto. Pues esto funciona un par de veces, y luego dejan de crearse nuevos objetos.
Alguna idea de porque pueden ocurrir este tipo de fallos (sabiendo que si lo ejecuto desde vc++ no pasan)
#415 Busca los errores que te da y búscalo e formas "creativas" en google. Piensa como podría pedir ayuda alguien al que le pase eso Es el único consejo que te puedo dar, y es como he resuelto yo algunas mierdas con el IDE, a golpe de buscador. Es el único consejo que te puedo dar, porque con el visual studio aún me siento como un pulpo en un garaje xD
Aprovecho para añadir un artículo que he visto que ha posteado itonny en el hilo de Unsurvive de Midgar.
Terminar un juego
http://gamingfondue.com.ar/2011/06/09/terminar-un-juego.html
Es un artículo más de filosofía que técnico, pero estos artículos sobre cómo encarar las cosas me molan mucho y me parecen muy importantes. Lo añado a #1.
EDIT:
el post original de Derek Yu, que en inglés mola más que la traducción latina
http://makegames.tumblr.com/post/1136623767/finishing-a-game
Ya me lo he leído entero y está genial, seguro que más de uno se sentirá identificado, a mi me parecía que hablaba de mí mismo y mis proyectos pasados Recomendadísimo. Por cierto, este tio es el creador de Aquaria, que está hecho en Indielib, el framework con el que trabajo, espero que sea una señal xD
Y curioso porque su segundo juego, Spelunky, lo hizo con Game Maker, en plan, librándose de los prejuicios de "así no mola". Hay un punto en el que habla sobre usar este tipo de herramientas y lo ha clavado en cuanto a los reparos que tengo con ellos. Puede que les de una oportunidad después de terminar con Indielib.
#417 sube el codigo si puedes y le echo un vistazo. O prueba a arrancarlo desde un terminal y ver si por ahi escupe algun error.
