top of page

The Gluttonous Grimalkin

Anchor 1
Game Summary:
​

The Gluttonous Grimalkin is a top-down action game in which players control an enchanted cat and run around dwarven city environments, eating dwarves, breaking trebuchets, and growing bigger. The game features three enemy types and two environmental hazards. As the cat grows larger, it gains the ability to eat formerly-dangerous enemies, until, at its largest size, the cat can rampage around each level without fear.

​
Development Methodology:
​

The Gluttonous Grimalkin was developed using an Agile development model with Scrum. The team planned milestones for the development of the game and implemented features according to milestone requirements.

Throughout development, the Game Design Document was updated and served as a living document consisting of feature details and projected outcomes from the development team.

​
What did i Do?
​
I was the AI and general gameplay programmer. I implemented the AI system using A*path plugin. Other than this I also added features like Audio System and Audio Clipper to play a sound and any Game Object can use my interface to play a sound on the fly. I implemented the camera shake system and Particle system handler and made a variety of particle effects used by the game. Other than this I also helped my LD’s on some scripts and animated a portion of dwarf and did low level tasks like loading level, bug fixing and integration testing.
Some of scripts I implemented:
​

AI System:

​

I used pathfinding plugin,learned the interface  and  implemented the AI system and configured all my levels to use a traversable graph for a 2D plane.

I wrote scripts to control the behavior of dwarves reacting to different situations that happen in the game.

​

​

​
APath.PNG
PathFindingOnEnemy.PNG
Camera Shake:

​

I created a camera shake system. 

Exposed a method to be used anywhere to shake the camera for an amount of time and intensity that can be controlled on the editor.  

​

​

​
I also created an audio manager and audio clipper, particle system handlers, some animation state controls, helped juice up the game and helped the level designers on
some scripts and also did integration testing and low level scripts like loading a level. 

​

​

​
Screen Shots:
Screenshot_20191202-101518_The Gluttonou
Screenshot_20191202-100942_The Gluttonou
Screenshot_20191202-100826_The Gluttonou
PostMortem :

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.

bottom of page