Chores Post-Mortem

Here's a quick post-mortem on Chores, the farmsim->rpg->horror->bullethell game from plexsoup, caevv, Cyril and Josef.

Disclaimer: This is written by plexsoup and may not reflect the opinions of the whole team. Hopefully I won't offend anyone.

Here we go!

Summary

The game turned out pretty well and met or exceeded our expectations in a lot of ways. We worked well together. There was no friction or drama. We all learned a lot in the process. The whole thing was a positive experience. The few things we did "wrong" were simply compromises made because of the time constraints imposed by game jams. Given more time, we could easily turn this into a professional game. The genre mashup works surprisingly well.

What went right

As always, the Godot game engine is a joy to use. During development, they released version 3.1 stable. So we didn't have to fight with our game engine.

We laid out the foundation and infrastructure very quickly... Usual things: discord server, github page, pause menu, game level switching, etc. That let us get on with the business of making the game.

The two programmers were in much different timezones, so we were working around the clock with very few merge conflicts. I'd go to bed with a problem I couldn't solve and it'd be solved by the time I woke up.

When we did have timezone overlaps, the programmers worked really well together, with lots of open communication and idea sharing.

Audio is really good. Having a professional composer on the team helped.

The pixel artist is really good and he clearly had experience on other games. He knew exactly what would be required and assets worked well with the game engine. (animations, UI elements, etc.)

What went ok (undecided on whether it was good or bad):

We chose a game concept very quickly. We pretty much went with the first concept presented. That goes against most conventional wisdom about game-jamming (throw away the first 3 ideas), but it was a solid idea and it let us get on with making the game.

We worked in relative isolation. Each "department" was a silo. That meant everyone had authority over their own domain, but it also sometimes felt like a contractor / client relationship instead of a collaboration. Contractor Relationship: "What do you need?", "This, this and that.", "Here you go." vs Collaboration: "Hey, I looked at the first level and figured it needed some more jazz, so I added some scenery. Cool?", "Yeah. Keep doing that. Oh hey, that gives me an idea. I can totally do something with that new thing you put in."

We didn't have anyone in charge of game design. No one really claimed the role. The game just evolved on its own. That could work well, especially with a rapid iteration cycle and lots of playtesting, but we didn't really have that either. Might be no big deal, because in a jam you only have time to develop once. There's not much time for revision. But the game would certainly benefit by it.

Integration is hard! If someone is tasked with integrating assets into the game, or weeding through git merge conflicts, that's time they're not spending on their primary tasks. I don't have any solution to this. It's possible that any given team needs to have one person be the integrator/asset wrangler/project manager/change coordinator. It's not reasonable to expect all contributors to be fluent in the game engine (Godot) and the revision control system (git), so someone has to get assets into the game.

What went wrong

There's lots that we could have improved upon, but game jams are about time and compromise. In any case, here's a list of game elements that could be added or need improving.

• Inconsistent art: some art was meant to be placeholder, but never got replaced. If you see bad art, it's probably "programmer art".
• Projectiles don't always go where you'd expect.
• Dungeon is big and empty and kinda boring. Needs items of interest or something to break up the repetition.
• Levels were never designed, nor playtested. The dungeon map was supposed to be a placeholder, but it stuck.
• It's kinda like an rpg, but there's no loot or levelling.
• Needs at least one more farm task and two more types of enemies.
• Enemies bunch up on top of each other, even though I had perfectly good flocking behaviour code I could have used to prevent that.
• Could use an Act III where the player has control over their powers: transform at will

Personally, I (plexsoup) wasted a lot of time refactoring systems which didn't need refactoring. I also wasted a lot of time coding systems which didn't have much impact on the game (eg: sheep flocking behaviour). My own inexperience with collaborative git workflow caused me problems. (branch always, commit often, don't rely on autostashes from a fancy git client). I wasted a lot of time producing placeholder art and audio assets which would later be replaced. Finally, I was new to the autotile system in Godot, and I wasted a lot of time trying to get bitmasks and collision areas right. I never did get a navigation system into the game, so enemy AI is a bit weak.

What would you do differently next time

Bottom line: the project needed more playtesting and iteration. Next time, I would deploy builds to itch.io much more frequently so the whole team would have a chance to playtest more often. I'd also encourage everyone to take an active game designer role and voice their opinions about the game during development.

If you've read this far, thanks for indulging me! I encourage you to voice your observations about the game, especially if you have any insights into what we could do better, or how we could apply more polish. If we continued development, what would you like to see?