Dev Blog: Unity

Blog Post 8 – Unity

Unity is a game engine, and is used to make every aspect of Jazz and Azul work. I’m Unity you can assign code to objects in order to control movement, place and position lighting within a scene, control camera movements and structure different scenes of a game. Prior to this project, myself and Jess had some experience with the software, she had a lot of hands of experience with the program from her role in a different game project the year before, I myself, had been taught the basics of it in the first year of university, and dedicated the summer before third year to touch up on this buried knowledge. Although programming isn’t something I necessarily enjoy, with such a small team of myself and Jess, it was understood that we would need to work together to get the game working smoothly. With some outside help and advice we have been able to teach ourselves new components of unity in order to build Jazz and Azul and release it in stages.

Learning unity was a struggle, personally the UI and movement in the scene view can feel clunky at times, especially in comparison to other softwares I use such as Blender. However, with after some time I came accustomed to it, and was able to quickly work on areas which required my attention. My typical work flow for this project, was to create the scene models in blender, arrange and create a scene in blender (with all of the assets remaining as single assets), then I would import it into unity as a .FBX file. In unity I would change the location in the inspector tab to make sure that everything is at 0.0.0. If anything needed to be added to the scene, I would go back to the blender, add a new folder, create or add the objects to the scene, delete everything previously added to unity, leaving the new additions and export it again to unit setting it’s position to 0.0.0. Everything would be lined up perfectly, and as long as I had tested the models previously, there were not any issues with normals. For the scene world, mesh followers were given to anything we did not want the player to walk through, and if we wanted invisible walls, we would simply add a collider and turn off the mesh renderer, this was especially helpful for when we did not want the player to go to a specific part of the world until they progressed to a different chapter in the game.

Once the game was divided into scene, it was only a question of copying and pasting the assets across and adding models or removing them based on their relevance to the chapter. Lighting also changes during the game, so the creation of multiple scenes means that the player can experience the same world at different times with different lighting, as they would transfer from one identical scene to another with the only difference being the change of time caused by the inclusion or removal of lighting.

Early on in the project I was also able to source a player controller from online, which gave us the ability to test the worlds scale as well as player movement and interaction. The player controller was pre-made and only required me to add a collider to the character. After testing the world, it was clear that the design and creation of the world in blender worked well with little to no issues in regard to the models. The biggest issue we did face early on, however, was caused by split screen. Initially we designed the game to be a two player co-op experience, with different audio outputs determined by the side of the game you play on. This created numerous problems, some we overcame, and some we never managed to deal with, as the project swiftly changed direction. One of the biggest issues, was that the world felt distorted when the screen was divided in two, the models appeared stretched and elongated, and the player felt small. Obviously this was not an issue with the models, as we have previously tested them, instead it was an issue relating to the camera. Instead of filling up the whole screen, split screen from a first person point of view was cut in half, yet the same information that the player should have been seeing was pushed and squashed to fit that space. With some help we were able to almost fix this issues, by flattening the models and scaling them down vertically, but some issues still remained. After some discussion, both myself and Jess realised that despite the issues we faced, even if we fully overcame them, the game would not work well as co-op, as it limited who could play the game, especially in a time where people were social distancing. To make the game more available to a higher audience we madd it single player, no longer having it rely on two players to being in the same room for the game to play. Due to this, we were able to avoid issues in unity such as the proportions being stretched by split screen or programming audio to come from individual controllers. The game changed for the better, and many issues were resolved as a result.

Over the course of the semester we encountered other small issues, however, as a team we were able to get the game running to a quality we were pleased with. There are still many things we plan on adding to the game before our deadline is reached, and many more builds scheduled to be released. Although programming and working in unity were not the highlight of the project for me, it was interesting to learn how a game works at the core of things. 

Leave a Comment

Your email address will not be published. Required fields are marked *