Warum wir mit einem Clicker angefangen haben
Schnee, Familienbesuch und die Frage, warum Menschen immer wieder einen Button drücken. Wie aus einem kleinen Versuch OshiYa wurde.
Es war kalt. Draußen lag Schnee, und die Familie war zu Besuch. Ein Spielstudio stand nicht auf dem Plan. Wir wollten nur ein einfaches Spiel bauen.
Nicht, weil wir „einfach“ mit „leicht“ verwechselt hätten. Uns ging es darum, ein Genre und eine Branche kennenzulernen, die wir bisher vor allem als Spieler kannten.
Was ist an diesem Button so faszinierend?
Clicker fanden wir schon immer seltsam. So viele Menschen laden eine App herunter, um immer wieder auf einen Button zu drücken. Eine Zahl steigt, ein Upgrade wird frei, und dann geht es von vorn los. Auf dem Papier ist das erstaunlich wenig Spiel. Und trotzdem kommt man von einem guten Clicker kaum los. Warum?
Im Programmieren waren wir nicht neu. Wir entwickeln seit Jahren Unternehmenssoftware. Die Spieleentwicklung stellte uns aber andere Fragen. Eine Funktion kann technisch korrekt sein und sich trotzdem leblos anfühlen. Ein Klick braucht eine Reaktion, einen Rhythmus und einen Grund, es noch einmal zu versuchen. Das war am Anfang der schwierigste und spannendste Teil: nicht das Programmieren selbst, sondern ein Gefühl in Regeln zu übersetzen.
Züge sind cool
Dem Clicker fehlte noch eine Welt. Züge sind cool, damit war die Entscheidung schnell getroffen. Statt Punkte zu sammeln, schiebt man Fahrgäste in den Waggon. Ein Zug fährt ein, füllt sich und fährt ab. Upgrades machen den Bahnhof voller und das Einsteigen schneller.
Für den ersten Prototyp nahmen wir Go und Ebitengine. Go kannten wir aus anderen Projekten, und Ebitengine reichte für ein kleines 2D-Spiel, ohne dass wir gleichzeitig eine neue Sprache und einen großen Editor lernen mussten. Der erste Stand im Repository ist vom 10. Dezember 2025. Er hatte schon Zug, Gleise, Fahrgäste, Upgrades und einen Klick, der Menschen zum Waggon schob. Er war grob, aber spielbar.
Korrekt ist nicht dasselbe wie richtig
Sobald der erste Zug fuhr, war das Projekt keine technische Übung mehr. Wir drehten daran, wie die Fahrgäste reagieren, wie schnell der Zug kommt und wie viel ein Upgrade bringen soll. Jede Änderung zog eine andere nach sich. Schnellere Züge veränderten den Rhythmus, mehr Fahrgäste den Druck am Bahnsteig, und ein starkes Upgrade ließ das vorige plötzlich nutzlos wirken.
In der Unternehmenssoftware fragen wir, ob ein System korrekt ist. Das Spiel fragte ständig, ob es sich richtig anfühlt. Ein Zug kann im mathematisch richtigen Takt einfahren und trotzdem langsam wirken. Eine Belohnung kann in der Tabelle ausgewogen sein und trotzdem keine Vorfreude wecken.
Heute würden wir anders anfangen
Mit dem Spiel wuchs, was wir selbst im Code organisieren mussten: Szenen, Oberfläche, Animationen und der Weg der Grafiken ins Spiel. Für ein neues Projekt würden wir heute Godot mit C# wählen. Nicht weil Go oder Ebitengine schlecht wären, sondern weil Editor und Szenensystem besser zu der Art passen, wie wir inzwischen Spiele bauen.
Die erste technische Entscheidung muss nicht für immer gelten. Sie muss die Idee spielbar machen. Unsere hat den ersten Zug auf die Strecke gebracht.
Aus dem kleinen Versuch wurde OshiYa, unser erstes Spiel, und um die Arbeit daran herum entstand JourneyBit Studio. Damals wollten wir nur verstehen, was an diesem Button so faszinierend ist. Wir drücken offenbar immer noch drauf.
OshiYa ansehenJourneyBit StudioRead in EnglishMehr aus SpieleAlle Beiträge