http://uruguaygamer.com/foro/forum.php?id=18 Comunidad de Desarrolladores de Videojuegos de Uruguay en-US Fri, 24 May 2013 00:27:13 +0000 http://bbpress.org/?v=1.0.2 q http://uruguaygamer.com/foro/search.php http://uruguaygamer.com/foro/topic.php?id=1153#post-8822 Wed, 27 Mar 2013 10:16:33 +0000 Erb 8822@http://uruguaygamer.com/foro/ <p>jeje, que tema tan intersante. Bueno estoy deaccuerdo con todo lo que plantearon, igual voy a intentar aportar algo. </p> <p>Bueno empezando por lo que planteo Naburu, programar un juego con esas caracteristicas es bastante costoso. Mas alla de la simulacion fisica requerida, te vas a encontrar con muchos mas problemas programaticos dependiendo del tipo de juego. Por ejemplo si el juego tiene NPCs, tenes que considerar como afecta sus comportamiento y pathfinding. El tema es que la mayoria de los juegos usan AI bastante sencilla, que generalmente es estatica/scripted y implementar AI dinamica te costara tiempo precioso del cpu. </p> <p>Y tener cosas destructibles tambien complica el diseño del juego (que por defecto afecta como lo programas). Osea si haces que un edificio destructible, todos tendran que ser destructible, que practicamente significa que todo tiene que serlo(hasta el suelo), sino vas a tener lo equivalente a esas paredes invisibles en los viejos juego 3d que separaba el area jugable del fondo, que siempre eran frustantes para el jugador. Ni hablar todo los problemas de locomocion que tendras que resolver para navegar por un mundo lleno de escombros y terreno con irregulardades generadas dinamicamente.</p> <p>A nivel progammatico todo eso se vuelve una pesadilla de escabilidad, durante el desarollo y despues de lanzamiento. Y el trabajo que estas sumando es exponencial por todo los casos especiales que vas a tener(ni hablar de optimizar todo eso). Es como planteabas Ronald en tu primer post, la mayoria de la situaciones de los juegos AAA dependen de la interalterabilidad del entorno(sea para contar la historia o para que funcionen a nivel programatico).</p> <p>Sacando eso del camino, yo creo que se puede hacer, pero es como dice MaXimiliaNMetaL, vas a tener que sacrificar cosas, sea a nivel grafico, mecanicas de gameplay o una dimension. Que para mi no seria algo malo al contrario. </p> <p>Una pregunta que hay que hacerse es si un juego asi(tipo graficos HD, hiper realistas, con fisica "real", mundos enorme, multijugador, etc) vale la pena hacer. Digo porque podrias perder años haciendo un juego como Spore(creo que llevo 6 años), que tiene un sistema genial para generar personajes, pero el juego en si no es nada nuevo, ni divertido, ni tampoco tiene que ver con su premisa inicial de la evolucion.</p> <p>y ta si miramos otros juegos que se han hecho, encontramos juegos con terreno totalmente destructibles como worms, voxatron, minecraft(ademas tiene mundos enormes y aleatorios) o cortex command. Y juegos con pila de interactividad y posibildades como los juegos rogue-like, dwarf fortress, terraria (para no decir minecraft) o façade. </p> <p>A lo que voy es que el "hiperrealismo" en juegos es un limitante enorme en todo los sentidos (programmacion, diseño, diversion) y muchas veces no aporta al juego en si. Mientras que los juegos que nombre eligen limitaciones/simplificaciones que potencian el juego, y hasta se podria decir que la mayoria de ellos no funcionaria o serian menos interesantes sin esas simplificaciones(un gran ejemplo es worms 2d vs worms 3d). Pero ojo no estoy intentando descalificar los juegos AAA con graficos salados, con mundos detallistas, simplemente digo que aveces menos es mas(mucho mas). Y que capaz tu idea Ronaldo estaria bueno intentarlo en 2D o en un mundo 3D mas simplificado, apostandole a la destruccion y interactividad como la mecanica central de juego y no como algo extra agregado.</p> <p>Y bueno como siempre esa es mi opinion, que se basa en la informacion limitada que contiene mi cerebro.</p> <p>Sigan alimentando las llamas de la discussion! </p> http://uruguaygamer.com/foro/topic.php?id=1149#post-8821 Tue, 26 Mar 2013 23:43:03 +0000 MaXimiliaNMetaL 8821@http://uruguaygamer.com/foro/ <p>Gracias por tu opinión, la vamos a tener en cuenta, aunque todavía no hay nada decidió.<br /> Alguna otra opinión? </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8820 Tue, 26 Mar 2013 17:38:49 +0000 MaXimiliaNMetaL 8820@http://uruguaygamer.com/foro/ <p>Comparto algunas de las opiniones anteriores y las expreso a mi manera.</p> <p>Muchos de los empresarios que basan sus inversiones en probabilidades de éxito. Y por eso invierten en algo que tienen mas certeza de que funcione, ej: mejores gráficas, no tanto en interacción entorno-player.<br /> Quizá algunos mas arriesgados se tiren a experimentar con eso, pero son menos cantidad.</p> <p>En cuanto a lo que decías sobre el avance tecnológico, es verdad que hoy día da para transmitir muchos mas datos que hace unos años, pero a su vez, las exigencias son mayores. O sea, hay mas capacidad de transmitir datos, pero hay mas datos que transmitir. Ademas la capacidad de desarrollo aumenta mas rápido que la implementación de redes mas grandes y veloces.<br /> Si a un juego mmo se le pusieran todos los detalles que los desarrolladores son capaces de darle (físicas a cada objeto y player, modelos highpoly, texturas full hd, interaccion fisica entorno-player, etc, etc)NO HABRÍA CONEXIÓN QUE AGUANTARA.</p> <p>Si hablaramos de un juego en el que el entorno tiene una relevancia vital para el gameplay, en ese caso se podria sacrificar un poco de calidad grafica, y cosas por el estilo (que limitan bastante el performance) e invertir en un buen sistema que administre los objetos interactivos. Pero de todas formas, lo de destruir un edificio y que realmente se convierta en escombros interactivos... lo veo lejos. a lo mejor se puede hacer que al ir disminuyendo la barra de "vida" del edificio el modelo 3d se valla actualizando cada tanto por uno en peores condiciones y al final poner un modelos del edificio destruido totalmente, Y junto a este crear algunos objetos interactivos que supongan escombros, esto si lo veo posible.</p> <p>Razones por las cuales no se ve esto en los juegos actuales, ya ves, acá mismo pudimos dar varias, pero esto no significa que no sea posible, pero quizá si en ese nivel de interactividad que buscas.</p> <p>Me gustaría leer otras opiniones, saludos </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8819 Tue, 26 Mar 2013 15:43:50 +0000 Tachikomaia 8819@http://uruguaygamer.com/foro/ <p>Tú lo haces? -_o</p> <p>Para mí es muy difícil. El otro día vi un juego de Angry Birds creo, en que disparan aves a unas estructuras que se van derrumbando de una forma que para mí es muy realista, o por lo menos nunca vi algo tan así en un juego. Y no sé si fue por eso, pero quise hacer unas olimpiadas de videojuegos, en que los poderes de c/u vayan aumentando/reduciéndose automáticamente para que todos sean más o menos igual de fuertes, o sea es un juego más bien de entrenamiento, se adapta a tu nivel, no es que cada personaje deba tener unas condiciones "fijas" como si fuera la vida real. Por ejemplo, sería posible que Mega Man pierda energía al disparar. O, que la absorba del suelo. Pero el suelo se iría achicando. ¿Pero cómo hago eso? MUY DIFÍCIL! Hablo de PARTES del suelo. Bueno ahora que pienso sería poner a cada parte un controlador, pero lo ideal -pienso- es poner todo el código en un mismo objeto...</p> <p>Coincido con zatarathustra sobre el cambio de 1 a 100. </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8818 Tue, 26 Mar 2013 15:17:37 +0000 Ronald 8818@http://uruguaygamer.com/foro/ <blockquote><p>@<a href='http://uruguaygamer.com/foro/profile.php?id=1000001899'>zatarathustra</a> escribió:<br /> supongo que te referís a un MMO</p> </blockquote> <p>Exacto!</p> <blockquote><p>@<a href='http://uruguaygamer.com/foro/profile.php?id=153'>juako</a> escribió:<br /> Tirar escombros y romper cosas aporta algo al gameplay o es solo un extra?</p> </blockquote> <p>En este caso aporta porque es para usar como armas contra los demás players o contra el propio entorno.</p> <p>Gracias por aportar al tema.</p> <p>---</p> <p>Sin embargo, la duda surge porque:</p> <p>- Si es por una cuestión técnica (cantidad de variables, rendimiento del servidor, etc), actualmente, con la tecnología existente debería ser posible. Que alguien me corriga si estoy equivocado.</p> <p>- Si es por una cuestión de costos, creo que la inversión valdría la pena ya que hay muchos jugadores que les gustaría que los MMO sean más interactivos con el entorno, por lo tanto generaría buenas ganancias.</p> <p>Estaría bueno que los amigos que están en la GDC pudieran trasladar esta cuestión a los grandes desarrolladores.</p> <p>¿Alguien más tiene otra opinión? </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8817 Tue, 26 Mar 2013 14:11:48 +0000 juako 8817@http://uruguaygamer.com/foro/ <p>En mi opinion es por 2 razones:</p> <p>Tirar escombros y romper cosas aporta algo al gameplay o es solo un extra? Yo creo que en la mayoría de los juegos es un extra.</p> <p>Después esta el reto técnico de hacer una simulación física en el servidor y distribuirlo en tiempo y forma a todos los clientes. Hay que pensar que en la mayoria de los juegos online el cliente lo unico que hace es "dibujar" segun lo que le manda el servidor.</p> <p>En ps3 tenes el juego fat princess, donde tenes que romper piedras y recoger los pedazos. En el juego es super cartoon la rotura de la roca pero para el gameplay es suficiente. </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8816 Tue, 26 Mar 2013 13:25:11 +0000 NaBUru38 8816@http://uruguaygamer.com/foro/ <p>Empezando por el principio, programar un juego en el que el entorno es interactivo lleva mucho tiempo y dinero. Cuando hay que priorizar, a menudo se corta lo costoso y se prefiere programar cosas más fáciles y que el jugador valora igual.</p> <p>Después, que el entorno sea interactivo tiene que encajar con el resto del diseño del juego. Hay que pensar mucho, experimentar mucho y probar mucho. Es más fácil y barato probar cosas que se sabe que funcionan con cierta seguridad. </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8815 Tue, 26 Mar 2013 13:11:21 +0000 zatarathustra 8815@http://uruguaygamer.com/foro/ <p>Aportando un poco de mi acides ignorante sobre el tema XD</p> <p>Es un reto técnico muy grande, primero que todo... Romper un edificio 3d en partecitas no es nada del otro mundo, pero que esas partes de juego se conviertan "mágicamente" en objetos de juego ya es un laburito interesante.</p> <p>Aparte, ya optimizar eso para un juego al estilo sandbox no-online es un garrón, imaginate para un juego online que hay miles de jugadores (supongo que te referís a un MMO) y que tienen que estar sincronizados!!! De golpe que de 1 edificio hayan 100 partes de edificios es una locura (interesante sin duda).</p> <p>Tal vez se podría explotar más la interacción con el entorno sin modificar los objetos... Ej, tirar sillas. =D<br /> Eso es medio costoso para el server pero es bastante realizable.</p> <p>Me encantaría poder tirar sillas en un juego online -.- </p> http://uruguaygamer.com/foro/topic.php?id=1153#post-8814 Tue, 26 Mar 2013 10:01:10 +0000 Ronald 8814@http://uruguaygamer.com/foro/ <p>Un tema recurrente con un colega de trabajo es el siguiente:<br /> Casí todos (por no decir todos) los juegos online NO permiten una total interacción con su entorno. Me explico: imaginemos que soy un personaje poderoso del juego y daño un edificio, parte de su estructura cae a tierra y puedo utilizar sus escombros para arrojarlos contra otro player. Lo mismo con cualquier otra estructura que forme parte del mapa del juego.<br /> La pregunta es: *** ¿POR QUÉ NO LO HACEN? ***</p> <p>Se me ocurren varias teorias...</p> <p>- Una de ellas es que si estuviera permitido modificar el entorno a ese nivel, la cantidad de variables generadas para cada objeto a partir de dicha modificación saturaría el rendimiento del servidor, o velocidad de conexiones.<br /> - Otra posibilidad es que los creadores del juego hayan elaborado ciertas situaciones que dependan de la inalterabilidad del entorno.<br /> - Hay más, pero con esas me parecen suficientes. Es bastante notable que los juegos online carecen de esta posibilidad.</p> <p>¿qué les parece? </p> http://uruguaygamer.com/foro/topic.php?id=1149#post-8800 Wed, 13 Mar 2013 11:17:31 +0000 Tachikomaia 8800@http://uruguaygamer.com/foro/ <p>Lo ideal es que des opciones.</p> <p>Pero si no quisiera complicarme y si fuera para mí, lo haría:</p> <p>doblar derecha / izquierda<br /> der/izq</p> <p>ir adelante<br /> arriba</p> <p>frenar / ir en reversa<br /> abajo</p> <p>disparar<br /> control</p> <p>acelerar<br /> shift, pero que la velocidad se cambie por siempre hasta que se presione otra vez, que no sea que para andar de una forma haya que mantenerlo presionado (presionar a la vez control+shift+alt+flechas!? Nah, I pass).</p> <p>cambiar a la siguiente arma<br /> cambiar al arma anterior<br /> Nope. Usa los números del 1 al 9 ¡a menos que tengas más de 9 armas! O.O agrega el 0 XD Nah, si son muchas usa q, w, e... etc. Pero habría que ver, porque a mí no me es tan fácil presionar la tecla correcta tan rápido.<br /> También puedes poner una opción, sí, para usar la anterior o siguiente. Basado en el Megaman, al que nunca me acostumbré en ese sentido (empecé con los de NES, en que tenías que usar pausa), diría que prefiero el estilo Doom. Pero la opción no está mal.<br /> Z y X para anterior-siguiente. Cerca del control conque disparo. También haría que RePag y Avpag hicieran lo mismo, por si otra persona prefiere usar eso.</p> <p>usar el power up seleccionado<br /> space<br /> Para seleccionarlos usaría los F (F1, F2, etc).<br /> jk para anterior-siguiente. También nm. </p> http://uruguaygamer.com/foro/topic.php?id=1149#post-8799 Wed, 13 Mar 2013 03:15:50 +0000 MaXimiliaNMetaL 8799@http://uruguaygamer.com/foro/ <p>Les cuento que actualmente estamos trabajando en un prototipo<br /> y tenemos que definir bien la jugabilidad<br /> Lo que estamos viendo ahora son los controles<br /> y me gustaría ver opiniones sobre como les gustaría a uds<br /> que fuera la configuración de los controles estandard</p> <p>SCREENSHOOTS del prototipo<br /> (pera ver la imagen mas grande: click derecho sobre la imagen &gt; abrir en una nueva pestaña)<br /> <img src="http://img831.imageshack.us/img831/9882/torus2013031302584523re.png" alt="" /></p> <p><img src="http://img62.imageshack.us/img62/1628/torus2013031300105098re.png" alt="" /></p> <p>Es un juego de combate vehicular, al estilo Vigilante 8 y Twisted Metal</p> <p>Acá dejo unas imágenes para que recuerden esos títulos</p> <p><img src="http://img2.imageshack.us/img2/2679/vigilante8.jpg" alt="" /></p> <p><img src="http://img113.imageshack.us/img113/6971/v8soscreen018ya0.jpg" alt="" /></p> <p>Mi idea es decirles las funciones que el juego tendrá<br /> y el que quiera aportar me cuente a que botón del teclado (o mouse) asignaría cada función</p> <p>acá dejo una imagen de un <a href="http://img232.imageshack.us/img232/8373/85916262.jpg">teclado</a>, capas que es mas fácil señalando las teclas en ella</p> <p>------------</p> <p>LAS FUNCIONES QUE TENDRÁ EL JUEGO</p> <p>Hay algunas funciones básicas que son obvias:<br /> ---<br /> doblar derecha / izquierda<br /> ir adelante<br /> frenar / ir en reversa<br /> disparar<br /> ---<br /> otras funciones que me gustaría agregar son:<br /> ---<br /> acelerar: el botón de ir hacia adelante seria como ir en primera y al oprimir este se aceleraría mas<br /> (como en un shooter: W = caminar y W + SHIFT = Correr)<br /> cambiar a la siguiente arma<br /> cambiar al arma anterior<br /> usar el power up seleccionado: habría varios power ups (turbo, escudo, etc) y se usarían al oprimir este botón<br /> ---<br /> Bueno, esas serian las funciones por ahora, nosotros ya tenemos varias ideas para la config,<br /> pero quiero ver que opinan uds, así que espero que puedan apoyarnos.</p> <p>Desde ya muchas gracias a todos,<br /> saludos </p> http://uruguaygamer.com/foro/topic.php?id=1148#post-8798 Mon, 11 Mar 2013 17:09:39 +0000 Tachikomaia 8798@http://uruguaygamer.com/foro/ <p><a href="http://rapidshare.com/files/2276842365/sim.swf" rel="nofollow">http://rapidshare.com/files/2276842365/sim.swf</a> </p> <p>Una pequeña muestra de los problemas, aunque el 1 y el 2 parece que los arreglé...</p> <p>zatarathustra:<br /> Me interesa que el rebote tenga el efecto real, la cantidad no me importa tanto ni que la velocidad de movimiento sea la real, sólo que... bueno, lo puedes ver en el archivo que puse. Pero el rebote en el techo no sé cómo es, el efecto, no sé cómo queda, si puede rebotar al revés. Tenía una herida abierta en un dedo así que no podía fijarme jugando contra el techo, además preciso una pelota de espumapláz que no sé si las perdí, Y ADEMÁS, es difícil hacer el efecto liftado pegándole tan hacia arriba, recto. O sea, no sé cómo rebota en un techo, y no podía comprobarlo por mí mismo, ahora se me arregló bastante el dedo así que veré, pero tengo algunas cosas que hacer antes. </p> http://uruguaygamer.com/foro/topic.php?id=1148#post-8797 Mon, 11 Mar 2013 13:01:31 +0000 zatarathustra 8797@http://uruguaygamer.com/foro/ <p>Bueno, el 3er. problema es el más simple:<br /> speed.x *= -1;<br /> speed.y *= -1;<br /> efecto.x = 0;<br /> Y el efecto se pierde una vez rebotado. (No es muy realista pero es bastante convincente)</p> <p>Y voilà! Tenés el rebote :D</p> <p>Después, los efectos... Es imposible que hagas algo "realista", y hacer algo con un comportamiento físico "real" depende de muchas cosas (ej.: Masa)...</p> <p>Lo que te recomiendo en estos casos es hacerte una lista de las "variables" que tiene un problema.<br /> En este caso:<br /> - velocidad de la palEta<br /> - velocidad de la pelOta<br /> - efecto de la pelota...<br /> Y ta! No hay más variables que esas!!!</p> <p>La velocidad de la pelota y la paleta es obvio lo que es... Pero el efecto tomalo como aceleración, siendo la aceleración un valor que se le aplica a la velocidad todos los ciclos.</p> <p>Así que después de tener las 3 variables, hacés alguna función re loca con ellas...<br /> EJ. con nombres re locos!!!:</p> <p>function OnCollideWithPaleta():void<br /> {<br /> bola.efecto.x = paleta.speed.x * bola.speed.x * 0.01;<br /> }<br /> // No te recomiendo que alteres la velocidad y, ya que al ser un juego de rebote te va a mutar todo... Así que cambialo alteralo así queda re loco :D</p> <p>function OnUpdate():void<br /> {<br /> bola.speed.x += bola.efecto.x;<br /> bola.x += bola.speed.x;<br /> bola.y += bola.speed.y;<br /> }<br /> // Notá que la aceleración se la aplico a la velocidad y no a la posición! Porque al aplicarselo a la velocidad, cada ciclo se mueve o más rápido o más lento...</p> <p>El 0.01 es la escala... Podés variarlo si se va muy a la mierda o no aplica mucho efecto.</p> <p>Con eso algún efecto cool podés hacer, después podés ir variando, agrando y todo eso =D </p> http://uruguaygamer.com/foro/topic.php?id=1148#post-8796 Sun, 10 Mar 2013 19:01:54 +0000 Tachikomaia 8796@http://uruguaygamer.com/foro/ <p>Ya hice bastante. Pero tengo problemas con los efectos (liftado y cortado, otros por ahora no pondré).</p> <p>------------------------------------------------------------------------</p> <p><strong>Problema 1:</strong><br /> No puedo darle mucho rango al efecto cortado.</p> <p>Mientras hacía el tema se me ocurrió una posible solución, <strong>pero quisiera saber cómo funcionan (los tiros cortados y liftados), en la realidad, matemáticamente</strong>. Porque yo hago que la pelota se acelere 0.01 hacia abajo a cada rato, pero si el efecto cortado es mucho mayor que eso entonces la pelota tarda demasiado en caer. Y entre 0 y 0.01 hay muy poco rango, por eso el problema (que lo es, no sólo problemilla, porque causa otros más). Disminuyo también el efecto a cada rato, pero si lo reduzco mucho entonces el liftado pierde la gracia, y reducir más a uno que a otro me parece antinatural y más complicado en el código. No creo que aumentar el 0.01 solucione (de hecho los tiros sin efecto no caen tan rápido).<br /> La posible solución es aumentar a cada rato la reducción del efecto que hay a cada rato.</p> <p>Un poco del código por si no se entendió:<br /> <pre><code>if (Math.abs(Top) &gt; 0) { Top = Math.abs(Top)/1.0001*((Math.abs(Top)/Top)); } YSp = YSp+Top+0.01;</code></pre> <p>Si el efecto es mayor que 0 (aunque el cortado funcione como negativo cuenta como efecto, el abs se encarga de eso).<br /> Se reduce el efecto. Como pueden ver la reducción que se haga será cada vez menor, mencioné que la solución podría estar en que aumente.<br /> YSp, velocidad Y de la pelota, influye en su posición a cada rato (así se aplica este código), pero antes es influído por el efecto y aumenta 0.01 (hace que la pelota caiga cada vez más rápido).</p> <p>El efecto cortado está representado con Top, aparece como negativo. Si es positivo es liftado. No sé si en la realidad cae más lento/rápido o si a su vez se reduce la velocidad hacia adelante (no por el rozamiento sino porque va cambiando de dirección), yo lo simulo de la 1era forma porque me resulta más simple y no me parece tan mal.</p> <p>------------------------------------------------------------------------</p> <p><strong>Problema 2:</strong><br /> <strong>Por culpa del problema 1</strong>, los cambios de efecto son más complicados.</p> <p>La pelota rebota en una pared, iba con efecto liftado 0.03. ¿Lo multiplico por -1 para que quede cortado? Pero quedaría -0.03, más allá del rango. Entonces puedo hacer, en vez de *-1, /-algo. Pero tengo una parte así:<br /> <pre><code>YSp = YSp-Top*(YSp/Math.abs(YSp))*50; Vers = XSp*-1+Top*(XSp/Math.abs(XSp))*50;</code></pre> <p>Vers es Versatil, variable que uso cuando necesito guardar un dato por un tiempo. O sea, ahí el efecto de los efectos es multiplicado * 50 (cuando rebota contra una pared). Podría crear un if y decir "si es liftado, *50, sino *tengo que ver", pero... en fin, parece antinatural...</p> <p>------------------------------------------------------------------------</p> <p><strong>Problema 3:</strong><br /> No sé cómo deben rebotar en el techo/las piezas.</p> <p>En las paredes tampoco, pero estoy más acostumbrado a verlo (juego al frontón).</p> <p><strong>Lo dicho en negrita en el problema 1, aplica aquí también.</strong></p> <p>------------------------------------------------------------------------</p> <p><strong>Problema 2:</strong><br /> <strong>Problema 3</strong> pero si el efecto es curvado, tengo más dudas, porque aquí (2D) el giro sería como el de un liftado/cortado ¿no? </p> http://uruguaygamer.com/foro/topic.php?id=1138#post-8766 Thu, 14 Feb 2013 21:12:15 +0000 Tachikomaia 8766@http://uruguaygamer.com/foro/ <p>1: 4 &gt; 0. Además la compu tendría que traducir la variable (aún más costoso entonces).<br /> Si hay que usarla más de una vez y cambiarla para cada vez entonces estoy de acuerdo, pero acá en principio no era el caso.</p> <p>2: No entiendo, aunque tengo un problema, y es que cuando se mueve hacia la derecha la reducción es mayor. Le aumenté mucho el rozamiento para ver. Y lo que sucede es que cuando va hacia la izquierda siempre golpea la barra, pero cuando va a la derecha no llega. Supongo que es por como hace las aproximaciones (elimina números tras la coma) ¿será?</p> <p>3- Ah esa no la tenía.</p> <p>4- Veremos.</p> <p>Mi flash no tiene AS3.</p> <p><strong>juako</strong>:<br /> Sí, pero si es corto también es más fácil.</p> <p>¿División entre 0 en esto?<br /> XSp = -1 + random(2)*2;<br /> Roz = 0.001 * (XSp / Math.abs(XSp));</p> <p>Dices si random(2)*2 te da 1. Eso es imposible. Te da 0*2 o 1*2, o sea 0 o 2. Además también se le resta -1, por lo que es -1 o 1. ¿Me equivoco?</p> <p>En cuanto a moverse hasta el infinito, sí, pero la reducción de la velocidad es muy poca (tanto que pensé en reducirla a 0, pero veremos), la velocidad inicial nunca será tan poca, y el juego "reinicia" cuando la pelota se sale de la pantalla, así que no, no va a cambiar de dirección antes de salirse (salvo que haya mucho slice o topspin XD veremos, pero si eso pasa entonces cambia roz). </p> http://uruguaygamer.com/foro/topic.php?id=1138#post-8764 Mon, 11 Feb 2013 22:09:26 +0000 juako 8764@http://uruguaygamer.com/foro/ <p>Es preferible tener codigo claro que codigo rapido y oscuro, porque si esta claro es facil optimizar si es necesario, si es oscuro es difícil cambiar.</p> <p>El codigo ese que puse lo saquee de flixel y esta llena la web de juegos hechos con ese codigo y anda.</p> <p>Otro error que tiene ese codigo es que si random(2)*2 te da 1 te va a quedar una división entre 0</p> <p>Ese codigo que pusiste va a hacer que se mueva para un lado se frene y luego se empieza a acelerar en el sentido contrario hasta el infinito. </p> http://uruguaygamer.com/foro/topic.php?id=1138#post-8763 Mon, 11 Feb 2013 18:36:52 +0000 zatarathustra 8763@http://uruguaygamer.com/foro/ <p>En respuesta a las respuestas de las recomendaciones...</p> <p>1. No te hace más pesado no, ya que las memorias de hoy en día tienen al rededor de 2.000.000.000.000 bytes, y un float solo ocupa 4 :D<br /> Aparte imaginate el caso común de que uses una constante más de una vez! Si cambias el valor de la constante no tenés que cambiar el valor absoluto N-veces.</p> <p>2. El código tuyo tiene un "error"... El rozamiento lo estás definiendo con signo... Entonces lo que te pasa es que cuando quieras moverte libremente en el eje, el rozamiento va a aplicarse para un solo lado.<br /> Ahora no te jode, pero mejor hacer las cosas bien de primera.</p> <p>3. Jajaja, no pesa más ni a palo, cuando se "compila" el código los nombres de variables tal como los conocemos dejan de existir.<br /> Si tenés un código muy chico no hay problema en poner nombres crípticos, pero es buena práctica poner nombres legibles así cuando el código crece no te haces tremendo pedo.</p> <p>4. Si te es más fácil de leer no hay drama... Pero podrías probar aplicar alguna norma de estilo, puede que te guste más :D</p> <p>Ah, y lo que hizo juako tiene tremendo sentido:<br /> Si el rozamiento sobrepasa el 0 tenés que truncar la velocidad a 0, porque sino es probable que haga una "vibración rara" el macaco.<br /> Si no te gustan usar ifs podés investigar sobre el operador ternario, en AS3 se que está.<br /> ej. uniendo todo:<br /> <em>const roz : float = 0.2;<br /> const minMove : float = 0.3;<br /> speedX *= (Abs(speedX) &gt; minMove) ? roz : 0;<br /> </em><br /> Si no te gusta el minMove (cosa que a mi si):<br /> <em>speedX *= (Abs(speedX) &gt; roz) ? roz : 0;</em></p> <p>Bye!!! </p> http://uruguaygamer.com/foro/topic.php?id=1137#post-8762 Mon, 11 Feb 2013 12:05:59 +0000 Tachikomaia 8762@http://uruguaygamer.com/foro/ <p>...lo que describí no ocurre en el rom original, no existe un juego en que ocurra eso (¡sino dime cual es, si lo puedo jugar!), el tema es sobre elaborar un rom en que ocurra, no desde 0, no, eso sin duda.</p> <p>Y mira, pensé que al editar podía hacer varias cosas, pero ya que lo mencionas no sé, capáz que sólo podría cambiar números.</p> <p>No sé si corresponde ponerlo aquí, ni si es elaboración, muévanlo a donde crean que va, no me importa.</p> <p>¿Qué es elaboración? No tengo interés en parecer que estoy elaborando cuando edito ese juego. Pero mira:<br /> Si sacan un programa que tiene todo armado para un estilo de juego o para uno específico (por ejemplo uno de cartas magic), y uno sólo escribe (o copia de otro juego) diálogos, hace (o copia) personajes, etc, etc (y en el caso concreto, elabora o modifica cartas) ¿no es elaboración? ¿cuando se elabora una campaña de Age of Empires tampoco? Lo único que se está haciendo es cambiar números (¿no? Obj1 = *escribes cual* Obj1X = *escribes cual* ¿no?). Oh shit, cuando programamos es casi lo mismo. En vez de poner personajes ponemos set variable ¿qué elaboramos? Sólo reordenamos los elementos que nos dan. </p> http://uruguaygamer.com/foro/topic.php?id=1138#post-8761 Mon, 11 Feb 2013 11:18:03 +0000 Tachikomaia 8761@http://uruguaygamer.com/foro/ <p>1: ¿Por qué? ¿qué ventaja tiene? Porque para mí es crear una variable innecesaria, lo hace más pesado.</p> <p>2: A ver, yo lo hice así (está en la película pelota):<br /> <pre><code>onClipEvent (load) { XSp = -1 + random(2)*2; Roz = 0.001*(XSp/Math.abs(XSp)); } onClipEvent (enterFrame) { XSp = XSp - Roz; this._x = this._x + XSp; }</code></pre> <p>¿Dónde lo pondría y qué saco? Lo imagino un poco pero no del todo, y lo que imagino perdón pero tampoco lo veo ventajoso, capáz que más adelante sí pero tendré que ver, por ahora es que la pelota aparece, y se empieza a mover para un lado, hacer la división cada vez que se mueve me parece más pesado que hacerla simplemente al principio.</p> <p>3: Depende del observador... si yo lo entiendo así, resumido, alcanza, -y es menos pesado ¿no? - cuando lo quiera mostrar lo especifico, ok, sí.</p> <p>4: El problema es cuando otro ve el código o cuando uno lo retoma tras mucho tiempo. Pero sino yo veo eso, que entre más chico sea mejor, y lo entiendo, no hay drama...</p> <p>Te agradecería más, recomendaciones sobre esto:<br /> <a href="http://www.forosdelweb.com/f14/filtro-acciones-para-que-encajen-1035385/" rel="nofollow">http://www.forosdelweb.com/f14/filtro-acciones-para-que-encajen-1035385/</a></p> <p><strong>juako</strong> lo 2ndo me gustó más, lo 1ero está lleno de ifs XD </p> http://uruguaygamer.com/foro/topic.php?id=1137#post-8760 Mon, 11 Feb 2013 00:26:57 +0000 juako 8760@http://uruguaygamer.com/foro/ <p>y esto en elaboración porque... </p>