Reworking ideas
After reviewing the ideas, some approaches to the phases have been changed as well as overall elements. This is including abandoning the broken Unity aesthetic. I had realised that rather than the game being broken in the initial unity loading section, it would be better if the player had to deal with an in game loading screen instead.
Research phase
Another change is adding a timer that keeps counting down through the whole game, this was meant to replicate the pressures of a deadline.
I also considered what the V.O would be saying through each phase, I also want to impart a sense of doubt and second-guessing at every point.
Development phase
Here the camera transitions to a different angle. Instead of stacking content inside the bar, the player can freely stack in without a container.
Refinement phase
The stack of content shapes is then taken and dropped into the loading bar, it will either not fit or fill the loading bar. As such the player must reshape the stack or fill the loading bar with ‘fluff’, this will be represented as liquid from a tap.
Finalising phase
The finalising phase will still be the same, I do feel that it is not entirely neccessary for the game. I would focus on working on the first three phases until I feel there is enough time to add the finalising phase. In fact I would deem this as a high-risk feature to implement as I have the least amount of experience with 3D game design, this can be resolved should I commit time to learn and implement skills for 3D design in the future. I do believe the main three must be implemented first in some manner.
Approach to development
During the writing of this log I had already looked at different Software Development Lifecycles to adopt for the Collaborartive project as found here: [https://collaborative.myblog.arts.ac.uk/2021/02/14/project-epsilon-dev-log-pt-3/]. In that log I had concluded that the AGILE model was the most suitable for that project, as such I will adopt the same model for this project too as these projects both make use of Unity and would result in a playable game at the end of the project. I will consider each of those models for this project too however:
- Waterfall– This model requires communication with a client and is not so flexible. This model also focuses on using a set of requirements that this project does not have.
- Iterative-Again this relies on a set of requirements, with this model the game can be incrementally built upon. However this project has some high-risk features, specifically the 3D elements of the game. The iterative model can only allow this if the requirements are clearly defined/known.
- AGILE-This model seems to be more useful as it is adaptive, it does not rely on a requirements analysis to inform the design. This allows me to respond to major project changes, if there is any part that may not work I could adapt quickly. For this project I imagine every cycle would start with some planning, development, testing then refinement (similar to the process I have found in my previous case study).
Initial plan
With my structure planned and my approach chosen, I believe I am in a good place to move forward with the project. My first plan is to adapt my current build of the game towards the ideas I had formed as shown above.
- Replace the “Broken unity loader” aesthetic. The aesthetic just needs to be a mock aesthetic, this will be replaced in the future once I do research into other game loading screens.
- Implement the drag and drop mechanic for the different elements within the game screen for the research phase.
- Develop the stackable content shape phase. These objects need to stack on top and instantiate themselves.
- Implement the refinement phase, where the stack is droppable into the loading bar object.
After next week these changes would be reviewed, if these have not been completed then changes to the plan would be made.