On wednesday we again met up to review our progress so far. It was just me and Arthur, we looked at what had been added to the game. This is specifically additional visual elements like the rising volume cloud bars (implemented by Hani). I had also implemented a floating dragon prefab, a series of sprites that snakes into the background (Hani produced sprites for this too). Arthur also began to implement a moving camera, this will not track the player but it will move forwards independently.
We now gave ourselves more tasks to do on the wednesday meeting, for Arthur it would be to finish off the camera as well as a health system for the player. We discussed whether to add health points or an instant death system. That is if the player should lose health upon colliding with enemies/dangerous objects or the player must straight away lose health. I put forward the argument that because the brief requires the experience to be under a minute then it would be suitable if that one minute was quite intense and as such should be an instant death system. However this should easily be changeable in the future. Hopefully this is a small scale design choice that should easily be rectified later if needed and shouldn’t affect other parts of the game. Right now I can only imagine needing to provide feedback upon damage as well as implementing possible health pickups if we choose to have a health system.
Arthur also requested that these tasks are listed in our trello board. This makes sense rather than just listing the minutes of that meeting. This made me reconsider our approach, I believe we need to adopt a Software Development Lifecycle.
- Waterfall-A linear approach. In 5 stages: Requirements where the needs of the client/project are analysed. Then the Design process takes place where we consdier how best to approach the project, how the game would be designed in our case. We would also figure out how we would work together. Next is coding where we develop the project. This is then tested and debugged. Then this followed by outputting the game and mainenance. Check the game for additional issues. This model would not work for us as the nature of the project is quite flexible, we do not have a defined set of requirements as we are piecing together the requirements and the project itself. Shown here: [https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm]
- Iterative-This approach is more suitable, it accomodates those with unknown requirements, emphasises on development and then testing the project. The project will then respond by changing the requirements/goals from the testing. This would give us a prototype earlier. As such we can identify what we like/don’t. This is already our approach we have been using. One disadvantage is that it could be time consuming doing this process repetitively. However our team is small and focused enough to implement this SDLC. Shown here: [https://airbrake.io/blog/sdlc/iterative-model]
- Spiral-This is composed of 4 stages that are spiralled. Similar to the iterative model, it incorporates planning, risk analysis, engineering and evaluation. This is a single spiral and would be repeated as neccessary. While it is safer as it involves risk analysis. I do feel that it is less beneficial as again we are a small group. Each of our roles are clearly defined and our chagnes may not need extensive consideration after every cycle. Shown here: [http://tryqa.com/what-is-spiral-model-advantages-disadvantages-and-when-to-use-it/]
- AGILE-This is a lightweight approach. Planning is quick just like our meetings. This is followed by development again nothing too far from what we have been doing already. Then followed by Testing the parts we have developed and demonstrated. This model is essentially what we have been doing so far. The only real change is that we should put together a complete prototype to demonstrate all parts together. As of right now the features all live in separate scenes. Incoporating them all into one scene should highlight issues that we have overlooked and would show if all the different parts do work together or not. Shown here [https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm#:~:text=Agile%20SDLC%20model%20is%20a,builds%20are%20provided%20in%20iterations.]
As such we should appraoch the project with the AGILE model.