KamiKatze: Random map generator

In order to improve replayability and diversity, we decided to implement a random map generator. Especially during the last project (Tiny Taxis) we had wanted to implement multiple maps but the priority of this feature was too low and there were always more important things to do. Therefore, we decided this time to directly start with a map generator to have diversity early on.

Every map consists of a certain amount of manually built tiles. These tiles are like a small map containing obstacles, buttons, triggerables, spawn- and powerup markers. Also, some meta information is included in order to properly align the tiles on the map and to allow interactions between different tiles.

Blocking and connectivity

Figure 1: Tile template

Figure 1 represents the raw tile template. In every direction there are two areas marked. As part of the meta information, it is stored whether these areas are "free" or "blocked". This information is important to make sure the map is connected. The free areas are also not only marked as free, but also with a connectivity number. This allows a single tile to have multiple partly connected areas.

Figure 2: Tile with seperated areas

There is a third state which we called “semi” which is meant for areas which might be free under certain circumstances. Mainly the idea was a laser wall which can be turned off by a button. But as the button is only on one side you are not always able to walk through this passage but only if you come from a certain direction. Therefore we cannot say this way is free but we want to make sure the algorithm doesn’t place a wall directly behind that “semi” passage as this would completely remove the possibility to use the passage. Therefore, the only thing the “semi” state does is to make sure the opposite area is “free”.

This method is not perfect as you are only allowed to mark an area as “free” if the whole area is not blocked. As soon as any part is blocked you are not allowed to mark it as free as the counterpart might have exactly the other part partialy blocked. Other than that there might be additional gaps between tiles somewhere in between. In the beginning, we had a tile template with only a single area per direction which felt too limiting due to the issues mentioned here. But with the two areas per direction this system works for us even though there is room for improvement.

Map generation
Now let's finally talk about the actual map generation step. We have defined different tiles as mentioned above. Every map has a set of options to define how the map should be generated.

Figure 3: Map Settings

First, you define all the tiles which might be used by this map. Then you define the size (where the values for width and height represent the number of tiles in the respective direction). Finally, you have the option to say that the map should be mirrored. This option was introduced to make the maps look more “planned” as if they were handcrafted.

There are a few more options which will not be discussed as they are not relevant for the map creation process. To generate the map, the following algorithm is applied:

1. Pick a random free position in the map.
2. Chooses a tile with a weighted random algorithm (e.g. already used tiles get their weight decreased).
3. Choose a random rotation for that tile.
4. Also place dependent tiles. E.g. if the mirror flag is set place the same tile with the inverse rotation on the opposite position of the map.
5. Check if the map is completely connected (by assuming that all free tiles are connected in all directions)
   • If everything is connected go to step (1) until the map is fully filled
   • If not undo all steps until (3) and try another rotation. If no other rotation exists go to step (2) and choose another tile. If there is no other tile left place a “fallback” tile which is an empty tile with connections in every direction.

Once the algorithm has successfully generated the map, we create the Unity game objects. Finally, we connect free triggers and free triggerables together so that you might press a button on one end of the map and something happens somewhere else.

Figure 4: The final generated Map

Perspective and tile rotation
Some of our graphics have a perspective. This prevents us from rotating the graphics. Therefore we need a solution to still be able to freely rotate the tiles even though some graphics cannot be rotated. We introduced two different concepts for that, the first one is simple: if the blocking of the object with the perspective graphic is symmetrical we can just keep the graphic in the same rotation independent of the tile rotation. If the blocking is not symmetric we need another solution: we need to have different graphics (which might even show different things) for different rotations and just switch between them depending on the target rotation.

There might be small inconsistencies in the blocking of rotated objects sometimes, but all in all it seems to work fine.

Figure 5: A perspective pile of pipes in the 4 main directions

Lessons Learned: Let’s Get The Party Started

Our first project Mages had some organizational issues which in the end led to some major problems. We especially suffered from a long development time with large breaks in between and a certain loss of motivation. For Tiny Taxis it was still not perfect, but we improved a lot on the organizational part. Here we want to share some ideas on how to get started.

1. Find your team
Making games in a team makes much more fun. Therefore, try finding some people to do a project with. Different team members can contribute different skills and you can learn from each other. I think the team should not get too big, we were about 5 people for our projects. When your team gets too big you have a lot more coordination work to do. Also, the bigger the team gets the more the expectations and opinions differ and in the end you need to bring them all together. You can still work with a big team but from my point of view it’s better to start off small.

2. Know what you want
Before searching for a concrete project idea you should meet up - virtually or in person - and find out what you want. What conditions do you want to apply to your project? You are free in your choices but make sure you are all on the same page. Here are some ideas. You don’t need to use all of them, maybe you have totally different conditions. Just make sure your whole team is starting with the same destination in mind:

• Are there limitations in the program you want to create? Should it be a game? A chat program? A pizza baking robot?
• Is there a certain technology you want to use? A certain game engine? A certain programming language?
• Are there features you want / don’t want? For what later became Tiny Taxis we decided e.g. early on that - after the multiplayer game Mages - we wanted to do a singleplayer game this time.
• Maybe even something unexpected like “We only want to use 2 colors”. This is done in some game jams and can really fire up your creativity.

There are also some organizational topics you should clarify before diving into the search for a project idea:

1. What is the motivation of every team member? Getting rich, gaining experience in realising a project with a team, having a finished project to attach to an application, learning to work in Unity, gaining experience in network programming, just having fun, ...
   Make sure that your expectations overlap. E.g. if one member of your team wants to get rich but the others want to experiment and learn a new programming language this might not match.
2. What is the timeframe you want to realise your project in? I think it’s important to have a deadline, we did not have one for our Mages project and this might have been the biggest issue. A deadline gives your project structure, allows you to prioritize and makes it easier to keep focus on the end product.
3. What do you expect from each of your team members? How much time do you expect them to work on the project every week? Do you want to meet weekly? For us a weekly meeting really helped to finish our project. It’s just a stronger obligation and you are more motivated because you can show your results regularly.

It is very important to talk about these topics early on and to make sure everyone is on track and has similar expectations for the project.

3. Find your project
We met all together and everyone could bring as many ideas as he wanted as long as they met the constraints we had agreed on. We then presented every idea and had a discussion about what we like and what may be problems (e.g. too big for our timeframe). Some ideas were also created during the meeting by combining different proposals. We then voted for our favorites and after an arduous process found an idea everyone was happy about. It is very important that all members are on board and motivated.

4. Before you start
Now we have our team and our project but the last step before we start is to define milestones until the end of the project. We decided to have one milestone every month. Now is the time to dive into the detailed planning and define goals for every milestone. Don’t forget stuff like polishing and bugfixing (for us the whole last milestone was left for this). Also keep in mind that you need time for publishing your game, so put it in your planning!
Meet after every milestone and discuss how well you are in time. Does everything work out as planned? Has something to be shifted to the next milestone? Is it still possible to reach the goal within time? Do we have to change prioritise?

5. After you finished
Show your project to others and celebrate!
You might feel a bit unsatisfied when you see your product because you know all the bugs and all the tiny flaws. You had this great dream and now reality got in the way. But remember what you have accomplished! You created and finished your project and it - kind of - works. Showing it to others helps you to see all the things you have accomplished! You’ll be surprised how other people see your game.
For Mages we had a small party in the end, we invited friends, presented our project, had a tournament, and a drink. We just showed what we had done. It was very motivating seeing people play our game and to hear what they like and what they don’t like. It was a great happy ending for our project!

For Tiny Taxis we are now in the last week before the release party. Let’s see how that works out :-)

Open Source Random Name Generator

Mages would not have been possible without the great open-source tools that helped us draw magicians, make connections, render worlds and much more. To say thank you to the community, we extract parts of our games that could be useful for others and publish them. This time: Our random names generator.

When building the lobby for Mages, we decided that the user would not need to type in a username. While a unique player identifier makes sense if you're playing in a massive multiplayer world, you do not really need it if you compete in a LAN game with your friends sitting in the same room. On the other hand, we still wanted to count the victories and identifying yourself with a colored number just doesn't feel right. That's why we decided to give the whole naming thing a little twist and add a random name generator, so that now Pyromancer Tohon the Fat can fight against Goddess Neziqua the Provident.

A lot of name generators out there in the wild are based on US census data. It's a large source, available for public use and it even comes with frequencies if you want to build a fancy probabilistic model and not just pick name parts randomly. However, if you ask me, Jack Taylor and Helen Wirght do not really sound like mighty wizards ready for battle (ok, there are exceptions). Other name lists sound more like fantasy but are not suited for commercial use.

Therefore, we let our creative team create our own lists with titles, forenames, last names and epithets which can be combined to over 4 million unique names. We have uploaded both the name parts and a Java implementation of a random name generator to GitHub. It's free and can be used for non-commercial and commercial projects. So, next time you need some names for brave knights and old wizards, take a look at this list and tell us where you used it afterwards! As always, if you have any questions, do not hesitate to contact us.

Lessons Learned: Multiplayer

No matter if it is a LAN party with your friends or an online multiplayer game, playing together with other people is fun (at least most of the time ;-). In our first sessions of this project, we juggled with a lot of ideas before settling on what became Mages: a side-scroll shooter where you could influence gravity, a mobile zombie apocalypse settlement builder, a strategic micro-management fantasy fighting game, ... Looking back, I noticed that nearly all of our ideas had one thing in common: they heavily relayed on multiplayer mechanics. Turns out, these are quite difficult to implement. Both from a technical and from a gameplay perspective, multiplayer presents a lot of challenges. In this article I'll write down some thoughts on what worked out and what not in these two areas.

Technical challenges
Early in the beginning, Jonas set up a command-based architecture which worked out really well. If you summon a fire projectile, the physic system decides to destroy a wall after a collision or the game mechanics notice that the game is over, every change is done by a command. The acting element (user controller, physics, etc.) will send a corresponding command object to the lobby (see the illustration). Based on the observer pattern different handlers listen at the lobby for new commands. Once a new command arrives at the lobby, each listener decides if it wants to handle this command or just ignore it. If it wants to handle it, it might send it over the network to the other players' lobbies or just apply it locally. Only when a command object's apply function is called, the fireballs are created, the walls destroyed or the game ended.

Exemplifying illustration of the command architecture used.

This architecture has the big advantage that game mechanics and network are clearly separated. If I want to add a new element to the game, let's say a fire-ball throwing minion, I first create the minion class to represent it. I then create a SummonMinionCommand class that extends from WorldCommands. In there I define all the game mechanics necessary for summon a minion: removing some of the player's mana, binding the minion to the corresponding mage, etc. I then only have to make sure that when the player clicks on the right button a SummonMinionCommand is send to the lobby. Since this is a WorldCommand the correct handler will pick it up and the minion will magically appear in every players' world without me having to worry about any network stuff. I'm simplifying a bit, but just a bit.

The commands can also be reused very nicely. If you take a look into our map files (in the directory res/maps the .map files), you can see that all objects in the environment (barrels, trees, rivers and so on) are defined as JSON-serialized object creating commands. We do not need to create any object-specific map loading code. Our map-loader just turns the JSON-commands into Java objects and sends them to the lobby letting the handlers take care of that. So far, so good. Let's come to the parts that did not work out that well.

We wrote a lot of code for serializing our commands to and deserializing them from JSON. Boring work that mostly could have been done by libraries like GSON or Jackson Annotations.

Sending some commands through the network is rather easy. But then all the little and not so little details start haunting you. One major problem is player lag, even in a local network. It can cause synchronization errors if a player tries to move an object that is already destroyed on the host. It can make objects jump in the clients' game worlds which looks really bad. Or it can make a client player's action have a totally different effect just because the fireball was on a slightly different place on the host machine. Especially for a fast-paced game, fixing these problems is essential. We spent a lot of time on them, adding e.g. tricks to resynchronize a client without the player noticing, but we have to admit that we are still not satisfied with it.

Gameplay
Developing a multiplayer game might seem easier than having to develop a complex AI. Just let the players play. But there are some caveats to this. Gameplay or mechanics are crucial for a game. A player might forgive a small bug now and then. But if playing the game does not feel right, he or she just won't like the game. And while fixing a bug in the later stages of your game is usually a minor task, fixing mechanics is much more difficult. One pain point of multiplayer mechanics is balancing. For a single player game slight (!) balancing is usually easier: if the level is not hard enough, you add some more enemy minions, the level is too difficult, you lower the end bosses health. In player versus player fights, you have much more combinations because each party can adapt their tactics independently. You might think that making the fireball a bit faster is the right thing to do. But this might change the opponent's strategy, which you can not control since it is another human, completely. And the more game mechanics you add, the more complicated this gets.

In an intermediate state Mages had much more weapons to offer. Apart from fire and earth projectiles and walls, you could cast a shield, summon totems that threw fire projectiles and slowed enemy objects. And there was a third element "Arcane" giving you bouncing projectiles, shooting rays and mana regeneration spots. But balancing did not work out. The fire projectile generating totem was e.g. either way to strong, basically giving you free fire projectiles all the time. Or it was much to expensive, causing players to never summon it. We then decided to remove all these parts and concentrate on a reduced amount of mechanics but getting these right. Still, it hurt to throw all these half-finished parts away.

Some elements that did not make it into the final prototype.

Summing Up
There is probably a reason why many successful small developers produce single player games even though their game ideas would have allowed to add multiplayer parts (FTL, World of Goo, Mini Metro, Prison Architect just to name a few). World of Goo and Prison Architect allow some indirect interactions between players (sharing highscores and maps) but that's it. Sticking to single player removes a lot of burden on the technical side. Also, testing your game gets easier because you need to coordinate with less people, in particular when getting feedback from external people. Although creating games that allow people to interact with each other in manifold ways is fascinating, if this is your first project, I'd recommend to start with a single player game and focus on the mechanics that make your game special.

Lessons learned: Never heard of Multithreading?

When you played the game (which you hopefully did!) you might have stumbled accross your game freezing for a moment. If not, it happens if you play via network and your friend (or oponent) did not click at the end of the match to start the next round. You might think: "A frozen GUI, have you never heard of multithreading?".

Well, yes we heard about multithreading... but we didn't use it. In the beginning of the development phase, one thread can probably do all the rendering, physics and world mechanics. And starting small is definitely a good idea. But multithreading is one of these topics you want to start thinking about early on. The first time we had to worry about it, was when we added an AI. My plan was to let the AI calculate all the moves in another thread and let it compute its (his? her?) ingenious masterplan undisturbed from the other game mechanics. An easy change I thought, but then OpenGL started to complain because I wanted to modify it from the wrong thread. And soon I was drowning in ConcurrentModificationExceptions. In the end I had to wade through a lot of our core code and refactore a lot of it. Well, to be honest, my implementation probably wasn't the best idea. But we are here to learn from our mistakes. Therefore, some tips if you want to do it right:

• Start thinking about it early on, even if you might need it only later.
• Create an architecture that takes care of the threading. If you have to assume that every function may be accessed from multiple threads concurrently, you need to write much more code, it's more error prone and probably quite slow. Instead, build an architecture that defines which classes/functions are accessed by which thread and how and when threads are allowed to share data or communicate between each other.
• Make sure your render pipeline has its own thread and a clear interface. This will actually result in some additional code because you really need to seperate the visual representation from the game object in order for this to work. But it will result in your game having consistent fps without freezes and you have no issues with OpenGL contexts.

Lessons Learned: Singletons

Let's assume we all know what singletons are. In Mages we only used a few of them. It felt very naturally to use a singleton for handling resources and our sound is also managed by a singleton implementation. For all other parts of our architecture we decided not to use them. We want to discuss why and analysis if this was a good decision.

By giving an object all its dependencies through the constructor or through initialization methods, one can directly determine how a class interacts with other classes. All dependencies are exposed through the interface. When using singletons, this is not the case. A class can have an empty constructor, might take no parameters and you still don't know what dependencies are hidden below the surface.

However, this caused convoluted dependency between our classes. In the end, many classes got access to the World instance because it was an "easy" way to reach nearly everything from there. And those classes that could not get direct access to the world, had to use long dependency chains. This made a separation of our code difficult if not impossible.

With singletons you get direct access to the dependencies your class needs. You do not have to restructure your code all the time to get this access to your dependencies. Also your code gets cleaner. A game often has many objects that represent a certain state. And a lot of the classes need to access these states. Examples are the network, the world and different resources. Manager classes which handle these states need to be accessible by different parts of your game in very diverse sections of your object graph. A button in the UI, a collision effect in your world or your background music DJ, all belong to very different parts of your game and all need to play sounds. Sometimes, like with background music, even over different stages of your game (different menus, during loading screens, in game, etc.).

There exist some side considerations:

Singleton users are hard to test. It's more difficult to test a class in a contained environment if it has possible dependencies to singletons. You need to set up a whole environment to ensure your code is running properly which makes it harder to write small testcases without a big overhead.

Context classes are another alternative. These have pointers to the resource manager, the network and all the classes that are frequently needed by others. This context is propagated downwards through the call hierarchy. A bit like our World class, but just focusing on being a context and not incorporating additional game logic. One advantage is a gain in flexibility. Imagine you want to go from single player to local split screen. Now some singletons like the camera or the player are no longer alone but have a twin. With context classes this is easier to refactor.

There are many more pros and cons for singletons, but it's getting late and the new alpha version still has to be packaged. So we'd like to refer you to the world wide web for that or your favorite book on patterns.

Singletons do not release you from thinking about your architecture. Neither are they the solution to all your dependency problems. But we think it is worth taking them into consideration and for the next project we will probably use them more frequently.

Get the latest news about Little Factory and their games by joining our newsletter. Don't worry, we send mails with low frequency, but when we send something, it's worth it!

Questions? Bugs? Criticism? Praise? Don't hesitate and just contact us at