This and the past week have been the final periods of development on Sagittarii Run. A large amount of the time has been spent on bug fixing, such as a particularly critical bug involving rifts transporting players to the end of the race, as well as more miscellaneous issues such as GUI elements overlapping, the doors of the dropship not opening across the network, and the spectacle of ghost racers moving while tilted on their sides. The other large part of time has adding more spectacle and general eye candy to the track–such as giant ships flying overhead, meteors passing by racers, or the debris of destroyed ships becoming obstacles on the racetrack. At this point, one day away from the Senior Show, we have more or less entered a code freeze (short of a few remaining bugs) and will be spending the remainder of the time adding more eye candy to the tracks, and testing for any remaining bugs.
This week was largely spent on working with rifts, quality of life improvements, improving and implementing visual effects and spectacles, and finally general tweaks to hovercars and the race experience. A great deal of time was spent improving the visual effects generated by the rifts–this was done mainly through shaders, though strange-looking and moving textures further aided the goal of making rifts an intense, six-second race all its own. Additionally, the general difficulty of rifts have been increased, adding more, smaller sections that can drop from the platform, in addition to randomly positioned pillars, which act as both an additional obstacle and visual effect. When it came to implementing spectacles and eye-candy around the track, we’ve implemented systems to control and allow for interesting spectacles, such as laser cannons which shoot at, but do not hit, players, as well as an object that can spawn prefabs, and then have them move across various points. When it comes to the hovercar, we made some basic changes to their stats, though we intend to soon go into testing with drastically differently balanced car, so as to get a fully spectrum of player response before making the final tweaks to the systems.
This week a great amount of deal was spent tweaking existing systems, improving existing content, and attempting to add in and test the remaining pieces of content. A large portion of this time was spent with the rift system, which has not seen a large amount of focus since its initial conception and implementation. Entrances and exits for rifts have been updated, in addition to some quality-of-life and bug fixing adjustments–though there are still many improvements that need to be made. Additionally, time was spent on general improvements to play–mainly through adjustments on vehicle’s stats, which will soon serve to differentiate the four unique hovercars.
This week was largely spent working on the rift system, as well as implementing spectacles and their controlling systems. One spectacle we implemented was a laser cannon that gives the appearance of shooting at the players. In actually, however, the cannon shoots at predisposed locations containing targets. Should a player enter one of these locations, the cannon will no longer shoot at that targeting, so as to hopefully give the illusion that players are narrowly avoiding shots. In addition, a system will soon be implemented that controls various spectacles that will do fly-bys around the track. For example, an asteroid or fleet of ships might fly over or around players as they race through certain sections of the track. Finally, the rift system is in the process of being further tested, fixed, and tweaked, to make sure that it is both functional and evokes the desired experience.
Procedural Generation is content generation algorithmically, often on the fly. In order to separate this from solely a random number generator, my research has led me to add three additional qualifiers that are often present. The first is Rules, which are bounds that contain and shape the randomness. For example, a rule might be that all procedurally generated rooms must have at least one door. Next is Guidlines, which most often take the form of weighted actions or components. For example, filling a section of a room with furniture might be more common than filling it with supplies. Finally, there are Goals, which are what the procedural generation is designed to do. For example, generate a room.
Procedural Generation is used in a massive variety of ways, two of which are maze and terrain generation. There are a number of terrain generation algorithms, a smattering of which can be found here, which can be used not only to generate mazes of multiple dimensions(2D, 3D, hyper and above) but solve them as well. Further, each algorithm uniquely creates mazes. For example, some algorithms generate perfect mazes, which have no inaccessible areas, while others focus on specific types of corridors or directions.
Terrain generation can also be done in a number of ways, two of which are the Mid Point Displacement algorithm–also known as the Diamond-Square or Plasma algorithm) and Particle Deposition algorithm. The first works recursively, finding the center of the terrain, dividing it into four squares via points from the center, finding the centers of those squares, which are then further divided. The height of each point is then influenced by a random number, which decreases each time the function is called. The process repeats until there are no points remaining to be influenced. The Particle Deposition algorithm works by selecting a random point, changing its height, and then moves to a random neighbor to repeat the process for however many iterations. The process can be further altered by using the ‘Roll’ method, which checks to see if a random neighbor of the current point has a lower height value than the current point, and if so, influences the neighbor, rather than the current point. The Roll method often causes points that have been influenced to be more uniform to one another.
A final, and complex, means of procedural generation is Perlin Noise. Developed by Ken Perlin while working on the original Tron movie, Perlin Noise is a pseudorandom generator that can scale into multiple dimensions and be used in a variety of ways, such as terrain or texture generation. It is important to note that Ken Perlin more recently developed Simplex Noise, which is nearly identical to Perlin Noise, but much more efficient when scaling into higher dimensions–O(n2) vs. Perlin Noise’s O(2n). Perlin and Simplex Noise are pseudorandom because once seeded, a given point will always return the same random number, even if used multiple times in the random number generator. In the first dimension, Perlin and Simplex Noise can generate random points that appear very similar to audio waves. In the second dimension, the noise appears similar to TV static, though application of Fractional Brownian Motion will smooth the result into appearing like a cloud or gas. The third and fourth dimensions often see the inclusion of the z-axis and time, which higher dimensions adding additional properties as needed. Effectively, the algorithms work by altering a given point by gradient vectors, dependent on the number of dimensions. More detailed information can be found in the sources below.
Maze algorithm examples: http://www.jamisbuck.org/mazes/
Types of mazes and algorithms: http://www.astrolog.org/labyrnth/algrithm.htm
Example of Diamond-Square algorithm: http://paulboxley.com/blog/2011/03/terrain-generation-mark-one
Fractal Terrain and height maps: http://www.gameprogrammer.com/fractal.html
Spherical Landscape generation: http://freespace.virgin.net/hugo.elias/models/m_landsp.htm
Mid Point, Particle Deposition, and Smoothing algorithms: http://www.lighthouse3d.com/opengl/terrain/index.php3?introduction
Perlin and Simple Noise Information:
Using Perlin Noise in Games: http://devmag.org.za/2009/04/25/perlin-noise/
Intro to Perlin Noise: http://freespace.virgin.net/hugo.elias/models/m_perlin.htm
Math and desription of Perlin Noise: http://staffwww.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf
The math of Perlin Noise: http://webstaff.itn.liu.se/~stegu/TNM022-2005/perlinnoiselinks/perlin-noise-math-faq.html
This past week was spent tweaking numbers, and getting gravity, hovercar, bumper, and other associated systems working well together–by the end of the week, the game was truly beginning to look like a racer. We spent a good deal of time further adjusting the numbers controlling the functionality of the car. Specifically, we paid close attention to vertical damping–essentially the suspension of the car–and ended up making it less stiff, so that the car might navigate bumpy or uneven terrain and track transitions more smoothly. Additionally, we increased the height of the thrusters off the ground, as well as the force they are capable of putting out–again, these changes were made to give the car more play and controllability when navigating difficult terrain or track pieces. Finally, we ended up slightly decreasing the speed of the cars, so as to aid in both collision detection and player control.
A new feature of the gravity system was also implemented, and now allows gravity to be preemptively linearly interpolated to the gravity of the upcoming section. Essentially, this causes the car to transition to the different gravity of an upcoming area, allowing it to be prepared when the change occurs. This feature was added specifically to aid in the navigation of especially gravity-intensive sections, such as loop-de-loops and aileron rolls, as well as counteract the fact that the car is moving a high speed, and must rapidly adjust to changes in gravity. As a result, gravity transitions are far smoother, and players very rarely lose control at high speeds.
A final, and much needed system that was added was the bumper system. Essentially, the bumper system is made up of volumes along the edge of the track, which nudge cars towards the center of the track piece if they get far off course, as well as points them in the correct direction in the case of a crash. Essentially, this system is a way of helping keep players from flying off the tracking, an aid system for less skilled players, and a navigation system to always keep players racing in the correct direction.
Not a huge amount was done this week, as spring break occurred in the middle of the sprint. We’ve discovered that our analytics service is currently down for upgrades, so we haven’t gotten any testing data from their end, but we are still able to upload data to the database service through the analytics service, so some testing data, as well as high scores, can still be saved. This upcoming sprint will likely be spent on major testing to the cars and tracks, the user experience, attraction screen/demo reel material, and getting the arcade cabinet prepped for creation and use in the senior show.