PureBoard

Hallo,

ich bin seit 5 Jahren leidenschaftlicher PureBasic Programmierer, und studiere Telematik an der TU Graz.

Bis jetzt habe ich meine PureBasic Projekte immer alleine durchgeführt.
Seit einiger Zeit schwebt mir die Idee von einem umfangreicherem Gemeinschaftsprojekt vor. Ich weis über Risiken solcher Projekte mittlerweise einiges, aus dem Grund möchte ich sehr organisiert vorgehen.


Spielkonzept:[Update]
Wir diskuttieren gerade das Konzept.
Derzeit sind wir bei einem multiplayerlastigen Strategiespiel, das in einer 1. Weltkrieg ähnlichen Umgebung spielt. Dabei geht es darum, um gewisse Gebiete zu kämpfen. In den Gebieten gibt es immer eine Produktion von verschiedenen Rohstoffen. Da es darauf ankommt von jeder Produktion genug zu haben, sollte man wissen, um welche Gebiete man kämpfen soll, und welche man dem Gegner schenken kann. Durch Spionage und Täuschung ergeben sich dabei ungeahnte taktische Möglichkeiten.

Gekämpft und verteidigt wird in einer eigenen Ansicht, die im Prinzip den Hauptteil des Spieles ausmacht. Hier kommt alles an Grabenkampf und Taktik zusammen, was es früher gegeben hat. Je nach Zuteilung hat man Resourcen, und Soldaten, und kann je nach Wunsch das Gebiet verteidigen, oder einen Angriff vorbereiten, oder auch den Gegner durch Bau von unbesetzten Atrappen täuschen.

Es muss aber gesagt, werden, dass wir das Konzept gerade disskuttieren.
Wer bei uns mitmacht, kann an dieser Diskussion teilnehmen.

Entwicklung:

So, jeder mit einem realistischen Blick auf die Dinge der Welt, wird jetzt schreien, dass mein Konzept viel zu Zeitaufwändig und kompliziert ist.

Ich weis natürlich, dass dieser Einwurf völlig korrekt ist. Ich finde jedoch, wenn man an das Projekt iterativ herangeht, also nach und nach Verbesserungen einbaut, kann diese Arbeit sehr motivierend sein.

Die Entwicklung bei einem Projekt dieses Ausmaßes wird wie gesagt iterativ ausfallen, und objektorientiert (wahrscheinlich mit PureObjekt).
Alleine wegen der Übersicht ist die Objektorientierte Programmierung für mich unausweichlich.

Bitte beachtet, dass es sich um ein Gemeinschaftprojekt handelt, alle meine oben beschriebenen Ideen sind nur Vorschläge.Grundsätzlich hat jeder Mitsprachrecht am Gesamtprojekt.



Jobs:


Programmierer:
-Aneignung von PureObjekt ist erforderlich
-volle Kenntniss über Objektorientierte Programmerung nur bedingt notwendig
-Programmierarbeit ist wertlos, wenn sie nicht kommentiert wird!
-Auch fortschrittenen Anfänger sind willkommen!

Projektdesigner:
Für die Zwischenversionen sind immer genaue Aufgabenstellungen zu vergeben, sowie die Grundstruktur des Programmes festzulegen.
Für diese Stelle sind erfahrene Leute notwendig, die viel Zeit in das Projekt investieren können. Englischkenntnisse wären auch vorteilhaft, da ich auch in der Englischen Community Mitglieder suchen werde.

Tester:
Für einen Reibunglosen Ablauf müssen alle Module einzeln, sowie kombiniert, auf Herz und Nieren geprüft werden.

Grafiker:
Ein Grafiker ist bereits dabei, wir suchen laufend mehr.
Die Arbeit der Grafiker beginnt aber erst in ein paar Monaten, bis dahin wird mit Dummys gearbeitet.



Bei Interesse an einen Job:
Einfach eine Email an: hplank@gmx.at

Wir bestehen derzeit aus:
1 Tester/Programmierer/Recherche
1 Programmierer / Komponist
1-2 Grafiker
1 Mädchen für alles / Projektplanung, Projektdesign


So jetzt seid ihr an der Reihe das ganze Projekt zu kommentieren, und diskutieren.

grundsätzlich möchte ich dazu anmerken:

bei der heutigen technik und der zu erwartenden entwicklung ist es nicht nötig und auch nicht sinnvoll,
einzelne 3D elemente nur dann zu rendern wenn sie sich verändert haben,
und ansonsten mit einer 2D-ISO-Engine zu arbeiten.
(so habe ich dich jedenfalls verstanden, dass du das vorhast)

du kannst auf basis vorhandener Subsysteme oder auch Engines eine eigene
Landschaft als Mesh erzeugen, anstatt das build-in terrain zu verwenden.
damit hast du die Vorteile
> -"einfacheres" Darstellen der Landschaft:
> - besseres Handling von Unebenheiten, Tunnels, etc
auch wieder drin.

zusätzlich verzichtest du auf einen fürchterlichen berechnungs-overhead,
wenn du dir das ganze in 2D geben willst.

wie frei du deine Kamera einsetzt, bleibt trotzdem dir überlassen.
ob freies drehen oder auf vier blickrichtungen festgelegt ist egal.
wenn du ein echtes ISO-feeling erzeugen willst, kannst du orthogonal rendern,
d.h. die fluchtpunkt-perspektive entfällt, es bleibt nur die ISO-perspektive.

du kannst die vorteile einer 2D-Tile-Engine in punkto
Matritzenhafte Feldberechnung (auch in bezug auf ressourcen, wegstrecken, etc)
und Athmosphäre/Style ganz ausnutzen, auch wenn du komplett über 3D gehst.

...

ich habe nichts gegen 2D, wenn man dann komplett über 2D geht.
Style, schick, einfachere Berechnungen... gut!

auch gegen on-the-fly rendern habe ich nichts,
allerdings würde ich das dann eher mit nem richtigen Raytracer machen wie POV,
dessen Core du tatsächlich mitliefern könntest,
um die Grafix für dein Game nebenbei successive zu rendern.
mit dem gedanken habe ich schon des öfteren gespielt,
aber leider braucht ein brauchbares einzelbild immer noch mehrere sekunden,
weil POV über softwareroutinen und die CPU geht
und keine Hardwarebeschleunigung nutzt/nutzen kann.

aber wenn du eine 3D engine wie OGRE, Irrlicht oder Dreamotion benutzen willst,
oder auch 'nur' openGL oder Direct3D, dann mach es gleich richtig,
und keine halben/halbherzigen sachen.

... just my

Zu deinen Vorschlägen:

Mein Ziel ist es eigentlich ein Gemeinschaftsprojekt anzugehen, in das man recht leicht einsteigen kann.
Wichtig ist für mich die Iterative Herangehensweise, bei der man das Konzept laufend erweitern kann.

Ich würde daher eher auf das 3D Rendern verzichten, als das ganze komplett in 3D anzugehen.

Das Argument, dass man es wenn schon in 3d, stimme ich voll zu. Wenn man die Objekte auf einer Landschaft im Vorhinein mit einem Renderer rendert, kommt das Ganze vermutlich schöner, als man trickst selbst "manuel" mit 3d herum, und hat dafür Lichteffekte, und evt. Schatten.

Meine neue aktualisierte Idee wäre daher, die Landschaft schon in 3D zu rendern. Das wird eh bei den meisten konventionellen 2D Spielen so gemacht. (mit vorgerenderten Tiles)

Die Objekte würden 2D in die Landschaft gezeichnet werden, wobei Sie selbst eine 3D Position in der Landschaft haben.

Hi.

Ich verstehe nicht, warum Du das Projekt einfach halten willst (zumindest für den späteren Einstieg) und dann irgendwie 2 verschiedene Renderwege gehen willst. Ich würde das viel mehr definieren. Entweder 2D (Isometrische TileEngine eingeschlossen) oder 3D.

Auch würde ich anders ansetzen. Konzept -> Idee entwickeln -> Ein spezielles Features was andere Games evtl. nicht so haben hervorheben -> dann übder die Realisierung nachdenken. Und wenn die Idee und das Konzept stimmen dann kann man durchaus auch mal eine Engine kaufen. Aber das ist dann nur die Umsetzung.

Es bringt doch nichts zu sagen, ja hier 1. Weltkrieg und Taktik. Das kennt man zuhauf und definiert noch garnichts. Und da würde ich halt ansetzen. Step by Step. Wie soll was funktionieren. Und wenn das fertig ist hat man auch einen super Überblick über die geforderten Leistungen an eine Engine (sei es nun 2D oder 3D).

Nur als kleine Anregung.

Ansonsten würde ich mich als Komponist zur Verfügung stellen ;o)

Gruss, Morty

Hallo,

von der Idee mit den 2 Renderwegen habe ich mich eh schon abbringen lassen. Reines 2D ist mit vorgerenderten Grafiken schaut vermutlich einfach besser aus.

Meine Idee war eigentlich, ein paar Anregungen zu bieten, damit einige Leute zusammenzubringen, und dann über ein vollständiges Konzept nachzudenken. Damit hat jeder das Gefühl, am Projekt teilzuhaben, und sich einzubringen. Deshalb habe ich mich oben recht kurz gehalten. Ich werde den Beitrag noch aktualisieren.

der Vorteil bei prerendered ist auch, dass dein Team nicht auf eine App angewiesen ist.
der Eine kann in Blender arbeiten, ein Zweiter in gMax und ein Dritter in POV, je nach Vorkenntnissen.
sogar mit sowas wie Google-Scetchup kann man 2D-grafix exportieren.

Solange die Grafiken simpel gehalten sind und die Shader in den 3D Programmen ähnliche Resultate erzeugen ja.

shader? wer redet hier von nem shader...?

Wenn man 3D Programme verwendet, um Grafiken zu rendern braucht man Oberflächen für die Objekte (Farben, Glanzlichter, Texturen usw. usf.). Damit diese einen bestimmten Look bekommen (z.B. Comic Look, oder metallisch usw.) benötigt man Shader dafür, wie z.B. eben einen Toonshader, oder Blinnshader, oder Phong, oder.... usw. Das gilt eben nicht nur für die Echtzeitdarstellung von 3D Objekten (OpenGL, DirectX) sondern auch für vorgerenderte Grafiken.

Man kann dem verschiedenen Look von den prerendered Grafiken insofern entgegentreten, indem man das Modelling aufteilt (Blender, XSI, Maya, 3DMax, Wings3D, u.a.) und das Shading, Lightning und Rendering einem einzelnen übergibt, damit die Resultate zusammenpassen. Jedenfalls machen wir das hier in der Videobranche so.

gekkonier hat geschrieben:... oder Phong ...

ah... das war das wort was für mich den Zusammenhang hergestellt hat.

bei POV ist das alles in den texture-definitionen, im finish,
da hab ich eben feinabstimmungs-werte für phong, specular, roughness...
neben ambient, reflection, etc.

den Begriff shader kannte ich nur in zusammenhang mit pixelmanipulation
(pixelshader, vertexshader) daher war mir der zusammenhang nicht geläufig.

die Argumentation ist einleuchtend.
in verschiedenen Apps gerenderte Modelle können derart abweichende "Atmosphäre" haben,
dass es nachher scheiße aussieht, wenn man sie in einem Game zusammenwürfelt.