What went well?
During the first half of the project, we had spent time together as a group removing parts that were not essential to the vertical slice. This was particularly useful because it assured that everybody was on the same page as to what we were making and allowed us to decide what each person felt comfortable working on, and what they needed to learn before persuing the actual development.
We kept an active list of questions we had for the designer on trello throughout the project which was very helpful when gaps were missing in the GDD or our team couldnt quite decide what the design was.
It also allowed us to keep an open area to write down questions if we ever had any and ensure that we could ask them during “question the designer” sections.
I gave my team 3 weeks of learning time to be able to achieve their individual research goals and tasks. This was a valuable time for each person to lay down their foundations for the project development. Each week we had a team meeting to discuss how each research activity was going and from that we decided if we needed to cut it out of the vertical slice as it would take too much time or couldnt be done.
Each person had a card on trello which contained a checklist of skills they wanted to learn/research in the 3 weeks.
During this time I assigned Bayley to the art lead and she created a style guide for the game. I chose Bayley because she had previous experience with low poly modelling and rigging; both with assets and characters.
After the 3 weeks of learning was complete, we had a test for us all to 3D model a basic piece of coral and a session where we modelled a wooden plank. These tests allowed us to talk together and all understand the “low poly” style of the game.
Next we sat down and evaluated where we were. As some members had not finished all they wanted to do (due to unforseen circumstances) we began to reduce the scope slightly to fit with the speed at which we were working.
Then we were forced into a remote working situation due to the pandemic. We further reduced scope, ruling out extra elements which wouldnt be essential to gameplay.
After these sessions of scope reduction we ended up with this scope:
Create a vertical slice showcasing the first area of the game, focusing on the first main quest in which Aurora (the sea slug) has to wake up Meryl (the manta ray) who is blocking her path.
This scope still fit our original goals outlined in the overview.
The main mechanic that has been impacted by this scope reduction is the extra collectables that were available for the player to pick up as they explored the envrionment. However the mechanic is still shown through the main questline collectables, so this still shows the mechanic working how it was intended to.
Communication was quite good at times and very helpful in improving certain aspects such as gameplay.
The enthusiasm from my team to create a great vertical slice was amazing and is really shown through the amount of work we completed on the trello board, as well as the documents, thoughts and discussions created there.
One of the most challenging elements during this project was making sure team members felt confident making their given elements/assets. We all worked together to try to teach each other skills that we already had so that everyone felt confident working together. This was especially useful while 3D modelling as at the beginning of the project 2 of us felt very un-confident about creating assets and by the end of the project we both felt confident making our own with very little guidence. In order to make this happen I created little workshops within the first 3 weeks where we all sat down together and slowly went through 3D modelling a simple asset. Then as the project progressed I tried to give more challenging tasks and encourage discussion between team members if someone needed help.
How could it be better next time?
Project management was going great until I became ill and could no longer meet my team for physical meetings. We kept in contact the best we could but there was often miscommunication as verbal discussions were not being had.
Then we went to entirely remote working due to the pandemic and my situation changed drastically as I was no longer available (At a PC) on a Tuesday, Wednesday or Thursday. I made this very apparent to my team by letting them know the days and times I was available for them to ask any immediate or important questions. That way I would be at my PC readily able to send any images, files or voice call if needed. Sticking to these times has been incredibly hard and has meant that often team members have been stuck without something to do; meaning that the Agile method of development began to fall through the floor.
To improve this issue, I would’ve passed the team leader role onto another team member during these times as they would be more available at the correct times. This would’ve allowed for us to make the most efficient use of our time and keep using the Agile method of development.
Other minor improvments I would like to try if given more time is more experimentation with the design of the game. As a team we felt very confined to the GDD and didn’t make lots of changes as we were worried it would take too much time.
Some areas on the trello board were not used as much as others. For example, we had created a version history document within the first 3 weeks of the project, and not many people used it when they created assets. I attempted to communicate that this needed to be filled in so we can track what we do and dont have, but only a few team members did so. Upon reflection I believe I should’ve reminded everyone each week to fill in the version history document and this would’ve prevented future collaboration issues.
Something I was also not aware of, which I am now, was that we needed a unity ‘style guide’ to ensure everything was kept organised and consistant throughout the project. This was created by team member Benedict rather late into the project as I wasn’t aware that we would need it. I can now use this valuable information in future projects.
Writing the bug testing document very early on was a bad decision as when we reduced scope more than half of the document became un-usable because the questions were not relevant anymore. A potential solution to this problem would be to create a bug testing document for each element that might need testing, and test the elements as we go. For example, if someone creates a character controller then we can test that before the level has even been made.
However we did pull through the remote working situatiuon together and created a project with a heavily reduced scope that was still able to convey what we wanted to show to a potential investor/publisher.
Conclusion
To conclude, I am very happy with the outcome of this vertical slice and it encapsulates exactly what we want to show a publisher; the relaxed atmospheric and curious gameplay that the player should experience in the full game.
I would be more than happy to take this piece of work to a publisher to show them what the game was about and would feel confident that they would be interested in persuing the game further.
SketchbookMegan 