Seit dem letzten Entwicklereintrag ist Pine Falls ein gutes Stück gewachsen. Ich bin zwar nicht so weit, wie ich es gerne wäre, dennoch erkennt man schon grobe Stadtstrukturen. Langsam und mühsam ernährt sich das Eichhörnchen. Ich habe ein Übersichtsbild der Aseprite-File mitgebracht, damit ihr euch ein eigenes Bild machen könnt. Ich merke schon jetzt, dass ich nen größeren Fokus auf abwechslungsreiche Vegetation setzen muss, da ich mit einer Tannensorte nicht das gewünschte Waldfeeling erzeugen werde.
Zwei ausgewählte WIP-Gebiete der Stadt möchte ich ich euch trotzdem noch zeigen und ein wenig erzählen:
Das erste Bild ist das Forschungszentrum der SANTRIA Company, der erste Dungeon im Spiel und Ursprungsort des Pine Tonics, einem sehr bekömmlichen Energy-Drink mit leicht radioaktivem Nachgeschmack. Die alte Version mit ein bisschen Dungeontalk könnt ihr auf der ersten Thread-Seite anschauen. Wahrscheinlich werde ich noch ein Transportfahrzeug in die freie Fläche parken, aber das kann ich erst abschätzen, wenn ich den Platzbedarf der Cutszene wissen werde. Freue mich schon sehr, wenn ich endlich am Dungeon basteln kann!
Das zweite Bild zeigt den besten (und einzigen) Supermarkt in ganz Pine Falls! Der ULTRA-Markt! Der Parkplatz wirkt noch ein wenig leer, da noch eine Motorrad-Gang Platz finden wird. Ich bin mit der Farbgebung zufrieden und mag besonders den orangenen Streifen an der Wand.
Soviel erstmal zu den Fortschritten.
Ich überlege, zusätzlich einen englischsprachigen Devlog laufen zu lassen, um das Spiel außerhalb des Ateliers bekannt zu machen/devlog-vernarrte Leser zu erreichen. Habt ihr damit Erfahrungen gemacht? Wordpress, tumblr, reddit, tigsource? Berichte und Meinungen?
Ich animiere gerade ein paar Emotion-Bubbles, um die Gefühle der Charaktere besser auszudrücken. Bin momentan bei rund 9 verschiedenen Varianten und habe euch heute mal die Glühbirnen-Bubble mitgebracht. Es ist eine gute Idee, ins Kino zu gehen, nicht war Tarquin (geht Zoomania schauen, starke Empfehlung)? Die Bubble an sich gefällt mir schon gut, die Charaktere dagegen sind mir noch zu statisch. Ich werde mir noch paar Charakter-Animationen überlegen, um die Bubbles besser rüberzubringen.
Ein weiteres Element, das ich heute testweise implementiert habe: wenn Tarquin sich einem interessanten Objekt nähert, erscheint eine Lupe als Hinweis darüber. Meine Gedanke war, dass es dem Spieler leichter fällt alle Spots zu finden, die man untersuchen kann ohne sich enter-hämmernd durch die Map zu bewegen. Was haltet ihr davon? Sinnvoll oder würdet ihr den Hinweis auf Dauer nervend finden? Bin auf eure Meinung gespannt!
Ich find den Effekt mit der Lupe ganz niedlich! Würde mich glaube auch auf Dauer nicht wirklich stören
...
Danke für dein Feedback! Der schwebenden Diskette über dem Speicherpunkt steht nichts im Weg!
Zitat von Avoki
Kann man die Einstellung mit der Lupe auch ausschalten?
Ich meine jetzt für die Leute, die lieber ohne Hilfe alles untersuchen möchten. :3
...
Gute Idee, der Spieler soll bei Spielbeginn selber entscheiden, ob er die Hinweise sehen möchte oder nicht! Das Feature zu implementieren ist kein Problem. Was mich interessieren würde: denkst du, die Lupe würde die Freude am Entdecken schwächen? Sie erscheint ja erst, wenn man mehr oder minder vor dem Gegenstand steht.
(Habe letztens dein Let's Play zu Agoraphobia beim Pixeln gehört. Gute Arbeit und mal eine angenehme Abwechslung zu den gewöhnlichen RPG-Maker-Rant-LPs! )
Aus persönlicher Erfahrung kann ich behaupten, dass ich viele Dinge zum Entdecken als unscheinbar betrachte und dadurch einiges übersehe. Um so mehr freut es mich, wenn ich diese Dinge dann doch anklicken kann. (und ich klicke alles gerne an.) xD
Die Lupe würde aber niemanden die Freude am Entdecken nehmen - es wär einfach nur etwas schwieriger ohne die Lupe. Ich mag das. Vielleicht ist dies aber auch nur mein Empfinden.
Woah ~ Danke schön, freut mich, dass dir "das hör - Let's Play" so gut gefallen hat. Hahahaha~
Aus persönlicher Erfahrung kann ich behaupten, dass ich viele Dinge zum Entdecken als unscheinbar betrachte und dadurch einiges übersehe. Um so mehr freut es mich, wenn ich diese Dinge dann doch anklicken kann. (und ich klicke alles gerne an.) xD
Die Lupe würde aber niemanden die Freude am Entdecken nehmen - es wär einfach nur etwas schwieriger ohne die Lupe. Ich mag das. Vielleicht ist dies aber auch nur mein Empfinden.
Woah ~ Danke schön, freut mich, dass dir "das hör - Let's Play" so gut gefallen hat. Hahahaha~
...
Vielen Dank für deine ausführliche Meinung, das hilft mir sehr bei der Entwicklung
UPDATE: TITLE SCREEN AND SOCIAL MEDIA
Hallo Atelier! Das Wetter ist schön und die Vögeln zwitschern. Ein perfekter Zeitpunkt für einen weiteren Entwicklereintrag! Ich habe mich die Tage mit dem Titelbildschirm beschäftigt und versucht, den Pine Falls-Charme und die Atmosphäre möglichst konzentriert rüberzubringen. Der Titelbildschirm ist meiner Meinung nach sehr wichtig, da es das Erste ist was der Spieler sieht und damit schon ein erstes Urteil über das restliche Spiel gefällt wird. Das Startmenü ist nach dem Stil des Spielmenü-GUIs aufgebaut um alles wie aus einem Guss wirken zu lassen. Ein finaleres () Spiellogo wurde entworfen und bringt hoffentlich den rustikalen Charakter einer Kleinstadt in der amerikanischen Wildnis rüber. Ich habe mit Parallax rumgespielt (es kann nicht genug Parallax in einem Spiel geben, oder Lachsen? Herrlicher Gamedev-Stream am Montag! ). Das Gebirge besteht aus zwei Schichten und in einer früheren Version hatte sich eine Schicht in geringer Geschwindigkeit zusammen mit den Bäumen bewegt... nun, sagen wir ich bin von den bewegenden Bergen sehr schnell abgekommen!
Das Menü ist schon stellenweise funktionell, New game und Load game funktionieren grob. Ich habe ein Bild des Ladebildschirms mal mitgebracht. Santria unterstützt zwei Files, zu denen Informationen über Standort, Spielzeit (noch nicht implementiert), Anzahl der freigeschalteten Partymember und Lvl angezeigt werden. Wahrscheinlich baue ich noch ein Feld für einen 100%-Spielstand ein, der dann eine Trophy anzeigt. Die Settings werden als nächstes angepackt.
Soviel erstmal zu diesem Update, ich bin auf eure Meinungen gespannt! Eine kleine Ankündung habe ich aber noch:
Wer Lust hat, mehr über SANTRIA zu erfahren und kleinere Updates mitzubekommen, die keinen Post im Devlog rechtfertigen, ist herzlichst eingeladen, meinen Twitter-Account zu folgen!
Wenn du noch eine bewegliche Schicht in deinem Panorama haben möchtest, kannst du ja noch Wolken einbauen...
Aber wirklich ein sehr hübscher Titlescreen! Ich frage mich aber, ob das Logo noch mehr poppen würde, wenn der Schlagschatten der Schrift tiefer wäre, und die typische Schwarze Kontur noch dabei wäre
Bei dem Speichermenü bin ich besonders neugierig - wie viel geht denn davon schon? Du benutzt ja auch den Game Maker, und speicherfunktionen schreiben ist etwas, woran ich mich selber noch nicht getraut habe...
Wenn du noch eine bewegliche Schicht in deinem Panorama haben möchtest, kannst du ja noch Wolken einbauen...
Aber wirklich ein sehr hübscher Titlescreen! Ich frage mich aber, ob das Logo noch mehr poppen würde, wenn der Schlagschatten der Schrift tiefer wäre, und die typische Schwarze Kontur noch dabei wäre
Bei dem Speichermenü bin ich besonders neugierig - wie viel geht denn davon schon? Du benutzt ja auch den Game Maker, und speicherfunktionen schreiben ist etwas, woran ich mich selber noch nicht getraut habe...
...
Flauschige Wolken wären das i-Tüpfelchen für das Panorama, fühle mich aber noch zu pixel-unerfahren um mich an sowas "Organisches" in der Größe zu wagen. Die Idee mit der schwarzen Kontur finde ich super und habe sie mal ausprobiert. Den Schlagschatten habe ich nicht tiefer gemacht, da es dann entweder zu gedrungen aussah oder die Buchstaben zu sehr in die Länge gestreckt. Ich denke, die Kontur hat das Logo nochmal verbessert, oder? Ist wohl wieder so eine typische "Über-Nacht-schlafen-dann-entscheiden"-Geschichte
Ja, das Speicher- und Ladesystem habe ich auch lange vor mich her geschoben. Langsam bewege ich mich Richtung Quests und bevor ich diese einbaue, muss erstmal ein systematisches Speichersystem vorliegen, mit dem ich den Questfortschritt hinterlegen kann. Meine Funktionen sind noch in einem rudimentären Zustand mit Spieler-Position und Lvl... vor allem um das Menü zu testen. Momentan beschäftige ich mich mit dem Lesen/Schreiben von ds_lists/ds_maps und die Verschlüsselung der ini-Datei für eine vollständige Erfassung aller Variablen. Wenn du Interesse daran hast, schreibe ich gerne ein kleines Tutorial, wenn ich mit meinem Speichersystem im reinen bin und poliert habe. Vielleicht kriegen wir nen coolen Game Maker-Talk hin!
Schön zu sehen wie es hier nach und nach voran mit dem Projekt geht.
Der Titelbildschirm und der Ladebildschirm gefallen mir auch sehr gut. Passt gut zum restlichen Grafikstil und zur Farbpalette.
Freue mich schon auf eine Demo, bis dahin verfolge ich weiterhin den Thread
Schön zu sehen wie es hier nach und nach voran mit dem Projekt geht.
Der Titelbildschirm und der Ladebildschirm gefallen mir auch sehr gut. Passt gut zum restlichen Grafikstil und zur Farbpalette.
Freue mich schon auf eine Demo, bis dahin verfolge ich weiterhin den Thread
Ich habe gestern lange an meinem Speicher/Lade-System rumgespielt und bin jetzt zufrieden damit. Die Telefonhäuschen in der Spielwelt sind Speicherpunkte, die unser kleiner Held nutzen kann um sein Spiel zu sichern. Das ganze System läuft wie folgt ab:
DIe meiste Frimmelarbeit haben tatsächlich das Menü + Interaktion und das Anzeigen der Dateien aus den Files gekostet. Die Speicher- und Ladefunktionen dagegen gingen kurz und knackig. Da Sabaku neugierig war, wie die Funktionen ablaufen, möchte ich euch ein bisschen darüber erzählen. Fragt gerne nach, wenn etwas unklar ist.
Das grobe Prinzip des Game Makers: Spiele bestehen aus verschiedenen Räumen, die verschiedene Objekte beinhalten können. Diese Objekte werden beim Betreten des Raums geladen und können mit Code versehen werden, um bestimmte Aktionen durchzuführen. Ein Object kann verschiedene "Events" beinhalten. Die (meiner Meinung nach) wichtigsten Events:
1. Creation: Ein Codefragment, das beim Erstellen des Objects einmal ausgeführt wird. Damit können Variablen initiiert werden.
2. Step: Ein Codefragment, das jedes Frame abgespielt wird. Sehr mächtig, um das Spielsystem an sich zu steuern.
3. Draw: Ein Codefragment, das jedes Frame abgespielt wird und die gewünschte Information auf dem Bildschirm "zeichnet" (Bilder, Sprites). Quasi der "Zeichnen-Step".
Natürlich gibt es noch unzählig andere Events, die sehr nützlich sind, die möchte ich aber an dieser Stelle nicht ansprechen.
Wenn das Spiel gestartet wird, landet der Spieler beim Titelbildschirm. Beim Betreten dieses Raumes wird ein Object initiiert, welcher "main_control" heißt und alle wichtigen Spielvariablen über sein Creation-Event festlegt. Ich habe ein paar Beispiele aufgezählt, damit ihr ein Gefühl kriegt, wie das aussieht:
Beim Codebeispiel wird die Zeitzählung auf null gesetzt, die Attribute des Helden geladen und die (ich nenne es mal so) Gegenstandsdatenbank geladen, damit das Spiel weiß, was ein Gegenstand für Attribute hat. Die Attribute werden in einer sogenannten "ds_map" geladen. Das ist eine Datenstruktur, die "Keys" mit entsprechenden "Werten" speichert, also sowas wie "HP" und den Wert der Lebenspunkte.
Soviel also zu den Variablen. Immer, wenn das Spiel startet, werden diese Variablen geladen und festgesetzt. Der Spieler startet also immer bei Lvl 1, etc. Nun möchte ich aber meinen Spielstand festhalten und darauf zugreifen können. Dafür eignet sich folgendes Speicherskript, welches ich beispielhaft vorstelle:
Das Spiel öffnet damit eine Ini-Datei, die im "AppData"-Ordner von Windows abgelegt wird. Über den Befehl "ini_write_real(section, key, value)" können Zahlen dort abgelegt werden, eingeteilt nach Sektionen und dann als Key-Value-Wertepaar gespeichert. Das ist bei einfachen Variablen kein Thema. Was ist aber mit unseren komplexen Datenstrukturen wie den "ds_maps"? Alles einzeln einzutippen wäre zu aufwendig. Zum Glück hat der Game-Maker die Funktion "ds_map_write". Damit wird die gesamte ds_map in einen unleserlichen Zeichenstrang umgewandelt, den "String". Dieser String kann kann unproblematisch in die Ini-File abgelegt werden. Das Ganze sieht das ungefähr so aus:
Über das Prinzip können auch Quest/Story-Fortschritte einfach abgespeichert werden. Ich werde zu diesen Zwecken ebenfalls eine Datenstruktur mit Key und Value wählen, z.B. "Switch1" und "0" bzw "1". Diese entspricht vom Prinzip der "Switch"-Liste beim RPG-Maker und kann genau wie dort auch hier genutzt werden. Wenn ein Quest aktiviert ist, stellt man den Switch für diese Quest von "0" auf "1" und das Spiel was bescheid. Statt 0 und 1 gehen natürlich auch "true" und "false" (die klassischen Booleans halt). Wie ihr bemerkt habe, habe ich die Gegenstandsattribute nicht gespeichert. Das macht Sinn, weil sie von Anfang bis Ende (hoffentlich!) konstant bleiben!
Nun starten wir das Spiel neu oder die Variablen werden neu initiiert und sind wie vor dem Speichern. Wie laden wir die abgespeicherten Daten nun? Dazu nutze ich ein Load-Skript, welches die initiierten Variablen mit den gespeicherten Variablen überschreibt.
Die Ini-Datei wird geöffnet, die Variablen neu festgelegt und der String wird rausgelesen und über die "ds_map_read"-Funktion wieder in die funktionierende Datenstruktur übersetzt. Alles schick, ein Problem ist noch da: der Spieler kann dieses Save-File selber öffnen und sich so natürlich mehr Attribute und Level zuschummeln (ach, als Kind habe ich so viele Spiele gehackt! ). Hierfür hat der Game-Maker eine Verschlüsselung. Über "base64_encode(string)" kann ein String in einen verschlüsselten String umgewandelt werden und über "base64_decode(string)" beim Laden wieder in einen leserlichen String umgewandelt werden. Bei Zahlen muss der Wert erst in einen String umgewandelt und nach dem Decoden wieder in eine Zahl zurückgewandelt werden.
Soo, ich hoffe ich konnte für ein bisschen Klarheit sorgen und euch die Speicher- und Ladefunktionen näher bringen. Ihr könnt den Code natürlich nutzen wie ihr wollt und ein bisschen rumspielen! Sagt mir bescheid, ob euch solche technischen Abhandlungen interessieren, dann schreibe ich gerne öfter über sowas.
Stay tuned und bis zum nächsten (und weniger technischen) Devlog!
Ja sehr gut! Da werd ich mir den Beitrag wohl später mal ganz genau ansehen, und kucken ob ich das wohl auch so hinbekomme. Vielen lieben Dank für deine Ausführungen, ich empfinde das als sehr hilfreich
Die Ini-Datei wird geöffnet, die Variablen neu festgelegt und der String wird rausgelesen und über die "ds_map_read"-Funktion wieder in die funktionierende Datenstruktur übersetzt. Alles schick, ein Problem ist noch da: der Spieler kann dieses Save-File selber öffnen und sich so natürlich mehr Attribute und Level zuschummeln (ach, als Kind habe ich so viele Spiele gehackt! ). Hierfür hat der Game-Maker eine Verschlüsselung. Über "base64_encode(string)" kann ein String in einen verschlüsselten String umgewandelt werden und über "base64_decode(string)" beim Laden wieder in einen leserlichen String umgewandelt werden. Bei Zahlen muss der Wert erst in einen String umgewandelt und nach dem Decoden wieder in eine Zahl zurückgewandelt werden.
...
Stopstopstop. Base64 ist keine Verschlüsselung sondern encodiert einfach nur Binärdaten zu ASCII-Zeichen und wieder zurück.
Den "einfachen Cheater" wird das vielleicht abhalten, aber bitte denke nicht, die Spielstände wären damit gegen Manipulation geschützt.
Wobei ich das bei einem Single-Player-Spiel jetzt auch nicht großes Problem sehe. Wenn sich jemand den Spaß vermiesen will, soll er doch...
--
"Banjo, you're a BEAR... and I will teach you... THESE MOVES!"
Ich bin zufällig bei der Suche nach etwas über Google Bilder auf Dich gestoßen - sehr interessanter Blog!
Mit viel Liebe, habe ihn gerne durchgelesen.
Dabei ist mir folgendes über den Weg gelaufen:
Zitat von Schotti
Das Spiel öffnet damit eine Ini-Datei, die im "AppData"-Ordner von Windows abgelegt wird. Über den Befehl "ini_write_real(section, key, value)" können Zahlen dort abgelegt werden, eingeteilt nach Sektionen und dann als Key-Value-Wertepaar gespeichert. Das ist bei einfachen Variablen kein Thema. Was ist aber mit unseren komplexen Datenstrukturen wie den "ds_maps"? Alles einzeln einzutippen wäre zu aufwendig. Zum Glück hat der Game-Maker die Funktion "ds_map_write". Damit wird die gesamte ds_map in einen unleserlichen Zeichenstrang umgewandelt, den "String". Dieser String kann kann unproblematisch in die Ini-File abgelegt werden. Das Ganze sieht das ungefähr so aus:
...
Da möchte ich dich kurz korrigieren: Es ist kein unleserlicher String, sonder einfach ASCII zu HEX codiert. Als Verschlüsselung hilft Dir das nur, wenn es jemand nicht auffällt und er kein Google benutzen kann:
5461727175696E5F7370656369616C73 --> CONVERT FROM HEX TO ASCII --> Tarquin_specials
Ich freue mich sehr, mehr über deine Projekte zu erfahren. Habe mir ein Lesezeichen zu dem Forum angelegt und mich sogar wegen Dir angemeldet )
Bin auch Game Maker Spieleentwickler.
Zitieren
Die Bubble an sich gefällt mir schon gut, die Charaktere dagegen sind mir noch zu statisch. Ich werde mir noch paar Charakter-Animationen überlegen, um die Bubbles besser rüberzubringen.
Das Feature zu implementieren ist kein Problem. Was mich interessieren würde: denkst du, die Lupe würde die Freude am Entdecken schwächen? Sie erscheint ja erst, wenn man mehr oder minder vor dem Gegenstand steht.
) Spiellogo wurde entworfen und bringt hoffentlich den rustikalen Charakter einer Kleinstadt in der amerikanischen Wildnis rüber. Ich habe mit Parallax rumgespielt (es kann nicht genug Parallax in einem Spiel geben, oder Lachsen? Herrlicher Gamedev-Stream am Montag! 
