spiele programirung

[localhost]

Wodrin werden spiele programirt also zum beispiel counterstrike, UT, quake oder harflife2

[tuxipuxi]

hi,

C/C++ in der Regel.

counterstrike nutzt OpenGL.
Ut auch.
quake weiss ich nicht.
Halflife 2 ist C++ mit DirectX, das weiss man ja sicher, seit der sourcecode veröffentlicht wurde.( nicht von valve, sondern von jemandem, der ihn geklaut hat ).

gruss,
tuxipuxi.

[Berufspenner]

Hi

Meist in C++/OpenGL oder C++/Direct3D.

Cu
André

[localhost]

OpenGL ist ??
Ich hab immer gedacht das wer ein Treiber?!??!
kann mir das einer erkleren.
könnte man sowas wie counterstirke auch in java coden ??

[tuxipuxi]

hi,

OpenGL ist eine grafikbibliothek. google für mehr informationen.

so etwas wie counterstrike kannst du nicht in java programmieren, das ist ausgeschlossen. es gibt soweit ich weiss OpenGL bindings für java, aber die geschwindigkeit, die du mit einem java programm erreichst, reicht für solche Spiele einfach nicht aus.

gruss,
tuxipuxi.

[Nuke]

C/C++/Assembler und OpenGL sind ein Dreamteam.

Doom3 wird in dieser Kombination programmiert, sowie auch schon Quake3 so programmiert wurde.

Java kannst du dir gleich abschminken. Für´n 3D-Tetris geht´s vielleicht noch, aber wenn du dicke Texturen und Sound handhaben willst...nee. Java wurde dafür nicht entwickelt und eignet sich ebensowenig dafür.

[peschmae]

Immer diese blöden Vorurteile. Das wird mal wieder n Flame. :( (Diesmal ist zum Glück nicht Tuxipuxi der scheinheilige sondern ich :D)

Natürlich kannst du Spiele mit Java programmieren. Das Paradebeispiel (ok, vielleicht das einzige) ist: Arkanae: https://arkanae.dev.java.net/

"So etwas wie Counterstrike" ist recht wage. Aber die Grafikqualität scheint mir etwa vergleichbar.

Klar C++ ist wohl meist ein bisschen schneller und so - aber mit Java gehts auch. Tuxis Behauptungen sind wie fast immer bei diesem Thema recht falsch.

MfG Peschmä

[Berufspenner]

Original geschrieben von peschmae
Immer diese blöden Vorurteile. Das wird mal wieder n Flame. :( (Diesmal ist zum Glück nicht Tuxipuxi der scheinheilige sondern ich :D)

Natürlich kannst du Spiele mit Java programmieren. Das Paradebeispiel (ok, vielleicht das einzige) ist: Arkanae: https://arkanae.dev.java.net/

"So etwas wie Counterstrike" ist recht wage. Aber die Grafikqualität scheint mir etwa vergleichbar.

Klar C++ ist wohl meist ein bisschen schneller und so - aber mit Java gehts auch. Tuxis Behauptungen sind wie fast immer bei diesem Thema recht falsch.

MfG Peschmä Wenn ich mich jetzt aber mal ganz naiv stellen würde, dann würde ich mich aber fragen, warum sich dann Java so schlecht/gar nicht in der Spieleentwicklerszene durchgesetzt hat? Ich meine, dass es doch grade die Produktionskosten senken und die Verbreitung steigern könnte, wenn man ein Spiel für eine einheitliche Umgebung, in diesem Fall dann Java, schreiben würde. Schließlich müsste man dieses Spiel dann nicht mehr portieren. Also irgendeinen drifftigen Grund wird es dann wohl geben.

Cu
André

PS: Ich hoffe das war jetzt kein geflame sondern der gelungene Versuch einer objektiven Äußerung.

[tuxipuxi]

Original geschrieben von peschmae
Immer diese blöden Vorurteile. Das wird mal wieder n Flame. :( (Diesmal ist zum Glück nicht Tuxipuxi der scheinheilige sondern ich :D)

Natürlich kannst du Spiele mit Java programmieren. Das Paradebeispiel (ok, vielleicht das einzige) ist: Arkanae: https://arkanae.dev.java.net/

"So etwas wie Counterstrike" ist recht wage. Aber die Grafikqualität scheint mir etwa vergleichbar.

Klar C++ ist wohl meist ein bisschen schneller und so - aber mit Java gehts auch. Tuxis Behauptungen sind wie fast immer bei diesem Thema recht falsch.

MfG Peschmä

bitte, bitte schreib mal verschiedene spieleentwicklungsfirmen an! JEDER entwickler wird sich dort an den kopf fassen, wenn jemand ein hochanspruchsvolles spiel mit java programmieren will.
das sind keine vorurteile, sondern feststellungen.
ich hätte echt nicht gedacht, dass ein javaner da widersprichen würde.

[Berufspenner]

Original geschrieben von tuxipuxi
bitte, bitte schreib mal verschiedene spieleentwicklungsfirmen an! JEDER entwickler wird sich dort an den kopf fassen, wenn jemand ein hochanspruchsvolles spiel mit java programmieren will.
das sind keine vorurteile, sondern feststellungen.
ich hätte echt nicht gedacht, dass ein javaner da widersprichen würde. Dito. Sollche Tatsachen muss man akzeptieren. Ich mag Linux auch sehr gerne, doch ist es auch keine 100%ig bugfreies und perfektes Stück Software. Damit muss man sich halt abfinden, sollange man es nicht ändert.

Cu
André

[tuxipuxi]

ich habe mal einen experten gefragt, der auch spieleentwicklung betreibt. seine aussage unterstützt mich nicht wirklich, aber ich unterschlage sie trotzdem nicht:


"

[22:01] <tuxipuxi> "is it possible to use java for games like counterstrike or ut? is java fast enough for those games"?

[22:02] <kilobug> tuxipuxi: I don't really know, Java3D uses a lot of C code (all the OpenGL backend) so may be not too slow... it'll still be slower, but I don't know how much
[22:02] <warp> tuxipuxi: as long as you get hardware accelerated 3D, the speed of the language or CPU is not that important on todays machines. so, assuming you're using Java3D or something, i'd say yes -- in theory :)

[22:09] <warp> kilobug: ofcourse, i would never use java for that, or anything. but IMO it is feasible to do it with java. which is what tuxipuki asked.
[22:09] <kilobug> warp: there are more ports of SDL and OpenGL libs than ports of Java3D AFAIK, so you'll have to port Java3D & such

"

gruss,
tuxipuxi.

edit: 2 lines hinzugefügt

[Nuke]

LOL! Klar. Speed hat man ja genug. Die Spieler können sich ja alle 3 Monate einen neuen Rechner kaufen, weil die Programmierer nur scheiße bauen. *ggg*

So etwas macht man nicht! Java wurde einfach nicht dafür entwickelt. Java ist eine Internet-Sprache.

[Lin728]

So komisch das klingt, ja das geht:

www.eis3d.com -> Ein Softwarerenderer komplett in Java geschrieben mit Demo-Applet. Wirklich sehenswert, wo doch java vieel zu langsam sogar für engines ist, hier rechnet es auch 3d-zeugs ohne grafikkarte!

www.javagaming.com
open-mind.sf.net
......

Fakt ist, dass sowieso nur ca. ~20% der Prozessorzeit bei einem Java-Spiel im Spielecode verheizt werden, der Rest betrifft das rendering und das wird von CPU/Graka in nativem Code erledigt....

[anda_skoa]

Original geschrieben von Berufspenner
Wenn ich mich jetzt aber mal ganz naiv stellen würde, dann würde ich mich aber fragen, warum sich dann Java so schlecht/gar nicht in der Spieleentwicklerszene durchgesetzt hat?


Speziell diese Hardwarebeschleunigten Sachen sind nicht überalk erhältlich.

Könnte mit SGIs neuen GL Bindungs besser werden.

Das Hauptproblem bei Java für Desktop ist der große Unterschied in der Güte der JVMs verschiedener Hersteller und verschiedener Plattformen.
Bis vor 1.4 war zB die JVM von SUN vorallem unter Linux zum Vergessen, wahrscheinlich mit Absicht.

Und natürlich das Voruteil, Java sei langsam :rolleyes:

Zusätzlich ist Portbilität bei den meisten Spieleherstellern noch nicht wichtig und sie haben riesige Beständen interner Bibliotheken und lizensierte Komponenten von Drittherstellern, die dann alle nicht passen würden.

Das hält auch die Portabilität bei Benutzung andere Sprachen zurück, rein technisch gibt es keinen Grund, warum Spiele nicht mit der selben Codebasis auf Windows, Linux, Mac und diversen Konsolen laufen können.

Ciao,
_

[localhost]

das heist ja wen Counter-strike mit java gemacht worden wer wer es kaum langsamer und auf linux openbsd und m$ lauffehig oder sehe ich das falch

[Lin728]

Damals nicht, damals war Java zu langsam für Spiele-Entwicklung. Da hat erst die Entwicklung von JITs begonnen und von einer schnellen HotSpot-Engine ist wiet und breit nichts zu sehen gewesen.

Außerdem darf man keine Bilbiotheken verwenden, die nur auf einer platform verfügbar sind, da du für Enviromental-Audio / OpenGL / Joystick auf native C++-Bibliotheken zugreifen musst.

Aber sagen wir mal aus dem heutgigen Standpunkt: Ja, es wäre ohne weiteres Möglich ein Spiel ala´Counterstrike mit Java zu machen.
Das wäre aber mit sauberem C++ und ein bisschen mehr Aufwand auch machbar.
Bei Java gehst vor allem um die leistungsfähige Classenbibliothek und eine klarere Sprache (das ist ansichtssache).

[fs111]

Meist ist doch wohl eher so, dass die Engines in C/C++ geschrieben werden, und das Spiele selber dann nur noch geskriptet wird. Bei Uru (das neue aus der Myst Reihe) ist das so, und zum Skripten wird Python verwendet.

fs111

[localhost]

hä das verstehe ihc garnicht?!!


Original geschrieben von fs111
Meist ist doch wohl eher so, dass die Engines in C/C++ geschrieben werden, und das Spiele selber dann nur noch geskriptet wird. Bei Uru (das neue aus der Myst Reihe) ist das so, und zum Skripten wird Python verwendet.

fs111

[peschmae]

ist aber recht klar so. Das will heissen: Du schreibst, aufbauend auf OpenGL/SDL/DirectX eine Spiele-Engine (gibt auch solche, die du dir irgendwo runterladen kannst) - mit der Quake-Engine wurden z.B. viele andere Spiele geschrieben, nicht nur Quake.

Die Engine stellt quasi Funktionen auf einem höheren Level zur Verfügung.

Das Spiel selbst wird dann mit einer Scriptsprache erstellt. (Spielintelligenz und Anordunung der Objekte (aka Feinde))

MfG Peschmä

[peschmae]

Original geschrieben von Berufspenner
Wenn ich mich jetzt aber mal ganz naiv stellen würde, dann würde ich mich aber fragen, warum sich dann Java so schlecht/gar nicht in der Spieleentwicklerszene durchgesetzt hat?


Akzeptiert. Ich frag mal gleich naiv zurück wieso die Spielerentwicklerszene und alle anderen Programme nur für Windows entwickelt werden. (Ich weiss, das stimmt nicht, aber als Naivling kann ich das ja nicht wissen :p)



Ich meine, dass es doch grade die Produktionskosten senken und die Verbreitung steigern könnte, wenn man ein Spiel für eine einheitliche Umgebung, in diesem Fall dann Java, schreiben würde. Schließlich müsste man dieses Spiel dann nicht mehr portieren.

Zweifellos. Aber der Linux-Markt ist klein. Die wenigsten spielen auf AIX oder IRIX. Mac OS X ist auch nicht wirklich wichtig.
Die wenigsten Spiele werden je portiert - und wenn dann ja nur von Freiwilligen. Ich glaube nicht, dass ein so kleiner Markt interessant ist...
Halt das übliche Problem.


Also irgendeinen drifftigen Grund wird es dann wohl geben.


Hab nie gesagt es gäbe keinen. Aber ich kenne keinen. Auch Tuxipuxi und sein Interviewpartner offenbar nicht.

Da OpenGL selbst ja eh in C geschrieben ist, und meist auch mit Hardwarebeschleunigung betrieben wird, sehe ich da eigentlich keine Performance-Probleme.
Zugegebenermassen habe ich aber bisher (mangels PC auf dem man spielen könnte (-> hint, hint, wer schenkt mir einen ;))) noch kein in Java programmiertes Spiel ausprobiert. Auch arkanae nicht (die Screenshots sehen aber Ok aus). Aber natürlich auch sonst keine aktuellen Games (CS, was auch immer).

Das Problem ist wohl - wie meist bei Entscheiden gegen Java - die Psychologie. Swing war lange Zeit sehr langsam. Extrem schnell ist es auch heute noch nicht.
Mit so einem Ruf ist es natürlich schwer für Java, sich durchzusetzen.

MfG Peschmä

[anda_skoa]

Original geschrieben von peschmae
Akzeptiert. Ich frag mal gleich naiv zurück wieso die Spielerentwicklerszene und alle anderen Programme nur für Windows entwickelt werden. (Ich weiss, das stimmt nicht, aber als Naivling kann ich das ja nicht wissen :p)


Wie gesagt:
- Abhängigkeit auf alte, nicht portierbare, interne Libs
- Abhängigkeit auf nicht crossplattform erhältliche Komponenten von Drittherstellern
- Unkenntnis von der Möglichkeit plattformübergreifender Entwicklung
- wenig Know-How bei den Entwicklern (zB Plattformhacks)
- alte Informationen im Management (Java sei langsam, oder man müsse auf andere Plattformen "portieren", etc)

Ich würde schätzen am häufigsten die ersten beiden und das letzte.

Ciao,
_

[peschmae]

so in etwa hab ich mir das auch gedacht. Aber ich hab ja nicht dich gefragt ;)

MfG Peschmä

[localhost]

und wie ist den jetzt der stand der dinge ??
java für game´s ja nein oder was anderes ?!,daföj

[peschmae]

kommt drauf an. Was für ne Engine und so...

Unter Linux wird wohl recht viel die libSDL verwendet.

MfG Peschmä

[SeeksTheMoon]

Es stecken also wesentlich mehr Dinge dahinter als nur die Programmiersprache und deren "Geschwindigkeit". Wenn man sich damit eingehender befasst (so wie ich), wird einem die Sache klarer. Ich will mal meine Erfahrungen mit der Spiele-Entwicklung und besonders mit der Java-Spiele-Entwicklung posten.
Der Text ist was länger, aber er ist für euch mit Sicherheit interessant.

Vorweg etwas zu Java:
Java ist NICHT zu langsam. Richtig, es IST langsamer als C, aber nicht ZU langsam. Diesen Unterschied muss man erkennen.
In den Anfängen von Java (1.0, 1.1) war es wirklich sehr behäbig, aber 1. sind die SDKs immer schneller geworden (und werden es auch weiterhin mit jedem Release) und 2. sind auch die Rechner schneller geworden. Dennoch hält sich dieses Vorurteil der Langsamkeit extrem hartnäckig.
Früher hat man auch gesagt, C wäre viel zu langsam, nur Assemblerprogramme wären richtig gut. Bullshit, wie man heute sieht.

Ich wollte selber mit meiner Crew ein sehr aufwendiges Spiel in Java programmieren. Was ich eben zu Java gesagt habe, hatten wir dabei im Hinterkopf. Wir haben viel mit Java programmiert, so dass wir zu dieser Ansicht gekommen sind. Ein weiterer Faktor für Java war die Tatsache, dass anscheinend niemand sonst so etwas in Java realisiert hat, wie auch oben bereits angemerkt wurde. Es war also auch eine Art Pioniergeist und Freude am Experiment dabei.

Anforderungen an das Spiel und die Bibliotheken:
3D-fähig, netzwerkfähig, plattformübergreifend, multimediafähig (also außer 3D noch Sound, Bilder und Videos), alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden. Die Dokumentation muss auch so gut sein, dass eine Einarbeitung gut möglich ist, bzw dass man überhaupt eine Ahnung von den Fähigkeiten der Bibliothek bekommt, sonst fällt einem möglicherweise ein Fehlgriff zu spät auf und man braucht dringend Ersatz und hat Zeit verloren.


Der Java-Ansatz ist während der Planungsphase an folgenden Dingen gescheitert:

1. Man hat für 3D-Grafik die Wahl zwischen GL4Java und Java3D.
GL4Java bekam schon lange keine Weiterentwicklung mehr verpasst und es lies sich auf keinem unserer Rechner zum Laufen überreden.
Java3D funktionierte auf Anhieb, dafür gabs folgende Probleme:
a) schlechte Doku (die von GL4Java hab ich mir nicht angesehen, weil es nicht lief), vor allem gibts bis auf 1-2 alte Bücher keine deutsche Doku.
b) Die Plattformunabhängigkeit ist im Ar..., weil: J3D gibts nur für Windows und Solaris (wer benutzt Solaris?), die Linuxversion hinkt ein Stück hinterher und wird von Sun nicht supported. Eine Mac-Version gibts überhaupt nicht!
J3D bietet Support für spezielle Eingabegeräte (Joysticks, Brillen, ...), allerdings nur auf DirectX Systemen.
c) Wie bei allen Libs, muss man dieses Paket vom Anwender installieren lassen.

2. Soundbibliotheken sind ganz großer Mist:
Die Soundformate, die man von offiziellen Erweiterungen benutzen kann, sind grauenhaft (au, aiff, nur bestimmte wave-formate). ogg und mp3 sind da nicht bei.
Es gibt diverse ogg und mp3 Libs, aber deren Lizenzen schmecken einem nicht immer, vor allem wenn man ein kommerzielles Game schreiben will. Außerdem liest man in einschlägigen Foren, dass diese Libs schweine-langsam sind.

3. Video-Bibliotheken
Ich hab bis heute noch keine Lib gefunden, die divx oder sonstige Formate abspielt. Das hat wohl lizenztechnische Gründe.

4. Bild-Bibliotheken
Java unterstützt nicht viele Bildformate. Man muss mal wieder mit einer weiteren Lib nachhelfen.

5. Dateiloader
Man braucht Loader für 3dmax oder sonstige Dateien und davon gibt es kaum welche. Für 3dmax gibts zwar mehrere, aber welcher davon am besten ist, wissen nichtmal die Autoren.

6. Kommerzielle Anwender wollen sich nicht in den Sourcecode schauen lassen
Also muss man den Java Bytecode durch einen Obfuscator jagen. Das Ergebnis ist zweifelhaft, denn man muss dann auf jeden Fall weitere Tests einplanen, weil der Obfuscator sich oft massiv des Name-Manglings bedient und wenn man dann einen Fehler findet, dann ist dank des Obfuscators die Fehlermeldung so komplex, dass man selber den Bug kaum findet.
Wer viel Geduld hat, wird übrigens auch mit einem obfuscierten Code (nennt man das so?) fertig und schreibt den um.
Zu Anfangszeiten von mp3 gabs ein Tool das den Fraunhofer Codec verwendet hat. Der Cracker, der das Prog zwischen hatte, der hat (trotz Assembler-Output) noch Stellen im Codec gefunden, die er verbessert hat. Unmöglich ist also nichts; auch wenn das vieleicht nur 1-2 Leute auf der Welt schaffen. (Nur das verschleierter Bytecode wesentlich einfacher zu entwirren ist als Assembler)

Diese Dinge braucht man um eine Engine zu schreiben, weitere Funktionen wie relativ komfortable Dateiarbeit, GUI und Netzwerk sind bei Java schon dabei.
Wir nähern uns übrigens inzwischen der 100MB Grenze nur für Bibliotheken (das Java-SDK eingerechnet)
Eigentlich muss man sich schon eine eigene Engine schreiben, weil es keine fertigen gibt (s.u.), aber dann erstickt man in diesem Bibliotheken-Müll von dem keiner weiß ob diese zusammengeschusterte, fette Konfiguration auf anderen Rechnern läuft.
Ich habe mal kleine Applikationen für eine Gruppe von Anwendern geschrieben. Denen musste ich erstmal mühselig verklickern, was jar-Dateien sind, dass sie sie nicht mit WinRAR öffnen sollen und dann stellte sich heraus, dass bei 95% der Anwender das Java falsch installiert war und die Programme deshalb nicht liefen. Und sowas stelle man sich mal mit 6 verschiedenen Bibliotheken bei 1000 Anwendern und 10 verschiedenen Betriebssystemen in 1000 verschiedenen Konfigurationen vor (jedes Windows-Release zählt als separates OS).
So ist es auch bei C. Es ist völlig egal, ob man SDL, DirectX oder OpenGL verwendet. Zahlreiche Features vermisst man dennoch. Man braucht eine Bibliothekensammlung, die wirklich alles abdeckt. Am besten direkt aus einer Hand und ohne *Kompatibilitätsprobleme*. Je mehr verschiedene Produkte man benutzt, desto mehr Support von verschiedenen Stellen braucht man auch.

Oder man fängt echt bei Adam und Eva an und baut sich ein komplett eigenes SDK aus komplett eigenen Grafik-, Sound-, Loader-, Video-Bibliotheken und dann ein Spiel das darauf basiert.
Wenn man zu viel Zeit und Geld hat, kann man das machen, die Entwicklungszeit verdoppelt sich mindestens dadurch, verdreifacht sich wohl eher.
Dann hat man auch wieder Plattformunabhängigkeit, denn die meisten dieser Libs gibt es in Wirklichkeit nur für 1-2 Betriebssysteme.

Wer das nicht kann oder will, greift vielleicht auf ein fertiges Spiele-SDK zurück:
Ich habe nur 2 SDKs für Java gefunden: davon war eines GPL und kein Stück dokumentiert (das eignet sich nicht fü kommerzielle Programme und man muss sich zu lange einarbeiten), an das andere kann ich mich jetzt nicht mehr erinnern, aber doll war es auch nicht.
Dann gibts noch 1-2 kommerzielle Engines, aber die kann sich keiner leisten (höchstens Firmen) und so ganz feature-reich sind die auch nicht.

Fazit: Die Sprache an sich ist toll. Man kann schöne Anwendungs-Programme schreiben und diese sogar mit dem einen oder anderen komplexen multimedialen Feature anreichern, aber wenn man ein aufwendiges Spiel mit aktuellen Anforderungen (Erwartungshaltung der Kunden/des Chefs und unter Zeitdruck) schreiben will, ist man auf eigene Bibliotheken und ein dickes Budget angewiesen. In der Planung für das Spiel muss man das auch berücksichtigen; nach 2-5 Jahren hat sich schon so viel auf dem Markt getan, dass man mit etwas Pech sein ganzes SDK in die Tonne kloppen kann und das Spiel gar nicht mehr anfangen muss.


Wie gesagt, ist der Java-Ansatz von uns deshalb verworfen worden. Jetzt benutzen wir die Engine Crystalspace, die schon über 1,2 Mio LOC (Codezeilen) hat (das muss man erstmal selber machen, da sitzt man aber ein paar Jahre!), die unter der LGPL steht (auch gut für kommerzielle Anwendungen), extrem viele Features hat (das hat man alles schonmal an Zeit und Arbeit gespart), relativ gut dokumentiert ist (es reicht für erfahrene Leute um sich einzuarbeiten und um damit zu arbeiten) und sich obendrein noch komplett wie Java benutzen lässt! Die Engine ist zwar in C++ und Assembler geschrieben, hat aber Mechanismen implementiert, die wie intelligente Zeiger mit Garbadge Collection und Java-Interfaces funktionieren. Man entwickelt also abstrakt und bequem.
Im Gegensatz zu einer zusammengefrickelten Java-Lösung wie oben beschrieben, ist die Engine auch wirklich plattformunabhängig und bietet alle Features unter Windows, Linux, MacOS, BSD usw.
Außerdem - und das ist nicht zu verachten - wird sie von vielen Entwicklern weiterhin gepflegt und erweitert. Die Engine modernisiert sich also, ohne dass man dafür auch nur einen Wimpernschlag unternehmen muss:
Heute arbeitet man mit Version x und vor Release (oder während der Entwicklung) kann man auf die neuste Version der Engine umsteigen, die z.B. bessere grafische Features hat, weniger Bugs hat, vielleicht sogar mehr plattformen unterstützt. At no Costs!!
Bei einem eigenen SDK macht das kein Mensch, sofern man niemanden extra für die Engine-Entwicklung hat. Das Produkt altert schon bevor man es benutzen kann.

Die Spielefirmen haben teilweise andere Interessen; so interessiert sie die plattformunabhängigkeit nicht immer (dank Zielgruppenbestimmung und Marktanalyse) und für eine eigene Engine, die genau auf die Bedürftnisse zurechtgemacht ist, muss man auch keine Lizenzen bezahlen oder fremden Support bemühen (sofern es ihn gibt).
Wenn man längere Zeit seine Engine pflegt und Erfolge mit darauf basierenden Games landet, dann kann man sogar mit der Engine Geld verdienen (siehe Quake/Doom-Engine oder UT-Engine), weil weniger zeit/geld-reiche Firmen oder Newcomer dann ankommen und sich die Engine mehr oder weniger günstig borgen.
Weil das seine Zeit dauert und aufwendig ist, macht das auch nicht jeder (bzw KANN das auch nicht jeder um in der Oberliga mitzuspielen).
Im übrigen gehört das zum Kalkül dazu: Wenn man sagt, dass man z.B. die Doom3 Engine verwendet, dann kann man jetzt schon davon ausgehen, dass man damit ein werbeträchtiges Argument und ausreichendes Kundeninteresse gratis dazu bekommt. Da spielt das Spiel schon fast keine Rolle mehr.


So, ich hoffe mal, dass das einen tieferen Einblick in die Problematik verschafft hat.

[Lin728]

CS ist von den features her super, aber die api finde ich irgendwie bastlerhaft,

[localhost]

giebt es ein spiel das so änlich oder so ist wie cs für linux ?

[tuxipuxi]

Original geschrieben von localhost
giebt es ein spiel das so änlich oder so ist wie cs für linux ?

wenn du unter ähnlich einen shooter verstehst, ja. ut2003, quake und enemy territory.

gruss,
tuxipuxi.

[Lin728]

CS != Counterstrike....

CS steht für CrystalSpace einer leistungsfähigen C++-3D-OpenGL engine

[anda_skoa]

Original geschrieben von SeeksTheMoon
Früher hat man auch gesagt, C wäre viel zu langsam, nur Assemblerprogramme wären richtig gut. Bullshit, wie man heute sieht.

Wobei in bestimmten Gebieten immer noch Assembler eingesetzt wird.
DSP Codecs zum Beispiel.
Aber der Trend ist dort auch, dass man solche Module praktisch vom Hersteller des DSP kauft, bzw von einer darauf spezialisierten Drittfirma.



alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden.

Sind wir ein kleiner Freeloader, hmm? :D



1. Man hat für 3D-Grafik die Wahl zwischen GL4Java und Java3D.

Hat schon jemand Erfahrungen mit den neuen GL Bindings von SGI (falls es die schon gibt)?



b) Die Plattformunabhängigkeit ist im Ar..., weil: J3D gibts nur für Windows und Solaris (wer benutzt Solaris?), die Linuxversion hinkt ein Stück hinterher und wird von Sun nicht supported. Eine Mac-Version gibts überhaupt nicht!

Sun ist leider sehr gut darin, sich selbst in den Fuß zu schiessen.
Das "böse" Linux wurde bewußt vernachlässigt, was keine so gute Idee war, weil dort doch viele Entwickler unterwegs sind und dadurch Java nicht gerade guten Ruf in der Zielgruppe bekommen hat.

Ein ähnliches Stiefkind bei den APIs ist das Java Media Framework.
Rick Ross, der JavaLobby Gründer schimpft da öfter :)



c) Wie bei allen Libs, muss man dieses Paket vom Anwender installieren lassen.

Nunja, das dürfte bei allen Sprachen so sein.



3. Video-Bibliotheken
Ich hab bis heute noch keine Lib gefunden, die divx oder sonstige Formate abspielt. Das hat wohl lizenztechnische Gründe.

Dazu muss man ein paar Postings von Rick Ross lesen :)
Eine der Ausweichlösungen die auch von ihm benutzt wird, ist eine Quicktime Bibliothek für Java, allerdings geht die wieder nicht unter Linux.



6. Kommerzielle Anwender wollen sich nicht in den Sourcecode schauen lassen
Also muss man den Java Bytecode durch einen Obfuscator jagen.

Diese ganze Obfusicator Sache ist mir immer höchstens suspekt.
Bei Bedarf kann man auch echten Maschinencode reverse-egninieeren, besser wäre es, die interessante Teile an Interessierte unter günstigen Konditionen zu lizensieren.


Eigentlich muss man sich schon eine eigene Engine schreiben, weil es keine fertigen gibt (s.u.), aber dann erstickt man in diesem Bibliotheken-Müll von dem keiner weiß ob diese zusammengeschusterte, fette Konfiguration auf anderen Rechnern läuft.


Wenn es etwas nicht gibt, aber Nachfrage danach besteht, nennt man das eine Marktlücke :)



Man braucht eine Bibliothekensammlung, die wirklich alles abdeckt.
Deswegen gibt es auch im Fahrwasser der Spieleindustrie eine große Anzahl von Bibliothekerzeugern, die dann Engines, Sounds- und Videobibliotheken machen.
Praktisch keine Spielefirma macht die selbst, das ist in Anbetracht von Time-To-Market keine gangbare Lösung.

Teilweise gibt es da aber große Kommunikationsschwierigkeiten, besondern was Angebot und Nachfrage betrifft.
Einige erinnern sich sicher an das Never Winter Nights Debakel, wo die Spiele Firma wochenlang nach einer Linux Alternative für ihre Soundlib gesucht hat, bis der Hersteller durch as Medienecho drauf gekommen ist und die Firma draufhinwies, dass es ohnehin auch eine Linuxversion gäbe.



Oder man fängt echt bei Adam und Eva an und baut sich ein komplett eigenes SDK aus komplett eigenen Grafik-, Sound-, Loader-, Video-Bibliotheken und dann ein Spiel das darauf basiert.

Gibt es eigentlich eine Java API zu SDL?



Die Spielefirmen haben teilweise andere Interessen; so interessiert sie die plattformunabhängigkeit nicht immer (dank Zielgruppenbestimmung und Marktanalyse)

Das ist glaub ich nicht so richtig, je nach Genre sind die Firmen durchaus daran interessiert, das Spiel auch auf diversen Konsolen anbieten zu können, bzw. einen Konsolentitel auch auf PCs.



und für eine eigene Engine, die genau auf die Bedürftnisse zurechtgemacht ist, muss man auch keine Lizenzen bezahlen oder fremden Support bemühen (sofern es ihn gibt).

Wobei man hier sieht, dass das zweite offensichtlich der bevorzugte Weg ist.

Ciao,
_

[Lin728]

alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden.

Hmm............

[SeeksTheMoon]

Eine Java - SDL Kopplung gabs glaub ich nicht; wär aber sicherlich ne gute Sache.

ich finde sowas ist irgendwie nutznieserisch. Alles gratis haben wollen, aber dann closed source entwickeln
Klar ist es das, aber wer versucht sich ein Standbein zu schaffen und kein oder wenig Kapital hat, der braucht sowas schon.
Softwareentwicklung wäre sonst auch nur ein Privileg für die, die schon fest im Sattel sitzen.

Bevor ich anderen mit freier Software helfen kann, muss ich erstmal selber was verdienen, damit ich was zu fressen habe und durch den Winter komme.
Den Überschuß kann man dann teilen. Meiner Meinung nach hört sich das vernünftig an.
Solange wir nicht in einer Welt wie bei Startrek leben, geht es nicht anders (außer man macht die Projekte nebenher, aber dann kann man es sich eh leisten sie freizugeben).

Deshalb bin ich auch der Ansicht, dass manche Firmen diverse Programme nach gewisser Zeit freigeben sollten; besonders wenn sie sich eh schon ne goldene Nase dran verdient haben und schon die 3. oder 4. Nachfolge-Software auf den Markt schmeißen.
Sowas wie Half-Life (Teil 1 wohlgemerkt) wäre kein wilder Verlust als OpenSource; id-Software machts vor. Man kann von fast allen Games/Engines den Quellcode bekommen und am Hungertuch nagen sie deshalb trotzdem nicht.
Das ist sogar eine Art Nachwuchsförderung: Ein begeisterter Programmierer bekommt ein Spitzenprodukt, kann daran üben und produziert vielleicht sogar was gutes, das der Firma auffällt. (z.B. Half Life Gunman, o.ä)

[localhost]

quake 2 ist ein paches bei debian habe ich gesenden
giebs auch quake3 packes also um das zu spielen der clint ??

[tuxipuxi]

Original geschrieben von localhost
quake 2 ist ein paches bei debian habe ich gesenden
giebs auch quake3 packes also um das zu spielen der clint ??

nein, da quake2 kostenlos ist, und quake3 nicht.

[localhost]

giebs das auch nicht zu kaufen ??

als linux version ?

[tuxipuxi]

nein, nicht als spezielle linux version. du kannst einfach die windows version benutzen, wie das geht ist auf holarse.net zu lesen.

[localhost]

Original geschrieben von tuxipuxi
nein, nicht als spezielle linux version. du kannst einfach die windows version benutzen, wie das geht ist auf holarse.net zu lesen.

hab ich schon gelsen ausprobirt und bin gescheitert

[peschmae]

Original geschrieben von tuxipuxi
nein, nicht als spezielle linux version. du kannst einfach die windows version benutzen, wie das geht ist auf holarse.net zu lesen.

Nu, das Linux-Teil ist einfach die Engine und sonst noch ein paar Sachen. Von der Windows-Quake-Version her brauchst du dann noch die Spieldaten.

MfG Peschmä

[localhost]

das forum müsste sowas als projegt starten ein java platforum unabheniges spiel.
wie CounterStrike nur das nicht Counter gegen terros spielen sonder Linux user gegen windows user

[SeeksTheMoon]

Interessanter Vorschlag, aber bedenke:
Die komplette Engine wird schonmal 3+ Jahre dauern, das Spiel selber dauert auch nochmal 2 Jahre.
Zumal hier die meisten Leute schon irgendwie beschäftigt sein sollten und das nur nebenher machen könnten, wird es lange dauern: Prüfungen, Prüfungsvorbereitungen, berufliche Projekte und Fortbildungen, Bundeswehr/Zivildienst, .... bei den Leuten verzögern das alles.
Ein Projekt aufbauen, (qualifizierte und garantiert mitarbeitende) Mitarbeiter finden, halten, motivieren, zum Arbeiten zwingen und die Planung ausschließlich online halten, wird sicher der lustigste Teil.
Investitionen in einen ständig verfügbaren root-Server mit guter Internetanbindung, Mail, Datenbank, Webserver, (FTP-Server), SSH-Zugriff sind noch zu machen (inklusive Admin), eine Webseite fürs Publikum muss her, Kommunikations- und Planungssoftware für die Entwickler muss her, ein leistungsfähiges Versionsverwaltungssystem, ein Bugtrackungsystem, Mailinglisten, ....
Und das wichtigste: Eine *Community*, bzw eine Zielgruppe bei der das auch ankommt (und die bereit ist, in 5 Jahren ein Java-Programm zu spielen). Das Bedeutet Werbung, Werbung, Werbung und die Vorurteile niederkämpfen, die sich auch in 5 Jahren noch halten werden ("Java ist langsam")...

[localhost]

also mir nemen dan die map´s von Counterstrike die models die sound´s und sparen wie viel :-)
das wer doch schonmal was

[peschmae]

Also ich mach da mal schon sicher nicht mit. Von Spielen halte ich nicht soo viel. Age Of in Ehren, aber das wars dann auch schon.

Ausserdem will ich mir meine Freiheit nicht nehmen lassen, wann ich will das zu programmieren was ich will - so ein Projekt wird unglaublich Zeit brauchen - und das bei den nicht allzuvielen Forenmitgliedern die da mitmachen...

MfG Peschmä

[anda_skoa]

Original geschrieben von localhost
das forum müsste sowas als projegt starten ein java platforum unabheniges spiel.
wie CounterStrike nur das nicht Counter gegen terros spielen sonder Linux user gegen windows user

Naja, ist eher ein schlechtes Genre.
FP Shooter gibts schon zuviele und die meisten ohnehin auch auf Linux.

Interessanter wären IMHO eher Spiele in Richtung C&C, Warcraft, AOE.

Boson hat ja zumindest schon die Engine dafür.

Ciao,
_

[Lin728]

Ich plane jetzt schon ziemlich lange an einer neuen Version von Tuxracer, die mehr auf Action/Fun aus ist wie die 0.61er.

Also geplante Features sind Sachen wie zeitrennen, multiplayer, computergegner

Ich möchts auf jeden Fall in einer interpretierten Sprache wie Java machen, da es aber leider was Java angeht fast keine freien Implementierunge gibt, die etwas ind ieser Hinsicht zu bieten haben und außerdem JNI das Problem hat auf native Wrapper-libs angewiesen zu sein, versuche ich mich derzeit gerade ein wenig in Mono und es ist definitif besser als ich mir gedacht habe.

[tuxipuxi]

Original geschrieben von ceisserer
Grüssi!

Ich plane jetzt schon ziemlich lange an einer neuen Version von Tuxracer, die mehr auf Action/Fun aus ist wie die 0.61er.

Also geplante Features sind Sachen wie zeitrennen, multiplayer, computergegner also weniger Fischies sammeln :-)

Ich möchts auf jeden Fall in einer interpretierten Sprache wie Java machen, da es aber leider was Java angeht fast keine freien Implementierunge gibt, die etwas ind ieser Hinsicht zu bieten haben und außerdem JNI das Problem hat auf native Wrapper-libs angewiesen zu sein, versuche ich mich derzeit gerade ein wenig in Mono und es ist definitif besser als ich mir gedacht habe.

Das Hauptproblem bei mir ist hauptsächlich Zeitmangel und dass die Engine die ich verwenden will noch nicht auf Linux portiert wurde. ( axiomengine.sf.net ).

Hmm, naja, das wars eigentlich .....
Wird wahrscheinlich eh nix, aber man träumt halt doch so vor sich hin, und mein traum ist halt son Tuxracer...

lg Clemens

hi,

das wäre in der tat ziemlich geil!
ich hab auch mal die kommerzielle version auf windows gespielt, die ist auch extrem spassig.
also wenn du das projekt starten könntest, wäre das echt toll!

gruss,
tuxipuxi.

[localhost]

nur mal angenommen man würde sowas wie CounterStrike machen könnte man die map hollen oder irgenwie einbinden und die models.
Und was müsste man alles lernen also OpenGL und java denk ich mal oder bin ich mit der annahme auf dem ganz falchen weg ????

[Lin728]

Ja, mal Java das ist schon klar :)

Ab besten du probierst es mit einer Szenengraph-API oder gleich mit einer kompletten engine wie z:B. openmind, das gibt unter open-mind.sf.net .

[localhost]

Hallo
Am besten fanngen wir kleich an damit.
Wir stellen uns das am besten vor wie star Trek Raumschiff Voyager eine lange reisse mit viel gefaren. eine deep java code mission.
Da ich nicht wirglich coden kann auser html und etwas php.
Bin ich am besten der Nilix der die moral der crew aufrecht erhellt und ihr immer bei allen gefahren beisteht, wenn die ganze energie ins code und kompeliren flist und keine energie mer für die replikatoren da sind koche ich auch mal im kasino.
Am besten giebt uns Captain netzmeister janeway einen extra forumbreich zu arbeiten.
Da ich im kasino meine küche schon aufgeschlagen habe, schlage ich vor die arbeiten an java-strike im maschinen raus durzufüren.

[BLUESCREEN3D]

Wo hier alle darüber reden, dass wir doch mal eben so ein Spiel auf Niveau von großen Spielen programmieren könnten muss ich doch mal einen Link posten.

Gefunden als ich danach gesucht habe, wie ich win98 dazu bringe mit mehr als 512MB RAM zu laufen :rolleyes:



http://journal.projectjj.com/paper_pong.php



So, und jetzt programmiert erstmal ein Pong! :D

[peschmae]

Da hast du wohl etwas komische Suchbegriffe eingegeben. :D

Aber das Dokument trifft den Nagel auf den Kopf. Ist eigentlich genau meine Meinung.
Die meisten hier können Programmieren und haben Erfahrungen mit kleineren bis mittelgrossen Projekten. Kaum einer aber mit grossen Projekten, mit Games und auch nicht mit 3D-Sachen. Das Projekt ist imho viel zu ambitiös.

MfG Peschmä

[Lin728]

So gesehen stimmt es vollkommen.
Ich bin jetzt seit einem halben Jahr am 3D-Programmieren (so zwischendurch) und ich hätt mir das auch alles leichter vorgestellt...

Guten Rutsch ins neue Jahr!

[localhost]

Die crew brauch eine kleine moraliche aufbesserung.
Sehtz doch mal so, Captain janeway brauch 40 jahre um als zihl zu kommen die zeit schlagen wir doch locker.
viel leich finden wir einen code wurmloch last euch nicht hengen

[BlueJay]

So etwas macht man nicht! Java wurde einfach nicht dafür entwickelt. Java ist eine Internet-Sprache.

Na, ist das nicht Schubladendenken? Es gibt Seiten mit netten Java-Spielchen der Typs Klicki Bunti (Yahoo), das wird zur Zeit aber von Flash verdrängt. Sogar Javascript - Spielchen sind möglich, dank DOM :-)

Natürlich kann man nicht so viel damit machen wie mit C(++), das ist einfach schneller, und Projekte, die in Javascript abbrechen (ein Script verursachte ....), sind in C++ problemlos möglich.

[peschmae]

Ich finds unglaublich toll: Uralte Threads ausgraben und nicht mal mehr was schlaues dazu sagen ;)

MfG Peschmä

[BlueJay]

Ich finds unglaublich toll: Uralte Threads ausgraben und nicht mal mehr was schlaues dazu sagen ;)
MfG Peschmä

Jo, sorry aber ein Newbie hat sich mit der Jahreszahl vertan.
Aber das mit den Schubladenkastendenken stimmt leider.

Spiele kann man mit fast jeder Programmiersprache schreiben, sobald es eine passende Anbindung an die HW (Bibliothek) gibt.

Und als auch-Windows-Benutzer muss ich sagen, dass der IE6 ein ziemlich gutes User-Interface (für Javascript) abgibt, und das schon seit mindestens anno 1998! Paradiesisch wurde es, als große Teile des DOM1 unterstützt wurden.
Der NN4 mit "DOM0" war auch ganz brauchbar, aber die neuesten Mozilla-Versionen sind, was Bildschirmdarstellung angeht, ein bisschen lahm geworden.

Und wenn es schon gelingt, mit Javascript interessante Spiele zu schreiben, wird es mit Java IMHO noch einfacher sein, obwohl der neueste Trend natürlich in Richtung Flash geht.

btw.
Wenn es dir nicht passt, dass der Thread weitergeführt wird, mach ihn zu.

[peschmae]

Aber das mit den Schubladenkastendenken stimmt leider.

Da hast du recht.
Aber ich halte schon einiges von "die richtige Programmiersprache für den Zweck" - und da brauchst du halt etwas Schubladen. Zweifellos kann man auch in Bash-Script ein Spiel schreiben, aber ob das das beste ist?



Der NN4 mit "DOM0" war auch ganz brauchbar, aber die neuesten Mozilla-Versionen sind, was Bildschirmdarstellung angeht, ein bisschen lahm geworden.


Ich hatte eher das Gefühl die älteren Mozillas seinen langsamer gewesen. Oder meinst du Mozilla und Netscape > 4.7 im allgemeinen?



Und wenn es schon gelingt, mit Javascript interessante Spiele zu schreiben, wird es mit Java IMHO noch einfacher sein, obwohl der neueste Trend natürlich in Richtung Flash geht.

Flash suckt. Jetzt nicht aus Entwicklersicht - das kenne ich - aber aus meiner subjektiven Sicht:
Ein proprietäres Plugin das sämtliche verfügbaren Ressourcen frisst und eine Programmier(sprache/umgebung) die noch weniger offen ist als Java (da gibts wenigstens ein Standardkomitee und einige brauchbare freie Implementierungen).



btw.
Wenn es dir nicht passt, dass der Thread weitergeführt wird, mach ihn zu.

Ich bin kein Mod. Kein Problem nur könntest du zu wohl jedem uralten Thread so etwas hinschreiben wie dus bei dem gemacht hast ;)

MfG Peschmä

[BlueJay]

Zweifellos kann man auch in Bash-Script ein Spiel schreiben, aber ob das das beste ist?


Mastermind nicht gerade in bash, sondern als Batch kam seinerzeit sehr gut an :) (1978)



Ich hatte eher das Gefühl die älteren Mozillas seinen langsamer gewesen. Oder meinst du Mozilla und Netscape > 4.7 im allgemeinen?

Netscape 4.7 mit Original-Netscape-Layer gab echt flotte Sprites ab (Win98, Win2000). Mozilla hing etwas nach. Eine einzige Version konnte dem NN4.7 das Wasser reichen: die Alpha 1.4, danach schneckte es von Version zu Version immer schlimmer (bezogen auf DIV-Sprites). Statt sich beim Refresh auf das übergeordnete DIV zu beschränken, hat der spätere Mozilla wohl immer das ganze Window mit allen Gadgets und Widgets refresht. Nagel mich bitte nicht darauf fest, die Info kommt von einem Mozilla-Profi.



Flash suckt. Jetzt nicht aus Entwicklersicht - das kenne ich - aber aus meiner subjektiven Sicht:
Ein proprietäres Plugin das sämtliche verfügbaren Ressourcen frisst...

Aus diesem Grund mag ich es auch nicht besonders, aber es gibt da so einige Sachen, schau mal auf http://www.parapluesch.de, mein absolutes Lieblingsflashspiel.

so long

[peschmae]

Ausnahmsweise was was sogar mit meinem Freien Flashplugin geht :)

MfG Peschmä

[localhost]

Nach viel viel lesen bin ich zu dem schluss gekomme dan c++ und opengl doch das richtig weren.
Also nur vür ein linux game

[Lin728]

..............................