Horizon post mortem

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.

 

Construction:

Terrain Gen

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

 

Time Changer

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.

 

Shuffle Player

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.
Team Work:

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.

 

Advertisements

How this project feels

Some people say it’s difficult working on someone else’s project, because it’s hard to find your own motivation. But with this current project, I haven’t been finding that. If anything, I’m finding it difficult to work on other things. This is probably because of a few things. Often with projects for clients, you are involved less in the construction of an idea than with a self directed project. But because our client was very loose with his plan, we as a team were able to form an idea together, which let me be influential on the idea process and have more passion for the project. Also, often people working on external clients projects find it difficult to have interest on what they’re working on, but with the need for a terrain generation system, I have always had something to focus my attention on with full interest. Ever since our client mentioned the desire for an infinite shuffle mode, I was thinking about a terrain generation system, and so I have been focussing a large amount of my attention on building the system as you can see in the previous blog. So I haven’t had to waste any time on finding motivation or passion since it was there from the start. The only difficulties in my understanding is a loose structure because of the clients broad idea from the beginning as I spoke about earlier and a confusion in the communication with our animators and our programmer, but this is most likely because I am not the project manager so it isn’t important for me to be communicating with these people, and I am just feeling stressed because I am not aware of every element of the project, which is something that I can’t do in my position (or probably will never be able to do without being the sole person working on the project). I could probably smooth this out by being in more contact with Izzy (our project manager) or to ask him to keep a better record of what our externals are doing. But I’m not sure that will fix anything because I already have a pretty good idea of what they are doing and I still feel this way. I can’t be certain, but it’s not a large amount of concern, since other than this, the project is going great.

Terrain Generation

So I’ve been working on a terrain generation system for the musicvideogame we are working on. This terrain generation is to allow the game to run for ever in it’s shuffle mode. To start with building it, I needed to have a collection of tiles that could fit together in any order and still look like a consistent road. To do this, I decided to have 5 different pieces to make up these tiles.

Road Bends

 

These pieces in order from left to right are the left turn, right turn, straight, outward S bend, and inward S bend. These pieces all needed to be oriented the same and have an anchor at the end of the road segment for the next piece. This lets me easily piece them together without any broken rotations. After the pieces were built(which took forever) I needed to create a script that would place them one after another in a general road structure. To do this I needed to have the script randomly pick a piece, and to place it at the same position as the next anchor at the end of the road. It then needed to reassign the next anchor and loop. This resulted with something like this.

Copy of terrain gen

 

But of course this wasn’t done, the road was always crossing itself and never deleted the earlier pieces. So, I decided to make the road have a limited length. To do this I made each piece be a part of a set array that cycled through. Each time a new piece was created the oldest piece was deleted to make room for it. I also created a system to limit the number of corners the road could take to prevent looping. I did this by only letting the road make a left or right turn every 10 pieces, and when it had the opportunity to create a corner, it was still only a 1 in 5 chance. This new system created a road that moved like this (sorry for the small size). 

terrain gen mkII

 

So this was now creating a road that would snake around the world all crazy like, but the car wouldn’t follow it. So I needed to make a collection of animations that would move the car along with the road. With these animations, it was extremely important to make them pass through the anchors, otherwise the car would drift away from the road over time. Also with the new animations, I was able to get the code running every time an animation ended instead of in update, meaning that the road could move along with the road. Also to have a reference to the animations names, rather than creating scripts for the pieces of road to hold the names, I added them as tags to the object, letting me reference the object’s tag as the string for which animation to play. This new update to the system let me have the car drive along with the road, meaning in some form, it was ‘done’. But, an issue with unity is that the further away from the origin you get, the less accurate the positions get, which cause shadow to flicker as the road got further and further from the origin. This was a big problem for a game that is focussing on visual pleasing scenes. To fix this, I needed to alter how the road would decide whether to use a left or right turn. To do this, I added a variable that would track the way that the road was heading (cardinal directions based off Z+ being north) and then depending on the direction it was traveling and the position on the x or z axis, it would pick a corner that would lead it back to the origin. But the problem with this system is that id would eventually just create a forever looping circle that would only ever pick left or right and never a mix of the two. So I decided to add a function that would let it randomly pick a corner or straight if the road was within 1000 units of the origin. Which resulted in this wonderful road.

terrain gen Fixed
After this I needed to tweak the anchors and the animations to not have holes in the road or big jutting out walls. But that is all I have done to the terrain generation system so far. I still want to make the road pick a type of terrain based on some sort of curve so that we can have more than the cliff face we have right now, but I need to work on creating the tiles for those first before I can create a system to spawn them as part of the road. But that task is for later, as I also need this system to spawn decorations such as beach furniture and boats. 

Making progress

 

So we’re working with a client, as I’ve already spoken about earlier. But, how’s it going? Well that’s a good question. Like most things, it’s a mix of good and bad. So far, what we have created for the project has been received really well by our client. But this is what worries me. Because I still feel as though our scope is too unclear, so it feels like pretty much everything is good which means we have no direction. It feels like we don’t have a clear idea of the visual style of the game and the mechanics seem unclear. We know we want a car that drives down a road while the music changes elements on the road. But the movement of the car, the songs we use, what elements we change, and how the road functions all seem to be unclear. I know this is part of the project being still in development, but I feel like this is something that could cause problems on the next few days. But onto more positive things, our client is definitely happy with what we have made so far. This: drive loop w trees (8)
I need to talk to the team more to make sure that is just me who is worried about the scope. I’m sure it’s just me overreacting. If I can talk to the team we can get solutions to these unknowns that make me worried. Another thing I am worried about is what I am meant to be doing next. After I created the basics for the level, I was left with not much to do, so I went ahead and started working on a terrain generator. But I’m not sure if I’m jumping the gun or avoiding working on a more important thing that I don’t know about. I could probably talk to our project lead to figure out what I’m meant to do. So far though, he seems to be ok with me working on the terrain generating system. It’s looking like the microsoft pipes screen saver:Copy of terrain gen

How do others do music?

So when considering the fact we are working on a musicvideogame, it would probably be a good idea to look at how other audio driven games function and how they emphasise on their music. So to start this, I had a look BIT.TRIP runner 2 <insert rest of title here>. The way the game takes traditional Mario style platforming and turns it into a music driven experience. All the collectables and obstacles in the game correspond with beats or a melody of sorts. But while they are placed this way, does not make each the same tone based on what they are, even when they are played a second time if the player fails to complete the run on the first try(which happened to me a lot). This made it feel like you were composing the music every time you ran the level because each time you ran it was something new. This was a good look at something that took a game and made music with it, but the musicvideogame we are trying to make is much more focused on the music and a laid back feeling then BIT.TRIP runner 2. So i moved on to looking at Panoramical. This was so much more fitting to our goal with what our game. While it is still a live composition of the music, it is so much more laid back. So looking more into Panoramical’s methods I could see that it didn’t focus on keeping to the music with every element of the level, and often just kept the feeling with the music. This also happened most with the steady music pieces, so when the music was upbeat and fast pace it would keep with the notes. So with what we are creating, like my previous blog post about this game, it would be good for us to focus on keeping with the notes and beats. But, like with Panoramical, we should keep away from drastic changes unless we are aiming to emphasise heavily on the beats. Something else that Panoramical does really well is it’s capacity for visually pleasing combinations of elements. There are many occasions where you can combine the pieces just right to make something that is pleasing to the eye. So this is something we need to focus on when choosing our colours and where they appear in the screen.