We make games that say something new.
Postmortem: Introvert vs. Extrovert
Design / Development

Postmortem: Introvert vs. Extrovert

On an unexpectedly-obligation-free weekend in August, I decided to take a crack at my first Ludum Dare. I’m no stranger to game jams, but this was a different beast altogether. Taking part in the Compo meant I would be responsible for hand-creating 100% of the code and assets in my game. It was going to be a busy 48 hours.

From my vantage point in Central Europe, Ludum Dare 42 kicked off on 11 August 2018 at 12:00 AM. I stayed up to catch the announcement of the theme – running out of space – and… went to bed. The opportunity to sleep on my idea and wake up refreshed and ready to be productive gave me a huge boost that a few dreary-eyed hours of programming would not have. And after two solid days of work – with healthy breaks for rest, food and sleep – I ended up with a nice little entry.

About the game

Introvert vs. Extrovert is based on a shower thought: extroverts are said to figuratively “gain energy” from crowds and introverts from solitude. What if they literally did? What would a game about that look like?

In this case, Introvert and Extrovert are each trying to navigate a busy beach party and outlast each other. One player wins when the other runs out of energy. Of course, Introvert gains energy when there are few NPCs around, and loses energy in crowded spaces. Extrovert is the reverse.

There’s no combat. Instead players affect the play area by dropping barriers to hamper the mobility of the other player and NPCs, and dash to escape danger or destroy the opponent’s barriers. Additionally, a set of asymmetrical powerups keep things interesting; the cellphone, for example, causes more NPCs to spawn if the Extrovert picks it up, but increases the size of the despawn hole if Introvert holds it.

What went well

A game jam was the perfect outlet for this idea. It’s a concept that really appealed to me, something I wanted to see in action, but not something I necessarily wanted to dedicate a ton of resources to. Ludum Dare was a great excuse to build and test-drive the idea without risking too much.

Player feedback especially praised the unique concept, controls, and music.

Production: the game was actually finished on time! Keeping in mind my game jam guidelines, I managed to make steady progress across the board and delivered a functional and complete (if imperfect) experience. Work/life balance remained relatively healthy despite the absurd 48-hour deadline.

I did a good job of spreading out the polish throughout the project. If I put it all off to the end, it simply wouldn’t have happened. And context-shifts like searching for a good font, generating sound effects, and drawing sprites gave me a break from design and programming tasks and time to creatively recharge. Plus there was just so much low-hanging fruit. Adding a tween to make the NPCs hop around took a couple of seconds. The bobbing player heads and blinking eyes just a few more. Those decisions alone added more personality than I could have managed with hours of mucking around in a modeling program.

Design: Realizing the concept was great of course, but I’m especially happy with the asymmetric powerups. Each has a sort of rock-paper-scissors effect that differs between the two classes. They were one of the more fun features to work on and with more time I would have taken it even further.

Development: A physics-based character controller was basically a requirement for me, as I wanted players to both affect, and be affected by, physics. Characters have some momentum, and move at the right speed to feel responsive but tense.

Perhaps the most interesting technical achievement was the crowd influence algorithm. I could have taken any number of quick and dirty approaches to get something running, but ultimately decided on sort of heatmap of NPC locations. This provided a more nuanced and flexible representation of which areas were “crowded.”

Here’s a visualization I developed to help myself work through and debug the algorithm. Green areas are most positive for Introvert, purple best for Extrovert, and red are neutral for both classes.

What could be improved

I didn’t get all the features in until the home stretch, which essentially robbed me of any time to playtest the game before shipping it. It was a painful call. Even though I knew I was eating up my runway, a lot of moving parts had to come together to even start iterating on gameplay – player locomotion, NPCs, the heatmap algorithm, controls for multiple players, and abilities. Building this all from scratch without plugins was really expensive time-wise.

On that note, I definitely messed up by not planning to bring code to the Compo. One of the few luxuries of the Compo is that pre-written code is allowed, as long as it is open sourced and shared as part of the entry. But I decided so late to join that I didn’t have much time to sort through my frameworks and figure out what I can and should open source. I used only a tiny handful of utility scripts I’d already blogged about – Observable Values, Pools, etc. A lot of stuff ended up being “from scratch” that didn’t need to be.

The balance is way off. It’s too easy for one side or the other to turtle and too difficult for a player to maneuver out of their comfort zone. Barriers are not as viable for Extrovert (too many NPCs around to get in the way).

Some of this is because I lacked time to fix bugs that come with a short deadline. Dashing, for example, is supposed to break through barriers and give players a recourse against turtling. Unfortunately, it doesn’t really work most of the time.

The opponent AI was a complete afterthought – it basically does something so it’s not doing nothing. But I just didn’t have time to give it actual goals or decision-making capacity.

But my biggest regret was failing to incentivize players to leave their comfort zone. Powerups alone were not enough of a draw. One idea might be to drop baubles that replenish one character’s energy and cut the enemy’s (as a way of integrating combat without the combat). But perhaps the simplest change might be to give more intelligence to the crowds. If they “flock” a bit (and have some ability to break barriers) players would actually have to be on their toes to stay safe.

Takeaway

I find the biggest learning opportunities from game jams are not the projects themselves, but the lens they put my own workflow under.

This time I was pretty strong on time management, work/life balance, etc. But I ignored my own advice to get the core mechanics in early and iterate, instead knocking out tasks when they were most convenient and holding out hope I could make it up with design expertise on the back end. Doesn’t really work that way. This project was a great refresher on how to prototype, prioritize, and iterate – a lesson I can take back to my ongoing projects.

If I participate in Ludum Dare again, I would almost certainly choose the Jam instead of the Compo. The marginal benefit of a slightly less competitive field seems more than outweighed by the option to have teammates, private code, assets, and an entire extra day of development. The challenge of the Jam itself was fun and rewarding, but time to make a more fun and rewarding game would have been better.

See for yourself

Play Introvert vs. Extrovert for free on itch.io HERE.

Resources used