THE GOOD, THE BAD AND THE UGLY
Things that went well and we should do more of
Sometimes, everyone contributed on improving something outside their area of expertise:
– Crusher Design by ART (Bomber never worked well)
– Worm movement by PRG (original proposal much more stiff)
– Capsule Header feedback by PRG (should be more interesting, more action oriented)
– Marketing Ideas by everyone (Papercraft, Short Animation, Story, etc.)
– Art Style by GD (we were without art style until the low poly reference was found)
These are successful examples of getting out of the comfort zone and working as a team.
Every time someone suggests a cool idea I never thought about, it makes me super happy and proud. As my experience is mostly from project management and not design (even though I have read a lot throughout these past years), any help I get is really appreciated.
We should continue doing this, it creates a great synergy between us.
The game overall has good quality in all fronts. We all worked to make the game as best as it could possibly be, and it shows.
Considering this graph:
We went too far on Time + Cost, but Quality was kept.
The challenge for the future is to maintain quality but reduce time and costs, by using ready assets, hiring third party freelancers, working smart, and/or using the suggestions from this post mortem.
Additionally, we can re-use parts of Gravitators into other projects (text files, menus, etc.) and we have already designed our Company Name, Logo and Website, so it’ll be easier to move forward with new projects.
Could have gone better and needs improvement
Contradicting information all over the place (various bugs, bug comments, tasks, Slack, spreadsheets, etc.). If you missed an update, you might implement the old proposal.
Information wasn’t always readily available. It got buried on a forgotten bug and then it took time to find again or ask, or (much worse) had to be figured out again and re-written.
It took a while to refine organization until finding the optimal method.
General information on how to do a few things was sometimes missing.
I created a sheet where I stored some of it for myself, but this should be something for the whole team to create and access.
Solution: A wiki page should be created for every game. In there, all the latest information divided by sections (overview, levels, enemies, objectives, powers, how-tos, etc.) should be updated. That will be the main reference point, and bugs and tasks should point to each of those pages when there’s an update.
Technical challenges were not evaluated at the correct time.
Originally game was designed to be more of a multiplayer arena with a handful of levels, but we discovered networking wasn’t possible too far into the project, causing us to re-design everything into single player, which caused conflicting designs, delays, changes and removals, etc.
Implementing FG/BG decorations caused a lot of performance issues. This should have been evaluated at the beginning, using placeholders.
Many times implementations were started without considering the implications or how they’ll interact with other systems, which ended up with many bugs and “hack” kind of fixes, causing messy code and leftover unused components that remained until launch.
Solution: Technical Design Documents with diagrams should be done immediately after a GDD, to evaluate the technical risks and to organize code structure on how all scripts/systems will interact with each other, specially if we suspect there will be a lot of systems involved.
Technical risks should be checked first, so design can be adjusted without losing time doing useless implementations that won’t be used in the end.
New implementations should be carefully evaluated first. Spend some time organizing to avoid heavy changes later.
Art Direction wasn’t decided from Day 1. We just tried a few art styles, without being convinced by any, and then we just moved forward with the game without any clear direction.
By the time we settled on the art style, we had to re-do a lot of the art, causing many bugs and delays until all graphical assets were adjusted.
Game box art and marketing assets were done too late into the project. This was partly caused by the fact that the game’s final name wasn’t decided though.
Solution: Art Direction should be settled along the GDD and Marketing Tactics. All 3 need to go hand by hand from the beginning. Projects cannot start without it.
Game Name and Logo needs to be done earlier in the project, ideally at the beginning (it can change after, but at least there’s something to share already).
Bugify (bug base) issues:
Caused major problems throughout project and needs immediate improvement
Remote work for everyone during pandemic complicated things, but the issues were there from before.
I need to constantly ask (and sometimes insist) for updates. Schedule was not properly used/updated some weeks.
When this happened, many times I found out someone was stuck on a useless implementation or a low priority task.
Working Times or Time Off should be communicated to the rest of the team.
Lack of communication can be taken as lack of care or apathy by other team members.
Solution: Given the work to do is always discussed, you should try simple quick messages at the end of the day, with: what you did, what you will do and what you’re having issues with, if you have a change in your working times or you’ll be busy/out. A few lines that will take a few minutes of your time might save hours.
Take advantage of being in a small team: be excited to communicate your progress! Not only we all care, but seeing each other’s progress can motivate us to continue. It’s a virtuous circle. Otherwise it feels like we’re all stuck and the project is static.
And don’t be afraid to share your problems. Many very difficult issues on a specific area are easily solved by another area. Examples:
Remember that you are experts on your area, so others can’t really gauge how hard something is. At the same time, other areas can help take a different approach that might give “good enough” results but saving a lot of time and effort.
Idea is that we all work together to make every task easier for us and for the rest.
Lack of Efficiency
Solution: Emergency Meetings. As soon as you realize something is going to take quite long, we do a quick meeting with the team, so everyone can provide ideas on how to help you do it faster.
Before implementing something big/new, we should go over how each area will do it. This way, we can all review if that’s the optimal way or if there is a way to make it faster.
Never do tutorials until the game mechanics are solid enough to not change anymore. If we need to teach the basics, we can do a quick video instead.
Sometimes I feel the team is still under the “boss-employee” paradigm from Gameloft. Being the former boss plus the fact that I work as GD/Prod organizing tasks obviously doesn’t help to change this. I believe this passive mindset is not allowing you to transcend that stage, and be able to just be an independent team member. It’s like you’re always waiting for the next step, when you should be creating those steps on your own.
No criteria. Most of the time it feels like you’re implementing stuff mindlessly, which caused many bugs on the 1st round of tests for things that seemed very obvious. This caused me to change the way I wrote bug descriptions from “somewhat short” into “extremely long”, because I had to try to cover all potential situations and explain everything in detail. But this in turn caused you to perhaps lose focus when reading and understanding those descriptions, because they were too long. A bit more independent thinking is expected.
No sense of urgency. This is perhaps related to remote work, but it’s hard to perceive urgency. When falling behind schedule, I didn’t usually see much effort to catch up.
No attention to details. A few examples:
Solution: Take an Agile course (there are many free options like this).
Read our Indie Game Blog. I’m sure you’ll actually found some useful information in there.
Play more games. Many issues spotted seem to be related to lack of experience playing games.
Before starting a task, spend some time organizing yourself on how it’s going to be done. You will be able to polish the structure, and come up with potential issues.
Then, ask questions or doubts or loopholes you found. That’s exactly what you should do, find the problems before you work so they can be revised at Design stage. Spending some time here will save you lots of time later (and many headaches), because you’ll start working from a solid base.
Challenge me: if what I’m proposing is crazy, or will take too long, or will delay your schedule, resist it. Do a counter proposal. Propose a meeting to discuss it. The mindset you should have is “I want to do more but with the least amount of effort”. Anything that goes against this motto should be discussed.
Solution: Focus on simpler designs, with less systems that don’t interact so much with each other.
Leave additional, unproven ideas as back up instead, to avoid implementing and then removing (saves PRG time).
Prototype and confirm the idea before committing to do the full effects/implementation or making it more complex (saves ART time).
Projects should be much shorter (1 year maximum time) as long as we are a small team.
Probably our biggest failure. It was very, very hard to get noticed.
Game choice was based on the fact that there weren’t many games like this on Steam. Between the choice of:
We decided to go with a niche game. Twin stick shooters were slightly declining vs previous years, but instead of bouncing back like we hoped, they continued a steady trend down from the moment we started the project until we launched.
More market research is required, including testing the market with a quick proto/demo (even if among very few people), to see if the game has appeal.
It seems there just isn’t enough interest for this type of games any more, except for roguelikes. A gravity twin stick shooter is too niche.
Solution: Marketing should start from Day 1, and should be worked along the Game Design Document, so the game is more marketable from the get go. Gravitators had a hard time generating buzz. The few big-time fans of the genre absolutely loved the game, but there doesn’t seem to be enough of them any longer (or at least very hard to reach).
Hiring a part-time community manager in charge of finding players and creating hype. If we don’t have budget for it, we can consider offering a % of revenue.
Create a mailing list and have a monthly magazine. In turn for signing up, we give free gifts to people:
© 2019 Insular Games. Gravitators, Gravitators Logo and Insular Games logo are trademarks of Insular CV. All rights reserved.