Spiele-Entwicklung Wettbewerb für Jugendliche

[Xaby]

Ich bin durch Zufall bei Google auf diesen Wettbewerb gestoßen.
Er ist wohl schon abgelaufen, aber die Idee fand ich gut.

http://www.wettbewerbe.de/wettbewerb_details.php?id=179

>>> Mitmachen können alle Kinder und Jugendlichen bis 25 Jahre

Hier der Link zum Wettbewerb 2007

http://www.lebensrausch.com/content/wtt ... /index.php

Ich Frage mich, wo der von 2008 ist

Das Thema neue innovative Spiele und Spielideen wurde ja schon oft in diesem Forum diskutiert und einige Male davon auch von mir angeschnitten.


Mich interessiert heute einmal ganz besonders, welche Intention unsere jungen Mitglieder gehabt haben, PureBasic zu nutzen und in wie weit sie schon Spiele umgesetzt haben oder was sie sich für zukünftige Versionen wünschen bzw. welche Tools man noch basteln könnte.

[Vermilion]

Also ich wünsche mir eine bessere Implementierung der OGRE Engine in PureBasic, was auch wahrscheinlich bald der Fall sein wird.

Außerdem wäre ordentliches OOP auch gut.

Aber letztendlich, wenn es ein bisschen größer wird, ist PureBasic derzeit keine so gute Wahl. Ich bin derzeit auch dabei, nach C++ auszuwandern.

[STARGÅTE]

wieso sollte die Größe des Spiels entscheident sein welche Sprache man nutz ?

Ich bin mit PureBasic im derzeitigen Version vollkommen zufrieden.
Ich kann leider nichts zu dem 3D-Zeug sagen, da ich nur 2D-Programmierung machen.

[Vermilion]

Ich meine ja gerade bei richtig umfangreichen Projekten wird das Prinzip der Imperativen bzw. prozeduralen Sprachen von den Vorteilen der Objektorientierten Programmierung in den Schatten gestellt.

Es ist programmiertechnisch nicht mehr so leicht zu handhaben, weil der Quelltext schnell unübersichtlich wird und man keinen Durchblick besitzt, wenn man ein paar Wochen nicht dran gearbeitet hat oder den Quelltext schon in ein gewissen Form in die Hand gedrückt bekommen hat.

Es ist aber auch eine Frage des Geschmacks und ebenfalls der Möglichkeiten. Mit PureBasic ist zwar fast alles möglich, aber manche Wege sind so verschlungen, dass es da doch günstiger wäre lieber gleich eine andere Sprache zu benutzen, die nativ unterstützt wird bzw. die von Haus aus geeignet ist. Eine Sprache ist auch nur ein Mittel zum Zweck oder anders gesagt ein Weg ein Projekt umzusetzen. Und wenn man mal Erfolg mit einem guten Projekt hat, interessiert es höchstens die Entwickler wie und womit etwas umgesetzt wurde, die Endkonsumenten machen sich darum keinen Kopf. Die wissen höchstwahrscheinlich gar nicht mal etwas von dem Thema.

[Xaby]

@Vermilion

Ich bin derzeit auch dabei, nach C++ auszuwandern.

und

... prozeduralen Sprachen von den Vorteilen der Objektorientierten Programmierung in den Schatten gestellt.

Na ja, das ist in meinen Augen Unfug. Windows ist prozedural geschrieben und sehr umfangreich.

Aus eigener Erfahrung muss ich sagen, dass ich JAVA zum Beispiel mit seinen vielen Listenern nicht so berauschend finde. Und es lieber ebenfalls prozedural verwende.

In meinen Augen spielt es keine Rolle.

Ob ich sage, dass ich das Objekt A um einen Punkt drehen möchte oder erst sage, dass ich etwas drehen möchte und mich dann für A entscheide.

A.drehe() oder Drehe(A) ... das Resultat ist das selbe.

Wie unübersichtlich ein komplexes Programm wird, hängt doch davon ab, wie du deine Prozeduren bzw. Methoden nennst. Auf Klassen kann man auch verzichten.

System.out.prin...

oder System_out_print("")

das bleibt sich ebenfalls gleich.

Ich würde die Schuld für die Unübersichtlichkeit deiner Programme nicht auf die prozedurale Form von PureBasic abwälzen.

Du musst ja nicht alles in einer Datei schreiben. Du könntest für jedes Fenster eine eigene IncludeDatei erschaffen.

Wenn du auf Listenener stehst, kannste dir auch in eine Event-Abfrageschleife die Prozeduren Mauslistener, GadgetListener oder wie du sie nennen magst reinschreiben. Und in der Prozedur selbst dann erst auf ein Ereignis überprüfen.

Genauso kannst du dir selbst auch Prozeduren schreiben, die fast so funktionieren als hättest du Objekte. Denn PureBasic beherrscht ja auch 3D und dort gibt es ebenfalls Objekte und wenn du die FensterElemente als Objekte sehen würdest, nimmt es sich nichts.

Aber lass uns mal nicht auf ObjektOrientiert oder NichtObjektOrientiert drauf rumreiten. Ich bin der festen Überzeugung, dass du in C++ noch kein größeres Programm als mit PureBasic geschrieben hast und eine Ausrede für deine "Faulheit", was die Übersichtlichkeit angeht, suchst.

>>>>>>>

Ich gebe dir Recht, wenn du meinst, dass man bei größeren Anwendungen sich etwas mehr darüber Gedanken machen muss, wie man sein Programm strukturiert, aber ich kann mir nicht vorstellen, dass man das in C++ nicht auch muss.

Was die Erweiterung von Ogre angeht, mmm, könntest mich bei meinen PureBasic3D-Tests im Prjekt-Forum unterstützen. Das wird Ogre nicht ersetzen, aber sicherlich ne Menge Spaß machen

[ZeHa]

Na ja, das ist in meinen Augen Unfug. Windows ist prozedural geschrieben und sehr umfangreich.

Das war jetzt eigentlich schon direkt mal ein Eigentor

Aber es ist schon richtig, es gibt Software, die trotz Umfang in einer prozeduralen Sprache geschrieben wurde, aber meist wird diese dann vom Design her auch so objektorientiert wie möglich geschrieben. Und nur, daß es möglich ist, heißt noch lange nicht, daß es generell eine gute Idee ist, zumal nicht jeder so ein Programmier-As ist und bereits bei Programmen mit mehr als 10.000 Zeilen seine Probleme kriegen dürfte.

Aus eigener Erfahrung muss ich sagen, dass ich JAVA zum Beispiel mit seinen vielen Listenern nicht so berauschend finde. Und es lieber ebenfalls prozedural verwende.

Listener sind aber kein Sprachkonstrukt von Java, sondern das ist einfach nur eine Art des OO-Designs, und die hat durchaus ihren Sinn. Ein wichtiger Aspekt der OOP ist die Kapselung und Geheimhaltung. Nicht jede Klasse soll von allen anderen Klassen wissen und über sie verfügen können, und zudem soll es auch für unterschiedlichste Klassen möglich sein, auf bestimmte Events zu hören, und da ist das Listener-Konzept wirklich eine feine Sache. Hat aber nix mit Java zu tun, sondern mit OOP.

In meinen Augen spielt es keine Rolle.

Ob ich sage, dass ich das Objekt A um einen Punkt drehen möchte oder erst sage, dass ich etwas drehen möchte und mich dann für A entscheide.

A.drehe() oder Drehe(A) ... das Resultat ist das selbe.

Naja das ist nicht alles. Es kommt z.B. auch noch Vererbung dazu, und die prozedural nachzubilden ist schon 'ne Stufe komplizierter. Machbar, aber bei weitem nicht so elegant.

[Xaby]

Ich weiß doch ZeHa, deshalb auch mein Satz

Aber lass uns mal nicht auf ObjektOrientiert oder NichtObjektOrientiert drauf rumreiten.

Denn:

http://www.purebasic.fr/german/viewtopi ... hlight=oop
und
http://www.purebasic.fr/german/viewtopi ... orientiert



Was fehlt uns denn nun noch außer OOP und Ogre?
Ich glaube, ich habe noch nie 10.000 Zeilen Code geschrieben für ein Projekt. Selbst FokisA war mit allen Units zusammen nur 5.000 Zeilen groß. Turbo Pascal 7 unterstützte übrigens auch beides.
Aber nicht abschweifen, sonst wird das wieder ein Laberbeitrag

Ich denke bei größeren Projekten, wird jedem sein Programmierteil zugeteilt und anschließend über definierte Schnittstellen zusammengefügt.

Das geht mit PureBasic genauso. Es geht auch nicht drum, welche Sprache die beste ist, sondern eher darum, was sich "Kinder" und "Jugendliche" von PureBasic erhofft haben, bzw. wünschen.

(Ob da OOP der erste Ansatz ist, wage ich zu bezweifeln )

[ZeHa]

Ich glaube, ich habe noch nie 10.000 Zeilen Code geschrieben für ein Projekt.

Jo aber genau daraum ging es ja, um große Projekte und ob 10.000 Zeilen bereits als "groß" gelten, ist auch fraglich

Gloomy Nights hatte so um die 7000 Zeilen, und das war zum Teil auch etwas umständlich programmiert. Mit gescheitem OOP wäre es sogar weniger geworden

[STARGÅTE]

Das geht mit PureBasic genauso. Es geht auch nicht drum, welche Sprache die beste ist, sondern eher darum, was sich "Kinder" und "Jugendliche" von PureBasic erhofft haben, bzw. wünschen.

Mein großer Traum war es damals (als ich die ersten Zeilen in QBASIC schrieb), dass ich irgendwann mal alles das was ich in meinen Gedanken habe, was ich für Spiele schreiben möchte, auch erfüllen kann.

Mit PureBasic 3.3 hat sich das damals mehr als erfüllt, fast alles was ich "haben wollte" habe ich mit PureBasic verwirklichen können, von Kartenspielen, über 2D-Weltraumspiele, bis hin zur Echtzeitstrategie.

Mit PureBasic 4.x geht nun der Erfolg weiter, und bis jetzt bin ich noch an keine Granze gestoßen, die nicht überwindbar war.

Ich wünsche mir nur das PureBasic weiterhin seinen "eignen" Stil behält.

PS:
Im übrigen werden "große" Projekte nicht an der Anzahl der CodeZeilen gemessen, sondern an der komplexität des Spiels und dessen Inhalt, der ja von Programmierer zu Programmierer, anders geschrieben wird.

[Vermilion]

Also um nochmal kurz auf die Sache mit C++ und OOP zurückzukommen, es ist auch eher Geschmackssache und wie Xaby erkannte, ja, ich bin faul. ^^ Das heißt aber nicht, dass ich nichts tue.
Also den C-Syntax finde ich immer sehr inspirierend und der Gebrauch geschweifter Klammern ist eine grammatikalisch sehr schöne Eigenschaft jener Sprache. Also ich meine PureBasic ist einfacher von der Sprache an sich, und vor allem um einiges produktiver, denn die Kompilierungszeiten zum Debuggen lassen sich zwischen PureBasic und Visual C++ 2008 nicht vergleichen, jedoch finde ich ist C(++) stilistisch einfach "schöner". ^^ Ich liebe den Syntax... und OOP ist eigentlich voll die geile Idee, wenn man erstmal verstanden hat. Ist ja eigentlich auch gar nicht so schwer.

Nur da alles derzeit immer noch darauf hin zuläuft, dass ich Spieleentwicklung später beruflich machen werde, will ich mich jetzt schon lieber mit C++ und C# (XNA) beschäftigen, und versuche auch wenn möglich alles damit umzusetzen, ansonsten greife ich auf PureBasic zurück. Aber an PureBasic hängen auch Erinnerungen... *träum*
Mit PureBasic kann man auch einfach am besten sinnlos, nicht unbedingt produktiv rumcoden, falls einem nichts sinnvolles einfällt. Programmieren aus Spaß, aus Freude an der reinen Ausübung (als das wird in Wiki "Spiel" bezeichnet).