GamezWorld.de - Forum
Von Spielern für Spieler
Du bist nicht angemeldet.
Seiten: 1
Hallo.
Ich bin grosser Mad News Fan und spiele das Original selbst heute noch regelmäßig.
Umso erfreuter war ich zu sehen das es bestrebungen gibt dieses Spiel in die heutige zeit zu transportieren.
Ich habe selbst schon mit dem Gedanken gespielt es neu zu programmieren.
Mir ist klar das dies ein Hobbyprojekt ist, gegen konstruktive Kritik habt ihr ja aber sicher nichts, oder ?
Ich bin selbst professioneller Softwareentwickler. Umso mehr gestatte ich mir die Bemerkung das ihr
mit der Umsetzung eures Spiels wohl Schiffbruch erleiden werdet da ihr bereits zu beginn eklatante Fehler begangen habt.
Gerade die Konzeptionelle Phase scheint mir etwas dürftig, die Art und Weise wie heutzutage Software entwickelt werden sollte scheint euch nicht bekannt zu sein. Sich hinzusetzen und einfach mal drauf los zu hacken ist ein großer Fehler.
Das Ergebnis wird sein das ihr, je weiter das Projekt fortschreitet, mehr und mehr am rumfrickeln sein werdet.
Bemerkt habt ihr das ja selbst schon wie ich gelesen habe, so das ihr euren ersten Prototypen gleich mal eingestampft und wieder von vorne angefangen habt. Ob das mit eurer neuen Version besser wird bezweifle ich. Wenn ich sehe wie lange daran schon nicht mehr gearbeitet wird habe ich das Gefühl das ihr bereits jetzt auch schon wieder keinen Durchblick mehr mit eurem Code habt. Habt ihr schonmal ein Spiel programmiert ? Also richtig, bis zum Schluss ?.
-Ihr habt euch m.E. viel zu viel vorgenommen. Ziel hätte es sein müssen, das Originalspiel erstmal ziemlich 1:1 umzusetzen. Ihr versucht aber bereits direkt, jede Menge neuerungen reinmzustopfen. Solche Neuerungen hätte man, ein vernüftiges konzeptionelles objektorientiertes konzept vorausgesetzt, nach der 1:1 umsetzung stück für stück einführen können.
-Ihr habt anscheinend mit der Grafik angefangen und dann das Spiel drumrum gebaut. Das ist falsch. Die Grafik hättet ihr euch bis zum schluss aufheben sollen. Ihr hättet das Spiel erstmal so entwickeln sollen das es auch ohne Grafik funktioniert, bzw mit Hilfsgrafiken oder Platzhaltern arbeiten sollen.
Das Ende vom Lied ist, das ihr jede Menge arbeit in etwas investiert habt was bereits jetzt schon wieder vollständig von der technischen Entwicklung überholt worden ist. Oder ist 800*600 Grafik heute noch zeitgemäß ?
-Gibt es den original Sourcecode irgendwo ? Falls nicht, ist euch mal die idee gekommen den originalcode zu dekompilieren um zu sehen wie z.B. Einschaltquoten berechnet werden usw ? Das spart Zeit. Sollte jemand den original quellcode haben bitte mir mal bescheid geben.
-Sehr unübersichtlich finde ich die Zahlenangaben. Ihr solltet prinzipiel mit . arbeiten, also lieber 200.000 anstelle 200000. Außerdem wird z.b. in den Werbeblöcken mit Hunderttausend gerechnet, die Einschaltquoten aber sind z.b. 0.34 Mio.
Das macht es oft schwer schnell zu erkennen ob die Quote für den Werbespot reicht. Hier solltet ihr euch ein einheitliches System überlegen das konsequent überall umgesetzt wird, also z.b. generell x.xx Mio oder x.xx Tsd benutzen.
-Weiter unübersichtlich sind die Werbeblöcke da die % Angabe der Zuschaueranzahl fehlt gemessen an der maximalen Zuschauerreichweite. Ich kann also nicht erkennen ob 2000000 Zuschauer viel sind oder nicht wenn mir nicht angezeigt wird ob das 5% oder 50% Einschaltquote bedeutet. (Eine der wichtigsten Funktionen überhaupt)
-Versucht, verschlimmbesserungen so weit wie möglich zu vermeiden. Das ist leicht gesagt. Versucht, die Stärken des Originals beizubehalten (das heisst, ihr müsst erstmal analysieren was eurer Meinung nach die Stärken sind) und die Schwächen zu eleminieren. Aber wie gesagt, das eleminieren der Schwächen sollte erst nach der 1:1 umsetzung erfolgen, wobei leichte und logische Dinge auch direkt umgesetzt werden können.
Beispiel Verschlimmbesserung: Ein 24 Stunden Programm. Was glaubt ihr wieviel arbeit das ist jeden Tag 24 Stunden Programm zusammenzustellen, inkl. Werbeblöcke, Nachrichten usw. Das würde nach kürzester Zeit nerven.
Beispiel Verbesserung: Ein Nachrichtenredakteuer (der Geld kostet) aber automatisch die neusten Nachrichten produziert.
Das ist erstmal das was mir so in den ersten Minuten aufgefallen ist. Mag sein das ich euch hie und da unrecht tue, ich kenne schliesslich eure Art der Softwareentwicklung nicht, denke aber das ich gefühlsmäßig richtig liege.
Vielleicht bekommt ihr ja noch die Kurve, ich wünsche es euch jedenfalls. Scheut euch auch nicht, erneut komplett von vorne anzufangen wenn ihr merkt das ihr euren eigenen Code nicht mehr versteht. Aber lernt draus und versucht Fehler der vorherigen Prototypen zu vermeiden und analysiert was schiefgegenagen ist und stellt es ab.
Eines solltet ihr, auf jeden fall machen: Einen stoppunkt setzen ab diesem keine neuen Features mehr eingebaut werden. Wenn ihr das nicht macht werdet ihr erst recht nie fertig.
-Sehr unübersichtlich finde ich die Zahlenangaben. Ihr solltet prinzipiel mit . arbeiten, also lieber 200.000 anstelle 200000. Außerdem wird z.b. in den Werbeblöcken mit Hunderttausend gerechnet, die Einschaltquoten aber sind z.b. 0.34 Mio.
Das macht es oft schwer schnell zu erkennen ob die Quote für den Werbespot reicht. Hier solltet ihr euch ein einheitliches System überlegen das konsequent überall umgesetzt wird, also z.b. generell x.xx Mio oder x.xx Tsd benutzen.-Weiter unübersichtlich sind die Werbeblöcke da die % Angabe der Zuschaueranzahl fehlt gemessen an der maximalen Zuschauerreichweite. Ich kann also nicht erkennen ob 2000000 Zuschauer viel sind oder nicht wenn mir nicht angezeigt wird ob das 5% oder 50% Einschaltquote bedeutet. (Eine der wichtigsten Funktionen überhaupt)
Du bist gut. Erst sagen, dass Feinheiten zuletzt kommen sollten, aber dann nörgeln 
Offline
waere catty nicht - ich glaube ich haette aehnlich (etwas praegnanter ;D) zitiert...
Natuerlich hatte ich zu Beginn (als ich das mit Delphi probiert hab bis ich gemerkt hab, dass mir eher grafisches als programmiertechnisches liegt) ein paar GFX gemacht um bestimmte Innereien gleich visualisiert zu bekommen.
Zwecks "Strukturierung" und Vorplanungen: Hein hat sich da einiges an Gedanken gemacht - und das auch schriftlich festgehalten.
Anstatt wie viele Teams ein Pamphlet zu veroeffentlichen was zwar alles an Details beinhaltet, aber nichts weiter bei rauskommt, haben wir uns entschieden - bzw ich Hein dazu gedraengelt, ab und an lieber was "sichtbares" zu machen.
Wenn Du dich mit Dekompilierung auskennst, wirst Du bei einigen Teilen der DUS- und auch Osterversion erkennen, dass vieles einfach nicht freigeschalten war - bspweise weil GFX fehlte oder funktionelle weitere Bestandteile nicht implementiert waren (nicht existent aber treffendes Beispiel: Eigenproduktion - was nuetzt die ganze Verwaltung von Eigenproduktionen, wenn der Supermarkt noch nicht existiert).
Wo ich dir allerdings Recht gebe: Vielleicht waere es besser gewesen ein kleineres Spiel zu proggen - aber ich glaube dann haetten Hein und ich uns nie getroffen (da uns MadTV ja zusammengefuehrt hat und nicht der milliardste Asteroid-Klon). Und da C++ bzw C einem die Sache zwar freikonfigurierbar machen, sich aber um Error- und Exceptionhandling einen Dreck scheren, hat sich Hein halt ueberlegt, die ganze Sache lieber mit BB zu machen. Mit der Erfahrung bei C war der Grundstock, sprich das bis dahin existierende, so ziemlich schnell in BB umgesetzt. Das soll nicht heissen, dass BB besser als C waere, rein der Umstand des "schonmal gemacht" brachte einen enormen Vorteil bei der Neuerstellung.
Warum dauerts also so lange? Die letzen Monate verbrachte Hein mit Bugfixing (man kennts. man laesst 1 + 1 ausrechnen und irgendwie passierts trotzdem, dass am Ende 3 rauskommt -> man weiss nie so wirklich wo der Fehler produziert wird) was, wie in einem anderem Posting schon erwaehnt, sehr demotivierend ist.
In einer der Juliwochen ist Hein bei mir zu Besuch - bis dahin habe ich ihm schon genuegend Motivation eingebl(a)eut und er kann mir dann ein paar BB-Kleinigkeiten erklaeren, damit ihm unnoetige Arbeit abgenommen wird und er sich weiter auf die Vernetzung der Funktionen konzentrieren kann. Inwieweit dann eine neue Version kommen wird weiss ich noch nicht, ich hoffe es allerdings - diese Version sollte dann zumindest den Mehrspielermodus bieten, der zwar sicher noch auf Eigenproduktionen verzichten wird, aber ansonsten alle notwendigen Funktionen besitzt.
Dabei werden dann natuerlich gerundete Werte und Tausendertrenner immernoch nicht implementiert sein - mit dem einfachen Grund, dass die richtigen Zahlen ja noch zu finden sind.
Achja...zur Aufloesung... Nun, zu "Beginn" der Entwicklung hatte ich die Moeglichkeit die Sache mit 1024x768 oder halt 800x600 zu machen... Ich hatte mich schon alleine aus "Retrogruenden" fuer die geringe Aufloesung entschieden. Hinzu kam spaeter noch die Auffassung von Hein, dass TVG am Ende auch auf seinem 500er laufen sollte. Dass mittlerweile vielleicht 2-300MHz mehr noetig sind mag OK sein, eine Highend-GraKa hingegen wird keiner benoetigen. Ausserdem ist so ein Fenstermodus moeglich - und man mag es nicht glauben - aber es sind nicht wenige die gern im Fenster spielen um nebenbei noch per IM zu chatten.
Hoffe auf nette Antwort ;D,
bye Ron
ps: Fuer wen entwickelst Du und was entwickelst Du? Spiele? Anwendungen?
Offline
>dann haetten Hein und ich uns nie getroffen (da uns MadTV ja zusammengefuehrt hat und nicht der milliardste Asteroid->Klon)
Naja, wie wäre es halt einfach mal mit einer 1:1 Umsetzung ? Dabei hättet ihr viel gelernt und das dann für eine erweiterte Version nutzen können. So ist halt die Gefahr das ihr euch einfach zu viel vor genommen habt.
Errechnet einfach mal für jedes Feature wieviele Tage daran jemand programmieren muss bis es läuft.
Aber warum sollen Hobbyprojekte auch anderst laufen als profiprojekte in der Wirtschaft ? Auch da werden viele Projekte nach jahrelangem Coding eingestampft.
>Und da C++ bzw C einem die Sache zwar freikonfigurierbar machen, sich aber um Error- und Exceptionhandling einen Dreck >scheren, hat sich Hein halt ueberlegt, die ganze Sache lieber mit BB zu machen.
Das ist vollkommen ok. Man sollte sich die Programmiersprache suchen die zum Projekt passt und nicht, weil sie 'in' ist.
Blitzbasic kenne ich nicht. Ich selbst programmiere in Smalltalk, Java und PHP. Eine objektorientierte Spiele-Programmiersprache hielte ich persönlich für besser. In der vorletzen c't war ein bericht über diverse spielesprachen drin wenn ich mich recht erinnere.
>Das soll nicht heissen, dass BB besser als C waere, rein der Umstand des "schonmal gemacht" brachte einen enormen >Vorteil bei der Neuerstellung.
Wie gesagt, die Programmiersprache ist die beste die zum Projekt passt. Es interessiert nicht ob z.b. C++ besser als Java ist, abgesehen davon das man das pauschal gar nicht ermitteln kann. Gerade für Spieleprojekte gibt es ja zum teil eigene Sprachen die viel besser geeignet sind (z.b. gamestudio/C-Script für 3D, BB sicher auch) schnell interessante Dinge zu machen und sich wie du selbst sagst nicht um Exceptionhandling, Garbage Collections oder ähnliches kümmern zu müssen.
>man weiss nie so wirklich wo der Fehler produziert wird) was, wie in einem anderem Posting schon erwaehnt, sehr >demotivierend ist.
Mmh, das kenne ich, kann man aber zum teil vermeiden indem man sich an strenge coding-richtlinen hält. Beispiel Variableninitialisierung oder Typisierung, 'sprechende' methodennamen damit man auch nach 3 Monaten noch weiss was da gemacht wird. Auch ein beliebter fehler sind variablennamen wie 't' oder 'xy' bzw die Angewohnheit Variablennamen möglichst kurz zu halten weil man die ja dann nicht viel tippen muss. Schwerer Fehler. Besser aussagekräftige namen wählen, z.b. 'einschaltquote' anstelle 'eq'. Das macht das bugfixing auch nach Monaten deutlich leichter.
Auch globale variablen möglichst vermeiden, bzw nie direkt im code setzen sondern setmethoden verwenden.
Beispiel: Anstelle 'einschaltequote = 10' sowas wie (in pseudocode):
'call setzeEinschaltquote(10)'.
'function setzeEinschaltquote(einWert) { einschaltquote = einWert; }'
Egal wo im code man nun die einschaltquote setzt, man ruft immer setEinschaltequote auf.
Vorteil: 1 (EINE) Stelle in der die variable gesetzt werden kann. Logging und Debugging macht das deutlich einfacher.
Gerade Basic verführt zu spagetticode. Hier zählt eiserne Disziplin.
>diese Version sollte dann zumindest den Mehrspielermodus bieten
Wäre es nicht sinnvoller den Mehrspielmodus hintenan zu stellen ?
Ich meine, teilt einfach mal alle features die ihr machen wollt in 3 kategorien auf:
-'must/muss sein' = Das muss in die version unbedingt rein.
-'nice to have' = nett wenns drin wäre, ist aber fürs spiel nicht zwingend nötig
-'unnötig' = alles auf das man verzichten kann
Nach diesen Vorgaben geht ihr an die Arbeit und räumt mal komplett auf. Macht unbedingt ein Featurestopp. Setzt euch Ziele (sog. Milestones).
Beispiel: Der Supermarkt ist bis zum 30.9. fertig. Dann habt ihr konkrete Ziele und 'hängt' nicht mehr sinnlos rum weil niemand weiss was gemacht werden muss bzw wie viele dinge überhaupt noch gemacht werden müssen.
Plant allerdings realistisch. Nicht zu knapp aber auch nicht utopisch lange. Versucht euch auch dran zu halten, auch wenns schwer fällt. Behaltet das Ziel im Auge. Evtl. hilft es auch, regelmäßig hier betaversionen zum download anzubieten, das hält auch die community bei laune und gibt euch feedback und ein bischen 'druck'.
>Grund, dass die richtigen Zahlen ja noch zu finden sind.
Das war einfach etwas was mir spontan aufgefallen war als ich euer spiel das erste mal gestartet habe. Nix weltbewegendes aber sowas kann m.E. ein an sich gutes spiel stark abwerten. Schliesslich ist die Einschaltquote die wichtigste Nummer im ganzen Spiel.
>ass TVG am Ende auch auf seinem 500er laufen sollte.
Die Entwicklung geht ja weiter, wer hat heute noch einen 500er ? Wenn das spiel in sagen wir 2 jahren fertig sein sollte ist es eigentlich schon wieder out of date.
>Ausserdem ist so ein Fenstermodus moeglich -
Ist bei 1024 auch, oder wer hat heute noch 15 Zoll Monitor ? Aber ok, hier habt ihr eine entscheidung gefällt und das ganze auf 1024 umzustricken wäre wohl eher 'nice to have' als 'muss ein', insofern kann man es nach hinten stellen oder gleich als 'unnötig' abhaken.
>Hoffe auf nette Antwort ;D,
Hab mir Mühe gegeben, ich wollte euch ja auch nicht dumm anmachen, sondern versuchen euch zu helfen.
Wäre schade wenn ihr aufhören würdet, sieht ja bisher vielversprechend aus.
Versucht euch aber besser auf die Basics zu konzentrieren um das Spiel fertig zu bekommen bzw einen weiten Schritt nach vorne zu machen, dann kommt die Motivation von ganz allein.
Beispiel: Da coded ihr dieses Animationstool. Ist ja ganz nett, aber vertane zeit. Ob da jetzt 1 Person durchs treppenhaus läuft oder 10 ist erstmal egal. Zuviele nebenkriegsschauplätze. Back to the Basics.
Zwecks Animationstool... das ist von mir (Hein hatte nix damit zu tun ;D), und ich habe bei TVG nichts direkt mit der Programmierung zu tun... da ich aber wenigstens ein wenig Delphi kann - und die graphische Darstellung innerhalb von TVG ja doch irgendwo auch mit mir zusammenhaengt (sprich Animationstiming, Spritedelay usw.), habe ich das ganze halt mal schnell gemacht - da es auch fuer mich praktischer war, neuhinzugefuegte Sprites (also in dem Moment "Bewegungsabschnitte" der Figuren) in ihrer Wirkung kontrollieren zu koennen.
kurz zur C't: da wurden "kommerzielle" Engines getestet mit denen sich vorrangig 3D-Spiele (sprich Klientel: Shooterfans) entwickeln lassen - war also nix richtiges fuer uns 2D-Junkies dabei ;D
Zu den Variablen ... naja ich kenn x und y genauso wie i und j immer nur aus den klassischen for schleifen ;D ... Hein setzt eh schon entsprechend wiedererkennbare Codeschreibweisen ein:
Function getRandomContractFromDatabase.CommercialContract()
...
Function createNewsblock.Newsblock(number, newstype, parent.Rectangle)
... usw usw.Es ist also ueberschaubar, was welche Funktion macht und was sie zurueckgibt. Dass man Funktionen nutzt um globaler und schneller Aenderungen an Berechnungen usw. zu machen - sowas weiss ja gar ich hehe.
Zur Aufloesung: nun ich sitz hier zwar an nem 17"er und hab daneben noch einen ... aber naja ;D die Aufloesung ist dennoch bei 1024x768... ist bequemer zu lesen und andernfalls sehen die meissten Webseiten ja eh bescheiden aus. Zum 500er... Nun, viele haben nen Zweit- oder Drittpc herumstehen - und dann kann man da ne schoene kleine TVG-Lan machen ;D
Vorrangiges Ziel von TVG war und ist es ja, ein MadTV mit neuen Daten und Mehrspieler zu machen. Das dabei natuerlich kleinere Aenderungen stattfinden ist klar. Dies ist allerdings auch notwendig, da ein menschlicher Spieler anders agiert als ein computergesteuerter.
Was ich letztens noch vergessen hatte: die 24h-Planung - natuerlich ist es ein Mehraufwand - und die Einschraenkung auf weniger Stunden ist "default" ja eh geplant - nur gibt es diese Moeglichkeit fuer Leuts mit mehr Realitaetsanspruch (24h senden - nicht 24h im Hochhaus herumlaufen ;D) halt auch noch. Inwieweit es sich dann in laengeren Spielsessions als "praktikabel" erweist, muss sich noch zeigen - es auf weniger oder mehr zu limitieren ist ja nur ein paar Handgriffe an Programmkonstanten entfernt.
Ich gebe dir aber erneut Recht: ein Schritt nach vorn erzeugt Motivation - genau diese Art von Phrasen habe ich Hein letztens mehrfach per Telefon ins Ohr gejagt ;D.
bye Ron
Offline
Dann will ich auch noch mal meinen Senf dazu geben:
Zunächst einmal danke für die konstruktive Kritik.
Mit einem Punkt hast du gar nicht so unrecht, mit der Menge, dessen, was wir uns vorgenommen haben. Als ich das ganze angefangen habe, da hatte ich tatsächlich noch nicht den richtigen Durchblick und dachte MadTV sei ein simples Spiel und innerhalb von ein paar Monaten nachprogrammiert. Das ist jetzt 3 Jahre her... Von der Menge her ist es echt wesentlich mehr, als ich mir je vorgestellt hätte.
Mangelnder Durchblick ist aber weniger das Problem, ich studiere den Kram ja und habe schon ein paar Richtlinien mit auf den Weg bekommen und auch bei Praktika das auch schon praktisch umgesetzt. Dass Variablen- und Funktionsnamen einen Bezug zu ihrem Inhalt haben müssen, ist klar.
Eine Objektorientierte Sprache ist aber kein Muss, zum einen kann man auch mit einer strukturierten Sprache objektorientiert programmieren, zwar eingeschränkt aber übersichtlich, zum anderen gibt es imho gerade in Spielen viele Situationen, in denen man ein Problem ohne OOP leichter lösen kann. Da viele Komponenten sich gegenseitig beeinflussen und aufeinander zugreifen müssen.
Dass zuerst die Grafiken da waren und dann das Spiel drumrum gebaut wurde, ist auch nicht richtig, denn zuerst war das Innenleben des Spiels da, das alles intern berechnet und die richtigen Zahlen raushaut. Nach außen hin hat das Innenleben nur ein paar Funktionen, die die Interaktion mit dem Spieler erlauben, also setzeFilmInProgramm, holeWerbevertrag, ... Die GUI wurde da drum herum gebaut und ruft die Funktionen auf.
Die Sache mit erstmal das was MadTV vorgibt umsetzen und dann alles andere nachbauen ist sogar total falsch, das kann ich so genau sagen, weil ich das zuerst so gemacht habe. In meiner C++ Version hatte ich noch 7 Stunden zur Planung im Programm und keine Netzwerkunterstützung. Aber wie ich dann überlegte, wie ich denn die Daten mit den anderen Clients aktualisieren will, merkte ich, dass man nicht einfach aus nem Singleplayer nen Multiplayer machen kann, das hat damals auch Bluebyte bei Anno1503 festgestellt. Der Sprung von verschiedenen Tagen, an denen man ein paar Stunden senden kann zu 24h Programm ist bei näherem Hinsehen ein großer, der besser von vornherein eingebaut werden sollte. Ob 24h nun sinnvoll sind oder nervig, gehört nicht hier diskutiert und ist auch schon öfters im Forum diskutiert worden.
Unsere mussts, nice to haves und unnötiges haben wir auch schon soweit definiert, aber es gibt halt ne ganze Masse an mussts, die erst mal laufen müssen. Der nächste Milestone steht auch schon fest: Lauffähige Mehrspielerversion, in der man sein Programm laufen lassen kann mit Werbung, Nachrichten und Filmen. Filmproduktion, Betty und die Terroristen müssen warten.
Wir sind uns auch durchaus der Stärken des Vorgängers bewusst, und wenn du hier im Forum bisschen liest, speziell den Threas "Ideensammlung" wirst du merken, dass wir nicht jede Idee übernommen haben oder gutheißen, eben um an den Stärken des Spiels festzuhalten. Eventuell bist du jetzt der Meinung, dass wir an den vollkommen falschen Stärken festhalten, aber das liegt in der Natur von Meinungen, jeder hat eine andere.
Gruß Michael
Stell dir vor, es ist Love Parade und niemand geht hin.
Dann kommt die Love Parade zu dir.
Offline
Einen Mehrspielermodus nachträglich reinzufrickeln wäre sicher keine gute Lösung.
Ihr hättet eine 1:1 Umsetzung machen und den Mehrspielermodus beim Design bereits im Hinterkopf behalten können,
oder aber eine 1:1 Umsetzung und anschliessend komplett neu coden.
Hört sich im ersten Moment bescheuert an, aber:
Die 1:1 Umsetzung wäre dann ein guter Test und Prototyp. Vieles davon hätte ja für den Mehrspielermodus benutzt werden können, andere
Teile hätte man komplett neu gemacht.
Wie du selbst sagst, man neigt dazu die Arbeit deutlich zu unterschätzen. Tauchen die Probleme beim coden auf merkt man das man schlecht designt
hat. Was dann ? Meist hat man viel zu viel arbeit investiert um alles umzuschmeissen. Also frickelt man meist doch rum damit es irgendwie läuft.
Aber egal, die Diskussion ist ja müssig, ihr habt ja bereits eine (falsche ) Entscheidung getroffen alles reinzupacken.
Die Wahrscheinlichkeit das das komplette Spiel aber irgendwann mal das Licht der Welt erblickt halte ich für sehr gering.
Die meisten Probleme treten schliesslich erst auf wenn ein Programm zu 90% fertig ist. Wenn ihr also glaubt das ihr bereits jetzt
Probleme habt, dann wartet mal ab, das wird noch schlimmer
Hier übrigens ein sehr gutes dokument (leider in englisch, aber leicht zu lesen) über gamedesign.
-->Linktitel: Gamedesign (Links sind aus rechtlichen Gründen nicht klickbar)
-->Link: 'http://www.garagegames.com/docs/tge/general/ch02s02.html'
(Zwar auf Torque gemünzt, aber allgemein gültig)
Seiten: 1