Will2Bill

This is the final log that is required for submission, though I intend to keep making posts on a semi-weekly basis in order to track my progress as the project goes on for the next month and a half.

Complete So Far:

The goal when I set out was to create a cycling game that procedurally generated the world around you as you cycled along its roads. I wanted it to create unique and strange environments that instilled in the player a sense of wonder and mystery as they explored.

In its current form my game is capable of generating new environments infinitely ahead of the player as they ride, proceeding in any direction. Though there are as yet few environments, the ones I have built are visually interesting to cycle through. The number of environment types will be substantially increased once the base game has been built (it is harder to test problems and make changes if you have already spent time making a lot of environments). The whole process went through quite a few iterations before I was able to get the terrains generating in a satisfactory and consistent manner.

Player movement was another key element in developing the game. I need the player character to move and control like an actual bike, in order to better bring them into the game world. The process of refinement is not quite complete (the player moves a little too fast currently), but the bike movement does at least feel natural. Your top speed varies depending on whether or not you are on a slope for example. Even without further tweaking, the controls are pleasant to use and successfully create the sensation of zipping through the terrain on a bike.

Creating Terrain features is the main focus of my work currently. One way of make my created environments more unique, and making it seem like I have more unique terrains than I have actually built, is to procedurally generate terrain features. This is things like trees, rocks, bushes, and buildings. Having a wide variety of terrain features that are placed procedurally means that even when a player passes through the same terrain, it will look different because of the unique arrangement of features. The development of this phase is still in its infancy though. A number of features have been built so far and the programs required to select them are mostly in place, but as yet the actual generation has not been successfully implemented

Still to come:

The main goal for the immediate future is successfully implementing the feature generation system. Once I have this (plus a few adjustments to complete the basic system) in place I can release my first playable demo. This is key in getting the feedback I need now, before work begins in earnest on the final write up.

The final development hurdle in the works is implementing the ‘game’ aspect of this procedural system. The game aspect I intended to build into the system was a sort of postal delivery, with letters that describe a path you need to take in order to reach a delivery spot (delivering about four letters over the course of the game). The development of this feature has taken a back seat to the more important task of generating the actual world, but now that the end is in sight it needs more attention. How exactly I will implement it though, and even whether or not it is necessary, will depend significantly on the feedback received from the first public demo. If players find that simply riding around is satisfactory, and they don’t long for more, that might mean the ‘gamey’ elements were not necessary to begin with. Other games in this same vein have described similar responses from their fans.

Beyond these two main goals, and working on the final write up, the main use of my time will be expanding the system.  More terrains to ride through and more features to decorate them. The more of these available to the system, the more effective it can be in bringing the player in.

Supervisor Meeting:

The supervisor meeting was unfortunately cut short, so we were unable to have a full discussion over what was achieved last week. Jeremy Gow was pleased with the progress on the player controls and terrain generation system, suggesting a few minor changes but otherwise agreeing that that section of the project can be considered effectively done. He suggested I focus in the next week/over the Easter break on two main steps. Develop the system need to place ‘decorations’ on the terrains. This means building 3D objects of trees and rocks, sheds, anything I want to see placed in the world ahead of the player. Then I will need to develop the generation system for these objects that chooses what objects get placed where. He suggested I focus on keeping objects as abstract as possible to avoid complications and keep with my initial vision of the game.

Plans for the week ahead:

• Create a range of basic 3D environmental objects (like shards, trees, rocks, etc)
• Build a network of waypoints on my current terrains that the generator will use as targets for the prefabs
• Create a script/interface and several scripts to handle the selection and placement of prefabs
• Once this system is working, decide on an appropriate terrain size (1000 or 2000) to avoid pop-in and seeing the edges of terrain, then remake the current maps to suit the new setup
• Decide on whether or not to implement some kind of Mountain -entry/exit terrain type

Progress So far:

Over the course of the week I built a few example terrain features, simple trees and crystal-looking shards. I didn’t bother creating a large number of types as their main purpose for now was to test that the feature generation system works. As of the end of the week I was able to get the generator to place a selection of objects at specific waypoints distributed around the terrain. At this current point in time they are entirely random (between one of the prefabs or nothing) but the proof of concept is there and the system only needs refinement.

I was also able to implement a simple wave function on the water tiles to make the water seem more believable and interesting, though the function could be refined further. As yet though, the work on this is low priority.

Supervisor Meeting:

We discussed the setbacks over the past two weeks and the choice facing me between a terrain system that goes everywhere (but requires much more work) and a terrain system that essentially follows a single line, with only minor deviations up and down before returning to the straight line. Jeremy’s advise was to build the generation system so that it could do the first one, but for now to build the tiles to fit the simpler second system. The generation system should be able to do either, and doing so would result in a system I can expand easily.

Together we agreed that the plan for this week would be to completely finish the generation system (barring later refinement) and significantly expand the number of landscape tiles available in the system in order to create a complete workable prototype.

Where to go from here:

• Complete the generation system
• Fix bike controls

Achieved Last Week:

Over the course of the week I refined the terrain generation system so that it could simply and effectively place terrains in any direction I required, based on what exits were available on each terrain prefab. The system is now fully capable of generating the required terrains and currently only needs refining to complete the process.

I also improved the bike controls. Bike no longer floats when going over terrain of variable height. Bike also speeds up going downhill and slows down uphill. Turning remains a bit awkward however and may need refining.

Achieved Last Week:

This week was focussed mainly on programming. I needed to develop the terrain generation system with a focus on trying to implement rotation of the terrain and dynamic terrain placement so that each terrain tile could be used in a wider range of circumstances and I could reduce any sensation of repetition. Part of this involved separating the generation system from the tile’s themselves.

Development went through three rewrites as I worked.

The first attempt involved developing a Tile interface that would govern a series of scripts attached to terrain types. Using this the terrain generator class could control them in a generic way when selecting and creating terrains. The problem however was that this resulted in complex and inefficient interactions with the terrain objects. The inability to create an instance of one of the classes that used the Tile interface (as they had to use the MonoBehaviour interface from Unity) was also severely limiting. After nearly a week trying to make it work I abandoned this attempt.

My second attempt went nowhere fast. It involved developing a Tile class to control interactions with the terrains, while still attaching the unique terrain classes to their tiles. It was slightly more efficient than the the first system, but still made for awkward and complex interactions.

In my third rewrite I finally separated terrain controllers from the terrain objects. I created a separate interface called TerrainController that will be used by subclasses like DefaultTerrain and MountainTerrain. These classes instantiate the terrain object and access a simplified Tile class that all terrains use. Only attaching a single simple class to the terrains makes it considerably easier to deal with terrains in a uniform manor and place them in the desired location without trouble. Having the more complex classes that use TerrainController separate from the terrains themselves allows me to separate a lot of the unique generation systems (like which terrain of a certain type to instantiate) from the TerrainGenerator class. Overall this system is much more straightforward and inefficient, and would have been perfect except for the next problem.

When I was finally able to run my code and test if the placement and rotation systems were working I discovered a huge flaw in my thinking up to this point. I had assumed the Terrain objects work essentially like all objects in Unity. I knew they could be moved, as that was how I made the initial working prototype. I assumed that rotation would work as well.

I was mistaken. As it turn out, rotation of Tile’s is completely impossible in Unity. It appears to be a side effect of some of the optimisation they did to make Terrain’s work in the first place. Unfortunately, much of my planned development hinged on the idea that Terrain could be rotated freely. Without this ability I would be unable to reuse tiles when the road forks, for instance.

**Note, there was no supervisor meeting this week as I was sick**

Where to go from here:

The rotation problem means I have to put some time into considering my options. There are essentially two ways ahead. Build a terrain object in Blender (or some such utility) and import that across into Unity. This promises to be incredibly complicated and may cause a whole host of new problems when it comes time to start decorating the terrain.

The better, albeit not great, option is to change up my system to involve dedicated vertical tiles (entering from the top or bottom of the tile) and dedicated horizontal tiles (entering from left or right of the tile). With some variations. It means a fair bit more design work, but it will probably be the only effective solution to my problem. My work over the next week will be getting this system working, and developing a wider range of tiles for use in this system.

Achieved Last Week:

Last week my two main goals was to make a series of decisions regarding how the program will be structure, and second to build a basic prototype of the system.

On the first point I reached the following conclusions

Select what tile system will be used

My original ideas for the tile system involved using transition tiles and full tiles to ensure the transition between tiles/biomes was natural. In brainstorming how I wanted these tiles to function I cam up with an alternative, superior method. Instead of having a variety of transition tiles to try and blend the variety of tiles I would create an official ‘default environment’. The edges of all biomes would return to this default tile type to ensure that the tiles would always be able to connect to the next tile.

Biomes will generally be followed by default tiles, though by making sure tiles always end in the default the system will be able to place two biomes next to each other without their different environments clashing.

In some cases though a biome will extend across several tiles. These will be built in the following way: entry tiles will transition from the default to the biome type, those transition tiles will always be followed by a ‘middle tile type’ that features only that  biome type, then that will be followed by a transition tile back out (or perhaps another of the middle types). This allows large environment types to exist, without overly complicating the existing system.

Select what size the large tiles and transition tiles will be & Choose other aspects like default height

By getting rid of transition tiles, I can be very flexible with the type of tiles being used. My system of placing a waypoint and the entrance/exit to ever road on the terrain allows me to place tiles of any height, and any size/shape, so long as I am able line up the roads. This means my system has great flexibility and allows a wide range of tiles without adding much complexity.

Build prototype that can place multiple tiles ahead of each other, connected by a road

This was the most important thing accomplished this week. Getting a working prototype prepared was absolutely essential to proving the viability of my program going ahead. I needed to be able to demonstrate that my program would be able to do what I wanted it to. So I set about working on the prototype in, admittedly, it’s most basic form.

The process was mostly straightforward, simply telling the program to instantiate a prefab. I had two environments to generate to make the road of my prototype. The procedure wasn’t without problems however.

The first was figuring out how to translate the generated prefab to the correct place in the unity world (ie, at the end of the road of the current tile, with its own road connecting seamlessly). This turned out to be a much less complicated problem than I was thinking. I was trying to translate the waypoint attached to the road, but this didn’t move the whole terrain. What I ended up doing was just finding the translation necessary to move those tiles, and then applying it to the whole terrain.

The next problem, which is not entirely fixed at the current point in time, was figuring out which direction the terrain would face when generated. If the terrain comes out in the wrong way it can end up overlapping the environment it is meant to follow. While I wasn’t able to find a good consistent way to fix this problem (in the sense of the larger game) I was able to get the current two environments consistently facing in the right direction for the prototype.

I discovered a handy way to get around the problem of players going offroad by setting up invisible cubes at the edges of the road. Aside from this success though, the player movement was a disaster. I was unable to set up the ability to turn for this prototype, and for some reason gravity wasn’t affecting the player normally (resulting in the floaty movement seen below). I decided to let it go for this prototype though as the main aim was to get the generation working correctly.

A final problem that was, thankfully, quickly overcome was figuring out how to decide when the program should generate a new tile. As I had built the generation system into the tiles themselves, I was able to overcome this using triggers, only generating a next tile after the player enters the current one. This system worked quite efficiently for the basic prototype, but will probably need revising in a larger system. For instance, if the player reverses back into a previous tile, then heads forward again, the system doubles up the generated tiles (do this enough times and the system will overload).

All in all, the system has some problems but I was able to get a functional prototype together that successfully demonstrates the viability of the game.

Supervisor Meeting:

In the supervisor meeting I showed Jeremy Gow the working prototype of my procedural generation system (shown above) and discussed the problems encountered in implementing. He recommended I separate the tile generation from the tile’s themselves and make some refinements in the system. Otherwise we decided that development should continue as is, expanding the number of tiles available and refining how the tile generation works.

Goals for Next Week:

• Work out what direction terrain tiles are facing when placed in the unity environment
• From this, work out how they need to be rotated in order to consistently line up and have multiple entries/exits
• Research procedural generation methods and styles to decide on the ideal method of picking the next tiles in the sequence
• Separate the terrain generator program from the terrain itself
• Create the ‘default’ tile type and test turning functions
• Fix the physics problems in the player controls and work out how to let it turn
• Test to see if choice works
• Confirm the system functions with very different tile heights, bending roads, etc
• Create the c# Interface that will be used for each environment type

Achieved Last Week:

The reading week was mostly taken up with work on the Preliminary Project Report, which was completed and submitted on Friday the 19th.

My other task for the week was to build a paper prototype of the tile generation system to demonstrate the way tiles would be placed ahead of the rider and how choices (turns in the road) will be handled. I developed models of two different systems that could both work for my needs.

Both systems use two types of tiles, large terrain tiles and smaller transition tiles. The large tiles (represented by the large squares) are generally a whole biome and are the ‘main feature’ of the game. They have the most interesting and varied environments to ride through. The smaller tiles are used to smooth out the transition between two biome tiles. They flatten out the environment and merge the landscape colours etc.

System A

The first system keeps the large tiles more scenic by making them roads you only drive through.  The transition tiles are used as choice tiles and provide the user with the option to pick from two directions and choose which way to go in order to progress towards the goal. This highlights the journey through the large tiles by removing any distractions as you witness the created scenes. It does however limit the variation of road and choice types and could create a sense that the scenery is just meant to be passed through and not experienced.

System B

The second system is essentially the reverse of the first. The choice tiles are also the large tiles, with anywhere from 1 to 4 roads leaving/entering the biome. The transition tiles are kept more simple with just a road passing through. This has the benefit of causing the cycle to spend less time in the more boring transition environments, but can clutter the larger environments with more roads.

Supervisor Meeting:

In the meeting we discussed the work done on my Preliminary Project Report and agreed that it needed more information on the planned procedural generation techniques and discussion of the tile system, but was otherwise decent.

We also agreed that this week needed to be a ‘decision week’, where I pinned down some of the exact specific about how the game will work in order to begin actual development of tiles etc. This includes choosing what tile system (as described above) would be used and more technical features like the size of the terrain tiles (if consistent) and how the road will be constructed.

Goals for the following Week:

• Select what tile system will be used
• Select what size the large tiles and transition tiles will be
• Choose other aspects like default height etc.
• Build prototype that can place multiple tiles ahead of each other, connected by a road.

Achieved this week:

This week I began work on the kind of tiles that will make generated world of the game. This generally involved playing around with the built in terrain creator in Unity to try and create some interesting environments.

Here are some of the scenes created to start with:

High shot of the mountain tile

Shot from the road – the view that the rider will have in game

Broad shot of the mountain world

Terraced hillscapes. No road as the tile isn’t complete.

Supervisor Meeting:

In the supervisor meeting we discussed the design work that had been done and decided that the current goal over the next two weeks was to build and design a paper model of the tile system my game will implement. From there I would need to start designing and building actual tiles in Unity and begin work on a true prototype.

Goal for the following week:

• Build a paper model to experiment with and demonstrate the type of connections
• Build a prototype in unity that can generate and connect multiple tiles.
• Write and hand in the Preliminary Report this coming friday.

Achieved this week
The focus this week remained on the design side with a lot of time spent working out how exactly the game tiles would work. I planned out how I would build them using Unity and what aspects of them would be subject to procedural generation.
In addition to more design sketches, I created a basic prototype of the smaller road prefab that will be laid across the created maps. I also attached a script that would generate new instances of the prefab (just drawing out a straight line of road for now) to make sure it works.
Finally I added to my research base by looking into more articles and related games and clarifying the results of my study into Walking Simulators/Exploration Games.

Supervisor Meeting:
As I was sick this week there was unfortunately no supervisor meeting or guidance provided.

Goal for the following week:
Coming up next I need to begin work building prototype maps that can be cycled across in game. I will also need look at and begin work on the first submission, the Preliminary Project Report due on the 19th Feb.

Achieved this week:

The goal going into this week was to work out exactly what role interaction would play in my games. Figuring this out was a key element in proceeding with the design planning and beginning work on the prototype.

Working this out involved a considerable amount of research into what other games of similar nature where doing. I read a variety of articles (and watched several videos) on the subject of Walking Simulators and Exploration games (the two genres closest to what I am doing). I also played a few related games like Sanctuary by Connor Sherlock, Ruah by Tristain Dale, and Endless Express by Florian Veltman.

The conclusion I found was that there are effectively While the majority of ‘walking simulators’ are a means of telling a story, the games that come closest to what I am trying to do are more focussed on the actual experience of the world than using it for a story. These are games like the ones above and the more well known Proteus by Twisted Tree Studios. These games sought to creator an experience and atmosphere in their game world. The actual ‘gameplay’ part was usually limited to a quite simple process of getting to 4-5 things within the world. The ‘gameplay’ just gave a reason to be wandering, without becoming the focus of the experience.

Inspired by my findings I came up with a reason for a player to be cycling down the generated roads of my world. The player would be a postal worker on a bike, cycling on their delivery route. They would have about five letters to delivery (either selected from a pool or generated randomly) that would indicate a specific area of the procedurally generated world. By following the address hints in the letters, they can choose which fork in the road to take and thus eventually reach their destination and deliver the letter.

Supervisor Meeting:

In the meeting we discussed the gameplay concept I had come up with and agreed it was suitable for Zen and the Art of Bicycling. The task I was assigned to work on this week was to start working on design specifics of ZAB; to illustrate the sort of scenes I would like to see, and create examples of the flora and fauna I would like to see in the world I would be generating.

Goal for the following week:

Most of the week was spent sketching various ideas about the world (some of which are below). I tried to work out what sort of visuals I wanted to see in the world I would generate, as well as some puzzling regarding exactly how the world would be arranged. I also spent a bit of timing learning Blender in preparation for the work I would need to do designing the assets for the game.

A standard desert scene, based on the experiences of my own bicycle journey across Australia. Can be made more fantastical by what populates it and the colours of things like the sky and ground.

An example of a fork in the road (one of the decision points) that will give players the option of turning towards the place described on their letter.

A more detailed view of the bicycle handlebars. This will be at the bottom of the screen of the player as they go.
This will be most/all of the UI for the player, including the current letter, a light, and perhaps a speed/distance counter.

One of the more fantastical scenes I would like to see. The road stretches out with the sea (or a vast lake) on either side. Water stretches as far as the eye can see.

Another possible scene, the cyclists going down a road in a vast forest, trees stretching up to the sky.

Rolling hills populated by strange trees.

Some sketch ideas of weird trees.

An idea for how the generated tiles may connect together and how the choices may work.

Another possible way the addresses and choices could be arranged. The lines of the address each describe a nearer ring.

Achieved this week:

The main focus in week one was getting everything set up and getting a plan in place for what needed to be done in the coming weeks. This meant creating the Gitlab project, this blog, and the Unity project itself.

The next step was to sketch out a more detailed outline of what I needed to create for my project. This involved breaking down the project into it’s core components and then figuring out what each one would need, and what I would need to research in order to develop them to the level I wanted. Broadly speaking I broke the project down into five categories: the Bicycle, the Road, the World, the decorations, and the Movement (or Interaction). From there I began listing elements of these that I would need, and researching those I didn’t know about.

Supervisor Meeting:

In my supervisor meeting we discussed some of the research that needed to be addressed, but focussed mainly on the element of interaction as a starting point to how my game would be developed. The game experience is inherently that of exploration and discovery, but player autonomy is an important factor when creating a game of any kind, and deciding on the best way to implement it in Zen and the Art of Bicycling (ZAB) is a factor I have yet to decide on. I was advised in the meeting to look at how other games within this or related genres have handled this issue.

Goal for the following week:

To begin with I need to look at a variety of games that deal with exploration. Primarily this involves games in the Walking Simulator and Exploration genres. Looking at reviews and studies of those genres as well will give me insight into the kind of experience players want out of these games.

In addition I plan to do some design work, sketching some of the environments and scenarios I envisage for my game so I can begin work on their creation.