Pascal-Spiel als Communityprojekt


Ich hab noch eine Idee: ein Adventure im Stil von Monkey Island.... da is auch Potenzial für "Nichtprogrammierer" drin, ich hab auch irgendwie gedacht das so eine Idee hier schon mal aufgetaucht ist.
 
Ziz said:
- Billiard
..
- Pin Ball:

Man könnte ja über eine Art Billiard/Pinball/Minigolf/Breakout-Hybrid nachdenken...

Mit vielen Kugeln, Gefälle und Hügeln, Löchern, verschlossenen Türen und Keys, Power-Ups...
 
Ich fände ein Rennspiel mal toll, oder einen Shooter.
Weil das Dinge sind die es noch nicht wirklich gibt.
 
Das allerwichtigste ist (und zwar ganz objektiv gesehen), dass ihr klein anfangt. So richtig klein. Streicht RPGs, Shooter, Adventures, etc. - das werdet ihr nicht auf die Beine gestellt bekommen.

Ich hab nun schon bei 3 Community-Projekten mitgemacht, aus einem davon ist was geworden (und das war als ich dazu gekommen bin schon 2 Jahre in der unstetigen Entwicklung und danach nochmal 1Jahr) und an allgemeiner Beteiligung hat es bei keinem gemangelt. Komplex waren die Spiele auch nicht, eher im Gegenteil.

Sehr wichtig ist, dass sich ein Kernteam aus Entwicklern bildet, d.h. 1-2 Coder, 2 Leute die für die Grafik zuständig sind, 1-2 für Musik und evtl. noch ein erfahrener Game-designer. Dabei müssen alle Posten besetzt sein, denn Grafik funktioniert ohne Code nicht und nur Code sieht auch nicht so toll aus. Evtl. muss man dazu mal über seinen Schatten springen und etwas Freizeit opfern, bzw als Coder Grafiken erstellen die später ersetzt werden oder als Grafiker Coden, bzw zu Coden lernen (wenn sich keiner findet), etc.
Dieses Team muss dann an einem Projekt arbeiten was alle Teammitglieder gleichermaßen begeistert und antreibt. Ob das nun als Mehrheitsentscheid in der Community entsteht oder nicht ist dabei ziemlich egal, denn wenn sich jemand nicht für ein Projekt begeistern kann, wird er nicht lange daran arbeiten bevor er die Lust verliert.

Wie man daran sieht hat das nicht mehr viel von "Community Spiel" und das ist richtig. Fakt ist einfach, dass die wenigsten hier fähige Entwickler sind (ohne einzelne Personen angreifen zu wollen) und damit so ein Projekt funktioniert braucht es nun mal Entwickler aus allen Bereichen die das Projekt vorantreiben und daran arbeiten, denn nur aus Ideen ist leider noch nicht viel entstanden.
Der Unterschied zu einem "normalen" Projekt ist nun, dass die Community gemeinsam Ideen entwickeln kann welche vom Entwicklerteam besprochen und dann evtl integriert werden.

Ein Projekt wo jeder mitarbeiten kann bzw soll sieht am Ende aus wie PandoraPanic, nicht wirklich schlecht, aber vllt auch nicht wirklich das konsistente Mega-Spiel was am Anfang jeder im Kopf hat (wobei das Minispiel-Konzept ja im Gegensatz zu allen anderen schon sehr geeignet für eine Community-Arbeit ist).

Es tut mir leid, aber das muss einfach gesagt sein, da leider viele unterschätzen wie viel Arbeit so ein Spiel ist (vor allem Vertreter wie RPGs oder alles mit vernünftiger AI oder in 3D), bzw überschätzen was durch die Community "einfach so" auf die Beine gestellt wird - oft sind es am Ende die Taten von Einzelnen die so ein Projekt stehen oder fallen lassen.

Beweist mir gerne das Gegenteil.
 
Chris_S said:
Ich hab noch eine Idee: ein Adventure im Stil von Monkey Island.... da is auch Potenzial für "Nichtprogrammierer" drin, ich hab auch irgendwie gedacht das so eine Idee hier schon mal aufgetaucht ist.
Gerade Adventures sind unglaublich komplex, keine Chance das gescheit in ein Community Projekt zu quetschen. Es gibt gute Gründe warum es kaum Open Source Adventures gibt im Vergleich zu den abertausendn Open Source Jump'n Runs oder Puzzle Spielen. ;)

Foxblock hat recht. "Keep it simple" sollte man beherzigen, damit es was wird.
 
Gerade Adventures sind unglaublich komplex, keine Chance das gescheit in ein Community Projekt zu quetschen. Es gibt gute Gründe warum es kaum Open Source Adventures gibt im Vergleich zu den abertausendn Open Source Jump'n Runs oder Puzzle Spielen. Foxblock hat recht. "Keep it simple" sollte man beherzigen, damit es was wird.

Das hab ich auch geschrieben,das ein Adventure kompkex ist,keine Frage aber es war nur eine Idee.
Bin auch für ein kleines Projekt, aber nicht umbedingt ein J'n'R....
 
Ich bin auch gegen ein Jump'n Run, davon gibts einfach schon zu viele und meine Ansprüche an ein gutes Homebrew Jump'n Run sind seit Cave Story eh gestiegen. :-D
 
Jump'n Run, Shooter
- Aufwändige Grafik wird verlangt
- wenig Logik

Billard, Pinball
- Physiksimulation
- Grafik einfach, aber nach oben offen

Adventure
- Grafik einfach, aber nach oben offen
- Logik extrem einfach (Dialog-Manager)
- Story extrem aufwändig
 
Hiess es nicht, es wird ein Spiel in 3D? Damit scheiden doch Jump´n Runs und Shooter schon so gut wie aus, wenn sich nicht ein extrem talentierter 3D-Modeller/Animator findet. Für Adventures gilt fast das Gleiche. Alleine die Hauptfigur zu entwerfen und zu animieren(in 3D!), wäre sehr zeitaufwendig, dazu kämen dann noch NPCs und Schauplätze.
 
carli said:
Jump'n Run, Shooter
- wenig Logik
Falsch, von der Engine-Logik her gehört ein Jump'n'Run immer noch zu den aufwendigsten 2D Spielen (von 3D mal ganz abzusehen). Die Physik richtig und vor allem auch Spielspaß-fördernd hinzubekommen ist nicht einfach, dazu kommen noch optionale Schwierigkeiten wie Schrägen, Rotationsphysik, Projektil-Kollisionsabfragen (bei manchen Jump'n'Runs, vor allem bei Shootern), etc.
Das ist nur der Physik-Anteil, der Rest ist sicherlich einfacher, aber vom Aufwand auch nicht zu unterschätzen. Wichtig bei einem Jump'n'Run ist ein vernünftiges Framework was es einfach macht aus einem Template schnell unterschiedliche Gegnertypen, Items oder Spieler-Zustände zu integrieren - das zähle ich jetzt im weitem Sinne einfach mal zur Logik.
carli said:
Adventure
- Logik extrem einfach (Dialog-Manager)
Ebenfalls nicht korrekt und eine typische Unterschätzung.
Ein Adventure braucht ein solides Framework und Datenverwaltung, sodass Dialoge auf einander aufbauen können, die Story sich voranbewegt und verschiedene Items evtl. einen Effekt haben (auf andere Items, auf Personen, auf Gespräche, auf Orte, auf die Story, etc.).
Dazu kommt dann noch generell das Item-System, was flexibel und dennoch einschränkend arbeiten muss (man will ja nicht jedes Item auf alles in der Welt anwenden können).
Das muss nicht nur intern in irgendwelchen Variablen liegen, sondern auch beliebig gespeichert und geladen werden können und dabei über die verschiedenen Etappen in der Entwicklung erweiterbar bleiben.
Weiterhin muss der Inhalt auch irgenwie eingebunden werden, für Grafiker und Designer am geeignetsten ist da ein speziell gestalteter Editor. Wenn man sich nun den der TheElderScrolls-Reihe anguckt sieht man evtl. was für eine Arbeit dahintersteckt (Editoren sind grundsätzlich eine Menge Arbeit).

Ich will deine Bemühungen hier nicht grundsätzlich torpedieren, aber man sollte sich im Klaren sein, was man letztendlich zu tun hat, bevor man anfängt. Ich versuche lediglich ein paar Warnungen auszusprechen, damit das Spiel nicht, wie so oft, nach viel Arbeit doch nicht fertig wird (habe ich selber oft genug erlebt).

Ich begrüße die Entschlossenheit die ihr an den Tag legt und wünsche euch alles Gute für das Projekt.
 
So,

Ich hab einfach mal angefangen und die grundlegendsten Dinge implementiert: Eingabe/Ausgabe-Verwaltung mit Tastatureingabe und eine rudimentäre Grafikengine, die Sprites und Text auf den Bildschirm zeichnen kann.
Demnächst werd ich mich an den Model Loader und die 3D-Projektion kümmern. Bis das so weit ist, können wir uns ja noch einigen, welchen Spielinhalt wir dann reinstecken.

Für alle, die mitarbeiten wollen (Grafiken, Modelle, Code, Wiki-Einträge) haben wir hier das Repository:
https://bitbucket.org/carli/communityproject
Am besten erstellt ihr einfach Forks und schickt mir Pull Requests.

Zum Kompilieren braucht ihr FPC und entweder eine fertig kompilierte eglport.o oder die C++ Development Tools. Kompiliert wird mit "./build.sh", anschließend erscheint eine Datei "game" im Verzeichnis.
 
hey Cool! Ich schau mir das Alles morgen an.Heute muss ich mir erst mal aufn Festival und bissl Kopf schütteln.
Eine weitere Idee, weis aber nicht wie komplex die werden kann: Es gab zu DOS zeiten ein 3D-Flug/Rennspiel (ich glaub es hies Slipstream 5000 oder so) hab bis jetzt eiglt. kein Vergleichbares Spiel entdeckt.
Oder einen Klassiker: Weltraum-Action-SciFi-Uber-Baller Spiel :D ist ja vom Grundgerüst eigtl. machber und sehr Ausbaufähig
mfg
 
Technisch ist alles drin, sag ich gleich.
Und alles vom Spielinhalt nicht gerade anpassbar und erweiterbar sein muss, ist extrem schnell entwickelt. Dazu zählt auch Jump'n Run, Shooter, Flugsimulatoren, ...

generell sollte das ganze dann so modularisiert werden, dass auch wirklich jeder, der mitarbeiten will, auch etwas in seinem Schwierigkeitsgrad findet
 
Es wäre interessant zu erfahren, wie flexibel deine geplante Engine wird und wie performant. Wenn du sagst "technisch ist alles drin" dann klingt das nämlich wirklich nach viel und schürt Erwartungen. ;)
Die Erfahrung zeigt, dass Dinge wie 3D und vor allem Hardware Beschleunigung auf der Pandora oft nicht so ganz einfach zu realisieren sind, daher meine Sorgen. Welche Games sind denn eigentlich mit Pascal realisiert? Man hört da ehr wenig von.
Aber ich persönlich brauch eigentlich auch keine Super Grafik oder tolle Effekte. Das Spiel sollte nur "solide" sein, gute Steuerung, keine Lags zwischen Eingabe-Reaktion aufm Screen usw. Es gibt viele Games, die spielen sich einfach toll, unabhängig von Grafik oder dergleichen, das ist sicher nicht immereinfach zu realisieren. Der Link zu dem "Flow" Artikel war übrigens recht interessant. :) Da sind einige Punkte aufgezählt, die man auch beim Design eines Spieles berücksichtigen sollte. Dann "flutscht" das Game sicher auch gleich viel besser.
Ich bin übrigens auch dafür, dass erst mal das Grundgerüst des Spieles stabil ist, also ne solide Engine auf die man dann aufbauen kann. Manche fangen ja gleich mit der Grafik an ohne irgend was gescheits "drunter" zu haben, das wird dann natürlich nix. ^^
 
Fusion_Power said:
Es wäre interessant zu erfahren, wie flexibel deine geplante Engine wird und wie performant. Wenn du sagst "technisch ist alles drin" dann klingt das nämlich wirklich nach viel und schürt Erwartungen. ;)
Mit "technisch ist alles drin" meine ich die Turing-Mächtigkeit der Programmiersprachen. Ich bastel zwar ursprünglich hauptsächlich Engines, die auf Flexibilität ausgelegt sind, diesmal soll es aber wirklich ein Spiel sein. Zum Thema Performance will ich mich vor allem an der Hardware der Pandora orientieren und lieber dafür etwas mehr Spielgenuss reinpacken. Technisch weiß ich schon, wie man mit der Hardware nen guten Datendurchsatz hinbekommt, allerdings will ich das nicht für Grafikschlachten ausnutzen.
Fusion_Power said:
Der Link zu dem "Flow" Artikel war übrigens recht interessant. :) Da sind einige Punkte aufgezählt, die man auch beim Design eines Spieles berücksichtigen sollte. Dann "flutscht" das Game sicher auch gleich viel besser.
Ich bin übrigens auch dafür, dass erst mal das Grundgerüst des Spieles stabil ist, also ne solide Engine auf die man dann aufbauen kann. Manche fangen ja gleich mit der Grafik an ohne irgend was gescheits "drunter" zu haben, das wird dann natürlich nix. ^^

Eine Engine ist hauptsächlich Grafik.
(Außer ein bisschen Menü-Zeugs)
 
carli said:
Eine Engine ist hauptsächlich Grafik.
(Außer ein bisschen Menü-Zeugs)
Ja, ich meinte auch ehr, dass man erst mal die Engine fertig bekommt und dann die Grafiken angeht, Am Anfang kann man ja auch erst mal Platzhalter verwenden anstatt schon super detaillierte Grafiken zu basteln, noch bevor der technische Unterbau überhaupt steht. ;) Da gabs mal ein (gescheitertes) Community Projekt im engl. Forum. Unzählige Forenseiten an Diskussion über die Grafiken und die Ausrichtung des Spieles (3D Zombie Shooter oder dergleichen) und das ohne, das der technische Unterbau fertig war. Drum konnte aus dem Projekt auch nix werden weils quasi keine Engine gab aber schon ellenlange Diskussionen wie der Titel-Bildschirm des Games aussehen sollte. :D
 
Als allererstes sollte man wissen, in welche Richtung(sprich JnR, SeU, Sport oder sonstiges), es sich überhaupt entwickeln soll. Deshalb wäre es nicht schlecht eine Art Producer zu benennen, der dann auch eine Entscheidungsmacht hätte. Ich würde hierfür den Threadersteller, sprich Carli, vorschlagen. Derjenige sollte dann auch in der Lage und befugt sein, Entscheidungen durchzudrücken, auch gegen den Willen einzelner. Wenn später in dem Projekt Leute abspringen(und das wird passieren), kann wenigstens keiner behaupten, dass sich das Projekt in eine Richtung bewegt, die man nicht vorhergesehen hat.
 
So,

Ich hab nen Model Loader eingebaut, der eine Palme einliest und auf dem Bildschirm ein bisschen dreht.

Wer bloß mal schnell die Binary ansehen will (die drehende Palme), der kann sich das ganze von http://botwars.tk/communitygame.tar.gz herunterladen und anschauen (Source ist dabei)

Ansonsten empfehle ich Interessierten, sich per Mercurial (bitte informiert euch, was das ist) das Repos von https://bitbucket.org/carli/communityproject ziehen.

Nächste Baustelle:
- Vertexbuffer-Klasse optimieren (Vertexbuffers statt Vertex Arrays nutzen)
- Beleuchtung
 
Vom coden hab ich eh keine Ahnung, da kann ich nix beisteuern, Hab 2 Jahre versucht coden zu lernen aber mir fehlt echt der Draht dazu. Ich merk mir ja nicht mal die Befehle einer Programmiersprache. :-D

Ach so, ein RPG oder dergleichen brauchen wir abgesehen von der Komplexität auch wegen nem anderen Grund nicht anzugehen, denn jemand ausm engl. Forum arbeitet bereits an einem 3D RPG Dingens für die Pandora, da gibts auch schon ne kleine Tech-Demo zu:
http://boards.openpandora.org/index.php?/topic/5267-handheld-rpg-desperately-needs-an-open-source-replacement-code-monkey-for-hire/page__view__findpost__p__95817

Somit kann man sich hier voll und ganz auf die anderen Genres konzentrieren. ^^
 
Na wer käme denn jetzt in die etwas engere Auswahl, mitzubasteln?

Und das Genre... müsste auch noch beraten werden.
 
Back
Top