Archiv verlassen und diese Seite im Standarddesign anzeigen : Wollen Spiele programmieren - doch welche Sprache?
stephan17
04-03-2004, 18:56
hi !
wir sind drei jungs, 17 jahre alt, und wollen ein spiel entwickeln, das uns allen spass bringt. das spiel soll natürlich nicht was weiss ich groß sein und soll auch nur auf 2D basieren. zwei von uns haben programmiererfahrungen. ich habe qbasic und visual basic ein paar jahre benutzt und mal hier und da in c und c++ reingeschnüffelt. jetzt weiss ich leider nicht welche sprache wir verwenden sollen. es soll auf keinen fall eine komplizierte sprache sein, nicht wegen den lernaufwand, sondern einzig und allein weil das projekt wahrscheinlich daran zuerst scheitern würde; uns geht es in erster linie nicht um die geschwindigkeit. mit java würde ich nicht so gerne programmieren, da ich gehört habe, dass java in erster linie für webanwendungen geeignet ist. habe von python einiges gutes schon gehört. ausserdem gibt es ja noch pygame, python bindings, mit denen man python spiele schreiben kann.......was sagt ihr. lohnt sich python??
Hallo!
Also ich hab keine Erfahrung mit Python respektive Pygame, und den ganzen Spässen dazu, aber ich würde dir vorschlagen mal C oder gleich C++ zu lernen und dann dazu SDL (www.libsdl.org) verwenden! Damit lassen sich relativ easy und in kurzer Zeit 2D-Games erzeugen (hatt eine Space-Game mit Netzwerkunterstützung in ca. 5 Tagen [naja hab auch schon mehr Programmiererafhrung als du :P]) (wenn du willst kann ich dir den Sourcen schicken, PM an mich) ! Aber im Allgemeinen lernst du hier viele Sachen und kannst du das Game anschließend leicht erweitern!
Ich würde dir vorschlagen, mal klein einzufangen, und dich dann langsam hocharbeiten! Und wichtig ist es genau zu wissen was du willst!!!
mfG
Ich würde 2D-Games entweder in Java oder in C++ machen. Java powert Server, dekstopanwendungen, 3d-spiele etc., wieso nicht auch ein 2d-spiel?
Für C++/C spricht die große anzahl an verfügbaren Libraries und dass es sehr viele GPL_Bibliotheken gibt.
Alles was ich so gehört habe, ist pygame eine tolle Art und Weise Spiele zu schreiben. Das ist ja nur ein Wrapper über die SDL, hat aber den angenehmen Vorteil Pythons Eifnachheit und Eleganz zu haben. Ich würde es einfach mal testen.
fs111
P.S.: Python lohnt sich immer!
oracle2025
05-03-2004, 16:14
Ganz meine Meinung
--> Python hält was Java verspricht ;) *duck*
stephan17
13-03-2004, 22:11
also kann man generell sagen dass man einfach und schnell kleinere spiele in python schreiben kann?
Die Sprache Python ist super, nur hat sie nachteile, welche sie für meinen Einsatz absolut ungeeignet erscheinen lassen (aber für dich egal sein können):
* Sehr langsam. Wirklich kein Scherz, bin Java-Verwöhnt.
* Man benötigt um was anständiges machen zu können, Tonnen von Python-Wrappern welche selbst auf nativen Bibliotheken aufsetzten, somit ist die platformunabhängigkeit vorbei. Das ist meiner Meinung der Hauptnachteil. Man muss den user entweder nötigen sich die Wrapper selbst zu installieren (oder gar zu kompilieren) oder man liefert diese mit dem Spiel mit und riskiert, dass aufgrund von abi/api problemen das Spiel nur mehr auf 60-80% der Linuxkisten läuft. Unter Windows ists ganz egal.
* Etwas kleiner Funktionsumfang der "Standardbibliothek".
Was solls, jede Sprache hat Vor/Nachteile. Man muss sich für den jeweiligen Einsatzzweck das Beste heraussuchen.
SeeksTheMoon
14-03-2004, 13:48
oder ihr schnappt euch eine C++ Spieleengine wie ogre oder crystalspace. 2D-Support bieten die auch.
Für Java gibts auf sourceforge auch ein Spiele-SDK unter der GPL, das wäre eine weitere Möglichkeit.
Original geschrieben von ceisserer
* Sehr langsam. Wirklich kein Scherz, bin Java-Verwöhnt.
* Etwas kleiner Funktionsumfang der "Standardbibliothek".
stimmt so nicht,
python ist zwar langsamer als java, aber deswegen "sehr langsam" ? :rolleyes:
und auch der umfang der standardbibliothek ist mehr
als ausreichend (was soll denn da fehlen ?)
und zum thema, es gibt auch mehrere sprachen
die extra dafür gemacht worden sind, zb.
blitz basic oder dark basic (beides leider nur für windows)
beides leider komerziell aber nicht so teuer dass
man es sich nicht leisten könnte.
gruß
Arthur
Original geschrieben von ceisserer
Die Sprache Python ist super, nur hat sie nachteile, welche sie für meinen Einsatz absolut ungeeignet erscheinen lassen (aber für dich egal sein können):
* Sehr langsam. Wirklich kein Scherz, bin Java-Verwöhnt.
* Man benötigt um was anständiges machen zu können, Tonnen von Python-Wrappern welche selbst auf nativen Bibliotheken aufsetzten, somit ist die platformunabhängigkeit vorbei. Das ist meiner Meinung der Hauptnachteil. Man muss den user entweder nötigen sich die Wrapper selbst zu installieren (oder gar zu kompilieren) oder man liefert diese mit dem Spiel mit und riskiert, dass aufgrund von abi/api problemen das Spiel nur mehr auf 60-80% der Linuxkisten läuft. Unter Windows ists ganz egal.
* Etwas kleiner Funktionsumfang der "Standardbibliothek".
Was solls, jede Sprache hat Vor/Nachteile. Man muss sich für den jeweiligen Einsatzzweck das Beste heraussuchen.
lg clemens
Langsam ist Python überhaupt nicht, das ist a) meist schneller als Java, vorallem wenn man es in pyo-Bytecode kompiliert, und es skaliert um längen besser. Python ist mir noch nie mit OutOfMemory abgestürtzt, wie Java das bei großen Datenmengen tut.
Des weiteren ist die Standardbibliothek, bis auf XML, was aber ganz einfach nachzurüsten ist, sehr gut ausgerüstet. ICh kann Python nur empfehlen, und die Firma in der ich arbeite, wird die gesamte Produktion damit gemacht, und alle Tools sind in Python geschrieben (gemischte Solaris/Linux Umgebung). Java mag ich auch, ist aber längst nicht so elegant wie Python, denn in Java braucht man immer erst zig Objekte, um überhaupt irgendwas machen zu können, ich sage nur Dateien einlesen.... Alles in allem ist meiner Meinung nach Python Java überlegen, auch wenn beide ihren Reiz haben.
fs111
Für Java gibts auf sourceforge auch ein Spiele-SDK unter der GPL, das wäre eine weitere Möglichkeit.
Und die heisst? Ich hab mit game und Java leider nichts gescheites gefunden...
MfG Bischi
PS: Bin interessiert!
Original geschrieben von fs111
Langsam ist Python überhaupt nicht, das ist a) meist schneller als Java, vorallem wenn man es in pyo-Bytecode kompiliert, und es skaliert um längen besser. Python ist mir noch nie mit OutOfMemory abgestürtzt, wie Java das bei großen Datenmengen tut.
Des weiteren ist die Standardbibliothek, bis auf XML, was aber ganz einfach nachzurüsten ist, sehr gut ausgerüstet. ICh kann Python nur empfehlen, und die Firma in der ich arbeite, wird die gesamte Produktion damit gemacht, und alle Tools sind in Python geschrieben (gemischte Solaris/Linux Umgebung). Java mag ich auch, ist aber längst nicht so elegant wie Python, denn in Java braucht man immer erst zig Objekte, um überhaupt irgendwas machen zu können, ich sage nur Dateien einlesen.... Alles in allem ist meiner Meinung nach Python Java überlegen, auch wenn beide ihren Reiz haben.
fs111
python bytecode verkürzt leider nur die ladezeiten,
nicht aber die laufzeit performance
und python hat auch schon seit der version 2.0 ein
xml interface, dass zwar nicht alle features unterstützt
aber sicherlich für die meisten anwendungen ausreicht.
und um die frage welche sprache besser ist zu beantworten, meisstens die die man besser kann/kennt ;)
gruß
Arthur
OK, dann nimm für die Laufzeit eben Psyco (psyco.sf.net), damit wird noch mal ne Ecke schneller.
fs111
Das Python langsam ist, ist ganz klar, da es interpretiert wird. Der Python-Interpreter ist sicherlich einer der schnellsten Interpreter überhaupt, aber halt noch immer ein Interpreter.
Psycho ist ein wirklich guter Ansatz, aber ich sehe da noch viel mehr Potential, derzeit bringt Psycho im Schnitt 3-4x höhere Performance, der Java-Hotspot mach das ganze im Schnitt 6-10x schneller. Da lässt sich aber noch viel machen.
Was ich bei Python schade finde ist, dass sich die Authoren nicht dazu durchringen können (und in näherer Zukunft auch nicht wollen) psycho standardmäßig mit python zu verteilen, oder wenigstens einen offiziellen unstable-psycho-tree zu machen. Erkläre deinem User, dass er psycho installieren soll und du verliert 30% deiner Zielgruppe (wenns nicht gerade Entwickler sind).
Was mit skalieren gemeint ist verstehe ich zwar nicht, aber nun gut. Ich kenne keinen Python-Garbage-Collector der für multiprozessorsysteme ausgelegt ist, Python hat keine JIT, Monitoring ist bei Python langsamer usw...
Zum Thema Standardbilbiothek:
Da fehlt mir so ziemlich alles, für das ich in python bindings (mit nativen Bibliotheken) brauche. Gui, eine mächtige sound-api, platformunabhängiges drucken usw.
Bei Java fehlen mir nur standardmäßige Open-GL-Bindings sonst ist so ziemlich alles native dabei. Ebenso bei Mono.
Ein großer nachteil an Java ist meiner Meinung nach, dass es nicht GPL oder ähnlich ist. Soweit ich bei open-source projekten ohne strenge Hirarchie gesehen habe, ist das aber auch meist nicht möglich selbst derart riesengroße Standards zu implementieren ohne ein Vorbild zu haben, an dem man sich orientiert. Sonst gibt es einfach zu viele Meinungen die die Entwicklung verlangsamen. Hat man ein Vorbild (Mono, RectOS, Wine) geht das ganze ziemlich gut.
Ein gutes Beispiel ist SWING. Lange hat man SWING verflucht (mich eingeschlossen), doch nun läuft es auf meinem P4-2.6 Ghz um einiges besser als SWT, und das obwohl swing unter X im Vergleich zu Windows eher mäßig perormt.
OK, dann versuch mal bitte ein Java Programm mit mehreren Millionen Datensätzen binnen kurzer Zeit zu hantieren, oder aber XML-Dateien so um die 50 Megabyte mit XInclude zu vereinen und dann via XSLT umzuwandeln, da wirst Du sehen, wie Java alle viere von sich streckt. Python läuft auch wennn nötig mit zwei oder auch vier Gig-Speicher, bei Java muss ich die Mehrbenutzung erst mittels eines Schalters an die JVM übergeben. Python ist nicht wirklich eine interpretierte Sprache, da man mit den pyc/pyo-Dateien genau wie bei Java auch nur den Bytecode zum ausführen braucht.
Das sind alles Punkte, die IMHO Python besser machen.
Zum Thema psyco: Das ist ja auch nicht ganz trivial, immerhin muss man da ja ganz nah an den Kernel, um das benutzen zu können. Unter FC1 bspw. funktioniert es mit dem Standardkernel in der Standardkonfiguration gar nicht, weil hier ein exec-Shield drüber liegt, der die Arbeit von psyco verhindert. Wenn man den ausschaltet, geht es aber prima.
fs111
SeeksTheMoon
15-03-2004, 11:08
Original geschrieben von bischi
Und die heisst? Ich hab mit game und Java leider nichts gescheites gefunden...
MfG Bischi
PS: Bin interessiert!
http://sourceforge.net/projects/java3dgamesdk/
aber Doku gleich Null und GPL, was für eine lib nicht so toll ist. LGPL rult.
Tut mir leid, ich kanns nicht lassen.
OK, dann versuch mal bitte ein Java Programm mit mehreren Millionen Datensätzen binnen kurzer Zeit zu hantieren, oder aber XML-Dateien so um die 50 Megabyte mit XInclude zu vereinen und dann via XSLT umzuwandeln, da wirst Du sehen, wie Java alle viere von sich streckt.
Ja, Java hat ein Heap-Limit. Es gab schon diskussionen dieses von 64m zu erhöhen, da dieser Wert nicht mehr angemessen erscheint.
Python kann übrigends nicht mit mehr als 2G ram umgehen, nicht mal auf 64-bit maschienen. Naja, was solls.
Python ist nicht wirklich eine interpretierte Sprache, da man mit den pyc/pyo-Dateien genau wie bei Java auch nur den Bytecode zum ausführen braucht.
Im standardbetrieb ist Python total interpetiert. Zuerst wird der Python-Code in Python-Bytecode umgewandelt und danach erst interpretiert. Ob du jetzt die Compilier-Phase weglässt oder nicht, die bytecodes werden interpretiert.
Zum Thema psyco: Das ist ja auch nicht ganz trivial, immerhin muss man da ja ganz nah an den Kernel, um das benutzen zu können. Unter FC1 bspw. funktioniert es mit dem Standardkernel in der Standardkonfiguration gar nicht, weil hier ein exec-Shield drüber liegt, der die Arbeit von psyco verhindert. Wenn man den ausschaltet, geht es aber prima.
Drum wäre es nicht schlecht, wenn es eine distribution mit psycho gleich drinnen gäbe.
Das sind alles Punkte, die IMHO Python besser machen.
Das war ein einziges Argument, nämlich das mit dem Heap-Limit. Gut ist Geschmackssache, 64m sind aber definitif etwas wenig, ich wäre für 128m auf desktop und 256 für server-jvm.
Ich glaube du hast mich falsch verstanden. Die Sprache python finde ich an sich sehr gut und durchdacht, nur die Laufzeitumgebung ist meiner Ansicht nach (und damit meine ich meine Ansicht, deiner Ansicht nach mag sie topaktuell sein) sehr veraltet.
Gerade auf dem gebiet der interpretierten Sprachen hat es in den letzten 10 jahren sehr viel Forschung gegeben, gerade was adaptive Kompilierung und Garbage-Collection angeht.
Python ist noch eine Virtual Machine die gebaut ist, wie man eben VMs vor dieser Zeit ausgelegt hat.
Das sieht man z.B. auch bei Servern: Zope hat bei statischen Inhalten gerade mal 1/4 des Datendurchsatzes von Tomcat, bei dynamischen Inhalten wirds noch schlimmer.
Original geschrieben von ceisserer
Das sieht man z.B. auch bei Servern: Zope hat bei statischen Inhalten gerade mal 1/4 des Datendurchsatzes von Tomcat, bei dynamischen Inhalten wirds noch schlimmer.
reine neugier, woher hast du diese zahlen ?
gruß
Arthur
peschmae
15-03-2004, 15:17
@ceisserer: Meinst du parrot oder was? Parrot ist nämlich für Perl und Python und andere Scriptsprachen.
Den Heap-Limit der JVM kann man ja wenn mans braucht selber raufstellen.
The initial and maximum sizes may be specified on virtual machine start-up using the "-ms" and "-mx" flags, respectively.
Das einzige mal dass ich das benötigt habe war als ich >10'000 ArrayLists erstellt hab, viele von denen halb leer, und das trimToSize vergass :D
Die Objekte für in die ArrayList waren auch nicht gerade klein. :cool:
MfG Peschmä
oracle2025
15-03-2004, 16:08
Diese Diskussionen, welche Programmiersprache, warum "schneller" als eine andere ist, halte ich kurz gesagt für total sinnlos.
Ohne nachvollziehbare Benchmarks kann man darüber ohnehin nur Mutmaßungen anstellen.
Ich sag mal bei 80 bis 90 Prozent aller einfachen Hobbyprojekt kommt es auf Performance nicht an.
Auf einem Rechner der Ghz Generation merkt man den Unterschied am Ende eh nicht.
Drum ist auf meinem Athlon700 KDE3.1 nicht mehr zu benutzen, obwohl WinXP total flüssig läuft.
anda_skoa
15-03-2004, 19:48
Original geschrieben von ceisserer
Drum ist auf meinem Athlon700 KDE3.1 nicht mehr zu benutzen, obwohl WinXP total flüssig läuft.
Komisch, ich konnte es auf meinem P2-350 immer ohne Probleme benutzen und das bei einem miserablen IDE Kontroller,der gerade mal 6MB pro Sekunde schafft.
Daran ist das extreme Layering unter Linux schuld, mit dem supertollen X-Server.
Ah, ja. :rolleyes:
Ich gehe davon aus dass du entsprechende Profiling Daten hast, die diese Aussage untermauern.
Oder zumindest wieso das Layering unter Linux "extrem" ist und wo anders nicht.
Ciao,
_
Original geschrieben von peschmae
Den Heap-Limit der JVM kann man ja wenn mans braucht selber raufstellen.
Das ist wohl richtig, ist aber mächtiger Mist, wenn einem nach ewigen Berechnungen alles um die Ohren fliegt, nur weil der Speicher out-of-the-box begrenzt ist, und das System selber noch jede Menge hat...
fs111
peschmae
15-03-2004, 21:26
@ceisserer: Auf meinem PII266 kann ich KDE 3.1 benutzen - ist zwar eher lahm aber es geht. 3.2 ist normal schnell. XP hingegen lüpt nicht. Da kann ich Not epad (!) beim Fensteraufbau zuschauen so schwuuuuups. :eek:
Original geschrieben von fs111
Das ist wohl richtig, ist aber mächtiger Mist, wenn einem nach ewigen Berechnungen alles um die Ohren fliegt, nur weil der Speicher out-of-the-box begrenzt ist, und das System selber noch jede Menge hat...
Stimmt schon. Allerdings ist es mir lieber der hört mal auf mit Speicherfressen. Andere machen da ja einfach weiter...
Ausserdem: Bei einem entsprechenden Programm weiss man das wohl schon vorher und kanns also auch entsprechend einstellen. Allerdings sollte man das auch ganz abstellen können (kann man ja vielleicht - k.A. ist mir auch egal...)
MfG Peschmä
P.S. Gnome 2.6 Beta unter Arch ist schnell :):)
Original geschrieben von peschmae
Stimmt schon. Allerdings ist es mir lieber der hört mal auf mit Speicherfressen. Andere machen da ja einfach weiter...
Ausserdem: Bei einem entsprechenden Programm weiss man das wohl schon vorher und kanns also auch entsprechend einstellen.
Das soll mir aber egal sein können, ich will nicht erst Nachforschungen anstellen, mit wieviel Speicher ich wohl so zu rechnen habe, wenn ich anstatt 10000 1000000 Datensätze mit Berechnungen hin- und herschaufel. Das ist nicht wirklich schön in Java.
fs1111
peschmae
16-03-2004, 10:12
dann stellst du die Grenze halt hoch. Wo ist das Problem?
Ausserdem - steht schon in der Bibel was in die Richtung von: Du siehst das Sandkorn im Auge des andern und den Balken vor dem eigenen nicht :D
Egal. Ist eh JVM abhängig. :)
MfG Peschmä
SeeksTheMoon
16-03-2004, 10:57
ist das hier eigentlich ein Java-Flamewar oder wollt ihr mit stephan17 zu einer Lösung kommen? ;)
@stefan17: kannst du ein paar Anforderungen an das Spiel definieren? Dann kann man auch eher zu einer Lösung kommen.
ist das hier eigentlich ein Java-Flamewar oder wollt ihr mit stephan17 zu einer Lösung kommen? ;)
@stefan17: kannst du ein paar Anforderungen an das Spiel definieren? Dann kann man auch eher zu einer Lösung kommen.
*g* der ist glaub ich durch den python-talk ein wenig aus der Ruhe gekommen, und sicher keine Lust mehr aufs programmieren ;)
Hi!
Ich würde dir Java in Verbindung mit LWJGL empfehlen, ist schnell und
recht einfach zu bedienen. Die Basis in OpenGL ist bald einmal da und
später kannst du damit auch 3D-Spiele programmieren, was aber überhaupt
nicht schwerer ist als 2D-Spiele zu programmieren.
MfG
Wi(E)Si
EDIT:
Ach, der Link ist http://www.lwjgl.org
Foren kenn ich folgende:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL
http://puppygames.net/forums/viewforum.php?f=3
Bei Java fehlen mir nur standardmäßige Open-GL-Bindings sonst ist so ziemlich alles native dabei. Ebenso bei Mono.
Grade jetzt wo Sun Looking Glass Desktop rausgekommen ist, dürfte eigentlich jeder mal von Java3D gehört haben oder? ;) Schau dir das mal an. Das ist die Standard-Library für Java und 3D.
comrad
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.