Ich find ja 8-bit killer hat unglaublich grossartige grafiken.
Sieht aber auch nach derb viel Arbeit und Koennen aus 
inspiration InspirationEnvironment InspirationWeapons
SkinningTexturingRessources ModelRessources
Atomunfall / Atombombe führte zu Stadtruine in der Wüste → vom Sand teil-verschüttete Stadt. Observations- und Aufräumroboter wurden losgeschickt und änderten aus einem Grund (Energie-/Magnet-/Kosmische Strahlung-Feld) ihre Ziele - entwickelten mehr oder weniger Bewusstsein. Sie begannen feindlich zu werden, Kampfroboter wurden nachgeschickt (das rechtfertigt Waffen und Gegner). Teilweise bestehen die Gegner aus noch erkennbaren Aufräum-Robotern und teilweise aus Kampfmaschinen.
Das umsetzen der Dungeons koennte man mit neuen Bombeneinschlaegen erklaeren.
Auf alle faelle nochmal zu DOTA gucken!
Kampfroboter:
| Angriffsfreq. | Schaden | Reichweite | Geschwindigkeit | Energieverbr. | |
| Flamethr | sehr hoch | mittel | sehr niedrig | sehr langsam | mittel |
| Railgun | sehr niedrig | stark | sehr hoch | schnell | sehr hoch |
| Submg | sehr hoch | schwach | niedrig | schnell | niedrig |
| Moerser | sehr niedrig | stark | sehr hoch | normal | normal |
| Granatwerfer | niedrig | mittel | hoch | normal | hoch |
Aufräumroboter:
| Angriffsfreq. | Schaden | Reichweite | Geschwindigkeit | Energieverbr. | |
| Kreissäge | sehr hoch | stark | Nahkampf | schnell | mittel |
Denkbar wären auch Kombinationen, die über die bloße Zuordnung der speziellen Funktionen an bestimmte Körperteile hinausgehen. Es muss evtl. nicht zwingend sein, dass Waffen nur an den Armen existieren können. Vorstellung: Maschinengewehre am Torso, Raketenwerfer an den Armen… Das würde bedeuten, man ordnet jedem Körperteil potentiel auch jede Eigenschaft zu - was die Kombinations- und Variationsmöglichkeiten enorm erhöht - dafür aber Game-Balancing und evtl. Modell-Aufwand erhöht.
Falls mir mal mehr spieler haben sollten: man kann ein item zu einem user definierten preis zum verkauf anbieten, das bieten dann NPC haendler im spiel den anderen an.
Grundlagen von http://www.garagegames.com/articles/networking1/ sind implementiert. http://unreal.epicgames.com/Network.htm fuer naeheres zur interpolation.
Hab uns grade mal nen javadoc ant task gemacht:
cubic.javadoc
Ich arbeite dran, das mal mit nem cronjob online zu kriegen.
http://www.cokeandcode.com/node/305
Les hier grade nen bischen /. : Communication. Ein anderer interessanter Punkt sind Code-Reviews, sollen wir sowas etwas organisierter machen? Oder liest eh jeder jeden Code? Bei /. empfehlen sie das waermstens (“If you want to learn from/about each other, review each other’s work. If you want to live dangerously, don’t.”).
Wie siehts ueberhaupt mit Codeownership aus? Trennung in Bereiche wird ziemlich schwierig, sobald wir die Utility Sachen fertig haben, glaube ich.
Fehlt uns ne Aufgabenliste?
Und, aeh, tests? Ich schreib in PHP tests fuer die wirklichen Kernsachen; dadurch hat man dann eigtl. nur Bugs, die in dem Code sind, in dem sie auftreten. In Java hab ich einfach noch keine Tests geschrieben, und fuer den Renderer stell ichs mir schwieriger vor (hm, GL-Mockobject… sollte eigtl gehen).
Regelmaessige Treffen & Deadlines hatte Frede ja schonmal vorgeschlagen.
Brauchen wir noch ein genaueres Designdoc?