TRIALS OF NEWTON
Jimmy Griffiths | Programmer
Anthony Pascone | Programmer
Josh Mahler | Programmer
Trials of Newton is an advanced seminar for programmers game that me and 2 other programmers worked on. The idea behind it was to create a racing game like an arcade racer. The difference being that in one course, there are two tracks. Players can swap gravity to go between the two tracks.
My focuses included
Tools to help team members create tracks
Sound Design and Implementation
Level Generation posed an interesting design challenge. We wanted to have both procedurally generated levels, and levels that were created by hand. This would theoretically give the player infinite content, while also providing them tracks to improve their skills on.
Looking back, this was a bit over-scoped. We should have absolutely just picked one or the other. But, I had a lot of fun with generating levels.
To generate tracks, I did what I called the "oblong circle algorithm". I have no clue if it has a real name or not. But, I started with an oval. Then, I picked random points on that oval to move. Then, I walk around the oval, which is a skeleton of a track, to place the actual track pieces.
It worked fairly well. We would still run into issues where the turns would get messed up, and sometimes get reversed or something. But, I'd walk through the track again to place what we called "candies". Powerups, or hazards on the track, like a boost panel, or a black hole.
The level creation tool I created was a different beast entirely. I made a Unity GUI tool that could let designers load in different track pieces and candies, and then walk around to place them all aligned, rotate pieces, undo what they just did, and so on. Surprisingly, the hardest part of doing this was actually the undo functionality of it.
I wanted to do sound design and implementation for Trials. It was a fairly simple system. I made my own wrapper around Unity's audio player component, making "Ambient music" versus a "one shot". Then, I just had a general audio manager object that would be created at start, and load in all of the sound clips that we needed.
The audio manager would play sounds through only two audio components. Although I don't think memory fragmentation is that big of a deal anymore, I do like to optimize where I can. A practice I see that I don't like is to create a gameobject specifically for sound, create it, and then destroy it when it's done playing. I don't like that approach because it's slow, and in a non-GC language, could cause fragmentation. Therefore, I just had a map of one-shot sounds I could play, and avoid instantiating objects.
The UI in trials is... Okay. Wrestling with Unity's UI is a task in and of itself. So, I did my best to make centralized UI managers for each thing. For example, the title screen goes through a single manager. The car selection screen goes through a single manager.
What I should've done was try to make a generic UI manager that could just be thrown on to a canvas. Something that could just take C# actions, hand those to its buttons, and then go from there. But, I made some mistakes with my UI that I've learned from, and have avoided in my capstone architecture.
Although, I will say I'm very proud of the slide show that appears on the title screen. It was inspired by double buffering in graphics, where I have a frame drawn and presented to the screen, while I swap out the texture for a frame in the background to draw to, before cross fading.