This is part of a set of blog posts this week about a lot of tasks we accomplished during an “open lab” week to finish off the game and test the game for both playability and performance.
Last week, I implemented a scrolling background into our game to give the sense of movement that the player plane was flying forward.
The scrolling code was very simple to do using only 2 background objects. How it worked was you set the speed and direction you wanted the GameObject to move then once it reached a certain point, it would look back up to its original position and repeat. In this case, the certain point was the length of the Sprite so as soon as the GameObject had moved it’s own length, it would then set the position back to it’s original one. The use of Mathf.Repeat helped simplify the movement code as it ensured a value was kept within a certain range and if it went beyond that range, it would loop back around to the start and add the difference on.
The code is simple, robust and is easy to read so I am happy with it. Using the y size of the Sprite means this script can be easily added onto any other GameObject with a SpriteRenderer and have that be used as a scrolling object without needing to calculate the length of it in Unity’s world units. Although there isn’t a specific I would improve this script, I would like to improve the background scrolling system overall. This would be done by allowing some randomness so the surface underneath you doesn’t feel as repetitive as different background sprites would be used. The sprites could also be randomly offset along the x axis too, to give more variance to the terrain.
As part our team project, we are creating a game so therefore we need some way to all have access to the latest code and art. Thus we decided to use Git as it’s pretty much the industry standard and fantastic. However unfortunately by default Unity and Git don’t really play well together (as I learned from spending easily 2+ hours resolving merge conflicts and still having issues). Thankfully, Unity release a tool with Unity 5 called UnityYAMLMerge to help with these situations. You can read more about it here if you’re interested.
Anyway getting Git and the tool to work was fairly easy, it just requires some editing of files but can be quite confusing for users new to Git. Hence writing this guide! Hopefully you’ll find it useful but leave a comment if you run into any issues and I’ll try to help 🙂
This also assumes you have already setup a basic Git repository.
Having a .gitignore file means that Git will ignore certain files and folders which is useful in this situation as we don’t need to commit everything Unity generates, saving both space and time.
This is an important step to prevent Git from trying to auto resolve merge conflicts which can break scenes most often.
This part is the tricky part as it will require a few file tweaks. It will also vary depending upon the merge and diff tool you prefer as well as the way you interact with Git (Whether via command line or a GUI such as SourceTree)
For the purpose of this guide, I will use KDiff3 however you can set up UnityYAMLMerge to use your preferred tool (and it has some as default configurations for some tools)
Unity has a manual entry here however some information is incorrect (such as setting up in the .gitconfig file). The first part of the guide is also not neeed
This is an important step and allows you to still resolve normal conflicts as well as resolve scene and prefab conflicts after UnityYAMLMerge fixes them.
Now that UnityYAMLMerge is setup, we need to tell Git to use it for resolving conflicts. This again heavily depends upon how you interact with Git so your experience may vary.
You’re all setup and ready to go now! Try merging two different versions of scenes and see what happens. What you’ll find UnityYAMLMerge does is try to automatically merge them as much as possible (including component deletion/additions) but not on the variables. This will use your fallback merger that was setup earlier and that works the same way as your usual merge, thus preventing scenes from completely breaking.
Scenes may still break, this tool tries its best but it’s not always perfect. Avoid large merge conflicts by merging together every now and then (don’t let it go weeks) to reduce the chance of anything exploding.
The .git* files can viewed as part of this gist in case you don’t want to download them.
This week we presented a presentation of our game in the current state as well as updated our hardware report based on feedback we received. Some development work was also done on the game however some of it was a quick fix to get a working demo for the presentation and other was not completed in time for it.