Overall, I believe Alien Burger Maker is a successful project. Although we didn’t entirely meet the criteria of an energetic experience, the final product is a finished – and with what time we had, a polished game. Yet that doesn’t mean the game is perfect. Both it and the process of creating it brought up a few problems that will be addressed in the post mortem.
Creating an Energetic Experience
This is not so much of an issue with the game, but an issue with the fact that we focused on this aspect far too late and far too in-frequently over the course of the project. The overall goal of the VR game was to create a short energetic experience to get people ready for their day. I believe that we accomplished this with the late changes we made, yet overall it could have been improved. Our bi-weekly interviews with Damian (CEO of Liminal, the clients for this project) gradually focused more on making it build up. Having it get more hectic, make the music tempo faster, have a big finale ending that can give the player that energetic boost. By the end of the project, we had quite a few elements that increased over the course of the game. The ingredients fell faster and more frequently, along with more customers coming to the window at a time and having more background activity. Yet it fell quite flat in other areas. The end scene was functional, yet very much not complete. There was no sound accompanying it and it felt quite sickening to watch in VR. Also we did not get around to making the music increase in tempo or change to more energetic tracks as the game went along, as we intended.
This happened because we were focusing on other aspects of the development. At the time, focusing on the energising elements felt more like polish to us. We had a large amount of bugs and refining of features to do, causing our focus to be more on the technical side than the design side. Although we did get around to adding in more “energetic” features and changes, this was later on in the project once the existing problems were fixed or at least held together. There were two main times in the project that we focused on the experience. A chunk at the start, before we had many technical problems, and a chunk at the end, when the problems were mostly fixed. The rising tempo in music is something that I believe would have been a great help in creating an energetic experience. Yet the process of doing something like that was foreign to us, and without an audio student, this feature was just left alone. We did have the idea of changing the track to something even more energetic every 1/3 of the game, yet that was just days before the release and we were still focusing on (what we thought were) more important matters.
So how could this problem be reduced? Well basically, just working on the experience as you go. We focused on it in chunks and put the technical problems ahead of the experience always. A much better solution would be to try and incorporate both at the same time. If there is a technical problem blocking you from working on a certain part of the experience, find another one that’s open. For example, if the ingredient tube is playing up, you can’t really test out the increasing speed and that. Yet the music would be open to work on. As a team of three, this could have even been less of a problem. Having one or two people work on the technical issues and another work solely on the experience. We all dipped our toes in working on the experience, yet really one person should have had the focus. They could have then attended most of their time in fine tuning and testing the game to make it even more energetic than it already was.
Good Work Ethic
Quite a contrary to what I talked about above, but let’s continue. I believe that the work ethic both my team and I had during the project was quite good. During class, we always knew what we had to do and never really slacked or procrastinated against working. Even when we had game breaking bugs and roadblocks, they were adamantly worked on until they were solved. The overall process of prototype, to placeholder to final build was a smooth and rewarding process.
This was probably due to the fact that we had a direct goal. The game as it is, is quite simple. Customer comes to the window, they give you order, you make the burger and give it to them. This game loop, although simple, can provide variety and interest for a player as there are many different approaches they can take. There was never really anything more complex apart from that. We had to create the systems, add a bit of progression to make the game end up somewhere and it was pretty much complete. This small, yet expansive goal, allowed us to work quickly to a fully functional game, then just move upwards from there. In many other previous projects, where we needed to add in levels, different characters, and other branches of design, the functional product is normally only finished much later on into the project. Here, we had a short goal, achieved it, then just refined it and added in polish. The inclusion of also having a set date for beta, made this process much more structured and streamlined. We knew we had to have all of our features done by a certain date, allowing us to just improve the game from there on. As working on a functional game is much more enjoyable and rewarding than working on one that barely works or is destined to fail.
In the future when attempting a game, the following things should be applied: A direct goal. Now not every game is going to be as basic in mechanics as Alien Burger Maker, yet working towards an achievable goal is. A game is not necessarily only functional (or ready to play) if all the systems are added in to some extent. As long as the core experience is achievable then i’d say it’s good for now. Removing or temporarily putting on hold aspects of a game that don’t directly affect the experience or core game loop would help to reveal the goal. Also having a set date for a beta would be good. This being the first project we’ve had with such a thing, it really helped us to scope the project and allow us to work smoothly towards the end goal. Then having those few weeks of just polish and bug fixing further made the process of working easier. We have a functional game – we can play it. Now, we’re just making it better than it already is. Really, it can only get better from there.
Frame Rate
By far the largest issue with the game both during development and now, is the frame rate. For a VR experience the frame rate should never really dip below 60 fps. Ours on the other never really reaches or goes above 60 fps. Early on in the project, the fps was fine. It only started to dip around half way through development, and we didn’t and still don’t really know why.
We tried many things to fix the problem. The code was optimised to remove any unnecessary loops or GetComponents that would slow down the game. We changed out the original voxel placeholder models (which were quite high in polys) to newer and smaller final ones. We tried disabling various different objects, then running the game to see if the fps went up. Overall, it didn’t really work. The best we got was a few fps increase, yet as a whole the problem still persisted. When I said we tried a whole bunch of different solutions, it wasn’t enough. We never went back to a previous build where there was no lag to see what was different. We just tried to use what we had at that current time to fix the issue.
If ever we were to make a VR game again, we’d approach it differently. Going into it, we were using the same approach as if we were making a desktop game. Optimisation was not a focus at all at the start and even quite a way through development, it was ignored. From the beginning we should have planned for something like this. Pooling objects that frequently spawn is one of them. The ingredient tube creates an object every 0.3 seconds, each with their own model, physics and script. If we pooled these objects when the game started, I believe that the fps problem would have been reduced, as that was a hunch we had, yet we never done anything about it. Also focusing on optimising the 3D models. Removing any unnecessary polys and scaling the models so that if they’re small or far way, they’re not as complex. Similar to the point of creating the energetic experience at the start of the post mortem; working on it throughout the project, rather than when it’s all of a sudden necessary is what should be done.