What went right?
Although when we pitched to potential collaborators, only one animator and one audio student approached us, they were both great collaborators and what they gave us was of a standard equal to, or higher than expected.
Syed, our Animator, in the limited timeframe, created five out of the wanted seven car models. He did make an Aventador, which we did not ask for, but we weren’t complaining as it looked amazing. I just spent five minutes in the game changing the name of the GTR to the Lamborghini Aventador, a pretty simple fix. We did approach him about not completing all of the cars we asked him to make, he apologised and said he was very busy with his own project, so we let him know that he should have told us we were giving him too much to do in the limited timeframe we gave him.
As for our Audio guy, I only met him the once, on the day of the pitch, and I never met with him again. Jake was contacting him and both did an audio production session together and they created our music for our game, but I don’t know what else he created audio-wise for our game. I know Jake did a few audio assets to fill his LOs so maybe Jake did all audio apart from the main track.
It was mostly my fault that I didn’t stay in contact with our audio guy, we had a group chat on Facebook together, but all contact between him and our group was through direct messaging with Jake, and the group chat was never utilised. I would have also really liked to experience the audio production that Jake got to experience, but because I was never informed about it, because it was discussed in direct messages to Jake, it was too late for me to go (I found out the late the night before when I had planned to stay up till early in the morning so I wouldn’t have gotten enough sleep). For all times I am working with collaborators in the future, I will be sure to enforce the use of a group chat, I missed out on a great opportunity because of the communication mistake. As I have already stated, I also do not know exactly what our audio guy has done, which is kind of a really bad thing, I would have liked to see progress over the project timeframe and to have provided feedback and suggestions to him, so we could better the assets.
2. Completed Documentation
Last project we completed just over half of what was expected of us documentation-wise, but with this project, we completed it all! The project, the documentation deadlines were more structured but I also understood the importance of documentation more from what happened (or did not happen) last project.
I helped create an Level Design Document for the first time. The first iteration of the LDD, I did not design any levels, but in a later iteration, I was in charge of re-creating the Outskirts level! I did create two versions of the Outskirts level and asked Jake to pick one. He picked the first idea initially, but then when I explained what I had drawn on the second mockup (as I am a pretty bad drawer, I can’t even colour between the lines), he insisted the second mockup was much better, which I agreed.
The Art / Audio Bible was a major improvement over last-project’s attempt. We had added in every asset we thought we would need in our game and gave example images and videos providing both audio and art-style examples we were looking for, to our collaborators.
Jake and I started and finished our first Technical Design Document. Last project we were meant to do one, but no time was allocated to it, as more important things needed to be done at the time, or so we thought they were more important. Yes, we survived without one last project, but after seeing how helpful a TDD is to have for a project, I kind of regret not assigning time to at least attempting to create one last project. There are still a few extra things we could have added into the TDD before we started making the game, that would have helped us a little bit more when creating the game, but from experience, comes greater things.
Why were we more successful this time round with documentation? Well I think it boils down to two ingredients: scheduling more time for documenting, and actually having time to document. Last project 90% of the time on the project was working on the game, whereas this time around, it was more like 70% game, 30% documentation, or maybe even more percent for documentation. Right from the beginning we assigned bigger lots of time to doing documentation than we both did on our previous projects. Since we scheduled more time to doing documentation, in turn, we spent more time doing documentation, amazing isn’t it! Because we spent more time doing documentation, we got more documentation done and it was of a higher standard than it was last project.
In the LDD, we could have put more information in explaining to our collaborators more conditions/rules they must abide by. We ran into an issue where models were not working well with our project, but that will be explained in more detail later in this blog.
Gareth helped us to understand what was meant to go in a TDD, as what I had written down in class was very vague for some unknown reason. I must bring up how great Gareth has been with helping in many different situations. Whenever I wanted outside feedback on our game or an idea I was thinking up for our game, he was always there to help, even if it takes a while to contact him (I don’t think he has notifications activated on his phone).
Next project, and with all future projects, I shall schedule the same amount of time, if not a little more than this time around. We did over schedule a bit this time around, but once we had finished documentation, and were further along in our game development, we then had more time to modify, update and maintain the documentation we wrote as we were ahead of schedule due to starting making the game earlier because we overscheduled the creation of the documentation at the beginning of the project.
3. Fixed a Major Issue (on External Playtest Day)
Throughout most of the project, we had an issue where if you were for some reason off the ground for a second, you would fly off into the distance as long as you were holding down a movement key, and once all movement keys were let go of, you would fall very slowly back to the ground. We were informed by Steve that this problem was due to me forcing the transform.position by adding to it each frame you held down a movement key, so it overrode the physics of the game.
I had nearly fixed the problem, after adding a rigidbody to the car and disabling movement if you were off the ground, but even though I was on a ramp when testing this out, and the ramp was tagged as the ground. the movement keys would still be disabled and would be frozen on the ramp. Obviously modifying the transform.position was not something I should have been doing.
On the day of the external playtest, we still had not fixed the issue, until Steve came over to us and played around with our movement code for a little while until he came up with a solution, thirty minutes before the playtest. I can’t 100% remember what Steve did to fix the problem, but I do remember he used the rigidbodies velocity instead of modifying the transform.position. I was also doing this in my testing with a rigidbody, but apparently not correctly, I may have accidentally kept in the transform.position code by accident, I can not be sure though.
For future reference, I now know that in a 3D space, I should be trying to manipulate the rigidbody whenever I can instead of manipulating the position of object transforms. It will save a lot of troubles with breaking physics by manually overriding them like I was doing before external playtest day.
What went wrong?
1. The Game Did Not Have all the Features we Set Out to do
We had promised many cool features, but the reason that some features we pitched and stated we would do in our documentation were not in our game by external playtest was due to overscoping for the timeframe we had to create this game. At the beginning of the project, we believed we were underscoping the game, and were planning on adding more things if we finished early, which we thought was a major possibility.
All but two mechanics in the game were added in, and only one of three levels were created in the game, but with an additional week to work on this, we could have definitely done the other two levels and had the other two mechanics scripted into the game, as the levels were already half-created but were not ready enough yet, by the external playtest, and the two mechanics not scripted in were crashing into cars and being able to collect cars over time, both which could have been scripted in, in a little amount of time.
We also had plans for a lot of extra miscellaneous game objects including rocks and shrubs, a monument of cars, fire hydrants, street lights and different rubbish assets, as well as different sounds when interacting with all of them, but none of these made it into the game by the external playtest.
I think next time, we need to seriously think about our timeframe and what we can achieve in that amount of time, sure these extra game objects would have been cool to have, but they were out of scope for the limited time we had. In future projects, we need to dumb down the assets to what we need in the game, and add all the wanted assets to ‘desirables’, so that we can still plan for them for if we have enough time, but also so we aren’t promising anything we can’t be sure we will have enough time to make. We have learnt our lesson, hopefully we will not forget it over the break we will have in a week’s time as this was the last project for this trimester.
2. We Didn’t Manage to Complete all the Brief Limitations
Our project did not successfully satisfy all brief limitations like both my previous projects did this trimester, I was hoping we could satisfy all so I could keep the streak going, but unfortunately, we missed out on satisfying the limitations of the players feeling a sense of discovery and progress, the main mechanic driving this progress, and the two different tracks of music depending on what the character was currently doing/was experiencing.
By external playtest day, we had only created one level and that level had a massive floor, players could press just the forward and left keys to move around the whole city outsides, not quite what we wanted to happen. This also stopped the player feeling a sense of discovery and progress as all they discovered were glowing buildings and some powerups, which in fact, were not clear enough that the players knew what they did.
The main mechanic assigned to us was Adapt. Our players would adapt to the changing controls for movement of their car, but this mechanic didn’t directly drive the progress of the game, it was just a little annoyance, having to use new keys to move the car every thirty seconds. I still really liked the mechanic, but I must agree that the limitation that the mechanic had to be driving progression, was not met.
It may sounds like there are two different tracks playing throughout the gameplay, but it is simply just two different versions of the same melody in the same track. I am not going to question what happened, because I don’t know if the second track was made and just wasn’t included in the game, or if there was no second track ever created.
In the future, we should focus on trying to satisfy the limitations we are given more, as these limitations drive great ideas for our games as discovered in previous projects. As with the previous “What went wrong” item, not satisfying all limitations was due to the overscoping of the project. If we had planned to do less for a game, we would have had more time to work on the main mechanic strongly driving the player’s progression of the game, and the satisfying the limitation of the players feeling a sense of discovery and progress throughout the gameplay.
3. Orientation of 3D Models
As hinted earlier in this blog, we had some troubles with some models not working well in the game. The issue was that when the cars were imported into the game, some were in the correct orientation and others were rotated 90 degrees, it was around half and half. I had wasted a lot of precious time trying to rotate the 90 degree turned models in Unity, as what I was trying to do required the model mesh, not the model itself, so I couldn’t just place the model in an empty game object and rotate that.
I ended up giving up on the idea I had, where the player would choose a car in the Garage Scene, and that car’s mesh would then be used to replace the car prefab’s default cube mesh in the Game Scene. Instead I placed all car models on the car prefab as children and just activate one depending on what car the player chose in the Garage Scene. I was then able to modify the model’s rotations as they were each in a separate empty gameobject.
It was a pain to work with, and a solid three hours was used up trying to get it to work the original way, but I now know for in future projects, to state in the Art / Audio Bible, which orientation 3D models should be facing when they are being created, in hope that this issue doesn’t occur again.
Another problem with the models we received, was that they were gigantic when imported into the scene. We did not state in the Art / Audio bible, the dimensions of the models we wanted, nor did we create a 1 unit by 1 unit by 1 unit reference cube in 3DS Max for our Animation collaborators to use when making all model assets.
We now know for future Art Bibles, to state these two key pieces of information, and also know to give our Animation collaborators a 3DS Max file with a 1x1x1 reference cube in it.
This is Daniel Jochem, signing out.