Código Fuente de Quake 3 liberado

Turyx escribió:

Uff, yo tb me vicié lo suyo al de DC...
Estaria bastante bien un port para PS2, y ya si añaden modo Online mejor xD(si, se q es tremendamente dificil xD)



Siento si sueno ignorante pero...no te he entendido para nada xD
Q tiene q ver un emulador de SCUMM con el Quake 3, Medal of Honor, etc...?

Si no me equivoco el scumm es un motor grafico usado por las aventuras de lucas arts en el que metiendole los datos de los diversos juegos puedes disfrutarlos.

Me parece que se refiere a hacer lo mismo, crear un motor base quake3 que metiendole los datos de diversos juegos puedas disfrutarlos en todos los sistemas donde este motor pueda portarse.

Rurouni escribió:Tienes que tener compilado antes el compilador para Quake y indicarle el path en el Makefile. Viene incluido en el código fuente, pero antes lo tendrás que compilar también

Uf... acabo de ver el readme, sí es así como dices... pero me pierdo, encima está en inglés... a ver si con el tiempo alguien se curra una traducción de esos ficheritos...

DyV escribió:Te recomiendo que empieces poco a poco, haciéndote pequeños ejemplos y aprendiendo algo sobre física y matemáticas (esencial si quieres entender código matemático y físico). Luego aprender algo sobre metodologías de programación e ingeniería del software. Mirarte arquitecturas de software, en concreto de videojuegos. Eso ayuda mucho. En definitiva, para programar videojuegos hay que saber programar videojuegos. Y para entender el código de un videojuego, también.

Me interesa esto, alguna web donde aprender poco a poco (a ser posible en español)?

Cojonuda noticia, lo esperaba como agua de mayo, mañana lo estudiare en profundidad.

Gracias, diox Carmack

Lo del scummvm era solo una comparacion, el mismo caso si hubiera nombrado el sarien, el exult o algun otro programa para hacer funcionar juegos con un motor comun, en este caso el del quake 3, eso es lo que he querido decir, si pensamos un poco sabiendo los fundamentos del codigo fuente podriamos hacer por ejemplo que el quake 3 corriera en una psp o una ngage 3 o lo que sea, eso es lo que quize decir

CaT_Os_MandRoS escribió:Me encanta la sinceridad de los programadores al hacer comentarios...

Mirad xD:

m-(~/quake3/quake3-1.32b)-(10 files, 68Kb)--> grep -ri fuck *
code/bspc/aas_map.c: //NOW close the fucking brush!!
code/game/q_math.c: i = 0x5f3759df - ( i >> 1 ); // what the fuck?
code/q3_ui/ui_atoms.c: // fuck, don't have a clean cut, we'll overflow
code/server/sv_main.c: // since the cmd formatting can fuckup (amount of spaces), using a dumb step by step parsing
code/ui/ui_main.c: // fuck, don't have a clean cut, we'll overflow
code/ui/ui_shared.c: // vm fuckage
code/ui/ui_shared.c: // vm fuckage
code/ui/ui_shared.c: //FIXME: this is a fucking mess
code/unix/ChangeLog: Note: Unix CR/LF in *.dsw/*.dsp fucks up MSVC++.
code/unix/ChangeLog: How the fuck did this happen?
code/unix/ChangeLog: some files, and between their revisions and ours we fuck this up.
q3radiant/DRAG.CPP: break; // dragged backwards or fucked up
q3radiant/ECLASS.CPP:// FIXME: this code is a TOTAL clusterfuck
q3radiant/EPAIRS.H: {"rem", "Less than half a fucking man."},
q3radiant/EPAIRS.H: {"rem", "You're fucking dumb! Suck it down."},
q3radiant/igl.h:// cleaning up after merging and thinks badly fucked up
q3radiant/MAP.CPP: this could fuck up if you have only part of a complex entity selected...
q3radiant/PMESH.CPP: // FIXME: this bend painting code needs to be rolled up significantly as it is a cluster fuck right now

Dios, que descojone...

Un saludo.

adri58 escribió:Entendido.

Entonces lo que yo se servira para otras cosas pero para juegos no.

Lo que dices de menuda idea de bombero lo preguntaba por que no sabia eeeee. No hace falta que me pongas a parir xDDDDD

No hombre, no te pongo a parir, es solo que me hace gracia. Al decir eso, se nota mucho que eres novato programando. Dentro de un tiempo, cuando hayas tenido que escribir algún proyecto de entre 10000 y 50000 lineas (abordable por una sola persona en un tiempo razonable), a ti también te hará gracia eso de "todo el código en un fichero". No es solo que haya muchos motivos para dividirlo en varios ficheros, es que en realidad no hay ningún motivo para tenerlo todo en un solo fichero. Ventajas 0.

Rurouni escribió:Si teneis Debian/Sid deberéis cambiar lo siguiente:

En lcc/makefile:
Linea 139:
- SYSTEM=$(shell cc -print-search-dirs | head -n 1 | cut -b 10-)
+SYSTEM=$(shell cc -print-search-dirs | head -n 1 | cut -b 11-)

Je, que curioso, ese comentario lo puse yo ;P Aprovecho para poner los saltos de linea que se me escaparon en barrapunto.

BladeRunner escribió:Me interesa esto, alguna web donde aprender poco a poco (a ser posible en español)?

Hay un par de enlaces imprescindibles:

Gamasutra
Gamedev

El primero está orientado al mundo profesional, pero con un registro gratuito tienes acceso a un montón de artículos interesantes (de nivel medio a medio-avanzado más bien).

El segundo es más orientado al desarrollo de videojuegos en general. Encontrarás tutoriales y artículos de todos los niveles. También te recomendarán un montón de libros (sobre matemáticas, física, gráficos por computador, APIs para 3D, de todo) y te pueden guiar sobre cómo aprender. Además hay foros donde preguntar y discutir cosas relacionadas con todos los aspectos de los videojuegos.

El problema es que están en inglés, pero sobre desarrollo de videojuegos no creo que puedas encontrar nada mejor. En español sé que existen foros y weblogs porque alguna vez los he visitado a partir de enlaces y noticias en weblogs por ahí, pero entonces estaban muy verdes y no me he vuelto a pasar por ellos (así que ni me acuerdo).

Si ya sabes programar y quieres aprender a programar videojuegos, te recomiendo dos cosas: primero que mires algún código de algún jueguecillo pequeño (muy pequeño) y trates de hacer tú algo pero que sea PEQUEÑO. Que puedas previsualizar todo el código y hacerlo en una sentada.

Si quieres alguna biblioteca que te permita lidiar con los archivos de imágenes, entrada/salida y temporización (lo básico), puedes probar con:

SDL , de bastante bajo nivel (ayuda a comprender como funciona todo por debajo). Funciona tanto en Windows como en Linux y está en C. No tiene soporte para 3D directamente, pero soporta OpenGL.

Clan , de más alto nivel que SDL, de hecho proporciona un framework en C++ para el desarrollo de videojuegos. Funciona también tanto en Linux como en Windows, y puede funcionar con SDL por debajo. Proporciona un wrapper de OpenGL para 3D.



OGRE , un motor gráfico 3D MUY completo y bastante rápido. Verás otros motores, con física incluida y demás (como Crystalspace), pero son lentos y pesados, y bastante feos. No es algo con lo que iniciarse ni muchísimo menos.

Esto es para cuando ya sepas cómo funciona todo y no te apetezca implementarlo tú mismo (OGRE ha llevado 4 años de desarrollo), la arquitectura de OGRE es bastante buena. Pero es importante que sepas qué es lo que hace por debajo, sino te abrumará. Si pruebas algún tutorial te parecerá fácil hacer alguna pequeña cosa (es hacer un par de herencias de clases y ya tienes naves espaciales moviéndose por ahí), pero cuando intentes hacer algo un poco serio se te escapará de las manos. OGRE se integra bastante bien con ODE, es un motor de física en tiempo real muy currado. OGRE+ODE es una buena base para videojuegos serios.

Programar videojuegos no es algo que se pueda aprender en poco tiempo, es algo que se aprende poco a poco a lo largo del tiempo. Son un montón de cosas. Pero si te lo tomas con filosofía, sin prisas, acabarás aprendiendo. Y no es que no puedas programar nada hasta que lo sepas todo, simplemente que los juegos que serán accesibles a tus habilidades irán desde los de hace 30 años (al principio), hasta los últimos que han salido (al final). Así que el proceso no es que sea un coñazo infumable, irás viendo resultados poco a poco, pero no el Doom3 desde el primer día.

Corregidme,pero el call of duty no usaba cmo base el engine del quake 3?

en realidad el call of duty usaba una version muy modificada de este motor

De todas maneras el motor tuvo dos versiones : la primera version fue usada por quake arena, alice, heavy metal , stark treck voyaguer y creo que a esta version pertenece el medal of honor. La segunda version que tenia mas cosas pero pedia mas maquina es la del team arena (la expansion), el jedi knight 2 y 3 (en el caso del 2 usaba una version con algunas modificaciones), el soldier of fortune 2, el star treck elite force 2, la segunda expansion del medal (los efectos de arena y otros no los soportaba de serie el motor quake 3 original), y se podria decir el call of duty

La pregunta de oro seria si se ha liberado el motor quake 3 original o tambien incluye las modificaciones del team arena

DyV

Gracias por toda la iniciación, no te la cito porque es larga y no es cuestión de llenar el hilo repitiendo, pero ya la he copiado y guardado en un txt para cuando tenga tiempo.

La verdad es que en cuestión de programación ando bastante verde, ya me cuesta pelearme solamente con PHP, pero el tema de los videojuegos siempre me ha entusiasmado ya desde aquellos tiempos con mi C64 y mis primeras subrutinas en ensamblador (hice una que en combinación con el basic hacía un scroll de pantalla bastante rapidillo para la increíble velocidad de la CPU: 1mhz, desde aquello cuando oigo assembler me digo "nunca mais" ).

Luego he intentado hacer pequeñas cosas pero se han quedado a la mitad con algunas herramientas (Div Games Studio, GameMaker), realmente tienes mucha razón con lo de hacer un PEQUEÑO juego de entrenamiento... (tengo muy poca base en programación).

Hay mucho, MUCHO que leer, thanks.

EDIT. En español yo conocía http://www.stratos-ad.com pero no tienen apenas documentación, parece que se ha quedado en una especie de "punto de encuentro" de desarrolladores...

El scummvm es un intérprete del lenguaje de script scumm (Script Creation Utility for Maniac Mansion). Un lenguaje de script es un lenguaje de más alto nivel normalmente interpretado, por lo que su ejecución es más lenta ¿para qué sirve? Por ejemplo, para definir una escena guionizada sin tener que recompilar todo el código cuando cambies cualquier cosa, o en el caso del Scumm, definir las posibles acciones sobre los objetos. El ScummVM simplemente interpreta el lenguaje para presentarnos las diferentes opciones en pantalla.

Que varios juegos tengan el motor del quake3 es algo radicalmente diferente a eso, y no se puede hacer. Básicamente un juego que usa el motor del q3, sería lo que ahora que tenemos el código del q3 se puede hacer: juegos nuevos basándonos en él.

Una gran noticia sin duda alguna.

Seguramente me comprare el Quake 4 si hay bastante mejoria respecto al 3 y si hay ejecutable para linux, como el unreal tournament.
Tambien esta incluido el codigo del editor de mapas, por si alguien no lo sabe.