Gravitators Post Mortem

THE GOOD, THE BAD AND THE UGLY

THE GOOD

Things that went well and we should do more of

Team Participation

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.

Quality

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.

THE BAD

Could have gone better and needs improvement

Information Organization

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.

For example:

Game registry location (which changed),
How to add a new OST/SFX,
Change elements or orders (like power up csv),
Trigger special conditions (mission success, ending, god mode for tests, etc.).

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 Evaluations

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

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).

Tools

Bugify (bug base) issues:

Logout bug when long texts present.
Ability to upload multiple attachments of the max size.
Missing shortcuts like CTRL+K to add hyperlink.
Adjust pop up size when you edit description, it’s too small vs screen size.
Worth to check if these issues are fixed by updating the Bugify License.
We should create better categories and milestones, for easier filtering.

Unity:

All Unity components done by us should have proper tooltip set up. We must take the time to set them up properly, because later on it might be hard to figure out what they do.
Acquire more unity assets that will accelerate development.
Ferr2D was a good choice at first, but then we ran into many issues that took long to fix, and the dev basically abandoned development so we were on our own.
Object naming convention should be decided from day 1. Too many objects have different names and are difficult to find.

THE UGLY

Caused major problems throughout project and needs immediate improvement

Communication

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:

(GD) Crusher difficulty fighting the Queen => PRG implemented different attacks when using that ship.
(ART) BGs took too long => We could have done quick tools to make it much faster.
(PRG) Trivial features => Many tasks took too long, but they could have been canceled if we knew they were so demanding.

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

Efficiency in implementations should always be on top of everyone’s minds.
When too much time is spent on a task, it’s usually not the optimal way of implementing it.

Examples:

Queen level. After 1 month, it was barely working. Anims without having mirroring moves into account.
City BG with tiny pieces placed manually, Space BG with millions of objects (both caused slow implementation and severe performance issues).
Original tutorial took a very long time to implement, just to be discarded later. Tutorials are usually left for the end, but given we wanted to teach people how to control ships (and test it, as we were worried about it), we decided to implement it right away. In the end it was a waste of time, as we changed much of the design. We should have used a “standard procedure” and leave it for the end.

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.

Employee Mindset

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:

Fixing bugs for only one ship, or forgetting to do the fix for the Armored Hunter.
Fixing bugs only for the human object, forgetting the alien object (or vice versa).
Many silly re-opens. A regular re-open rate was 50%. It should be 10-20% max.
New implementations full of bugs. SFX had 2 bugs per SFX implemented on 1st round.
Repeatedly implemented Text UI that wasn’t in the text files.

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.

Complicated Design

5 ships with 3 different weapons each (originally 5 weapons, most were changed).
12 different control methods (5 classic, 1 modern) x 2 types (M+K and Gamepad).
2 HUD/Map UI (Human and Alien).
30 enemies, some of which at the beginning had several abilities. Several enemies changed or dropped (Kraken, Berserker, Puffer, Scanner)
Numerous effects (silhouetted shadows, darkness, water, UI effects).
2 types for most objects (Human and Alien).
30 PUs (that modify SFX and GFX on each ship) and 30 perks that suffered many changes.
11 Mission types for final build, but more types dropped (Prison Breakout, Mothership, Protect Spaceship).
Secondary objectives with different unique requirements.

Too many systems interacting with each other in a physics-based game caused many bugs or required further implementations to balance the game.

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.

Marketing

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:

Mass market game with tons of competition.
Niche market game with small but committed audience.

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:

Papercraft Ships.
Wallpapers.
Gravitators – Lost levels (levels removed from the game).
Topic of the month.
Alternatively, all this could be done directly on our Discord Channel.

GRAVITATORS POST MORTEM

Follow us: