Turtle Tops! As soon as we saw them one of our producers said we could make a good game out of it, but it was a gift to another team. Thanks to faculty who gave the privilege to steal a gift from another team. It was our turn and we stole them. After a brainstorming session we decided to build Multiplayer Top Down Battling Tops Game. “Sumo Turtles” we titled the game. Our team had 2 producers, 2 artists and 3 programmers including me. For the first prototype we were asked to use MonoGame Engine. After we decided on some basic gameplay, we programmers decided to start off studying the API for MonoGame. As our gameplay demanded intense physics for the game, we also decided to use Farseer Physics engine with permission from the faculty.
I personally do not prefer jumping into the code unless I am clear with what I am working with (MonoGame? That was the first time I came across that Engine). Some prefer to dive into sample code, experiment with it and learn. But after years of experience and practice I adopted to a different style to my process of learning. I take a day or two in advance to prepare myself for the project ahead. We started on Tuesday and for two days I went through a lot of sample codes and games that were made using MonoGame. It was Thursday and there was not a single line of code but I was very clear on what needs to be done and where should I look for when I have a problem with a particular feature. This preparation paid off and I was able to give a head start to the project by implementing the most basic and important functionalities for the game, which are objects controllable through keyboard and also react to collisions.
The following are my contributions to the project
- Integrating Farseer engine: Created bodies prone to collision and also implemented on collision function to simulate force model for spinning tops.
- Extensive use of Object oriented programming: Created multiple classes to be able to scale the project
- Created Animated sprite class to animate sprite sheets (controllable frame rate, position and rotation for sprite sheets)
- Implemented a Screen manager using singleton design pattern to support multiple screens for the game.
- Provided an Interface for the programmers to extend and implement multiple screens (different levels, title or credits screen)
- Provided settings interface for the producers to play around with the force model for the game.
- UI Design (with art assets form the art team) in Photoshop, Menu and sound for the title screen.
- Implemented Logic for the game: Count Down for the match to begin, kill tops on border cross, Declare winner, Restart functionality after we have a winner
- Animation for death and collisions. There seems to be a bug in the Farseer Engine, it was returning the same normal from the point of contact for both the collided bodies. I had to used the contact point and calculate the normal myself using the center of the body in order to draw the collision effects according to the point of contact. This hack wouldn’t have been possible if I had not spent time to study the Farseer engine before I began to code.
- Integrated controller code implemented by other engineers into the game.
With the time given to us to build a prototype I felt a bit of pressure not having worked with MonoGame Engine earlier but in the end I feel I contributed everything that I planned for. I also interacted with the artists (discussed on pixel sizes, arena shapes and collision sprites, sprite sheets format to suit the constraints enforced by engineers) and producers (found what exactly they were looking for) to inform about what we (and I) have accomplished and what we might need for the next sprint which I think is also an important contribution or rather being responsible for the work in progress.
What would I do differently next time?
- First thing obviously would be to get familiar with MonoGame and Farseer Physics Engine well ahead of time so that I could have enough time to implement more levels and features for the game.
- I would be more active in coordinating with the whole team rather than reporting work through emails.
What did I learn from participating in this process?
It seems like a cliché but there is something other that you learn while working in a team and realize how important it is to have a positive energy and relationship with the team. I learnt that I have to improve on my communication and coordination with the team. I feel that it is very important to have Scrum and also complement it with a tool to assign tasks and update progress. That way the whole team knows how much an individual is contributing to the project. We did not have this kind of protocol for the current project.
The following are the top five things that contributed positively to the project
- It is very important to fail faster, have core feature implemented first and play test to see if it is the game we wanted to build which is exactly what we did. We were pretty solid with our game idea and haven’t made a lot of changes to the idea.
- Never lost hope even until the end. We didn’t really felt accomplished until we integrated the controllers, which happened in the last week.
- Tasks were documented to keep track on work.
- A good project architecture, which made the game flexible to have new game play elements.
- It is also important to pitch the game correctly to sell the game idea and the producers did a great job on it.
The following are the top five things that held back the project
- We were working like 3 different groups (art, production and engineering) rather together.
- We had conflicting feedbacks which left us confusing and also led to a bad pitch because we weren’t clear on which way to move at one point
- We did not have proper communication towards the end, which resulted in some redundant work.
- Not every one utilized the lab space. A few worked from home and A few only when we have class. I hope it is important that we spend more time at lab.
- We never had hangouts, May be if we did then there might have been a better understanding between team members.