Horizon is a music video game that was created to demonstrate the works of musician Jbox. It was made to shuffle through all of his songs and have elements that responded or acted along with the music. The game was focussed on the idea of a journey rather than a destination. So it was created to be an infinite drive game, with continuous terrain to focus on the journey. Another emphasis was on colour and colour explosions as this was a key thing that Jbox wanted from the game. We made a decent effort to create this but due to scheduling, format and communication faults and limitations, we weren’t able to fully accomplish this aim.
The terrain generation system was my main focus during development, since it was a key part of the game. I started by planning out how it would need to be put together. I knew that it’d need to be built out of preset pieces of terrain to create corners and bends in the road I decided these pieces would left and right turns, inward and outward S bends and a straight road. So I started by building these pieces inside of unity. I then needed to figure out how to create a system to piece them together one by one. This was done by instantiating the pieces one by one onto anchor points that were at the end of each piece and deleting the pieces after they were around for too long. This worked well but would often take the road too far from unity’s origin point and things would start to freak out graphics wize. So I needed to adjust the system to guide it back to the origin. But once it was doing that, I just needed to create more decorated versions of the terrain pieces to select when spawning and then it was done. I also had the car move along with the road through an animation, this could have been done better as the animations were quite clunky. The pieces of terrain that I created were also very clunky, I’m no 3D animator. It would have been great to have modeled terrain pieces rather than clunky pieces made from unity primitives. But our communications with our animators had problems and we weren’t able to fit the models into what we could get from them. You can read more about how I build the terrain generating system HERE
The next system I needed to create was the ability to change the time of day within the game smoothly with simple inputs. So, to start, I decided to create 3 states of time that would be used as our times of day. These were day, sunset, and night. The next step was to get predetermined positions, rotations and colours for all the elements that would change with the time. These elements being, the rotation of the sun and moon, the scale of the stars, the colour and rotation of the directional light, the offset of the skydome texture, the colour and emission of the headlights and the light level of the headlights. Once these were predetermined for each time state, all I needed to do was create lerps between the points when the time states were changed. I did this to change between songs, but also decided to make a steady transition between closer points during the songs, so it wouldn’t be so stagnant. This system worked on the most part, but at times had some issues with jumping elements. This is probably an issue with the preset values, since not all elements were doing it.
The shuffle player was a bit messy initially, because it wasn’t nailed down what needed to be in the script and what each song was going to need to reference. Also, initially I wasn’t working on this system, and only took over after the deadline got too close and the person working on it hadn’t completed it to the level it needed to be. So I stepped in to finish it off so we could ship it on time. The style of shuffle I aimed for was to play through all the available songs once in a random order before it plays any songs twice. This is how most shuffle systems work. The shuffle system would select a reference number to a song, that would also refer to many other variables, such as song lengths and assigned time of day. The shuffle system worked ok in the end, but because it was rushed, the coding was a bit inefficient.
As a team we work pretty well. We created a final product that was satisfactory to the client and ran in the formats it needed to. But at times our balance was a little bit off, and a large portion of the work was done by one person, this lead to multiple problems. The main problem was that the other members of the team didn’t know how parts of the game worked if they didn’t make it themselves, so it was difficult for others to take over and “share the load”. This was also a method of dealing with difficult schedules from some members of our team, which is what pushed us in the direction of unbalanced work loads. We also had communication issues with some of our collaborators and so we weren’t able to get that part of our game to it’s full potential, but some of that was outside of our control.