Day4: Level Loader, Locale and Languages

My Sprint ends on Friday, that leaves me two more days to finish the first Milestone: A…

Playable Prototype

with the following things:

  • tutorial
    • levels are played one after the other
  • input is complete
    • user can lay tracks
    • user can press validate
    • user can jump between the levels
  • validation is complete
  • validation works
  • user gets feedback of the validation

So lets walk through each one.




The level loader plumbing was finished yesterday. Today I finalized to integration on the UI. The user is now presented with the tasks for the level. I replaced the colored squares with some icons for the requested trains in green and the forbidden trains in red. I also gave the station types more distitinguishable icons.

show levels.
The tutorial levels introduce the mechanics one by one:

Later I want the tutorial to explain each mechanic:

  • Get trains from left to right
  • trains need to pass stations
  • You might need to get more than one type of train into the station
  • There are multiple station types
  • Trains can pass multiple stations and their order matters
  • There are orders of stationtypes that are not allowed


So the levels are there. They can be loaded, and are stored in a json format. Like that I can later simply add a new file for a second set of levels. There are some great tutorials  to see how one can approach serialization: Tutorial

The first coded tutorial levels. Also the keys to the names can be seen here.

Its some kind of common knowledge, that you should start thinking about localization right away. You can see in the json file, that I kind of did that. Instead of giving the names here, I gave keys. I can list all my keys in a in a csv spreadsheet, and extract the language properties easily. The localization is fogiving: when a value is not given in a locale, it tries the default language (english) and if that also fails, the key is presented.



Following the list above, the user can indeed lay down the tracks, and build the buildings. He can also press validate. This currently leads to the next level. from a UI perspective, I think it would not be good to have a forward and backward button directly on the screen, but I might do that in the menu. The thing that worries me today a bit is the validation, which is probably the hardest piece of code and one of the most important features for this week. I probably could have started with some things today, but I procrastinated with other features.

So let me commit for tomorrow:

We will see a validation happening, and it will work.

I am convinced this can be done. Before actually starting in Unity I made a paper prototyp and the validation question arose back then. What I have here is a Non-Deterministic finite automaton. Each station passed represents a letter in the word. Each tile has 8 states – 2 per edge, one of which is an “in” node, and the other is an “out” node. To nodes along edges of neighbouring tiles connect from out to in. Inside a tile edges are connected in pairs from in to out. That way, I can build my graph. A building on a tile represents that each edge inside the graph has a letter depending on the building type attached.

This is the underlying model for a  horizontal tile

So I know what  I will have to build. I have noticed in earlier situations that when I know what to do, I tend to procrastinate the doing to a later point in time (most of the time luckily before it actually needs to be done) and priorize other stuff.


So given I keep my promise to myself and the world that would leave my Friday for testing on mobile devices. I will see then, if not doing that till now was a good idea. <- do you see me procastinating?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s