Monthly Archives: July 2013
Due to technical difficulties from last weeks presentation, none of which was our fault thankfully. We did however go out feeling a little robbed of all our efforts. So to make amends we decided to investigate the same game some more. Some of the other teams had done so already with one of their prototypes and granted it was within the rules to continue and expand on an existing prototype, we felt this was the game that required this need. The only caveat was we decided to step it up a notch, which wasnt as bad as it seemed as we had become more familair with unity over the weeks, which also built up our confidence with the tool. We were also becoming much more comfortable with each other and their abilities, so the time was right to spread ourselves more thinly and onto new unfamiliar areas. Firstly, it was time to delve further into the story and experiment on existing mechanics, either polishing them up or adding to them on the programmers side, while on the art side, more detailed models and texturing would be their next stage.
For my task I personally took on the responsibility of creating an in game fly through camera, something I have wanted to do for a while in unity, also investigating if a rewinding feature could be implemented. This rewind action would be called via a button press, namely ‘r’ this would then being the process of reversing the characters movement until the button was depressed, it was designed to remove the need for a life system giving the player a softer punishment rather than a harsh one of restarting from a designated checkpoint. I always thought any type of fly through camera was a better form of narrative in explaining or emphasising points of interest. In our attempt, we utilized this technique by indicating where the character should go next from their current location. It would be implemented as an extra camera that would follow a path, smoothly until it reached its end point, in which event it would switch back to the main camera. The flythrough was borrowed from a google search and massaged into our code. I discovered that the system was using time to calculate the path to follow and this would cause issue when run in game. Basically once started, the flythough camera played. So when the cameras are switched we had not way of pinpinting the position of the flythrough camera which was already making its way around its designated path, which and was also looping back to the start once it completed its full path. So the cheapest workaround with the least rewrite overhead in getting around this was to position and save a prefab in edit mode and save it out as a prefab, later instantiating that prefab with initial positions set automatically. The prefab would then appear and run as if it had been set to run from the beginning, of course some may say, why didnt you just reset the time to zero. Well this is because it was using system time and this is read only. In any event this workaround fixed the issue and was enough to get our point through during presentation time.
The rewind feature on the other hand took a lot long as this idea was quite rare and there was little information on how to do it, I had only seen one game using unity, called Time donkeys and they weren’t doing it as an in game rewind rather a replay system. After 2-3 days of research and coding I came up with a solution that worked, only problem was when time to test I discovered that it did not work as intended against a moving platform. The issue arose due to the rewind not being able to indentify the existing trigger and script that allowed the character to attach and follow a moving platform, so instead you would warp to whatever collider was below. What was most pressing about this bug was that our starting platforms in the game were those that moved, and due due to time constraints I wasnt able to come up with a feasible and stable solution to fix and present. I literally got the rewind functionality working 2 hours before presentation and even then it was in a rough basic form. So we decided not to show this feature and continue with only showing the other things we had added. As for the art we did see some new additions, for example a new model for the character which was created and textured. We managed to get it to perform basic ragdolling, only problem was the ragdoll was applied to another model so it just looked weird when you died and the main character would then swap from the current to an army dude while also going all limp, still got a cheer from the crowd so happy with the result.
This week was back to normal in terms of time allowed, we were back to 3 days instead of 2. Last week being interupted and shorter due to a public holiday. Another change was made to the team, another new artist was added and we were now 5 artist strong. This week extra day allowed us to experiment more with mechanics, but what was alleviating us going into this week was a concrete game idea. A few arose, but in the end we were undecided upon two game running of the bulls, my top pick and a rocket jumping game similar to quake in mechanics but with puzzle elements. I prepared a mini prototype going into the week but it wasnt enough as the team decided upon the rocket game that later evolved into a bug extermination game 3rd person puzzler. Similar to tombraider but with bugs as enemies and the main character wielding a rocket laucher instead of dual pistols.
Due to a shorter week, we knew we had to choose a game from our list that was both fun and achieveable. The game with simplest mechanics was deemed Hurricane Derby and it was the game we set forth to make. A small change this week as well to the team. A new member joined from another team, as this was within the rules of prototype week we decided to give the new guy, who happened to be an artist, a try. His skills in creating realistic greybox assets in short time really helped see this particular prototype come to fruition very easily. Mainly because one of the other artist was beginning to show his reputation of slacking off.
The idea was simple, you are a tornado and it’s your job to destroy as many objects in the game as you can in the fastest possible time you can. Points are awarded for destroying multiple objects chained together. Health is restored by finding the golden cow. The game ends when nothing else remains in the level to destroy or when the timer runs out. What we realised after naming it Hurricane derby was there was little hurricane and more tornado, however, since we didnt want to redo our branding that had been created by the concept artist, the name stuck so we kept it.