Beat Gravity – Post-Mortem
|
This is a post-mortem for a project that I have been working on for the last 10 weeks, where I together with a dedicated group managed to develop Beat Gravity!
INTRODUCTION This is a post-mortem of the project where we worked on the development of the game Beat Gravity for Theme Park course that is part of the course Game Design and Programming. The course was to develop a game with a design for a unique input device, not keyboard with mouse or a controller. The hope was to make a game that could be exhibited at GGC, which we succeeded. The game that we developed was Beat Gravity and was designed to be played with a set of drums that were made for use in Rock Band, which was developed by Harmonix. The group I worked with during the project consisted of: Anders Hagström (Design Lead / Lead Sound / Artist), Thom Hujanen (Producer / Artist), Filip Frandsen (Art Director / Artist), Erik Ögren (Lead animator / Artist), Sebastian Ringvold (Lead Tech / Programmer) and me (Lead Code / Programmer). Being Lead Code of the project meant that I was responsible for the code of the game and that everything in the game worked purely functional. What went well Unity The game has been developed in Unity5 engine, which has given the project more opportunities than if we had spent the time to develop their own game engine. By using Unity, we could also save time that would otherwise have been spent coding our own game engine, and instead used that time towards the actual game. The code language used was C# (C-Sharp), which is similar to C++ (which had been used in previous course and one that I was more accustomed to) both in structure and language, with a few differences. The differences were few enough though that the transition from using C++ to C# was easy enough to get quickly started with the work. One of the possibilities Unity gave us was to be able to easily implement 3D models to give the background more depth than 2D backgrounds had contributed. This could be done without previous experience of 3D engines since Unity was very easy to use and there was comprehensive guidance materials within easy reach. I had expected that Unity would have taken longer time to learn but with the intuitive interface and tutorials presented on their website, it was easy to get started with the project. During the times when I was not working on the game directly, I looked through the archives of recorded material from when the employees had live tutorial sessions. During these so I learned more and more about how Unity worked and could identify potential solutions to potential problems that could arise during the project. Code structure Since I was the Lead Code for this project it meant that I was responsible for the code of the game. This led to me along with Sebastian Ringvold, the other programmer in the group, discussed the naming conventions we would use while writing the code for the game. To have these naming conventions made it easier for us as we could read each other’s code and understand what was going on without having to ask for a translation, which in turn reduced the potential confusions and problems. It turned out that in previous projects we had separately developed a coding style that was relatively similar to each others. This meant that it was not so difficult to develop naming conventions for the project, as we already had similar styles. The rhythm Since the game would assess how well the player hit the drum in sync with the beat we needed a system that would keep track of the rhythm. I wrote a script that would take a value representing how many BPM (Beats Per Minute) the featured music would be using. This script calculated a normalized rhythmic value between one(when a new beat was started) and zero (when the beat was finished and right before the next would start). This value is calculated after each new frame was developed and used by other parts of the game for varying effects. The rhythm value was calculated based on the time differences between the frames were developed, but this led to some inaccuracy since the timing between frames was not always the same. This inaccuracy was so small though that it was negligible. One of the effects used were lampposts that could flash in time with the music. This was done by the lampposts had a script that looked at the calculated rhythmic value and translated it into the alpha channel of the objects light. This meant that when the value was equal to one the glow was opaque, and when the value was zero it was completely transparent. WHAT WENT WRONG Inexperience / Poor planning Since I had no previous experience of working with Unity and C# I devoted some time to get to know the user interface and how Unity handled various components individually as well as jointly. This time, however, was spread out over the whole project, which meant that when I encountered a problem and did not know how I could best handle this so I had to come up with a own solution. For example, we needed a flash of light and a effect that was displayed when the player hit the pad in beat with the music. One problem I encountered here was that I did not know a way to have a process that could run a bit at a time over a certain period of time to get the lights to fade in and then fade out without getting the code to get very messy. But since I did not know better so did the code got messy. After a few days, I found that there was something called Coruoutines in C#. I encountered these while I watched one of the recorded tutoring sessions Unity Tech had. This was exactly what I wanted and then rewrote the code for managing to fade in and out the candles, which in turn led to the code became more readable and I could also use this knowledge for future problems in the project. However these problems were not just because I did not know how Unity or C# worked previously, but we also had poor planning. If I instead had planned out all the features that needed coding for the project so had I known what specific topics I had needed to do research on. Problems with Input One of the early problems we encountered was that the drums we had for the game were worn out which resulted in that they sometimes did not register that player had struck on one of the drum pads. We also noticed that some of the drum pads suffered from this problem more than others. At first, we believed that this was a problem with the game engine and wondered if we had to change the engine completely. After that we tested with keyboard controls we noticed that the problem was actually with drums. A thought that I had then was that because they were used, it was possibly dust in the pads that may have caused the issue. So we opened up the drums but noticed that there was no dust inside. I tried to inspect more closely the cushions that were more affected by input problems. Then I noticed that the drum pads contained springs, which led us to open up the remaining drum pads. It was then we noticed that there was a difference of springiness has between the pads springs. After much reflection, we realized that we could not do anything about this. We simply had to accept that the drums are sometimes did not register the users input, even though this could lead to a worse gaming experience. Another problem with the drums was that there was a minimal delay between the player to beat on a drum pad until the character reacted. However, this was a negligible delay. Level Design One of the goals we had was that the obstacles were placed on the track would be placed in such a way that the player kept the same rhythm with the music, they would get past the obstacles without trouble. One problem we noticed here is related to the problems we had with our input. As the drum pads sometimes did not register the users input it was very difficult to accurately test the placement of obstacles in such a way that the player’s actions could sync with the music. So then we tried instead to do the testing with the help of a keyboard configuration, which was a problem for me because I have a habit of hitting the keys too early in time with the rhythm, with the result that I corrected the courses based on my preference. Why I do this I do not know, it’s just something I do. However I caught this to late into the game’s development, and came upon it during the last weeks when we wondered why it was difficult to get the doe’s location so they sync up properly with the music. Had we known this before, I had not been the one who had implemented the level design, but put someone else in that seat. FEEDBACK Before the Alpha and Beta presentations, there were opportunities to get our fellow students to test the game in order to get feedback and see what worked and what needed changes. Many thought it was fun to play the game and liked the gameplay of drumming. However, we noticed that players often did not know what to do in the beginning of the game, which led us implementing a tutorial section at the beginning of the game that showed what the drum pads did and these pulsed in sync with the music to encourage the players to drum in sync with the music. During the exhibition at GGC (Gotland Game Conference) we got very positive feedback on potential changes from those who tested the game. From this, we noticed that many of the players wanted more feedback on when they were in sync with the music than what is already in place, which was that the players got more points the longer they stayed in sync, and that a trail was built up behind the player which many players thought that they were running faster through the course even though they did not. One of the points that many raised during various feedback sessions was that the drum pads are not always registered input and that the placement of the barriers were not in sync with the music. See the above sections for a response to these. SUMMARY To hear from those who play the game that they thought it was fun to play has given me an assurance that I at least have learned something from the education so far, although I can not directly point to one specific thing. I have noticed that my skills have grown during this first year, but can not say exactly what has been improved. One of the things I learned during this project is that I have to become better at planning ahead, how the code of the game will look at a basic level so that time could be spent researching the skills that may be required for specific operations, and to distribute the work more smoothly. Now, we programmers worked in a way that we worked on the necessary tasks based on how comfortable we felt working on specific tasks. This meant that we often worked within the same scripts which could lead to problems when we tried to sync our work together. Working in Unity has opened up opportunities for me in game development, as I’ve seen what can actually be done with the engine and have gained insight into how it could be done with an engine that had been made internally. The biggest problems we encountered during development had to do with the drum set we used were worn from the beginning, which led to more problems. From this, we learned that controls sometimes do not work and do not record all of the player’s actions, which we must accept and ensure that future projects take this in mind from the very beginning of the project.  |
