BGP Week 2-3: Early level generation with splines

Big Game Project has started! For those who don’t now, Big Game Project (BGP) is the examinatory course of the program. It can be summarized as “create any game you want, with any team you can get your hands on, and with any production methods you want”. It is meant for us to show understanding of what we have been taught during these two years, and apply it.

I got hijacked into a team consisting of William Nordin, Laban Melander, Valdemar Ribbing and Ludwig Lindstål. They came to me with an idea of a game which combines F-Zero with VVVVVV. In short, a futuristic high-speed racing game consisting of two parallell tracks which can be swapped between at will. I liked the idea, and while I didn’t agree to work on it, neither did I deny it, so I just kinda went with it. I ended up taking the roles of lead programmer/producer (which is kinda stressful, but meh. I’ll handle it.) We also picked up Simon Brundin as a level designer, in order to move that task off our backs, as well as improve the quality of the levels.

As of this post, we have been in production for two weeks. During these weeks, I have been working on the system which we will use to generate the levels in the game. The system works by creating a spline (which is basically a line which is influenced by two other points to cause a 3D curve), and generate the level around that spline. This would allow the artists to only have to create one level piece, which then gets repeated throughout the entire level, meaning that they won’t have to create a billion different level parts (which would then have to manually get pieced together), nor would they have to do the whole thing in 3DS Max. The system would also be very quick to iterate in, since you would only need to adjust the spline, press generate, and test it again.

The idea for this sytem came from Valdemar, who also found a tutorial on splines from catlikecoding.com which explained in somewhat deep detail how splines worked, and how they could be implemented in Unity. This allowed me to have something working nearly right away, avoiding the headaches of trying to implement splines myself.

After following the tutorial, I was at a loss of how to progress forward. I knew that I would have to move individual vertices of each mesh to avoid having chunks of the track missing, but not much more than that. Therefore, I booked some tutoring from the programming tutor, who basically confirmed that my plan of moving the vertices was probably the best (or at least the simplest) way of doing it.

I got to work, and while I had some issues along the way (such as corrupting the default cube mesh in Unity >.>), most of it went smooth. After two and a half days of working on it, I can now generate cubes following the spline, and connect those.

Spline -> Objects -> “track”

This is still quite hardcoded, since it places the 12 back vertices (yep, 12.) at the same position as the 12 front vertices of the cube before it. This means it’ll break horribly if I try using it on something other than Unity’s default cube mesh, and this issue is what I’ll be working on fixing for next week. Doing it like this also means that the normals get messed up, as can be seen in the turns of the above image, since the objects aren’t rotating, causing the objects to end up inside out. I currently have no idea on how to fix that; I tried rotating the objects to face in the direction of that point on the spline, but that didn’t yield any results during my short testing period, so I temporarily gave up on it. I think there’s something similar to it which’ll work, though.

As for the hard coded vertex-problem, my current line of thought is to find out which vertices are on each respective end of a mesh by checking the highest and lowest local Z value, and find the vertices which share X and Y values between those “extremes”, and connect those. I might work on it some during the weekend, else it’ll have to wait until Monday.

The code can be found here for splines, and here for the level generation.