It’s been just over a week and a half since I finished my last project Mamore. Similar to my previous project, now I’ve had a week to clear my mind, I’ve decided to write a post reflecting on the experience and summing up a couple of the things I have learnt or came across during development.
Time Constraints
The idea and design of Mamore was solely the result of the IGM competition. In fact as I mentioned in my last post, it was brainstorming with the idea of growth from which the game was developed. As a result, during the ideas development stage I was very much aware that development of game features was going to be constrained by the limited amount of development time. And that, whilst the competition stated that games did not need to be perfect or necessarily finished for the competition, they had to be finished and/or complete in a playable sense. At times I felt this limiting in terms of creativity, stopping me from going down and trying different avenues. However, I did find that it kept me focused on the core game and gameplay, preventing me from going down rabbit holes that would take time away from areas that needed it. For example, during development I focused on making a minimum viable product (ExtraCredits did a great Youtube video on the subject). This way, if time became constrained I would at least have a playable game. For Mamore, this was staying focused on the enemy block’s AI and the life block logic, the two elements that I felt around which the game was based; in hindsight player movement should have been in this list, but I’ll get to that in a moment. Elements I left until last were the purchasable items, turrets and traps, particle effects, animations and sounds; things I wanted to add to the game but felt weren’t necessary to the core experience.
Physics of Movement
This is something that caught me near the end of the project, in fact on the day I submitted it. Much like in Click ‘n’ PoP where input was key, in Mamore a key element was making sure that movement felt right. Too often I have played a game, this applies to platformers especially, where the players movement just feels off, and for Mamore this is the core gameplay element. Now, I should say that unlike Click ‘n’ PoP which was actually broken, Mamore was not broken, it just didn’t feel exactly how I wanted it to; the player’s movement was just a bit slow and sluggish in nature. It played fine, and performed as it should, it just needed some refinement. And so this is exactly what I did; on the morning I was planning to submit my project I decided to put my head down and spent the whole of the morning playing with various values, tweaking them until the player’s movement felt just right.
In hindsight I should have done this a lot earlier in the development cycle, which would have allowed for further refinement. However, unfortunately that was not the case, though in the future this will definitely be at the forefront of my mind when I start a project.
Final thoughts
I feel that this projected helped to highlight that sometimes you need to focus on the core game and try and keep feature creep at bay, as this can consume time you may not have, especially if you have a tight deadline. It also made me realise that you should make sure you have all the base mechanics tuned, at least close to ideal, early in development, so as to allow for more time to fine tune. Overall I probably learnt many more things from this project than just the two listed, some I don’t even realise, but I feel that the above two concepts are things that, after a week and a half, stand out clearly in my mind. Much as I said in my previous post, whilst I realise the game is far from perfect, I am happy with how the game turned out and most of all I enjoyed the process.
Finally you can check my IGMC2015 submission, Mamore, here
Joe