This will cover the post mortem of the Vendorbus game, it will cover some of the mistakes we made, what we did right and what should we do to reduce or mitigate the issue so that when the problem arises again, we know how to solve it.
What we did right?
Conveying the Message
We were able to convey the message of the game, where we were able to convey the tone of the game, being comedic and upbeat. We were also able to make the aesthetics reflect the game’s overall nature. We were also able to learn fundamentals of 3D modelling and how to implement them into the game, showing that the aesthetics reflect the upbeat nature of the game. This can be proven through the questionnaire, where the majority of the playtesters are in favor of aesthetics.
To maintain this quality of design, we need to be more attentive to what our overall style is and try to keep it as consistent as this one, reflect to the style and nature of the game and work on it to the best of your ability, which allows us to continue nurturing the understanding the elements and make people see it the way we want to.
Provide Exploration Mechanics/Delivered Some Core Brief Requirements
There were some minor forms of exploration mechanics in the game, which was one of the brief required for the game. We were able to reach this to a degree by giving player the freedom to explore the different areas and let them test out however they like. We were able to showcase what we can do to explore the game, but not in the mechanics way in how we tried to distribute the resources to the people, which we failed at completing the development for. Nevertheless, we were able to complete this core task to a proficiently passable degree because we were able to make the vending machine move and let them explore the towns, the beach, the ocean waters and the like.
We need to improve continuously on making a proper mechanic build, which means that we need to ensure that these strengths continue to grow as time goes along during the next development projects in the future.
What we did wrong?
Lack of Understanding of the 3D models/verts/softwares
From what we did, we used Magica Voxel software to replicate the formula of the Crossy Road Style aesthetics and we did not use textures as means of providing the quality of the game itself. In turn, what we were unaware of is the fact that there were too many verts collecting on each other for each asset, which would reduce the render time of the game and would actually make the game less than functional if there were too many since Unity could not handle the immense amount of verts made in the game, especially when it is used for animation, which the quality would vastly decrease immensely. In addition, the models would all look strangely stuck on one another when one pays attention to them, thus leading to the models looking odd when you pay very close attention. This is because we lack the fundamental knowledge of the risks needed when we are approaching this project.
Version Control and Source Control Issues
There were issues in regards to the version that is being played up upon and in regards to source controlling. Using SourceTree, we were unaware of the fact that we have to ensure that we do not work on the same time when one opens the project, doing so leads to an error when pushing/pulling in SourceTree. As I am not aware of this, we, as a group, had problems when trying to adjust to our source control and ensure that all the branches do not merge, leading to a massive resource error. This is due to the lack of communication and information between teams. This goes the same way for version control. I was unaware that the old version will be led to the document becoming obsolete. This should be something that could be added to the Game Design Document to ensure that everyone is working in the same version, and if someone isn’t doing that, then ensure they know is the best way to prevent this issue from happening, as it happens to me.
Lack of Document Structure
The way we design the documents are not clear and concise enough, mostly during the Art Bible, we were confused on the fact that the models we made are to be placed in the game, where the truth is we were supposed to put concept art and overall aesthetic quality of the game, what it looks like and why does it need to look like that.
This goes for the other documents as well, such as the TDD where we do not understand how to source code a document and make sure that each section would provide you with adequate instruction and code structure so that programmers who are experienced would know what code you are using and the justifications for it.
We also lacked attentiveness to the High Concept Document and the Game Design Document, both are supposed to showcase what the idea was and convey them like a manual that other people can understand without playing the game. We do not have a proper structure which allows us to ensure that we have a section we need to make a document design flow well to designers and outside readers.
And even our level design document overall does not contain “what’s in a level” and details what sort of interactions and feedback are needed to make the level. The main thing here is the lack of structure in which we failed to communicate with the documents and the lack of understanding of what the documents are supposed to showcase marks a huge disadvantage to us when making the game.
We neglected to set everything to prefabs for easier access, this leads to the issue of the models sticking to one place and ended up having to put all the assets again which led to time loss, and ended up damaging our schedule as a whole.
This is something we all personally noticed right from the start, we knew we would not get the main core mechanics done by then, and I anticipate the fact that we were too ambitious in making the game done than to make it work, and it shows during meetings and communications between the artists and our group. We failed to communicate the issues that we did not notice until it is too late and it ended up destroying the work the animators did for the models for the game, which ended up being a mess of a work.
This is made apparent in scripting, as we need to make the AI movement, have it correlate to the manager(controllers such as inventory, UI and all other elements in the game) and have it functional, which due to scheduling reduces the amount of time taken for scripting the game. Also, a lack of communication between team members of the scripts provided also leads to this issue.
What should we do to improve what we do wrong?
This is expected. We need to improve further on our scheduling to plan not only the points we need to pull, but we also need to take a step further and make contingency plans, ones where we could actually have time to make fixing some of the issues and make communication with the team as necessary, this may reduce the issues of game problems. Also, noticing the problem early allows you to reschedule and change your time to reflect on this with what you have and it requires keen time management to pull it off, which leds us to share our schedule, communicate with the team better and make frequent updates to the progress we made and make necessary changes as needed. The methodology for this is to ensure that during meetings, we need to keep in mind each other’s long-term schedules and times and make changes if something unexpected happens. Making constant updates helps to remove the issue of one team member flunking out. In addition, scheduling when one team member is working on the game scene, the other should be in charge of making assets or scripts early on to test later, so when you added them to the scene and noticed the errors, you can make changes as necessary during the time you have or when you are off, ensuring maximum productivity for each member without them doing nothing, of which I had the most knockback effect during this project.
We are ought to continuously maintain our documents, such as our TDD, GDD, Art Bible, HCD and others alike. Having a structure allows us to make changes on each section we work on to prevent issues like lack of communication from arising. Making sure that each member comments on each section and give short feedback to read to the people is crucial, so make sure that each section is concise and quick to read so that they can immediately give feedback within the first few minutes, if not, then try to keep each point you make and separate them into sections for easier structure reading. Technical writing is crucial to ensure that the documents flow and understandable by even people who are not in the games industry working for the game at all. (TDD should be readable to programmers as they may use that as a base for how they will program their code).
Learn 3D/Animation Fundamentals
Learning the fundamentals allows you to mitigate the issue at hand. If you understand that you want something working without it reducing the quality, testing the models to ensure that the points of each vertices do not overflow in a model would help to increase game quality and reduce risk of issues when playing the game or rendering. It also helps to learn what you are going to make, so fundamental 3D concepts can help you to understand how it works and how it could be prevented from having this issue arise in the games we are making in the future. Either through tutorials or through experience, learning what you know can benefit you greatly in the future, and this problem may arise again in the future, but knowing some basics can mitigate this to a degree that it would work while sacrificing a little quality work, considering the game’s framerate and the animations on it.
What Learning Outcomes we, as a group, achieve?
- 3D modelling
- Audio Asset
- Scripting (A lot of basic fundamentals)
- Justification (to a degree)
What Learning Outcomes I am missing?
While I did not able to assist others as much as I should, I was able to assist one member of the class who needed help to iterate their cards. Using the models of their cards for the game, I noticed that the earth cards for the game has major issues in regards to sizing and model design. So I took a look at it and noticed that the colors were dark and does seem too simple. Using what I know now of card structuring and design in photoshop, I was able to mitigate the issue by asking him to change the color and make it brighter. The result was one of the earth cards being changed into the version provided.
While I was able to write two blogs on this matter, I am not certain that the reasoning is sound and I was unable to understand the precise specific goal in mind of where I want to go really. I thought to myself that I would work on an indie development team, but specifically, I am not certain what I would do to work on a specific team or what sort of AAA particular job that I want to solidify working on as a starting career or as an end goal. Although art director seems tempting, it is certainly one job that I will least likely to get on the long run because of lack of experience and communication to the team at the moment.
What approach that we were to take next in this development for this prototype is to develop the game so that the world would be much bigger than anticipated, because when we were testing the game, we noticed that the world was too small for exploration. We were also a little lacking in terms of the giving mechanic, the other main mechanic we need to add to the game. It is something that we may approach next. It may be possible to rework the audio and the assets to remove the quality render problem and to reduce risk of copyright due to the nature of the audio.
I personally learned a lot on the fundamentals of Game Design documentation, and learned a lot on what makes a digital game during the development of this project. We made mistakes and we move on from it. We learn how to make changes and learn mistakes we did not expect. The project has a lot to work off of, but it would be important to learn from these experiences and reduce or remove the issues that may arise again in the next development project we could work on.