This article by Maike Thies originally appeared in DP 04 : 2014.
There really are many racing games: But in “Krautscape”, developers Mario von Rickenbach and Michael Burgdorfer give players more freedom and a say in the course of the game – thanks to procedurally generated tracks. The game project, which was created at the Zurich University of the Arts, was released on Steam.
The special highlight of “Krautscape”: By navigating his racing car, the player influences the course of the track. This is only built during the race, so the leading player decides where to go in the future. To give the whole thing even more pizzazz, the individual racing cars have been equipped with wings. This allows entire sections of the track to be skipped along with their rivals. “Krautscape” is designed as a multiplayer game that can be played in three modes. In “Snake” mode, the aim is to build as many track sections as possible in order to score points, while in “Collector” mode, the aim is to reach a floating cube, which must be collected and brought to the end of the track. In “Ping-Pong” mode, the increasingly long track is travelled alternately in both directions. For “Krautscape”, the two game designers chose a reduced visual language that combines low-poly geometry with bright colours. The sound design by Phil McCammon emphasises the gaming experience with a challenging beat.
Basic idea and concept
The idea for the project came to game designers Mario and Michael in 2009 as part of a teaching module in the Game Design specialisation at Zurich University of the Arts (ZHdK). The parameters given were “multiplayer” and “network-orientated game design”.
Under the supervision of lecturers René Bauer and Max Moswitzer, a first functional prototype was created, built in Unity. This envisaged the following arrangement for navigating the vehicle: The vehicle travelled on a small surface, at the end of each one a trigger was placed, which generated another surface in the process of driving through it, which was aligned differently depending on the position and speed of the vehicle. For example, if the car passed the area on the left-hand side, this element was rotated to the left around the y-axis (yaw), creating a left-hand bend. At the same time, the local x-rotation (pitch) of the next element was dependent on the speed of the vehicle, so that at high speed it was slowed down by the upward inclination and vice versa. This first functional prototype was built in just one afternoon on the basis of a test vehicle that had proven itself in previous physics tests – and it worked straight away. Prior to this, the two developers had built vehicles in prototypes using the Unity physics engine to test the functions of the wheel collider implemented in the engine.
Modelling in Blender
The vehicle was modelled and animated in Blender. The development team decided in favour of Blender because it corresponds to their development philosophy: a platform-independent, compact tool with all the necessary functions and easy export to Unity, which is also available free of charge. In addition, since version 2.5, Blender’s animation tools in particular have been very clearly laid out and well designed. The ease of switching between Mac OSX and Windows was a particularly important point, because Mario, who was responsible for most of the 3D models and the vehicle, regularly switched from his main computer, a MacBook Pro, to various secondary computers running Windows for testing purposes. With 3ds Max this would not have been possible at all, with Maya there could have been licence problems – with Blender it was only a ten-second download. The entire project was also designed in such a way that it could be opened at any time within 30 minutes on a newly installed system – whether Windows or Mac – with Github access to the game repository, including download and installation of all software. Blender was also new to the two developers at the start of the project, but it proved to be very reliable and flexible during the development and production of the models. There were neither import problems nor major difficulties with the programme itself, apart from a short familiarisation phase at the beginning. Mario will probably not go back to 3ds Max, which he used to work with regularly, for his next projects: “The days of cumbersome, expensive 3D programmes that only run on one platform are finally over.”
Further development of the track construction system
Although the system developed for building the racetrack worked straight away, the lack of real bends resulted in an angular track appearance, which was also difficult to drive due to the lack of transitions. The solution: a trigger was placed on a small area at the end of each bend, which generated another area as the car drove through it, which was orientated differently depending on the position and speed of the vehicle. For example, if the car passed the area on the left-hand side, this element was rotated to the left around the y-axis (yaw), creating a left-hand bend. At the same time, the local x-rotation (pitch) of the next element depended on the speed of the vehicle, so that at high speed it was slowed down by the upward inclination and vice versa.
This first functional prototype was built in just one afternoon on the basis of a test vehicle that had proven itself in previous physics tests – and it worked straight away. Prior to this, the two developers had built vehicles in prototypes using the Unity physics engine to test the functions of the wheel collider implemented in the engine. Modelling in Blender The vehicle was modelled and animated in Blender. The development team decided in favour of Blender because it corresponds to their development philosophy: a platform-independent, compact tool with all the necessary functions and easy export to Unity, which is also available free of charge. In addition, since version 2.5, Blender’s animation tools in particular have been very clearly laid out and well designed. The ease of switching between Mac OSX and Windows was a particularly important point, because Mario, who was responsible for most of the 3D models and the vehicle, regularly switched from his main computer, a MacBook Pro, to various secondary computers running Windows for testing purposes. With 3ds Max this would not have been possible at all, with Maya there could have been licence problems – with Blender it was only a ten-second download. The entire project was also designed in such a way that it could be opened at any time within 30 minutes on a newly installed system – whether Windows or Mac – with Github access to the game repository, including download and installation of all software. Blender was also new to the two developers at the start of the project, but it proved to be very reliable and flexible during the development and production of the models. There were neither import problems nor major difficulties with the programme itself, apart from a short familiarisation phase at the beginning. Mario will probably not go back to 3ds Max, which he used to work with regularly, for his next projects: “The days of cumbersome, expensive 3D programmes that only run on one platform are finally over.” Further development of the track construction system Although the system developed for building the racetrack worked straight away, the lack of real bends resulted in an angular track look, which was also difficult to drive due to the lack of transitions. The solution: curved elements that fitted together exactly at the seams. Mario and Michael generated the track elements by extruding cutting moulds/shapes along a line. They each produced both a high-resolution mesh, which acted as a collision object, and a lower-resolution object with fewer extrusion steps, which could be displayed in the distance using Unity’s level-of-detail system to save performance.
To increase the fun of the game, the two game designers implemented the option of switching between different shapes. This means that the track has small walls on the outside at certain points to prevent the racing car from crashing. Manually designed elements are used for the transitions, which make the change from one shape to the next drivable.
The students also used special elements and obstacles that can be activated by the pursuers so that the leading player is slowed down – similar to “Mario Kart”. The obstacles are activated by switches on the ground, which regularly appear on the track. The obstacles include specially shaped elements such as loops or lanes as well as normal track sections with attachments, such as walls.
The two game designers also implemented automatically generated supports, which are occasionally built at the bottom of the track elements to give the game environment more structure. For time reasons, the aim was to create the entire environment with as little handcrafted content as possible throughout the track production process. At the same time, they were also able to deepen their knowledge of procedurally generated game content. In particular, the manual generation of the track meshes by code via the Unity Mesh API turned out to be a very powerful tool. The team was unable to use any ready-made libraries or engines because the generated track had to fulfil very specific conditions as it has a major impact on the gameplay and driving physics.
Networking & Server
A major technical issue was the development of a network-based game such as “Krautscape” at server level: How are the players connected to each other? How is the gameplay synchronised? What happens when players want to play online? Are there already existing servers or do players have to start their own? As “Krautscape” is entirely focussed on multiplayer mode, Mario and Michael decided to design the system so that the servers are provided by the game. The aim was to ensure an optimal gaming experience and performance and to minimise the usual problems with firewalls and port sharing.
The team encountered problems early on in the development of the network architecture: although Unity supports network-based projects, the tools offered proved to be rudimentary and limited in comparison with other engines. For example, it is not possible to easily start and control several instances of a game in parallel, which is necessary for the simultaneous races.
During their research into alternatives, they became aware of the possibility of building a network using the Photon framework. This server offering initially proved to be easily scalable and scored points with its integrated lobby system, which enables parallel game instances. However, the two game designers ultimately decided against it, as the server runs completely independently of Unity. As a result, they would have had to program and synchronise the entire physics calculation of the track separately on the server. This was clearly too time-consuming and costly for them, so they finally decided in favour of uLink & uLobby from MuchDifferent. The server platform offers an excellent mix of good scalability and practical application. In terms of their network structure, the system built into Unity and uLink & uLobby are very similar. Nevertheless, extensions such as the uLobby Server and the uZone Instance Manager as well as a login system with an attached database are convincing.
When switching to the uLink library, the game could almost be left in the structure of the already implemented Unity Networking. However, Mario and Michael had the extended features of the framework at their disposal with this variant – a big plus. With this solution, an instance of the actual Unity-based game could be started for each race. The race was now controlled by the uLobby server in cooperation with the uZone Instance Manager. This variant worked satisfactorily for the two game designers, although the framework is not equally well developed in all parts.
Workflow Patcher
Mario and Michael were confronted with a fundamental workflow problem in multiplayer games with online servers during their game development. During the first test phase of “Krautscape”, the question quickly arose as to how new game versions could be easily sent to testers to ensure that everyone was always playing the latest version. Of course, the servers also need to be updated regularly. The two game designers tested various options: For example, they produced a build at regular intervals and ensured that the testers downloaded this latest version immediately. In this case, the correct version had to be uploaded to the server at the same time. In principle, this variant worked well, but it took a lot of time and was anything but flexible.
Finally, Mario and Michael developed an extended automatic patcher based on the M2H patcher from the Unity Asset Store. From then on, they could create a new build for all platforms (PC/Mac/Linux) and generate patches for all versions at the touch of a button, upload them accordingly and update the respective version number online. With the help of this tool, all testers can simply restart “Krautscape” after an update and automatically find the latest version. The same applies to the server: Here, too, the version is always updated to the latest version, as this is also updated when the game is started. The patches take into account all changes to the previous version, which the “bsdiff” programme calculates for each file when generating the patch. The changes to all files are packaged together with a list of all changes in a zip file and released for download as a patch.
Each time the game is started, the system checks online which of the available versions is the latest and searches for the appropriate patches so that the latest online version can be played. Mario added that this scanning phase for minor updates would take place so quickly that the player would hardly notice it.
Programming effort
Despite the obviously well-developed basic functions of the M2H patcher, the two game designers did not show themselves to be alThe team deliberately focussed on a fictitious and eccentric environment in order to set “Krautscape” apart from realistic racing games. The project is named after a certain Dr Konrad von Krautkopf. It must have been around 1880, Karl Benz would still need a few years before he would bring his first motorised car with an internal combustion engine onto the market, when a pioneering idea sprang from the whimsical mind of inventor Dr Konrad von Krautkopf. He imagined a machine that would not only drive on the road with a high number of horsepower, but would also be able to fly over short distances. Krautkopf called this vehicle the “Krautomobile” or “Krauto”. He also envisaged a system that would equip the vehicles with a simple control mechanism that would have enabled the drivers to build roads while driving. Dr von Krautkopf conceived his system as an efficient and practical alternative to existing means of transport. He also toyed with the idea of generating unusual routes with the system for specific occasions, such as car races. If the explanations on the “Krautscape” website are to be believed, the two game designers Mario von Rickenbach and Michael Burgdorfer have realised Krautkopf’s never-realised vision in virtual space based on the highly detailed original plans. The story behind “Krautscape” The first prototype was still very rudimentary, but worked surprisingly well. Depending on where and at what speed the vehicle passes through the trigger at the end of the track, the subsequent element has a different orientation. They were missing some features that were important to them, which they ended up developing themselves: Release channels, patcher updates and various other improvements.
With the basic version, it was not possible to release builds from different computers and there was only one release channel. However, different release types with different options were planned as part of the “Krautscape” project: A beta version for testers, the internal test version for the development team as well as a special master build for the uLobby master server were planned. All of these builds are configured differently, but are based on the same Unity project.
Mario and Michael also developed a way to update the patcher programme themselves. These patcher updates ensured that the patcher application itself was updated at regular intervals, greatly increasing the flexibility of the project work. Bug fixes are possible in this variant for the patching system, which means that players never have to download the game again completely. This made it possible to release a new version of the game in just a few minutes. This solution is particularly helpful for small bug fixes and online test sessions.
Project progress
The first trailer for the game was completed in 2010 after a relatively short phase of further development following the end of their studies. in 2011, the two game designers submitted their project to the Swiss Arts Council Pro Helvetia’s Call for Projects and were successful in the competition with “Krautscape”. It was only thanks to the funding that the two were able to continue the project after completing their studies. During the one-year production period of the Call for Projects, they reprogrammed large parts of the game. There were structural problems with the networking and driving behaviour in particular, which were easier to solve by reprogramming these parts based on the new conditions instead of improving them with incremental changes.
During this phase of the game, the two game designers benefited from project pitches and conversations with experts at industry meetings and festivals. This enabled them to gradually approach the marketable character of the game. From mid-2012, Mario and Michael were invited to festivals and exhibitions with “Krautscape”. for example, “Krautscape” was shown at the Gaîte Lyrique (Paris) as part of the Play Along exhibition and was also honoured with the Best In Play Award at the GDC Play (San Francisco). A game presentation at the Tokyo Game Show proved to be particularly profitable. There, an audience with an affinity for games engaged with the games and gave constructive feedback.
At the end of 2012, Michael left the team for professional reasons and Mario continued working on the project alone. It was only during the finalisation process of the game that he brought in fellow student Flurin Jenal as an assistant in summer 2013 to ensure the early completion of the game. At the end of summer 2013, “Krautscape” went online on Greenlight and was accepted by the community. This step brought “Krautscape” to the attention of publisher Midnight City(www.midnightcity.com). As of April 2014, you can now play the game on Steam via Early Access(store.steampowered.com/app/268360).
Zurich University of the Arts (ZHdK)
The Zurich University of the Arts(www.zhdk.ch) offers a six-semester Bachelor’s programme and a three-semester Master’s programme in Game Design that focuses on the conceptual, creative, technological and practical application of computer game design.
The Game Design specialisation focuses on the culture and design of interactive games. Within the programme, students acquire fundamental subject-related knowledge in the context of game development projects and deepen their knowledge by studying analysis, planning and implementation techniques. The aim of all projects is generally the development of fully functional games or game prototypes. The BA programme has a generalist structure. The central components of game design are covered by offering learning modules that build on each other thematically.
The Bachelor of Arts in Game Design programme is a six-semester full-time course. The curriculum offers modules and courses in the following subject areas: Game Culture, Storytelling, Game Mechanics, Programming, Usability Design, Game Conception, Game Analysis, Game Business, Media Management, Visual Techniques, Game Engine Programming, Game Design Projects, Character Design, 3D Modelling & Animation.
The Master’s programme Game Design is a focus within the Interaction specialisation, which specialises in training versatile and innovative experts in the fields of interaction design and game design. The Master of Arts in Design programme offers four subject areas – Collaborative Worlds, Game Production, Ludic Game Art and Serious Games – which guarantee an in-depth practical and academic examination of areas of contemporary game design over three semesters
