Spaceman
While studying at the University of Waterloo I took CS 446 the Software Design and Architecture. It was a course designed to teach students the fundamentals of designing and maintaining a clean and easy to work with code base. To provide students with practical experience with this the course asked students to choose a project and create and plan out a design and architecture for the code base. It was advised that you did not choose a game as you would not have much course time to implement it and would mostly be planning around how you would implement it. So my group made a game.
My group had these grand ideas of a Minecraft style of game where you managed your resources while travelling planet to planet to build a better ship to get to the center of the universe! We ended up creating this grand architecture for it and all the things we wanted to do and had art and design for it all.
However we only ended up having time to create the voxel system, procedural generation of the world, and the digging mechanics.
Most were implemented pretty well. We also had this weird idea of switching between top down and third person. With cool rendering issues.
However, I was particularly proud of what we accomplished in our implementation of the voxel system and terrain generation. For the most part the voxel system is very standard using chunking for performance, rending textures only if they had the potential to be seen by the player, and using a tiled texture and texture coordinates to dynamically render the proper section of the texture for a voxel. The terrain generation gave us a little more trouble. There seemed to be many different ways in which to accomplish what we wanted and weren’t sure where to start we eventually settled on our first approach.
Approach 1: Diamond Square Algorithm
The diamond square algorithm was the first algorithm me and one of my partners stumbled across. We ended up choosing it after looking at a few other methods because of how easy it was to implement and how quickly it allowed us to start focusing on other parts of the game. Without getting to much into the specifics the algorithm essentially chose mid points between diamonds and squares at the edges of the working space setting a height based on the heights of the points it is between with some variance and continually doing this until all x coordinates on a map have a corresponding y coordinate. The result which I do not have with me ending up looking similar to this
There were big dips with high peaks and it looked…alright. We both weren’t satisfied with how random the heights were. They were too random. It created these pillars in parts of the map and these big dips because the algorithm had to resolve the y coordinates between a very large dip and very high peak. It was also pretty limited in the size of words it would create would was a problem for us. For the most part it was alright but it wasn’t exactly what we were looking for. So despite our desire to move on to other things we both thought it was an interesting and challenging enough problem to give it one more try.
Approach 2: Perlin Noise
This produced much better results. It was harder to implement but allowed us to create better looking terrain and gave us more freedom over the shape of our world. Since all points in a region are determined use the same random values it felt that there was less random variance between nearby points solving our problem of these big shifts in the terrain.
I’m pretty happy with the results we were able to accomplish in the short amount of time we were given to work on it. We added some extras like trees and cows and the great antagonist Gideon! Id like to revisit the problem some time in the future with my current knowledge and see how much better I can make it.