The Gluttonous Grimalkin

Individual

• What went well

  • I felt I did very well on my discipline and had clear communication from the start about the tasks each of us are responsible for and made sure the code I wrote is easier for the LD’s to understand and maintained a proper pipeline which made the debugging and testing process easier.

  • I felt I did a pretty good job at integrating my code and reviewing the scripts LD’s wrote and made sure all the scripts had the intended behavior and didn’t hinder our development progress.

  • I felt I had a good insight about the future sprints and wrote code in a way that would accommodate changes easily. I also felt that my code was easily understandable as I noticed my code was modified many times by the LD’s.

  • Although I had some communication issues early on, through the course of future sprints I felt that I improved my communication significantly and did not create any blockers for my team.

  • I felt that I was very flexible at implementing certain features and had a lot of alternative ideas to do the same thing differently.

 

• What went wrong

  • Initially I did not follow the sprint process and felt that doing so many simple tasks like standup meeting, updating mindmup, updating scrum board etc.  was pointless. This hindered our progress in terms of documentation and planning for future sprints.

  • I had a lot of communication issues early on, was shy and was most of the time hesitant to talk about ideas and any issues the team had. Many problems that I could have solved weren’t even told to me because of my communication issues.

  • I felt that my participation towards documentation was poor and most of the time I used to delegate documentation tasks to the LD’s.

 

• What I learned

  • This was my first experience of making a game with a team and I learnt a lot of things and realized communication is greater than individual knowledge. Clear communication makes things much easier and progress can be seen clearly.

  • Working with version control is much more complicated than I imagined, and we had a lot of issues, dealing with these issues and fixing them was a great leaning experience.

  • Only by alpha I realized the actual importance of documentation. Trying to determine times and details blindly is much more difficult than just updating documents at the end of day.

  • I feel I am a lot better at planning and communicating which was the biggest positive learning experience for me.

 

 

Team

• What went well

  • Our team was generally as a whole was positive, competent and focused. We had a good team dynamic which helped us push through, despite all the setbacks we faced we came through together as a team and this was the reason, we were able to submit a good quality game.

  • We were really happy that we did not have to crunch a lot and made sure we got almost all of our work entirely done during the core hours.

  • We did a good job of dividing the labor according to preference and ease of working on a particular thing. For example, Tyler let me work on AI and gameplay and took over tasks like menu system and things that I did not really like.

  • Everyone was on board on the idea of quality over quantity and did not feel bad for their ideas not getting added. I was particularly happy that the entire team took a lot of effort in improving conveyance.

  • Interdisciplinary communication improved significantly towards different sprints which was the major reason we were able to complete the game easily and deliver a decent quality product.

 

• What went wrong

  • I felt that we did not have a clear vision of what our game was supposed to be which led to a lot of changes and most of the major features that we initially planned never made it into our game.

  • We did not strictly follow asset pipeline and workflow and got in few small changes even after the asset lockdown.

  • There were a lot of merge conflicts throughout our development process which took up a lot of our development time. This could have been reduced by making a more granular breakdown of our asset pipeline and strictly following them.

  • We did not communicate early on with our stakeholder which deterred some of development process initially.

 

• What was learned

  • Over the course of different sprints, we learned that that organization procedures and structures i.e. Asset pipeline, asset lock, adhering to deadline etc. is very important. It makes the workflow easier and development process much faster and resolves conflicts sooner.

  • A cohesive team and good communication are very important as it makes the development process faster and helps us deliver a good quality product.

  • It is very important to consider how our individual work affects other disciplines and the overall project. One small change on an individual work can potentially affect the entire project.

It is very important to maintain and keep the documentation up to date as it makes tracking our progress and planning much easier.