⋅─⊱✧✧✧⊰─⋅
Methodology:
I have decided to use a combination of Agile and Kanban methodologies for my project. Being able to divide my development process into sections and sprints will make it easier for me to playtest and refine every aspect of my game, without missing out any features or steps. It will also help me to structure my time and understand my priorities. Working in sprints will allow me to produce a minimum viable product earlier in my development timeline, giving me more time later on to fine tune the game. This will be vital for contingency planning, in case any features need drastic changes. The Agile methodology is commonly used in the game industry, so it would be beneficial for me to gain experience with it, and the software often used to manage it.
As someone who likes to get everything in their head written down visibly, the Kanban methodology has been incredibly useful. I used this methodology in my last project and it helped me visualise all of my tasks and priorities in order, without them feeling muddled up in my head. Being able to visibly distinguish between tasks in different development stages, tasks in progress, high priority tasks and tasks that affect other tasks is great for efficiency, project planning and stress reduction. It will also help me see if there are any tasks that I haven’t taken into account, as they will all be listed and depend on each other. Being able to move tasks into the complete column will boost my serotonin and motivate me to continue completing tasks. The Agile project structure will also limit how many tasks are being worked on at once, reducing feelings of overwhelm and stress.
My project structure:
As mentioned previously, my game will be split into 5 sections based on the rooms the player enters. Each section contains 3 levels. With this in mind, I will have 6 Agile rotations / sprints in total, 1 for each game section, and a final one for menu’s and general polishing.
Planning:
Organising timeframes and listing requirements for the current sprint. This stage would involve writing out all the goals for the sprint on the Kanban board, with different colours for different stages of development, etc. I would need to be especially careful with task time allowances and prioritisation to ensure I stay on track.
Designing:
Designing levels and puzzles for current section of the game, the visual style and layout. Ensuring designs achieve my intended goals, challenge the player, and create an inviting atmosphere.
Developing:
Building the game in engine, seeing what works and what might need adjusting, making assets for development. This stage will likely take the longest amount of time, considering I am a solo developer and new to coding.
Testing/deployment:
Testing the game myself, with teachers and play testers. Gathering feedback on new implementations. This will help me understand if my game is having the intended affect on players (controls feel comfortable, the game world is soothing), and to see the game from a players perspective.
Review:
Review feedback and observations from tests, potential bugs and note further changes. Make sure to list necessary updates in priority order. These fixes will be saved for a later stage in development, unless they break the game.
⋅─⊱✧✧✧⊰─⋅
Schedule:
I used a Gantt chart to plan out my work schedule for the upcoming weeks. I’m aiming to finish each stage of development in one week to have the game completed by our first event on the 14th March. I may need to make some edits after this date, but the game should be playable. I have left week 7 as a contingency week to make any tweaks or fixes before the event. As this is a solo project, I’m going to have to be working everyday to stay on track and reduce stress later down the line. I have split the schedule into sprints as mentioned previously, after our first event I will focus on tweaks and fixes, and promotional content.
⋅─⊱✧✧✧⊰─⋅
Next Section:
⋅─⊱✧✧✧⊰─⋅
Reply