Ach was, auch Perfektionisten können etwas zusammenkriegen, denn vollkommener Perfektionist ist niemand. Meistens hat man ja nur ein bestimmtes Ziel als Perfektionist, das man unbedingt erreichen und keine Kompromisse eingehen will, wobei diese Ziele, im Bezug auf den Maker, dann eher im technischen Bereich sind.
Wenn man erstmal sein Ziel erreicht hat, wird man auch weiter Fortschritte machen können und eventuell recht schnell ein Spiel zusammenbringen. Hängt wirklich mehr von der richtigen Wahl des Werkzeugs und einer gründlichen Planung ab, als davon, ob man Perfektionist ist oder nicht.
Btw, wer es sich durchlesen will:
Finishing Games - Part I
Finishing Games - Part II
Imo werden hier sehr gute Ansätze geschildert.
Geändert von Kyuu (07.03.2008 um 17:52 Uhr)
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Wir reden von einem ungepatchten 2k oder 2k3, ja?
Dann diese:
- keine Arbeit mit Dateien möglich
Was das bringen würde? Man könnte z.B. Dialoge in Textdateien schreiben. Alternativ auch in eine XML Datei. So müsste man nicht alle Dialoge über den Show Message Dialog vom Maker eintippen. Das wäre komfortabler als es den gewünschten Text immer stückenweise einzutippen. Um einiges.
Man könnte eigene Speicherstände schreiben. Und ja, im Entwicklungsprozess findet man meist noch mehr sinnvolle Verwendungszwecke.- inkonsequente Referenznutzung(ja referenz, nur für kelven =) )
Man kann auf Variablen zugreifen mit einer Referenz. Man kann sie über diese auch beschreiben. Eine IF Abfrage kann man jedoch nicht direkt auf Referenz anwenden. Du musst den Inhalt der Referenz erst zum zwischenspeichern in eine Variable übergeben. Warum?
Warum kann ich einen Switch über eine Referenz setzen, allerdings den Zustand des Switches nicht auslesen?
Warum kann ich bei den Bild IDs keine Variable nutzen?
Sollte klar sein wodrauf ich hinaus will.- Datenspeicherung
Sagen wir, wir wollen abspeichern was für Monster und Zauber es in unserem Spiel gibt. Allerdings kommen diese in einem eigenen KS vor. Ergo kann man die Standard DB vom Maker nicht nutzen. Was nun? Also muss man sich selbst etwas ausdenken.
Das wiederum endet im Endeffekt damit das man sich z.B. ein CE baut in dem man zich Forks stapeln muss. Das ganze verbindet man dann mit einer "ID-Variable" über die man dann die einzelnen Forks anspricht.
Klingt gut? Nein. Es ist eher einer der schrecklichsten mir bekannten Formen um Daten abzuspeichern. Ach? Dafür ist der Maker nicht auslegt? Jupp. Da hätten wir die nächsten Nachteil.
Das wären drei. Gibt es nur die drei? Nein. Der Maker selbst reagiert bei viel gleichzeitig laufendem Eventcode schnell langsam. Wäre ein Messagefenster offen ist funktionieren keine Bildbefehle mehr. Es gibt von Haus aus keine anständige Tastatur oder Mausunterstützung. Und so weiter und sofort.
Durch den Destinypatch bspw. lassen sich durchaus ein paar Nachteile ausmerzen. Jedoch bei weitem nicht alle. Zudem man auch nie weiß ob diese Erweitungen alle so funktioniert wie sie sollen.
Nur ist das alles doch an sich nichts neues?
--
Wieso hat eigentlich noch keiner die Standard Sachen aufgezählt?
Beispiele der Grenzen der 2k/3 Maker:
- nur 8bit Farbtiefe
- feste Auflösung (320x240)
- feste Grafikgrößen (kein Char kann größer als 24x32 px sein/ feste Chipsetgröße)
- begrenzte Soundformate (kein mp3)
- keine zusätzliche Skriptmöglichkeit
- keine Maus- und kaum Tastaturunterstützung
- nur 2 Mappinglayer
- simple Chipsetpriorität
uvm.
Einiges kann durch Patches aufgehoben werden, anderes wiederum nicht.
Erst ein neuer Maker wie z.B. der XP erweitert die bisherigen Grenzen ungemein. Auch der VX kann sich sehen lassen, allerdings hat der wieder einige künstlich eingeführte Grenzen.
Nein, nein. Nicht einfach irgendwelche Fragmente aus einem Post rausreißen.
Ich hab die Frage rückwirkend gestellt und dahinter zitiert was bisher kam.
Der/die/das unglaublich faszinierende
-->nton: -Smiley
sollte eigentlich selbst erklärend sein. Grenze heißt nicht Umständlichkeit und auch nicht Nachteil. Ich könnte eure Posts jetzt nochmal zitieren und dann ein Enton hinpflanzen, nur damit danach noch jemand kommt und die Liste der Umständlichkeiten erweitert.
Was genau bleibt einem denn damit verwehrt? (Tipp zur Beantwortung der Frage: Meinen Post lesen - auch den vorherigenZitat von Ascare
)
CapSeb
![]()
--
Achso, so meinst du es...
Naja, unmöglich ist so ziemlich wenig beim 2k (bei 2D). Mal abgesehen davon das manche Sachen wirklich umständlich umzusetzen wären...fällt mir jetzt spontan nur das pixelgenaue Abfragen ein. Das wäre relevant für Shooter oder wenn man ein Beat'em up macht (bzgl. Kollisionsabfragen).
Zwar ließe sich auch ohne pixelgenaue Abfragen so ein Genre realisieren, allerdings wären die Abfragen ja sehr grob (16x16 Tile) und das verfehlt so ein bisschen den Zweck des Ganzen.
Noch etwas was ich auch noch nie gesehen habe ist ein Multiplayer AKS bzw. ein AKS mit mehreren Partymembern dessen Steuerung man dynamisch übernehmen kann. Zwar sehe ich technisch keine Grenzen, aber seit 8 Jahren Makern habe ich noch kein Spiel gesehen das so ein AKS hat, insofern ist das schon eine Grenze die noch nicht durchbrochen wurde, also ist sie praktisch da.