Tagebuch: Industry City

Wie wird die Anzahl bestimmt, und kann man dann auch Autos anderen Fabriken übertragen?

Final ist noch nichts. Aber bisher schaut meine grobe Idee so aus, dass jede Fabrik und Shop mit einem Auto startet. Jedes weitere muss der Spieler kaufen (ingame Währung vllt in Kombination mit Werbung).

Das man Autos übertragen kann ist derzeit nicht geplant und auch nicht vorgesehen. Da ich die Autos mit sowas wie einem Level Up gleichsetzen würde, da man die Fabrik ja effektiv auswertet (mehr Autos ermöglichen fortgeschrittenere Rezepte).

Zur Verdeutlichung des ganzen, hier mal ein Screenshot vom aktuellen Mockup. Der aber noch nicht „Final“ ist. Mit den Buttons bin ich nämlich noch nicht ganz zufrieden (bin mir noch nicht sicher, ob mir das tatsächlich so gefällt wie ich es gerade habe oder nicht):


Aber ich denke, es ist erkennbar, in welche Richtung das geht. Während ich den Post hier schreibe, kam mir im übrigen auch erst die Idee, die Maximal-Anzahl der Autos auf 3 zu setzen. Vorher war noch der Gedanke im Raum, es variable zu halten (was aber nur für den Shop Sinn macht. Aber ohne MAX-Wert würde es theoretisch wenig Sinn machen mehr als einen Shop zu bauen. Wobei ich beim Shop vllt 5 Autos zulassen würde. Das ist noch offen).

So. Ich bin nun fertig mit den Factory settings und das gefällt mir auch ganz gut:

Etwas stolz bin ich auf die transparenten Hintergrund-Bilder die verdeutlichen sollen, von wo die Resource abgeholt wird. Hat etwas gedauert, bis ich zu dem Ergebnis gekommen bin. Denn an vielen Stellen war mir das Transparente Bild entweder zu unpassend, zu störend, zu transparent oder zu aufdringlich.

Mein „Big-Picture“ hab ich auch entsprechend geupdated. Dementsprechend sehe es nun so aus:

Ok. Die Shop-Settings gingen jetzt echt flott von der Hand. Letztendlich sind diese aber auch nichts anderes als eine abgespeckte Variante von den Factory-Settings:

Heute hab ich nen Lauf. Hab nun auch (hoffentlich) den letzen View fertig. Im Gesamten schaut es jetzt so aus:

Wie Ihr seht gibt es unten zwei neue Einträge mit „Route Settings“ die nahezu identisch sind. Der einzige Unterschied: Beim Shop wird alles gelistet - bei der Factory sollen die angezeigten Elementen nach dem zu produzierenden Item gefiltert werden.

Gefreut hab ich mich vor allem darüber, dass ich den Button wiederverwenden konnte, den ich heute mittag aufwendig designed habe.

Als nächstes werde ich mir mal ein paar GamePlay-Momente im Kopf überlegen und schauen, ob das mit dem angepeilten UI möglich wäre. Und ob es noch Schwachstellen gibt, die ich ausmerzen könnte.

ThinMatrix bastelt auch an einem City-Builder-Spiel, vielleicht kannst du dir ja Inspiration holen:

1 Like

Hehe, ich weiß. Verfolge dieses Projekt schon seit dem ersten Video :stuck_out_tongue:. Aber bisher hat er hauptsächlich Probleme gelöst, die mit Unity3D geschenkt werden ^^. Trotzdem ist es irgendwie interessant, seinem Fortschritt zuzuschauen und werde mir auch die Folgevideos angucken.

Ich merke gerade, wie wichtig ein BigPicture ist. Warum? Erklär ich später. Erstmal Context:

Wie bereits erwähnt möchte ich in dem Spiel durchaus Werbung unterbringen. Dabei aber (wie schon oft erwähnt) so, dass es vom Spieler selbst getriggert wird. Ich dachte da an ein Konzept: 1x Werbung gucken gibt einen Kristall (oder wie auch immer ich die Extra-Währung nennen werde). Dementsprechend hätte der Spieler die Chance sich durch einige male Werbung gucken im W-Lan diese Währung anzusammeln um offline trotzdem alle Möglichkeiten zu haben.

Soweit so gut. Jetzt muss ich diese Währung natürlich auch irgendwo anzeigen. Kurzzeitig hab ich überlegt, ob ich es unter dem Gold-Betrag anzeigen lasse. Aber dann hab ich mal auf meine anderen Screens geschaut und gemerkt, dass das nicht gerade gut wäre. Denn dann würde die Anzeige im Titel von den Fullscreen-Dialogen drin hängen. Und hier wären wir bei meiner Einleitung. Durch das BigPicture kenne ich nun meine Restriktionen.

Hab die letzten Tage hauptsächlich Krank auf der Couch verbracht und deswegen nicht viel machen können. Dafür war ich heute morgen recht kreativ. Zum einen gibt es noch ein paar weitere Views zum anderen glaube (und hoffe ich) so langsam zum Ende zu kommen. Das Big-Picture schaut nun so aus:

Neu ist die Anzeige, was ein Gebäude an Geld kosten wird. Dafür hab ich Tabs eingeführt und für den Shop schaut das z.B. so aus:

Als ich mir den Prototypen vo rkurzem angeschaut hatte, ist mir zudem eine Sache aufgefallen. Ich hab vorgesehen, dass man Gebäuden Namen geben kann, verwende diese aber nirgends. Also blieben mir zwei Möglichkeiten:

  • Diese Möglichkeit entfernen
  • Einen sinnvollen Verwendungszweck dafür finden

Einen Zweck hab ich auch gefunden. Nämlich das man bei den Routen den Namen sehen kann. Vor allem wenn mehrere Fabriken das gleiche Produzieren kann das für die Lastenverteilung sinnvoll sein zu wissen, woher jetzt eine Resource bezogen wird.

Neben kleineren Änderungen hab ich noch eine die sich auf den Fokus bezieht. Die Buttons zum kaufen von Fahrzeugen werden im ersten Schritt keine Funktion haben. Es ist naheliegen, dass diese einen Dialog triggern der den Kauf bestätigen lässt. Um den Scope aber nicht weiter aufzublasen (der UI-Prototyp ist bereits jetzt schon sehr groß) möchte ich das auf später verschieben.

Gefühlt dürfte aber jetzt alle information dar gestellt werden, die auch tatsächlich schon in der Simulation vorhanden ist. Auch sollte wirklich alles sinnvoll und begründet sein was vorhanden ist und es folgt gewissen Richtlinien. So folgen z.B. die Farben von Buttons einer Bedeutung (blau: ändern, grün: übernehmen, rot: vorsicht). Dadurch glaube ich ein recht einheitliches Bild geschaffen zu haben.

So. Ich glaube, dass ich alles habe und hab deswegen mal mein Board basierend auf dem Plan erstellt. Hat etwas gedauert, denn ich hab daraus 5 User-Stories mit 21 Subtasks erstellt.

Für die Umsetzung werde ich auch glaub einfach den Branch vom UI-Prototyp mergen. Letztendlich befindet sich darin ja nicht viel mehr als das UI und so muss ich es nicht nochmal nachbauen - sondern lediglich mit Leben füllen. Außerdem hatte ich mir die Mühe gemacht und viele Komponenten sinnvoll als Prefab hinterlegt.
Dementsprechend sollte das alles recht sauber sein.

So. Den einen Task hätte ich sogar schon erledigt. Und zwar wird nun das Geld korrekt angezeigt. Meine Simulation rennt gerade und die kleine Stadt ist wirtschaftlich erfolgreich wie man hier sehen kann :stuck_out_tongue: :

Gestartet hat das ganze bei 100 und durch den Verkauf von Wasserflaschen sind wir bei 145 :slight_smile:.

Kleine Änderung - aber ist mal wieder schön zu sehen, wie sich da was bewegt.

Es ist immer so ein Glücksspiel, wenn man Zeitbasierten code testen darf. Ich hab nämlich die bestehende Logik für die monatlichen Zahlungen umgebaut von der Schleife:

  1. Warte 10s
  2. Kassiere die Zahlungen

In etwas, was auch 10s wartet, aber pro Sekunde 25 Signale feuert, damit ich darauf basierend die Kalenderanzeige updaten kann.
Für das Warten hatte ich WaitForSeconds von Unity verwendet, weil es angenehm einfach war. Und lesbar.
Hat auch wunderbar funktioniert. Nur leider nicht für den Test. Und basierend auf meinen Beobachtungen liegt das an den beschleunigten Tests (der Test beschleunigt als mal kurzzeitig die Zeit um Faktor 100, sodass 10s nur noch 0.1s dauern).

Meine Vermutung war dann, dass der LifeCycle von Unity3D da einfach nicht mehr mit klar kommt. Denn meine Theorie schaut so aus.

Ich hatte innerhalb einer Schleife WaitForSeconds aufgerufen mit einem Wert von 1/25 (0.04). Dieser Wert wird jetzt nochmal um den Faktor 100 beschleunigt => 0.004. Das sind 4ms. Ich nehme mal an, dass es einfach länger dauert, den LifeCycle zu durchlaufen als 4ms. Sagen wir mal, ein Durchlauf würde 10ms dauern. Dann würde der Code 250ms brauchen. Ich warte aber nur 100ms bevor ich den Status vom Spiel überprüfe.

Ich bin vor kurzem zufällig über PixelArt gestoßen. In einem Discord-Channel hat einer sein Spiel vorgestellt und wie er mit PixelArt begonnen hat. Das ganze war ein YT-Video und seit dem bekomme ich über YT immer mal wieder PixelArt vorgeschlagen.

Das hat mich jetzt durchaus mal gereizt und ich hab jetzt mal ein paar Tools ausprobiert. Und ich find mit Aseprite hab ich tatsächlich eine nette kleine Szene hinbekommen :slight_smile:. Da ich es in der Trial-Version nicht speichern kann, muss halt ein Screenshot her:

Und es war tatsächlich nicht schwer. Viele Kommentare sagen, dass Pixelart auch nicht wirklich schwer zu lernen sein soll. Jetzt überlege ich mir ob ich mir das Tool kaufe und nebenher mir mal die Fähigkeiten aneigne.

Habs mir jetzt einfach mal gegönnt. Zumal ich mir gedacht hab. Denn vllt kann ich die Produkt-Bilder durch Pixel-Art ersetzen (noch nicht sicher, ob ich das möchte). Aber das hier kam raus, als ich mit dem Wasserglas rumgespielt hab:

Sprite-0004

Und das hier ist so nebenbei entstanden. Auf der Couch vorm Fernseher.
Sprite-0003

Tu ich im übrigen sicher nicht. Nachdem ich mir nochmal kurz meine mockups angeschaut hab wurde ganz schnell klar: blöde Idee xD.

So. Die erste Story hab ich abgeschlossen und zugleich auch noch einen Bug gefixt, der nur aufm Handy aufgetreten ist. Der Shop wurde falsch initialisiert und hat deswegen nichts verkauft. Das hat für erst mal für ein paar Schreckminuten gesorgt, weil ich mir nicht erklären konnte, wo jetzt das Problem ist.
Nachdem ich aber die App nochmal als Development-Build gebaut hab und in LogCat reingeschaut hab wurde es klar.

Nun funktioniert alles wie es soll :slight_smile::

Jetbrains zeigt Humor? Hab mich gerade über diesen Hinweis „gefreut“ ^^:

image

Viel vom Hauptmenü fehlt mir auch nicht mehr. Man kann es nun aufrufen + pausiert das Spiel, sobald man den GameScreen verlässt:

Hab heute Abend mal wieder etwas weitergemacht. Man kann nun den Namen der Fabrik in der entsprechenden Ansicht sehen + ändern. Dazu wieder verwende ich einfach den Namen des GameObjects. Netter Nebeneffekt an dem ganzen: Man kann es in der Hierarchie von Unity sehen.

Wie immer gilt: Ein Video sagt mehr als 1000 Worte :slight_smile::