For this week’s spark activity, you are encouraged to share your experiences of teamwork so far. This is not a chance to name and shame. The discussion should remain constructive at all times. The only reason to share is to help others learn from your experiences. This requires you to go beyond purely describing events. You must identify the key learning points and suggest ways to manage similar situations in the future.
What went well? The group dynamic has been great so far. We often share tasks and bounce ideas off one another. I feel like my peers are very approachable, with everyone being available to communicate through Discord on a regular basis. Furthermore, I feel like the group is honest and motivated, with people willing to help out others at a moments notice. The regular scrum meetings help as they often boost my spirits. It is also refreshing to know how everyone else is feeling in regards to the project and their general health.
What did not go so well? Personally, I think my absence from the 9th to the 19th of June didn't help the project. I think there's really no right time to leave a project, but it was during the research and proof-of-concept phase. I felt if I had stayed, I would have started the Unity project a lot earlier and attended the weekly meetings. This is something I need to think about when I fly to America later this month.
What could be done better? I'm not sure what could be done better without being able to reflect on the module as a whole. However, I should have been available to my peers from the 9th to the 19th of June when we were deciding on what idea to take forward. Other than that, communication has been frequent, and our Trello board is being constantly updated with new tasks. I feel our group is in a good position to deliver a great pitch and eventually our game.
Distributed vs Collocated Scrum
Distributed or 'remote' teams can be challenging to maintain. Many of the normal processes and procedures teams rely upon are easier when they are carried out face-to-face. Although, some benefits suggest remote teams are better than collocated. For instance, there is a reduced cost and carbon footprint, access to new markets, and arguably more innovation with larger talent pools. Daily scrum meetings are harder to achieve with remote teams as they may often include people from different time zones.
As for our group, I enjoy working remotely. We have a scrum meeting every Wednesday at 6:00 pm BST and a supervisor meeting scheduled for every second Monday at 6:30 pm BST. You could argue that because the degree is part-time, it makes working remote easier. If we were a collocated group on a part-time basis, then it may be hard to match everyone's availability, although I would love to meet them face-to-face!
Design & Code Style Guides
Style guides should be created at the beginning of the project. They're great for managing expectations and helping/motivating onboard team members. The style guide can either be short or vast. Examples include NASA and Skype. Visual guides include, but are not limited to, colour palettes, the logo, descriptive words and typo-graphics. For our group, Kyle has decided to take up the mantle of responsibility and create the :fish-cake: logo!
Trello (27/06/22)
Figure 1: Trello (27/06/22)
Before prioritising the slide deck and video pitch, we had time to discuss other tasks. These included the gameplay flow and core mechanics (figure 1). After initial debates, we wanted to make certain that everyone understood the project in terms of design and flow.
Gameplay Flow
Figure 2: Jack's Gameplay Flow (Cottage-core Auto Battler)
As a group, we took the time to devise what we thought the gameplay flow would function as. These would take the shape of a flowchart, highlighting scenes and transitions. For example, my gameplay flow consisted of four significant scenes, the 'Main Menu' scene, the 'Preparation Phase', the 'Battle Phase', and the 'lose/Win State' (figure 2). I then connected them with arrows to draw attention to the gameplay loop. However, this would later become its own dedicated slide in our slide deck. In addition, I decided to incorporate UI elements based solely on my teammate's examples.
The Ultimate Flow
Figure 3: The Ultimate Flow (Cottage-core Auto Battler)
Once everyone had created their version of the gameplay flow, I merged them all into a single flow (figure 3). We would later find out that the flow wouldn't be necessary for the pitch presentation. Although I do not regret creating the flow because it helped the team better understand the functionality of the game we were developing.
Developing the Grid System
Figure 4: Grid System and Enemy Units (Unity)
This week I set up mobile development within Unity by incorporating Android Studio. This plugin is a requirement so that we can test our game on android devices. Next, I got to work setting up the grid system (figure 4). Before developing the system, I researched ways to create a grid within Unity.
One way was to instantiate the grid using the debugger. This way would allow total control over grid variables, including size and the number of tiles. It would also be the most efficient way of creating a grid system. However, it was very advanced, with the creator of the tutorial advocating you download his plugins for the grid to actually function. So I decided to take another approach and physically create a grid using sprites. I wasn't keen on this approach because it meant each tile had a script attached to it, which would not be efficient. However, I understood the code, and it was easy enough to make my own. Next on the agenda is placing and spawning units onto the grid.
Comments