Samstag, 10. November 2007
Von Blöcken, Pfeilen, Farben, Koordinaten und einem Buch
semai, 00:13h
Ein herrlicher Tag muss es gewesen sein, als mir in den Sinn kam, eine Klasse zu schreiben, die ich als Grundgerüst für gaaaanz vieles brauchen kann.
Eine Klasse, die zwei VertexBuffer zur Verfügung stellen soll, in welchen ein einfarbiger Würfel gespeichert ist.
Denn wenn ich mit solchen Blocks arbeiten will, wäre es äusserst umständlich, immer alles komplett neu zu berechnen und so, vielleicht hätte es ein paar Vorteile, aber ich als One-Man-Army unter zeitdruck, habe auch schlicht und einfach weder die Zeit, das benötigte KnowHow, noch sonstwas dafür. Also müssen viele Blöcke her!
Doch halt, damals dachte ich an eine Klasse, die einen Würfel zur Verfügung stellt, ich wusste da noch nicht einmal was ein VertexBuffer ist, geschweige zu was ich ihn gebrauchen konnte.
Bevor ich mir also mehr Gedanken darüber machte, legte ich mir kurzerhand ein Buch zu (Ein dickes Lob an meine Buchhandlung, die haben mir das ganz schnell geliefert :) ), welches ich allen Neueinsteigern in MDX in C# empfehlen kann ("Managed DirectX und C#" von Jens Korenow) und lernte mal die Grundzüge, ich bin zwar nicht ganz überall einverstanden mit dem Buch aber falsch oder schlecht ist darin nichts wirklich. Nach kurzer Zeit war ich relativ ernüchtert, keine Möglichkeit gefunden zu haben, um direkt in DirectX irgendwie einen ganzen Würfel zu rendern (Darunter versteht man das auf-den-bildschirm-zeichnen von Dingen), sondern lediglich einen halben, wenn mans geschickt anstellt.
Also überlegte ich erst einmal, was muss meine Klasse können?
-2 Buffers für je einen halben Würfel
-'Umfärben' der Würfel
-Positionieren der Würfel
Nun... das ganze ging danach recht fix, weil ich genau wusste, was ich machen musste und so vom programmiertechnischen her. Nur eins war eklig: Das berechnen der Vertices, die standardmäsig bei all meinen Würfeln exakt gleich sind. Auch da, wo ich die Würfel gemäss der Mapfile erzeuge, sind alle am selben Punkt und haben diesselbe Farbe, also noch nix mit Map... lediglich die Anzahl stimmt.
In einem zweiten Druchgang konnte ich dann bequem die Würfel in einer 3fach-geschachtelten Schleife so umpositionieren, dass sie an den gewünschten Ort kamen und auch in die entsprechenden Farben umfärben.
Letztendlich habe ich aber doch einige Zeit in die Würfelklasse selbst investiert und bin wirklich froh darum, alles, was zu kommentieren war, auch kommentiert zu haben (das überflüssige natürlich ausgenommen). Ich glaube sogar es handelt sich bisher um die sauberste Klasse, die ich jemals geschrieben habe: Zwecksmässig wie auch Syntaxmässig.
Und ja, ich bin stolz auf meine kleine BlockKlasse, auch wenn sie für manchen vermutlich sinnlos erscheint, da mancheiner vielleicht bessere Ansätze kennt oder schon sehr erfahren ist, was das Programmieren betrifft. Nun, für mich ist sie alles andere als sinnlos, mir ist kein besserer Ansatz eingefallen, der so einfach realisierbar ist und ich habe bisher nicht wirklich viel Erfahrung...Aber ich werde daran festhalten.
Für die, die's genauer interessiert:blockbase (cs, 7 KB)
Eine Klasse, die zwei VertexBuffer zur Verfügung stellen soll, in welchen ein einfarbiger Würfel gespeichert ist.
Denn wenn ich mit solchen Blocks arbeiten will, wäre es äusserst umständlich, immer alles komplett neu zu berechnen und so, vielleicht hätte es ein paar Vorteile, aber ich als One-Man-Army unter zeitdruck, habe auch schlicht und einfach weder die Zeit, das benötigte KnowHow, noch sonstwas dafür. Also müssen viele Blöcke her!
Doch halt, damals dachte ich an eine Klasse, die einen Würfel zur Verfügung stellt, ich wusste da noch nicht einmal was ein VertexBuffer ist, geschweige zu was ich ihn gebrauchen konnte.
Bevor ich mir also mehr Gedanken darüber machte, legte ich mir kurzerhand ein Buch zu (Ein dickes Lob an meine Buchhandlung, die haben mir das ganz schnell geliefert :) ), welches ich allen Neueinsteigern in MDX in C# empfehlen kann ("Managed DirectX und C#" von Jens Korenow) und lernte mal die Grundzüge, ich bin zwar nicht ganz überall einverstanden mit dem Buch aber falsch oder schlecht ist darin nichts wirklich. Nach kurzer Zeit war ich relativ ernüchtert, keine Möglichkeit gefunden zu haben, um direkt in DirectX irgendwie einen ganzen Würfel zu rendern (Darunter versteht man das auf-den-bildschirm-zeichnen von Dingen), sondern lediglich einen halben, wenn mans geschickt anstellt.
Also überlegte ich erst einmal, was muss meine Klasse können?
-2 Buffers für je einen halben Würfel
-'Umfärben' der Würfel
-Positionieren der Würfel
Nun... das ganze ging danach recht fix, weil ich genau wusste, was ich machen musste und so vom programmiertechnischen her. Nur eins war eklig: Das berechnen der Vertices, die standardmäsig bei all meinen Würfeln exakt gleich sind. Auch da, wo ich die Würfel gemäss der Mapfile erzeuge, sind alle am selben Punkt und haben diesselbe Farbe, also noch nix mit Map... lediglich die Anzahl stimmt.
In einem zweiten Druchgang konnte ich dann bequem die Würfel in einer 3fach-geschachtelten Schleife so umpositionieren, dass sie an den gewünschten Ort kamen und auch in die entsprechenden Farben umfärben.
Letztendlich habe ich aber doch einige Zeit in die Würfelklasse selbst investiert und bin wirklich froh darum, alles, was zu kommentieren war, auch kommentiert zu haben (das überflüssige natürlich ausgenommen). Ich glaube sogar es handelt sich bisher um die sauberste Klasse, die ich jemals geschrieben habe: Zwecksmässig wie auch Syntaxmässig.
Und ja, ich bin stolz auf meine kleine BlockKlasse, auch wenn sie für manchen vermutlich sinnlos erscheint, da mancheiner vielleicht bessere Ansätze kennt oder schon sehr erfahren ist, was das Programmieren betrifft. Nun, für mich ist sie alles andere als sinnlos, mir ist kein besserer Ansatz eingefallen, der so einfach realisierbar ist und ich habe bisher nicht wirklich viel Erfahrung...Aber ich werde daran festhalten.
Für die, die's genauer interessiert:blockbase (cs, 7 KB)
... link (0 Kommentare) ... comment
und dann die Rechnerei...
semai, 23:47h
Okee... Rechnerei ist vielleicht etwas übertrieben...
Trotzdem, nachdem ich alles augeschrieben hatte, war klar, dass ich etwas BlockOrientiertes machen wollte (Ich habe also eigentlich eine Welt die aus Tiles besteht, die jedoch auch in die Höhe gehen, ne Blockwelt halt)
Und dann war da die nächste grosse Frage:
Bunte Blöcke oder solche mit Texturen?
Ich entschied mich dann für erstere Variante, da ich mich zu dem Zeitpunkt immer noch nicht wirklich mit MDX auskannte und mir bewusst war, dass Texturieren immer so seine Problemchen mitbringt (einfarbige, solide Blöcke tun das zwar auch, aber das ist was anderes )
Nun gut... also... ich will ne Welt aus farbigen Klötzen...
Ich kann ja unmöglich alles hardcoden was diese Welten angeht, das wäre nicht nur unsinnig, sondern auch mit einem Riesenaufwand und massig späteren Schwierigkeiten verbunden, also musste ein Dateiformat her!
Toll... Ein Dateiformat... hmm.. was muss denn da rein? halten wir es vorerst mal möglichst schlank... ein kleiner Header von, sagen wir mal, 50 Bytes und gut ist...
die ersten 12 nahm ich für die Grössenangaben der 3 Dimensionen (1 Ganzzahl = Integer = 32BitInteger = 4 Byte) dann entschied ich mich spontan dafür, einfach mal die Farben der Blöcke speichern zu wollen, warum auch nicht? So kann ich dann entscheiden, was für nen Geländetyp ein Block hat, oder ob er überhaupt existent ist: z.B. ein grüner Block wird Wald oder Wiese verkörpern, blau wird wohl Wasser sein und Schwarz nichts, etc.
Nun... nach langer Rechnerei, wie ich die Blocks am besten speicherte, ob ich einfarbige Blöcke machten sollte oder jede Seite einzeln speichern kam ich zum Entschluss, dass ich einfarbige Blöcke speichertn will!
Mein map-file-Format ist derzeit soweit entwickelt, dass es 3 Bytes/Block benötigt, sowie die ersten 50, die den Header darstellen.
Danach kam die zweite Rechnerei... die relevanten Daten einer solchen Datei in einen 3-Dimensionalen Byte-Array zu überführen...
Das sieht nun so aus:
Mit dem gegenteiligem Problem, einem kleinen Editor für die Basiskarten, der die entsprechenden Dateien bequem speichern sollte, habe ich mich erst viiel später wirklich befasst, heute um genau zu sein, doch dazu später mehr^^'
Nachdem ich mich für das Dateiformat entschieden hatte und einen entsprechenden Parser gecodet habe, war schon mal ein grosser Schritt getan.
Trotzdem, nachdem ich alles augeschrieben hatte, war klar, dass ich etwas BlockOrientiertes machen wollte (Ich habe also eigentlich eine Welt die aus Tiles besteht, die jedoch auch in die Höhe gehen, ne Blockwelt halt)
Und dann war da die nächste grosse Frage:
Bunte Blöcke oder solche mit Texturen?
Ich entschied mich dann für erstere Variante, da ich mich zu dem Zeitpunkt immer noch nicht wirklich mit MDX auskannte und mir bewusst war, dass Texturieren immer so seine Problemchen mitbringt (einfarbige, solide Blöcke tun das zwar auch, aber das ist was anderes )
Nun gut... also... ich will ne Welt aus farbigen Klötzen...
Ich kann ja unmöglich alles hardcoden was diese Welten angeht, das wäre nicht nur unsinnig, sondern auch mit einem Riesenaufwand und massig späteren Schwierigkeiten verbunden, also musste ein Dateiformat her!
Toll... Ein Dateiformat... hmm.. was muss denn da rein? halten wir es vorerst mal möglichst schlank... ein kleiner Header von, sagen wir mal, 50 Bytes und gut ist...
die ersten 12 nahm ich für die Grössenangaben der 3 Dimensionen (1 Ganzzahl = Integer = 32BitInteger = 4 Byte) dann entschied ich mich spontan dafür, einfach mal die Farben der Blöcke speichern zu wollen, warum auch nicht? So kann ich dann entscheiden, was für nen Geländetyp ein Block hat, oder ob er überhaupt existent ist: z.B. ein grüner Block wird Wald oder Wiese verkörpern, blau wird wohl Wasser sein und Schwarz nichts, etc.
Nun... nach langer Rechnerei, wie ich die Blocks am besten speicherte, ob ich einfarbige Blöcke machten sollte oder jede Seite einzeln speichern kam ich zum Entschluss, dass ich einfarbige Blöcke speichertn will!
Mein map-file-Format ist derzeit soweit entwickelt, dass es 3 Bytes/Block benötigt, sowie die ersten 50, die den Header darstellen.
Danach kam die zweite Rechnerei... die relevanten Daten einer solchen Datei in einen 3-Dimensionalen Byte-Array zu überführen...
Das sieht nun so aus:
BinaryReader br = new BinaryReader(new FileStream(fstring, FileMode.Open, FileAccess.Read));
byte[, ,][] ret = new byte[br.ReadInt32(),br.ReadInt32(),br.ReadInt32()][];
byte[] color = new byte[3];
br.BaseStream.Position = 50;
for (int i = 0; i < ret.GetLength(0); i++)
{
for (int i2 = 0; i2 < ret.GetLength(1); i2++)
{
for (int i3 = 0; i3 < ret.GetLength(2); i3++)
{
color = br.ReadBytes(3);
ret[i, i2, i3] = color;
}
}
}
br.Close();
return ret;
Mit dem gegenteiligem Problem, einem kleinen Editor für die Basiskarten, der die entsprechenden Dateien bequem speichern sollte, habe ich mich erst viiel später wirklich befasst, heute um genau zu sein, doch dazu später mehr^^'
Nachdem ich mich für das Dateiformat entschieden hatte und einen entsprechenden Parser gecodet habe, war schon mal ein grosser Schritt getan.
... link (0 Kommentare) ... comment
Am Anfang war das Wort...
semai, 23:27h
Jup... das ist gaaanz wichtig...
Jedes kleinste Detail, dass ich geplant habe, hab ich sorgfältig ausgeschrieben aufgeschrieben und zwar von Hand... alles schön in meinem kleinen Büchlein.
Zu Beginn, war es etwas mühsam, alles so auszuschrieben, da zum Teil Listen entstanden und ich dreissigmal fast denselben Satz schreiben musste mit je einem anderen Ende (z.B 'Ein charakter hat...')
Manchmal geriet ich schon in Versuchung da mit änsefüsschen abzukürzen, doch dann wurde mir wieder bewusst, dass mein Vorhaben kein Zuckerschlecken ist und ich definitiv nicht alles im letzten Moment machen kann, da so ein Spiel mehr als nur eine Nacht schwerstarbeit braucht; selbst mit wenigen Dingen... und umso länger meine Liste wurde, umso mehr hatte ich mir vorgenommen zu implementieren. Wie sollte ich aber jemals auch nur daran denken können, etwas in einem Programm gut durchdacht einbringen zu können, wenn ich ja schon zu faul gewesen wäre um es in einem kurzen Sätzchen aufzuschreiben?
Gar nicht!
Also biss ich mir auf die Zähne und schrieb Satz für Satz schön sauber zu Ende... richtig musterhaft könnte man schon fast sagen :P
Nun, ich hatte nach einer Weile eine schöne Zusammenfassung all meiner geplanten Features und ihren genauen Zusammenhängen und ich kann mich nur wiederholen: Ich bin verdammt froh, dass ich das alles aufgeschrieben habe, ansonsten wär mir das Projekt längst über den Kopf gewachsen... und zwar seehr weit! Also, falls du auch mal ein Spiel planst... immer ALLES aufschreiben, auch was selbstverständlich erscheint.
Jedes kleinste Detail, dass ich geplant habe, hab ich sorgfältig ausgeschrieben aufgeschrieben und zwar von Hand... alles schön in meinem kleinen Büchlein.
Zu Beginn, war es etwas mühsam, alles so auszuschrieben, da zum Teil Listen entstanden und ich dreissigmal fast denselben Satz schreiben musste mit je einem anderen Ende (z.B 'Ein charakter hat...')
Manchmal geriet ich schon in Versuchung da mit änsefüsschen abzukürzen, doch dann wurde mir wieder bewusst, dass mein Vorhaben kein Zuckerschlecken ist und ich definitiv nicht alles im letzten Moment machen kann, da so ein Spiel mehr als nur eine Nacht schwerstarbeit braucht; selbst mit wenigen Dingen... und umso länger meine Liste wurde, umso mehr hatte ich mir vorgenommen zu implementieren. Wie sollte ich aber jemals auch nur daran denken können, etwas in einem Programm gut durchdacht einbringen zu können, wenn ich ja schon zu faul gewesen wäre um es in einem kurzen Sätzchen aufzuschreiben?
Gar nicht!
Also biss ich mir auf die Zähne und schrieb Satz für Satz schön sauber zu Ende... richtig musterhaft könnte man schon fast sagen :P
Nun, ich hatte nach einer Weile eine schöne Zusammenfassung all meiner geplanten Features und ihren genauen Zusammenhängen und ich kann mich nur wiederholen: Ich bin verdammt froh, dass ich das alles aufgeschrieben habe, ansonsten wär mir das Projekt längst über den Kopf gewachsen... und zwar seehr weit! Also, falls du auch mal ein Spiel planst... immer ALLES aufschreiben, auch was selbstverständlich erscheint.
... link (0 Kommentare) ... comment
Mittwoch, 7. November 2007
...Das Ende allen Anfangs und der Anfang...
semai, 21:13h
Nun noch einige äusserst wichtige Dinge:
Du bist hier möglicherweise genau richtig;
1. Ich hab noch NIE wirklich ein Spiel von grundauf programmiert (Ausnahme: So ne PongVariante, aber die ist heute noch buggy)
2. Ich habe keinerlei Ausbildung in Sachen GameDesign
3. Ich hatte Anfangs keinerlei Kenntnisse von MDX
4. Ich BIN in der Ausbildung als Wirtschaftsinformatiker
5. Ich WEISS, dass ich mir SEHR viel mit diesem Projekt vornehme!
6. Ich muss das Ding letztendlich Alleine Planen und Umsetzen
7. Ja, ich weiss, ich bin ne Knalltüte XD
Nach diesen Fakten werden sicherlich einige denken, dass es nicht Wert sei, in Zukunft weitervorbeizuschauen, da das Projekt eigentlich fast zum Scheitern verurteilt ist. Nun, grundsätzlich WÄRE es das, jedoch handelt es sich hierbei, wie bereits erwähnt um meine Semesterarbeit und ich kann und darf das Projekt nicht einfach 'sterben' lassen!
Sondern werde alles daran setzen wollen und müssen, dass es Termingerecht bis zum 21. Dezember 17:00 fehlerfrei läuft! Deshalb bitte ich auch die, die nicht daran glauben, hie und da mal vorbeizuschauen, schaden tut's nicht und ihr werdet am Ende sicherlich überrascht sein.
Du bist hier möglicherweise genau richtig;
- falls dich jemals interessiert hat, wie ein Spiel entsteht
- falls du selbst ein Spiel programmieren möchtest
- falls du ein erfahrener Spieleprogrammierer bist und dich mal dafür interessierst, wie son blutiger Anfäger vorgeht
- wenn dir einfach langweilig ist und du nix besseres zu tun hast
- falls du dich über meine Mühen amüsieren willst(verbieten kann ichs nicht; ABER bitte, KONSTRUKTIVE kritik, klar?!)
- falls... eh ja... kA, gibt noch mehr Fälle die hier richtig sind... aber kann ja nich alle aufzählen :P
1. Ich hab noch NIE wirklich ein Spiel von grundauf programmiert (Ausnahme: So ne PongVariante, aber die ist heute noch buggy)
2. Ich habe keinerlei Ausbildung in Sachen GameDesign
3. Ich hatte Anfangs keinerlei Kenntnisse von MDX
4. Ich BIN in der Ausbildung als Wirtschaftsinformatiker
5. Ich WEISS, dass ich mir SEHR viel mit diesem Projekt vornehme!
6. Ich muss das Ding letztendlich Alleine Planen und Umsetzen
7. Ja, ich weiss, ich bin ne Knalltüte XD
Nach diesen Fakten werden sicherlich einige denken, dass es nicht Wert sei, in Zukunft weitervorbeizuschauen, da das Projekt eigentlich fast zum Scheitern verurteilt ist. Nun, grundsätzlich WÄRE es das, jedoch handelt es sich hierbei, wie bereits erwähnt um meine Semesterarbeit und ich kann und darf das Projekt nicht einfach 'sterben' lassen!
Sondern werde alles daran setzen wollen und müssen, dass es Termingerecht bis zum 21. Dezember 17:00 fehlerfrei läuft! Deshalb bitte ich auch die, die nicht daran glauben, hie und da mal vorbeizuschauen, schaden tut's nicht und ihr werdet am Ende sicherlich überrascht sein.
... link (1 Kommentar) ... comment
Was soll denn meine SemA können?
semai, 21:07h
Bis jetzt wisst Ihr ja eigentlich noch gar nix über meine SemA...
Also das ganze soll ein relativ komplexes Spiel werden, für dessen Realisierung etwas weniger als 5 Monate zur Verfügung stehen. Toll.
In dem Spiel wird es um einen 'Feldherren' gehen, der je nachdem entweder treu für seinen König kämpft, seinen König verrät und dann für einen Feind weiterkämpft oder sich selbst das ganze Reich unter den Nagel reisst.
Das ganze wird schlussendlich in rundenbasierten Gefechten ablaufen, wobei der Spieler seine Figuren immer wieder mit in die Schlacht nehmen wird. Soll heissen, er wird sich keine auf dem Schlachtfeld 'bauen' lassen können.
Die Figuren werden einen Level haben und mit der Zeit so stärker und stärker werden bis sie schliesslich sterben... sei dies im Kampf oder an Altersschwäche...
Ja, Sie haben völlig richtig gelesen, Altersschwäche! Die Einheiten werden auch ein Alter haben, welches einen enormen Einfluss auf die betroffene Einheit haben wird und kann daran auch sterben! Endgültig sterben (Viel Spass den Powerlevlern sag ich da nur... ) Und joa, ich weiss es ist unglaublich fies, hinterhältig und saddistisch dem Spieler gegenüber, dieses Feature einzuführen, ich machs trotzdem... muhahaha^^
Doch dessen nciht genug... nein, die Einheiten werden nicht alle gleich alt und der Spieler weiss NIE mit welchem Alter seine Figur sterben wird... Doch um dem noch eins oben draufzusetzen, entspricht das Alter gleichzeitig dem Höchstlevel der Einheit...
Eine weitere Fiesheit ist dann noch die Nahrungsgeschichte während der Schlacht...
Whatever, für den Moment sollte euch das Wissen über das Altern, den Feldherrn, den man letztendlich selbst darstellt reichen. Zudem wisst Ihr jetzt auch, dass es sich um ein rundenbasiertes Strategiespiel mit Rollenspielelementen handeln wird...
und ahja, die Gefechtskarte wird aus Blöcken bestehen wo 2D-Figuren kämpfen sollten; dachte nur, dass dies vielleicht auch noch interessant zu wissen sein könnte
Also das ganze soll ein relativ komplexes Spiel werden, für dessen Realisierung etwas weniger als 5 Monate zur Verfügung stehen. Toll.
In dem Spiel wird es um einen 'Feldherren' gehen, der je nachdem entweder treu für seinen König kämpft, seinen König verrät und dann für einen Feind weiterkämpft oder sich selbst das ganze Reich unter den Nagel reisst.
Das ganze wird schlussendlich in rundenbasierten Gefechten ablaufen, wobei der Spieler seine Figuren immer wieder mit in die Schlacht nehmen wird. Soll heissen, er wird sich keine auf dem Schlachtfeld 'bauen' lassen können.
Die Figuren werden einen Level haben und mit der Zeit so stärker und stärker werden bis sie schliesslich sterben... sei dies im Kampf oder an Altersschwäche...
Ja, Sie haben völlig richtig gelesen, Altersschwäche! Die Einheiten werden auch ein Alter haben, welches einen enormen Einfluss auf die betroffene Einheit haben wird und kann daran auch sterben! Endgültig sterben (Viel Spass den Powerlevlern sag ich da nur... ) Und joa, ich weiss es ist unglaublich fies, hinterhältig und saddistisch dem Spieler gegenüber, dieses Feature einzuführen, ich machs trotzdem... muhahaha^^
Doch dessen nciht genug... nein, die Einheiten werden nicht alle gleich alt und der Spieler weiss NIE mit welchem Alter seine Figur sterben wird... Doch um dem noch eins oben draufzusetzen, entspricht das Alter gleichzeitig dem Höchstlevel der Einheit...
Eine weitere Fiesheit ist dann noch die Nahrungsgeschichte während der Schlacht...
Whatever, für den Moment sollte euch das Wissen über das Altern, den Feldherrn, den man letztendlich selbst darstellt reichen. Zudem wisst Ihr jetzt auch, dass es sich um ein rundenbasiertes Strategiespiel mit Rollenspielelementen handeln wird...
und ahja, die Gefechtskarte wird aus Blöcken bestehen wo 2D-Figuren kämpfen sollten; dachte nur, dass dies vielleicht auch noch interessant zu wissen sein könnte
... link (0 Kommentare) ... comment
Darf ich vorstellen: Das Wesen meiner SemA
semai, 20:42h
Nachdem sich sicherlich alle von euch noch immer fragen müssen, worums denn geht, will ich das hiermit beantworten...
In unserer Klasse hiess es plötzlich, dass wir bis nach den Ferien ein Projekt haben müssen, welches wir gerne als Semesterarbeit umsetzen würden. Am Anfang hab ich mir den Kopf darüber zerbrochen und plötzlich kam mir in den Ferien eine schöne Idee... Ich könnte doch ein Spiel programmieren!
Sogleich hatte ich mir ein kleines Notizbüchlein angeschaffen um darin alle meine Ideen peinlichst genau festzuhalten, die ich für das Spiel hatte. Eigentlich tat ich das ungern, aber ich bin mittlerweile über diese Aufzeichnungen mehr als nur froh, also glaubt den Leuten bitte, die euch etwas über Projektmanagement und Planung erzählen, sonst geht später nix mehr ;)
Nun, also wie bereits erwähnt: Ein Spiel!
Jetzt freuen wir uns alle erstmal ne Runde über diese Erkenntnis und fahren fort.
Was denn für ein Spiel? Ein Computerspiel!
Bevor wir jedoch weitere 'Erkenntnisfreudentänze' aufführen, will ich hiermit anmerken, dass ich es am Ende zwar vermutlich 4 free veröffentliche, ABER es lediglich für Windows programmiert wird. Hierbei gilt auch noch, dass ich eine Windows XP - Umgebung benutze und das Spiel auf dieser sicherlcih funktionieren sollte, wie es mit der Kompatibilität zu VISTA steht, kann ich hier leider noch nicht sagen...
Wahtever, wo war ich? Achja, ein PC - Spiel...
...programmiert in C# und MDX... im .NET framework...
is ja ne tolle Sache so n'Framework, ABER es braucht seine Zeit zum laden -.-''
Also fassen wir an dieser Stelle mal zusammen, dass das Wesen meiner SemA aus einem PC-Spiel in C# und MDX, welches auf der .NET-Runtime basiert, besteht...
In unserer Klasse hiess es plötzlich, dass wir bis nach den Ferien ein Projekt haben müssen, welches wir gerne als Semesterarbeit umsetzen würden. Am Anfang hab ich mir den Kopf darüber zerbrochen und plötzlich kam mir in den Ferien eine schöne Idee... Ich könnte doch ein Spiel programmieren!
Sogleich hatte ich mir ein kleines Notizbüchlein angeschaffen um darin alle meine Ideen peinlichst genau festzuhalten, die ich für das Spiel hatte. Eigentlich tat ich das ungern, aber ich bin mittlerweile über diese Aufzeichnungen mehr als nur froh, also glaubt den Leuten bitte, die euch etwas über Projektmanagement und Planung erzählen, sonst geht später nix mehr ;)
Nun, also wie bereits erwähnt: Ein Spiel!
Jetzt freuen wir uns alle erstmal ne Runde über diese Erkenntnis und fahren fort.
Was denn für ein Spiel? Ein Computerspiel!
Bevor wir jedoch weitere 'Erkenntnisfreudentänze' aufführen, will ich hiermit anmerken, dass ich es am Ende zwar vermutlich 4 free veröffentliche, ABER es lediglich für Windows programmiert wird. Hierbei gilt auch noch, dass ich eine Windows XP - Umgebung benutze und das Spiel auf dieser sicherlcih funktionieren sollte, wie es mit der Kompatibilität zu VISTA steht, kann ich hier leider noch nicht sagen...
Wahtever, wo war ich? Achja, ein PC - Spiel...
...programmiert in C# und MDX... im .NET framework...
is ja ne tolle Sache so n'Framework, ABER es braucht seine Zeit zum laden -.-''
Also fassen wir an dieser Stelle mal zusammen, dass das Wesen meiner SemA aus einem PC-Spiel in C# und MDX, welches auf der .NET-Runtime basiert, besteht...
... link (0 Kommentare) ... comment
Hallo, liebe Leser...
semai, 20:29h
So, nachdem ich nun mein Profil einigermassen eingerichtet habe, erst einmal ein freundliches 'Hallo' an meine lieben Leser...
In diesem Blog hier geht es, wie Ihr unschwer erraten könnt, um meine Semesterarbeit. Jetzt fragt Ihr euch bestimmt: 'WAS? Semesterarbeit, wann fängt denn das Semester für den an?'
In der Tat hat es schon seit geraumer Zeit begonnen, nämlich anfang des vergangenen Augustes...
Aber ich habe mich erst jetzt entschlossen, daraus auch noch einen Blog zu machen...
So, nun denn viel Spass beim stöbern und lesen ;)
In diesem Blog hier geht es, wie Ihr unschwer erraten könnt, um meine Semesterarbeit. Jetzt fragt Ihr euch bestimmt: 'WAS? Semesterarbeit, wann fängt denn das Semester für den an?'
In der Tat hat es schon seit geraumer Zeit begonnen, nämlich anfang des vergangenen Augustes...
Aber ich habe mich erst jetzt entschlossen, daraus auch noch einen Blog zu machen...
So, nun denn viel Spass beim stöbern und lesen ;)
... link