SCRUm Group Work

For the group project, we had to work on a game that is based on the Mythology of non-European countries. We had to create a small game experience that inspired people to understand more about the culture and history of these countries.


For this, we were given a brief to follow outlining what we had to create and showing examples of what to create and what to incorporate.

Background Info & Breif

The Background

First, we got the background which is the basic description and background behind the idea and reason for the concepts. Next, we have the description which gives another basic description and then leads to the rest of the examples. For the examples we were given a few ways we could incorporate the themes into a game. lastly, we were given the outputs which are just the expected things we have to give to complete the project.

Here is the original pitch for our Mythology based game, here we pitched the idea and gave some information on the game and how they will work. We originally had two ideas and moved it down to only one the Egyptian tomb adventure game.

After working on the basic pitch we moved onto making the GDD filling it in with the actual idea we had decided on.

Tomb of Anubis Labyrinth.docx

To start the next part of the project, we worked on the planning and research, starting with the collaborative part. Here is the first part of the planning and research: 

Videos referenced in this part:

Next, I went on to work on independent research, looking into the specific mechanics I would be working on in the game. I had to find videos on each mechanic I planned to work on and ensure they would work for the planned idea.

Videos referenced in this part:

Here is the team collaboration going over our meetings and chats over the project. Starting with the meetings and schedules.

Here are the chats

Here is my production work. This shows the prosses of coding the basic movement and creating a temporary map, as well as a few other production tasks I handled. I used videos and plans from the original planning and research phase.

Videos referenced in this part:

Here is more of my production work. This shows the prosses of coding the advanced movement, as well as a few other production tasks I handled. I used videos and plans from the original planning and research phase.

Videos referenced in this part:

Here is more of my production work. This shows the process of adding the movement to the level of the base project. I also created the pixelated screen effect for the game and imported it in.

Videos referenced in this part:

Here is the last of my production work. I go through making the animations and sounds for some of the puzzles. This is my last production not because the game is as complete as it can be but because I can focus on the written work.

Videos referenced in this part:

Here are some last-minute details I added on the third to last day. Keep in mind that this is after I have finished everything but feedback.

Evaluation of personal skills - Smart targets:

Evaluation - Peer Feedback:

Evaluation - Final Product:

Down bellow are some screenshots from the game and a video walkthrough.

Team Reflection

Here is my reflection on the project and the team:


​​Team Reflection:


INTRO:

For this project, we got put into teams of four with my team being me (Joseph Bowman) along with Kyle, Alex, and Mitchell. In this project, we had to allocate job roles for each of us focusing on completing the game. For my roles, I took charge of the idea with later refinements from the entire team. I also took on programming for the movement and worked on the level and lighting design. 


Kyle and Alex were the main forces behind the game's visuals, being in charge of planning, researching and producing the models and textures for the game. They were also in charge of planning the props and environments that they were making. Mitchel would be picking up the other half of the programming, with him focussing on making the puzzles open up to the next rooms. This means he had to look into planning puzzles and research how to create them.


We also had to choose some roles for SCRUM group meetings. We had to do a group week once a week after they were introduced. For this, I decided to take on the role of SCRUM master, with Mitchell taking on the role of product owner. This leaves the roles of developers, which are being taken by Kyle and Alex. We managed to stick to these group meetings from weeks three to seven.


WEEK ONE:

For the first week, we could not work on the project as we had to create and complete an idea for a game jam. But in this first week, I looked over the brief and got an understanding of what had been asked. During this time, I also did some brainstorming on my own of ways you could interpret this brief. I also thought about some mythology options available to cover for this project.


WEEK TWO:

In the second week, we got the most of our ideas down. After we formed the teams, we began looking into different mythologies from around the world. We made a mind map to cover all the mythologies we were interested in covering. After creating a mind map, we divided our idea into just two, one based on Egyptian mythology and one on Japanese mythology. After we created these ideas, we wound it down to one, an Egyptian adventure game.


I would say in this part of the project, Mitchell and I were pulling the most weight as we were the ones most researching different mythologies. I had also come up with the idea, with Mitchell helping to refine them. Kyle and Alex did contribute, especially in the details like the items and rooms.


WEEK THREE:

For the third week, we began the planning, stage where we decided more on group team roles and began looking into the specifics of our idea. To start, we filled out a GDD where we filled in the details of the project by answering questions. Again, I believe that Mitchell and I pulled more weight this week. I did all the audience planning other than getting approval for ideas. I also worked on other areas of planning, as well as helping Mitchell with some charts.


Mitchell made the charts as well as coming up with most of the steps. He also worked on planning the ideas. He also looked a lot into the mythology of Egypt, looking at the history and gods, including Anubis. Kyle and Alex researched the specific rooms and visuals of Ancient Egypt. They worked on a few slides of the collaborative developments as well as a few of their own.


At the end of this week, we began to work on the independent research. As this was at the end of the week, not a lot was done in the two days in this area, but we began looking at this area.


WEEK FOUR:

For week four, I did the rest of my independent research and worked on map planning. To start with the independent research, I looked into different mechanics in the game and a few visual effects I plan to add. I also worked on map research and planning. We looked at what makes a good map, and I listed a few features we thought made a good map.


I also added a map from a game and analysed it. We planned and created our map, and Mitchell made the final map. He used the map created by Kyle and Alex. Overall, we were productive this week, with Kyle and Alex stepping up their work. Not only did they draw up the map while we all planned it, but they also worked on researching their assets and even made a few. Mitchell planned a bunch of puzzles and worked on researching inspiration.


WEEK FIVE:

For week five, I wanted to focus on finishing up as much production work as I could. This week, my team and I truly worked to the bone as we spent making as much of this game as we could. This week, Mitchell made most of his puzzles for the game, mainly focusing on the first two we were making. Alex and Kyle were still making the assets through this week. Alex spent a lot of time making the assets that would be found throughout the level. Kyle made the entire map this week, as well as other models and changes.


I feel this week we stepped it up as we could finally finish all the written work and focus on the production. We all did a good job of avoiding problems faced in older projects. We did this by putting epiphysis into polish and pre-production/research.


WEEK SIX & SEVEN

During weeks six and seven, I aimed to focus on the written work, mainly the reflection, skill analysis and team analysis. My team was mainly focusing on this as well, with maybe a few production parts just to finish up. I started by making sure that all my work was on my website blog so that the teacher could find it. Then I went on to write up all my skill analysis, focusing on the skills I used over this project.


I feel I improved over this project, and I feel as a team we worked better overall. This project, while small, was more polished than others I have worked on. This project is also a much better planned and researched project than I have ever made before.


Questions:

What skills did you lack going into this project that you struggled with? How would you improve on those for next time?

I improved when it comes to identifying problems and finding solutions. I came into the project having experience in coding, which is the area I chose to focus on, but one of my biggest weaknesses in this area is my ability to find solutions for some of the more complex p[problems. Furthermore, I believe through this project I started working on this area well. While I did not fix all the issues I had, I managed to get rid of a lot of them. I believe there is still a lot of room for improvement in this area.


What part of the game development process (graphic design, narrative writing, world-building, 3D modelling, concept art, level design etc) did you most enjoy? Would you want to specialise in it someday? Why? 

I enjoyed the testing/bug-fixing phase of the development. This stage was during the coding part, where me and Mitchell spent time looking through the code and making sure it worked. I enjoyed the process of making sure the mechanics worked how I expected. This part of development is hard, but it is fulfilling. Get to see how your changes affect the game and get it to work. While I cannot see this being the main thing I go on to do, it is a part of coding, so it will be a major part.


What aspects of your game design and mechanics worked especially well? Why?

I think all the player movement worked well. I believe it was mainly due to how simple it is compared to other games. For an audience of all ages, being a game in a museum means that many people need to play. This means if the controls or the movement system were complex, it would not be accessible enough to fit the ideas. The puzzle mechanics also fit especially well in the game as it is fun enough to be a playable game but is also simple enough to fit the desired audience. The general setting of the game and the design work well with the idea and setting of the game in reality. This is due to its sense of identity and sticking to a distinct colour pallet.


Does it achieve the museum's goals?

I believe this game not only fits in the description of a game that could be seen in a museum, but I also believe this game does a good job of informing the guest of Egyptian items and their history. I believe this game would make an impact on a visitor, investing them in the setting of Egypt and the history of the country.


If you redid the project again, which role(s) would you want to take on or try next time to continue developing new skills? Why?

I would have liked to maybe take part in the puzzle creation. Although the roles are the same as they both are coding, having a chance to make a puzzle would have been fun. I know when I was helping debug, that I was having a ton of fun working on the puzzles and seeing how they were made. I believe that based on this, I would have had fun working on making them in their entirety.


How well did your group find, access, and pull together relevant research on the mythology you selected and general game design?  What sources did you use and how helpful were they?

For our game, the research was generally easy to find. I believe this came from choosing a simple mythology, with a lot of history that had been thoroughly researched. When it came to mechanics, I had a pretty easy time finding sources and tutorials on the effects I wanted. Now for this project, I did not focus much on the research when it came to the mythology, but I did do some of the initial research for the game idea. For sources, I used a few sites, making sure to avoid websites like Wikipedia. Here are two of the websites I used for getting the initial ideas below.


How clearly did you define the purpose, goals, and target audience for your game?

One of the areas I feel we did well in was making sure to get a concrete vision for the game and developing an understanding of the goals of this project. I feel we did a great job of defining the general audience for this project and making sure it fits the brief.


How effectively did you incorporate knowledge of the museum's needs and objectives?

The game incorporated the idea of making a game that would be in a museum. The game holds info on each of the items and this would align. The game incorporates the museum items and stories, making sure to fit the museum well.


How engaging, educational, and user-friendly is your final game?

Our final game is immersive as the lights and sounds add to the Egyptian tomb environment. This adds to the engagement of the payer as they can get absorbed into the environment. The game is user-friendly and allows nearly every type of player to experience it. The puzzles are not too hard, and the environment is small and compact. The education aspect comes from the descriptions of the item. These give useful info on the items of the game. We could have had more info on aspects like the gods and environment pieces.


How well did your group communicate and collaborate?

Overall, we were on point with communication and kept each other well-informed on each area we were tackling. We used a variety of tools like Trello, Miro and Teams to keep communication up. We made sure we were getting input from each other on our mechanics and assets. Furthermore, we used GitHub to share files and share the project. We used it to add our contributions to the game and add our work.


Were roles and responsibilities clearly defined and balanced between each group member?

Yes, we made sure we took roles that not only were our strengths, but roles that could work well together. We split it into two coders and two modellers. Mitchell and I tackled the coding, and we even further split into one handling the puzzles and one (ME) handling the player movement and managing the game. Kyle and Alex worked on the modelling, with Alex focusing on the props and environment pieces with Kyle working on the entire map and items.


How would you rate your contribution to the project?

I think I did a ton for this project, and I took a manager role making sure the game came out how we planned. Most of the base gameplay was made by Mitchell, with the assets being made by Alex and Kyle. But I took a role in helping and giving advice, and I also worked with and fixed a ton of code for the game on Mitchell’s end. UI added items animation and sounds, and I added all the movement systems. I would say I did around 60 – 70 per cent of the game, adding parts to make it finalised like post-processing and lighting.


What working practices helped or hindered your progress? (different ways of working)

Through this project, I took a different approach to working and the game and written work. Normally I do the production and then write about it after I have finished the entire thing. But for this project, I made sure after every little thing I did I wrote it down. Overall, this slowed done my production but made sure I wrote down the contribution I made.


How successfully did your group organise work and meet deadlines? Were any deadlines missed or changed? Why?

We used many methods to organise the project. The two main methods we used for planning the main project, were the Trello board, which we used to keep track of tasks and roles, and a Gantt Chart to keep track of dates and goals. There were some small changes to the plan like removing content or changing ideas. This was mainly due to time restrictions and new concepts being introduced.


What problems or issues happened in the development process?

There were a few main issues found in the project. There were a few issues with the lighting where, depending on the view angle, the lights stopped showing. To stop this, I created a new lighting profile, which helped fix this issue. Another issue we had was some sound not working. I did not manage to fix this as the time restriction got in the way.


How did you / your group deal with them?

To deal with issues, we first identify them and inform each other about them. Then we take a bit to think about the issue and the best way to solve it. After that, we spent some time implementing the fixes. We then test the project to make sure the issue has been resolved.


What would you do differently next time?

If I were to do this over, I would have made the idea even simpler and made sure the game had a ton of polish. I could have made sure everything had a collision and made sure it was working 100% over. I would have added a main menu and made sure all the UI had polish. Furthermore, I would have also asked for a different stylistic approach, but it would have been more time-consuming.


How could it be improved?

As I mentioned before adding more UI and sounds would have improved the project. More puzzles and variety in gameplay would have made the experience better. Adding a more realistic style would have worked better with the environment and planning.