Open World Runner
Hannes Saariste, Lauri Leiten, Renee Kroon
Brief Description
Open World Runner is basically a running simulator on steroids (aka driving a bike simulator not on steroidsbecause driving while on steroids is illegal) with its procedurally generated world. In Beta release player can look around and explore what the simulator is capable to generate. Also there are yellow targets appearing that you can try to collect. Every world is different.
Prepeare yourself for the video demonstration
Game Screenshots
What we had at start
What we have accomplished
More about the simulator and how did our work go
So finally the simulator didn't have as magnificent graphics as we wanted to do. Also there was a lot more work than we thought there would be. Also we didn't use any premade assets from the asset store. Making everything from start wasn't that fast and easy but we got it done and i think we are pretty satisfied with what we have done. I think we have learned a lot from this project since we tried to make everything ourselves. That's why it wont look that good but for us its pretty awesome that we have made something like that.
Who did what and how
Hannes Saariste worked on the map generation.
Basically the simulator is using default Unity Terrain for terrain creation. The heights are generated using Perlin noise and some local variables. Depending on the height the type of land changes from green grass - dirt-ish thing - snow. It took some time to get everything working since it seems like there's not much information about changing unity Terrain from code. Now according to terrain heights also grass and stones are generated. At low lands there's really thick grass that starts to get thinner when height increases. At snowy places also some rocks are being generated. Most of the details generations are done by some defined heights, height ranges and randoms. For every detail resolution pixel on the terrain if the "random says so" we generate some kind of grass or stone. Also the random chance decreases for grass when the height increases.
The infinte terrain is done by having 9 different terrain chunks each 512x512, which are moved when player leaves from the center terrain. Lets say player moves from center chunk to north chunk, so all the 9 tiles are moved north so center takes the old north place and all the other chunks move one chunk north as well. now all the chunks generate new data according to position. Thats not the best way to implement it since it takes around 1 sec to load when entering new chunk at the moment but it works. For optimization i tried to save 6 chunks TerrainData and pass it and only generate 3 new chunk TerrainData but it didn't seem to have an notable impact on performance. One idea i had was to use tons of really small chunks but i think unity Terrain just isn't for procedurally generated worlds.
In the end I would say Unity Terrain is pretty awful for doing generation from code. It's okay for some premade terrain made with brushes etc but not that good for modifying from the code. Lets not even think about some optimized stuff with better grass, more effects, trees etc etc. But i think that's pretty awesome what it came out in the end.
Lauri Leiten worked on menus and clouds.
The menu has four different options: play the game, change the options, show credits (who made the game) and a quit game button (that only works on runtime version due to Unity's limitations). The menu was made using Unity's built-in UI elements. In the options menu you can only change the quality of the game graphics (the options for the game graphics are Unity's QualitySettings levels). After changing the selected option in the dropdown menu the quality setting is changed.
The clouds are generated using a custom script, the script generates an amount of clouds in one ingame tile (512x512), the quality of the clouds isn't the best - they look similiar to Minecraft clouds. The generated clouds are instantiated from a prefab and they move on the X axis on a set speed. When a cloud goes outside of the borders (outside of the 'tiled' area) the cloud is destroyed.
Renee Kroon worked on the character, bike and camera movement.
The bike works by using a rigidbody. To make the bike a bike and not a plane it checks the distance to ground with a raycast and you can only control the bike when it is close to the ground. Finding the right forces to apply to the bike and make it feel usable was difficult, in the end the bike is still a little too slippery and floaty. I also used rigidbody (torque) to keep the bike from falling over - that worked quite well after I changed the bike's collider to capsule.
The camera was built from scratch and went through quite a few iterations. Eventually I managed to get the camera controllable using a mouse and follow the bike smoothly and not go under the terrain. Looking up and down was achieved with a simple trick - by simply making the camera look at a position a little bit higher or lower. I initially made the camera movement smooth because the bike was really jerky when moving. Smoothing the camera didn't help though, and I found out that the stuttering was there because I didn't interpolate the rigidbody.
The character was our initial plan for the game that was later replaced with the bike. Character was able to move and jump, with rotation controlled by the mouse - that's how much was already done before we decided not to use it. There were some problems - for example, because it was not using a rigidbody the movement on the terrain didn't feel quite smooth. Most of the code for character was reused for the camera or developed into the bike.
I also added the yellow target circle thingies. That was fairly easy to do because I just had to use a trigger collider and teleport the circle to a random location nearby after the bike hit it.
Repo
Our final release is pretty much the latest version at github.
Add to this page a clear description, links (to repo / webpage), images (screenshots), the final report, anything else you think is cool.