Holaps

Drakkar, lo que planteas viene a ser el eterno problema, y es algo k ya se ha discutido largo y tendido
por estos parajes. Lo primero que debes tener en cuenta a la hora de implementar un sistema de particionamiento es:
- Voy a usar mapas muy chatos ? Entonces usaré quadtree
- Voy a tirar más de alturas ? Entonces usaré octree
Y por otra parte, debes tener en cuenta que para comparar 2 sistemas (como los que tú mismo has planteado) necesitas que el mapa sea suficientemente grande (unos 100.000 polys) y que posea un gran número de materiales (unos 100-200). Apartir de esas cotas es cuando te empiezas a dar cuenta de que ningún sistema es lo suficientemente rápido XD. No, es coña....

La primera técnica k expones (la que ya tenias implementada) es la óptima, pero necesitas además otros factores a tener en cuenta:

1) Que el vertex buffer no sea demasiado grande, para lo cual (en el caso del quadtree) es conveniente dividir el vertex buffer en 4, uno para cada rama primaria del árbol. Esto es así por lo mismo que no es óptimo usar texturas muy grandes, ya que a la larga causaremos un cuello de botella de 3 pares de cojones. Sería óptimo si en el transcurso de todo el juego/programa solo fueras a seleccionar (con SetStreamSource) un vertex buffer, pero eso es algo que normalmente no va a suceder. En un juego normalito, la media de stream changes per frame oscila entre 100 y 300 cambios, así como los de textura. Lo que planteaba Huevox de usar texturas de 2048x2048 es óptimo para un sistema 2D, como tmb para implementar animaciones de textura sobre un determinado material-superficie.
2) Precalcular TODO en cada nodo, de forma que construyas el index buffer ordenado por:
   a) Distancia de nodos con respecto a la cámara,
   b) Por materiales, de forma que se lance el menor número de DrawIndexedPrimitives.
       c) Además se ordenarán los materiales según sean ópacos o transparentes.

Dicha precomputación te costará alrededor de 20 mb de ram para un mapa de unos 60.000 vertices, 100.000 faces y 100 materiales. Esos 20 mb de ram que pierdes los agradeces después en fps XD

Ah!, ten en cuenta que en tiempo de render tendrás que ordenar los indices de las faces con materiales transparentes, de lejos a cerca.

Por último, y si quieres hilar fino, ten en cuenta que las primitivas MUY TOCHAS joden mucho a la GPU; así que por ejemplo, teniendo un mapa con pocos materiales, si vamos ha hacer 5 llamadas de 20.000 faces cada una, será muy estimulante en un Gf 6800 pero muy jodido para una 4MX. Además debes tener en cuenta el StartVertex, VertexCount, StartFace y FaceCount para que el procesamiento de vertices sea el adecuado (para no saturar el vertex caché de la GPU).

Salud2

Efectivamente, yo creo k el tema está en lo k puede (o no puede) demostrar tanto el grafo como el programer. En mi opinión (y de esto ya tengo algo de carrera XD) es imposible "sodomizar" a un grafo solo con palabrerio, es decir, hace falta material visible, vistoso, hardcore o llamadlo como kerais. Cuando un grafo ve una demo (aunk solo dure 2 minutos y tenga 2 habitaciones) bien hecha, sólida, tecnológicamente avanzada, etc, es cuando realmente le entra el gusanillo de colaborar (y sí, he dicho eso, el gusanillo), xq ni aún así estará dispuesto a comprometerse del todo. En resumen:
1) Si kieres grafistas para hacer un juego 2D simplón no te molesten en encontrar, hazte tú mismo los gráficos (acabarás antes y con menos kebraderos de cabeza).
2) Si kieres grafistas para hacer un juego 3D más complejo, hazte primero una buena demo del juego con gráficos hechos por tí o conseguidos de por ahí y entonces es posible k consigas llamar la atención de algún grafo, pero como decía, esto no te garantiza NADA.

Lo que está claro es k no se puede exijir sin demostrar, y además los grafos del panorama actual ya estan muy kemados (+ o - como los programmers XD).
Yo ya me he vuelto loco y peleado con varios grafos (5 en total) para conseguir cosas decentes en un intervalo de tiempo decente y ha sido imposible. Pero en el fondo no les culpo, xq comprendo k si no les pago no puedo exigirles nada. Lo que jode es k les ofreces dinero y no te lo cojen, xq precisamente no tienen ganas (ilusión, o llamalo como sea) de comprometerse con el proyecto. Al final te acabas dando cuanta de k están colaborando en 3 o 4 proyectos a la vez, pero no rinden bien en ninguno, y lo hacen simplemente para expandir el ámbito de posibilidades de......no sé, la verdad es k no entiendo xq se menten en tantos ajos si al final no se comprometen en ninguno XD

En fin, k me estoy rayando ya demasiado...

Salud2

 Sí Grugnorr, tienes toda la razón, Google rules XD

Yo el primer día de practicas, además de ponerme a sacar tutos de Visual Basic (yo había usado Delphi en el módulo, no VS) tmb tube k buscar como se hacía un nudo de corbata, y no tardé en encontrarlo (para mi fortuna XD). Yo, aún saliendo de módulo reconozco y siempre reconoceré k como una ingeniería no hay nada, pues aprendes toda una base teórica k no aprendes ni de lejos en 2 años de módulo. Pero no os confundais, al menos en el módulo k yo he exo te enseñaban a programar como el mejor, y algoritmos de programación....el k kisieras (sin pasarse, no vayamos a irnos a algoritmos matemáticos de esos k no sabes ni por donde cojerlos XD). Yo lo único k sé es k llevo allí poco más de una semana y ya he visto 2 movidas con universitarios (becarios) k tmb están haciendo las practicas allí. Además me jode mucho xq ellos cobran y yo no XD. ¿Y xq de las movidas? Pues muy facil, xq ellos kieren entrar de analistas, rompiendo la pana, y sinceramente, no saben programar ni la mitad k yo o alguno de mis compañeros de módulo. Seguro k saben 1000 veces más k yo de mates, y seguro k saben algoritmos chungos, pero coño, es k les dices k te hagan algo en php-mysql o visual basic o delphi y se te kedan a cuadros. Y luego es k por no saber no saben ni retocar una imagen en el paint, y no les hables de fotoshop xq entonces ya la lias....En serio, k la teoría está muy bien, pero pa la empresa lo k vale es la practica, no la teoría. La teoría te la puedes meter por los cojones, xq para otra cosa poco te sirve. Lo dicho, yo con tiempo y dinero hubiera exo la carrera, pero visto lo visto y tal y como está el panorama no me arrepiento NADA de haber exo el módulo, xq al fin y al cabo lo k uno sabe es lo k uno ha estudiado, NO lo k le han enseñado.

Salud2

 Holaps

Weno, yo voy a hablar con conocimiento de causa xq ahora mismo estoy realizando las practicas de DAI (Desarrollo de Aplicaciones informáticas). Es un módulo de grado superior, creo k el mismo k hizo Berserker.
Estoy en Grupo Mecemsa (www.mecemsa.es). Se podría decir k es de lo mejorcito en empresas de desarrollo de software de Alicante, por no decir la mejor.
Aki cuando llegas, lo primero k hacen es pasarse el curriculum por el culo. Les importa una mierda de donde vengas, k títulaciones poseas o k cojones de juegos hayas hecho, xq dan por sentado k al entrar en la plantilla vas a ir PEZ PEZ.
Yo cuando salí del módulo pensé k sabía algo (sumando lo k había aprendido allí y lo k había aprendido yo por mi cuanta haciendo juegos y un motor gráfico k sigue en desarrollo). Ahora me doy cuenta de k no sé una mierda XD. Pero no os lo peerdais. En Mecemsa hay 60 empleados, de los cuales el 70% vienen de módulo, un 10% de la uni, y el otro 20 de otras carreras k no tienen nada k ver con informática (marketing, finanzas y leyes). Por lo k parece los gerentes de akí estan bastante descontentos con los universitarios (no es bueno generalizar pero es la pura verdad) pues llevan 8 años ajercicendo como empresa de formación y practicas y han tenido más de un disgusto con gente de carreras. Esto no pasa con gente de módulos xq en los módulos te ponen las pilas (sobretodo el 2º año) y no os podeis imaginar lo JODIDO k es aprobar los últimos parciales, pues tened en cuenta k solo hay 2 o 3 empresas k precisan gente en cada promoción, y hay unos 60 alumnos k kieren realizarlas XD. De esos 60, solo 10 aprueban, k son los k harán esas prácticas y el resto se tendrá k conformar con aprobar en junio o repetir curso.... Con deciros k yo suspendí una asinatura con un 5,10 (y esto no es ni mucho menos para tomarselo a broma). El profesor me dijo k simplemente tenía k aprobar a los k sacaran las notas más altas, y la más alta era de 6,5. Lo que kiero decir con esto es k aunk injusticias se cometen en todos lados (y en las carreras se cometen a diestro y siniestro) en los módulos te suelen dar más caña DE CARA A LA EMPRESA. Akí en mecemsa lo único k importa es tú capacidad de sacrificio y de autonomía, es decir, tú capacidad de buscarte la vida y aprender por tu cuenta lo antes posible (y a poder ser estudiar tmb en tu casa). Una vez estás dentro te kedas flipado y dices "¿pero yo k coño se? ¿he salido sabiendo algo?"...
En realidad aprender se aprende, pero se aprende UNA BASE, nada más. En la uni por el contrario se aprende una base y además mucha TEORIA, pero mucha teoría k luego no te vale para casi nada, así k está en las mismas XD. En fin, k como decía mi colega Zaelsius, lo k importa no es lo k hayas estudiado, lo k importa es lo CAPAZ k seas, el espíritu de sacrificio k poseeas (esto se traduce en CUANTO te vas a dejar la piel por la empresa) y por supuesto el factor SUERTE.
Si lo k realmente deseas es la base PRACTICA para poder currar en una empresa, es decir, Visual Basic, Delphi, ASP, PHP con MySQL, Oracle y nociones básicas sobre empresa, entorno laboral, etc, lo mejor es sin duda un módulo superior. Si por el contrario kieres saber más mates, más teoria de la programación y las computadoras, y más C/C++, pues te vas a la uni.
Si la empresa es MUY grande, la típica de 100 empleados para arriba, el ser o no ser ingeniero se mira con lupa, xq ten en cuenta k los gefes no van a dar a basto para probar a la gente (k es lo k se hace en mi empresa, probar a la gente durante un periodo de 2-3 meses). Lo que hace pues es ir directamente al curriculo, cosa k eso me parece mal xq un curriculum te dice muy poco de una persona (en primer lugar xq la mitad de lo k se pone suele ser mentira XD).
Por otro lado, si la empresa es pekeña te la come los títulos k tengas, xq lo único k importa es lo k sabes de verdad y lo k vas a poder demostrar en el tiempo k te dejen demostrarlo.
Eso es todo por mi parte, desde mi humilde experiencia por supuesto.

Salud2

 Gracias Jonny

Aprovexo para decir que la refde de Max Script es una puta basura XD
Si miras en filestream no hay ningún linkado a esa página, tienes k poner en el índice "BinStream" como
si fueras adivino XD
La verdad es k Max Script es una pasada cuando te acostumbras a utilizarlo (y sobre todo cuando aprendes a usar la ayuda XD), pero la ref se podría mejorar bastante la verdad....

En fin, gracias de nuevo!

Saludos

 Holaps

Bien, la pregunta es sencilla...
¿Se pueden grabar datos a un archivo en formato binario con Max Script?
A priori la función createFile no tiene ningún parámetro para especificar el formato de grabación,
en cambio sí lo tiene la función openFile mode:" ". Lo que hago es crear el archivo normalmente
con createFile y luego closeFile, para finalmente hacer un openFile con "wb". Aún así sigo
en las mismas. Todo me hace suponer k eso solo sirve para reconocer el archivo k abres de
forma binaria, para luego acabar guardandolo en modo texto XD
También he visto k no hay nada aparte de print y format, y estas funciones solo actuan con streams
de cadena....así k creo k me van a dar por saco.

Ale, asias de antemano y un saludo

 Hola a todos
Pues seitrix, la verdad es k lo tienes jodido...
Creo k en la avenida Maisonave había algo relacionado con el tema (Visual C++, Java, diseño web...)
Lo sé xq un amigo hizo un cursillo allí. Ahora no sé si habrán kebrado o no, pero te aseguro k a pesar
de k tenia buena reputación tmb dejaba mucho k desear XD
En fin....yo he aprendido c++ en año y medio básicamente a base de tutoriales y por supuesto con ayuda de compañeros ( Pablo (Shaq), Pablo (Huevox), Julio (Zaelsius), Ruben, ... ) entre otros.
Lo de los cursillos está bien para otro tipo de materias más gordas. En realidad aprender C++ no tiene mucha historia, aunk a priori sea más complicado k cualkier otro lenguaje script, o sin ir muy lejos Visual Basic o Delphi. Yo te recomiendo k mires en google ref sobre C++, seguro k encontrarás cosa buena...
Yo mismo puedo pasarte docu sobre el tema.
Agregame en d_carmak@hotmail.com

Salud2

 Wolas
Bueno, con respecto a lo k decía Drakkar:
- Cuando dije k no se efectuaban procesos de compilación me refería al apartado PURAMENTE gráfico. Hombre, está claro k algo hará para optimizar
colisiones y otro tipo de hardwork. Pero por lo k respecta al sistema gráfico es lo k dije, un portal-technology de toda la vida en tiempo real (no un PVS como el de los Quakes) sino un portal-rendering EXACTO. De hecho poner el noclip y fijaros en las celdas, TODAS SON CONVEXAS, y casi todas cuadradas.
- Con respecto a lo de k si el motor de Doom3 está anticuado a no, efectivamente SI LO ESTA. Mira, la prueba la tienes en k el motor de Quake3 vendió unas 15 licencias, y el Doom3 va a tener suerte si vende 5 (demomento solo lo van a usar 3 juegos). No hay k irse muy lejos, cojete demos de nVidia o ATI....vamos...k no hay color. Como dije, esto no es culpa de John; él mismo reconoció k la tecnología de Doom3 se diseñó en sus primeros pasos para una Geforce1 o ATI 7500, aunk luego consiguió adaptarse al nivel de Geforce3 o 4 TI (xq en realidad los requisitos de juego así lo exigían), osea, estaríamos hablando de NV20-25. La culpa la tienen los fabricantes de t.gráficas por sacar una generación gráfica cada 6 meses, cuando antes se hacia cada año y medio. Todos hemos visto la demostración de Unreal3, y está claro k está a años luz de lo k puede hacer Doom3 y va a salir para dentro de 2 días como kien dice (2006).
- Sobre lo de k Doom3 peca de no tener disparo secundario.... :-D. No sé Julio, eso ya me parece de recochineo XD. Yo me lo he pasado en 1 semana y precisamente el disparo secundario es algo k no he echado de menos. El juego es simplemente LA CAÑA, por no decir otra cosa. Te podrá gustar más o menos (eso es indiscutuble, sobre gustos no hay nada escrito) pero la calidad del producto no tiene parangón ahora mismo. Yo así por sacarle un defecto.....la IA, creo k se la podían haber currado un poco más con según k enemigos (sobretodo los finales), pero aparte de eso no me he kejado de nada más. Mi nota es de 9.8 en calidad, pero lo dejaría en 9.5 por los elevados rekisitos k exige, ya k me parece bastante abusivo tener k gastarse 300 € para poder gozar un juego en todo su explendor (yo jugué con una 4200 TI de 64 mb en 800x600 ya la verdad es k no me puedo kejar, pero aún así lo suyo es jugar a 1024 o 1280 en high, con anisotropico).

Ale, ya no me repetiré más sobre el tema, solo una cosa más:
Doom rules, ID Software rules!!!
Bay

 Wolas!
Bueno, el hilo ha empezado de una forma y parece k se está torciendo un poco XD.
La verdad es k ambos motores NO son comparables, pues si decidiese hacer un juego con espacios naturales me kedaria con el cry engine 400.000 millones de veces antes, más k nada xq el de D3
no sería capaz XD (no usa terrenos LOD, ni masking a saco con mucha vegetación, ni tiene nada k ver con un motor así). Pero como bien apunta berserker, con D3 los diseñadores de niveles pueden ver
como va a kedar la pantalla en el juego en tiempo real, sin tener k pasar por procesos de compilacion. Por otra parte, el D3 está realmente MUY MUY MUY optimizado, a pesar de lo k digan muchos primaveras de por ahí. D3 basa su sistema de ocultación en celdas->portales->boundings de luz, y por cada bounding de luz pinta los polys k tenga seleccionados (akellos k chocan contra el bound), y los polys k no pertenezcan a ninguna luz simplemente no se pintan (luego el backbuffer se limpia a negro y ya tienes la sombra TOTAL). Recuerdo k la demo alpha tocaba picos de 200.000 polys/frame de media, mientras k motores anteriores (sin ir muy lejos Quake3) no solía pasar de los 20.000 frame. Esto, unido a físicas, IA, bumpmap, sombras stencil, y otro trabajo underground, dando como resultado una media de 30 fps en una mákina medio buena no me parece un mal resultado en absoluto. PERO....k ha pasado con este motor? Pues ha pasado algo así como lo k pasó con el motor de Blade en su día: el juego ha tardado 4 años en salir y el motor ha kedado practicamente anticuado, pues realmente no aprovecha más de una Geforce3. Imagino k la versión final de juego usará shaders 2.0 para realizar ciertos efectos (de postproceso), pero el núcleo del motor está programado para aprovechar SOLO los vertex shaders 1.0, o lo k es lo mismo, cualkier tarjeta k disponga de TnL. Esto lo puede comprobar cualkier persona abriendo los paks, veréis k lo k es el núclo del motor, osea el sistema de iluminación, se basa en un par de vertex shaders 1.0. Recordad k aunk la iluminación luzca por pixel, NO se calcula por pixel. El tio John se sacó de la manga las tablas lookup para acelerar el proceso de iluminación (usando texturas de luz ya hechas y aplicandolas con un vertex shader de forma k parezca iluminación real [modificando coordenadas de textura y poco más]), con lo k al final sacas unos gráficos bastante buenos sin un coste muy fuerte en GPU.  Y nada, eso unido a las texturas proyectadas (tipicas luces de detalle k implementan una textura, como la tipica rejilla de sombra k se aplica sobre el escenario y los personajes), volumenes de sombra, bumpmap, specular (también por pixel) y a las animaciones por bone te da un resultado bastante especial. No hay más k ver la pantalla de HELL, luciendo una calidad gráfica como ningún juego podía haber soñado antaño (digno de una película de animación). Al fin y al cabo este problema de "antigüedad" no tiene nada k ver con Carmack, sino k simplemente se trata de un mero factor TIEMPO. Estos últimos 2 años han sido un cachondeo para el mundo de las t.gráficas. Han sacado muchos modelos, muy caros, entre muchas polémicas, a cual más fuerte entre ATI--nVidia. La dura competencia entre ambas competidoras se traduze en un salto generacional MUY fuerte (de una gForce3 a una X800 o 6800 k están realmente MUY por encima). Creo k motores como HL-2, k sí van a aprovechar PS 2.0 y 3.0 seguramente, y alguno k puede dar cierta sorpresa como el de Stalker tienen más futuro de cara a ventas de JUEGOS k lo k pueda hacer el motor de D3. Pero la ventaja de hacer un motor como el de D3 es k luego cambiando 50.000 lineas de código ya tienes un motor NUEVO, orientado a los últimos chipsets del mercado. En cambio cojer un Unreal2 y pasarlo a un Unreal3 es ..... vamos, k mejor empezar el motor de 0 y acabas antes XD.
Pues nada, ahí keda eso, siento haber metido tanta paja :-D
Taleg!!

 Bueno, dada mi miserable experiencia yo te aconsejaría k, si el juego va a ser pura y llanamente 2D, no es necesario ni k uses un motor 2D/3D. Como ha dixo alguien anteriormente, puedes probar suerte con OGL o D3D a pelo para crearte un pekeño motor (serían unas 2.000 lineas de código a lo sumo) que solo reproduzca quad's. Nada, solo tendrías k aprender a aplicar varias texturas (por si kieres k el quad use varias superficies mezcladas), saber transformar las coordenadas de textura para mover texturas sobre el quad, saber transformar la posición del quad para moverlo, rotarlo, escalarlo y finalmente algunos efectos de transparencia. Luego es posible k necesites animaciones por frames o por set's de coordenadas de textura, como se ha exo toda la vida con los sprites. Vamos, no sé, es informarte un poco por ahí y enseguida tendrás lo k necesitas. Motores buenos y "gratuitos" hay varios. He visto Cipher y Ogre por encima, pero sobretodo Irrlicth ha sido el k he probado, y la verdad es k está bastante bien (seguro k para lo k tú kieres hacer te sobra), aunk el tema de las animaciones (sprites animados) lo veo más dificil en este sentido.
LO QUE YO HARIA EN TU LUGAR es pillarme DirectX y hacer uso de la ID3DXSprite y a tomar por culo, te haces un pekeña capita y a correr. Crear o usar tecnología a ese nivel (solo para juegos 2D k nisikiera van a usar scroll) es muy liviano; donde realmente las vas a pasar un poco canutas será a la hora de hacer el juego :-P
Ale, taleg!!

 Por supuesto, yo tmb me apunto!!!

 Llevo algunos años dedicando al mundillo del videojuego. Hace 6 meses me dió la vena de hacer engine.
1) Reconozco k me estoy rompiendo los cuernos cada 2x3.
2) En estos 6 meses he aprendido más Dx, API Win32 y C++ k en 3 años anteriores (dedicando el tiempo ha hacer mierdecillas en D3D u OGL, e intentado trastear con algunos motores ya hechos).
3) Conclusión: si quieres aprender a programar y a romperte los cuernos haz un jodido motor :-P
4) Conclusión2: si no te interesa aprender y solo kieres hacer un jodido juego, haz el jodido juego y olvidate del jodido motor. XD

 Bueno, dejando polémicas y suposiciones aparte, yo también quisiera mostrar mi más profundo pésame a las víctimas y familiares. Ya no impora si ha sido ETA, los moros locos o su puta madre, aquí de lo que se trata es que hay gente QUE SE GANA LA VIDA MATANDO, y es eso lo que no debemos tolerar. Venga, ánimo a la gente de Madrid...

 Colson, tienes razón, lo del UT 2004 son palabras mayores, pero yo nunca me juego algo k no puedo cumplir ;-). Ahora, k diga k tendrá el mismo redimiento/gráficos no significa que tmb vaya a tener un editor como el del UT :-P (no se puede pedir todo). Demomento estamos tirando de herramientas externas para hacer escenarios/modelos, pues realmente lo k más se tarda en hacer de un engine es el editor de escenarios y las herramientas de animación. Las herramientas de RET se basan en mini programas, como editor de materiales, exportador de archivos a los formatos nativos (con posibilidad de especificar multiples opciones), editor de físicas, etc, vamos, nada del otro mundo. Y sea como sea, estas herramientas todabía no están implementadas :-(. Soy consciente de que nos kedan muchos meses de trabajo para tener un motor DECENTE. El problema es el de siempre, la falta de tiempo (los estudios, el trabajo, la vida social). Llevar a buen puerto un proyecto como RET exige una de 3, o mucho dinero, o muchos cojones, o estar gilipollas perdido (mi caso). Ale, ahí dejo la cosa, no volveré a pronunciarme más sobre el tema.
Salu2
 

 Bueno, ya k habeis preguntado sobre RET FX...
RET (Real Environment Tech.) será un entorno de desarrollo con muchísimas posibilidades, MUY fácil de usar (lo más fácil de usar k he visto hasta ahora), y con las prestaciones justas que un desarrollador necesita para programar cualquier tipo de juego (excluyendo los juegos que necesiten espacios abiertos descomunales, como algunos simuladores de aviación). Lo de entorno de desarrollo lo digo más k nada xq incorporará diversas herramientas embebidas en el propio sistema que nos serán de gran utilidad. Quiero decir con esto k no es un blitz ni nada parecido, se programa en C++ (VS 6.0 o .NET en principio). De momento solo es compatible con DX9 y Windows, pero ya estamos pensando en pasar a oGL, más k nada para una posible versión de Linux. Dicho sistema se presenta en varios módulos (varias DLLs), algo como:
RETD3D o RETOGL: Incluye el core de RET y el motor gráfico
RETPHYS: Es el motor de física
RETNET: El motor de red (lan/online)
RETAUDIO: Será una capa para poder usar la LTML de Lemon Team (una librería de audio/media).
Llevamos trabajando en RET unos 6 meses entre 2 personas (aunk el 95% del trabajo me lo estoy tragando yo, ya que mi socio está dedicando su tiempo a probarlo mientras hace un juego de coches XD). Cuando la demo de dicho juego esté lista daremos a conocer RET (será dentro de unos 3 meses como mucho).  Sinceramente creo k va a causar un gran impacto entre la comunidad de desarrolladores. En primer lugar xq podrán hacerse juegos simples con MUY POCAS lineas de código, y no por eso el rendimiento será frustrado, todo lo contrario. De hecho me juego el cuello aquí mismo y diré que espero unos resultados muy parecidos a los de UT 2004. Pero en fin, no es plan de fardar sin enseñar nada a cambio, así k paciencia y al toro.
Salu2