Download Hatchery

I've never made a game with online multiplayer before, so I did one as warm-up. It was a really good learning experience. I hope I'm ready to pull it off for PyWeek now. Feel free to test it out at the link above. Instructions are in the README. Python 2 + pygame required. Please let me know if you encounter any bugs, such as being unable to connect to the server or being unexpectedly booted.

What did I learn from this?

• Suggestions I read online said to make the game work locally first and then add the networking. I wish I had gone the other way, though, starting with the networking. It was hard to add in after I'd already gotten started.
• Lag is higher than I expected for using web sockets. I was hoping for ~300ms but I typically get ~1000ms. That's fine, I'll just choose my mechanics appropriately.
• Sound logic is unexpectedly hard. For instance, making sure when you jump you play the jump sound once and only once. I usually throw sound in an the end, but this time I'll be sure to incorporate it earlier.

I now have a rough core mechanic in mind for each of the five theme candidates. I'm posting a vague description of each so that, when the theme is announced, I can't use a different theme's idea after a slight modification. I hate that.

In all cases, I want a massively multiplayer open world with cooperative gameplay. For instance, once one player unlocks an area, all players can access it. But beyond that, the ideas are fairly different:

• Bat cave: construction Metroidvania
• Secret identity: top-down or isometric dungeon crawler
• Nemesis: tile puzzle + strategy
• Kryptonite: space exploration
• Sidekick: pinball

I decided to go with a very abstract interpretation of the theme. It's not much to look at yet, but there's a lot going on behind the scenes. Networking is implemented and works great, so there's that.

This game is causing me some trouble. Have you ever had a game idea and then spent days implementing it and when you finally get it done you realize it's way too hard? And the mechanics don't lend themselves to easy simplification, like tweaking the speed or gravity or anything. That's what happening here.

I made a couple last-minute changes to the fundamental mechanics that make the gameplay much less overwhelming. It's still too hard, but hopefully it's within range now that I can balance it just by adjusting some numbers.


I'll have to write a post about my thoughts on the fundamental mechanics of this game. Suffice to say, this is why you make prototypes, because not every idea actually makes for a good game.

Last Will of the Emtar



I have noticed an occasional bug where a tile appears activated when it shouldn't be or vice versa. I believe this is due to server/client async. It doesn't affect the gameplay that much: just rotate the tile back and forth to fix it. Please let me know about any bugs you find.

Online multiplayer games are always a lot of work to balance, and this was no exception. The way I finally settled on is, players can unlock nodes that other players have already unlocked. Since these nodes will tend to already be well defended, it should be pretty easy. You can probably beat the game by just choosing a few well-defended nodes and watching the action.

But for people who want more of a challenge, find some nodes without defenses, build the defenses yourself, and give it a try. If I'd had more time I probably would have added a "decay" mechanism whereby defenses disappear after a time. Anyway, I don't think the game is that hard even if you do this.

The final boss, however, is pretty much impossible to beat alone. (EDIT: no it's not, you can probably beat it alone.) Once you unlock the final boss, you can have any other players join you, even if they haven't unlocked it.

I hope the final cutscene is worth it. :)

Typically I'm pleased with how game ideas turn out. They're fun either immediately or after a little work. This is the first time I was ever really disappointed in an idea. The final game contains significant compromises to the original idea. Many of the game's imbalances are the result of gameplay elements being affected by changes near the end of development, in order to salvage the overall experience.

It's a tile puzzle tower defense game. Tiles are active or inactive based on their orientation relative to adjacent tiles: all the contacts must touch contacts of the opposing color. This is where "nemesis" came in. Defensive towers only operate when their tile is active.



Quite early in the development I realized this is way harder to play than I expected. First of all, if you change one tile you affect all four tiles around it, like a huge Rubik's cube. Also, that sea of red and blue is disorienting. Just look at it. If they weren't highlighted, how quickly could you pick out the active tiles? I considered changing the rules so that you had to match colors rather than mismatch them. This is far more common in puzzle games, and it was slightly easier. However, since this was my main link to the theme, I decided to stick with the mismatching mechanic, come what may.

(I did, however, get a story out of it. The disorientation of mismatched colors became the central plot point. If you like stories like this, I think the payoff at the end of the game is well worth it. Among my games, this has one of my favorite stories.)

And that's only half the mechanics. Then you have the tower defense elements on top of it all. I originally conceived TD mechanics that made extensive use of the tile layout. eg, traps that would swap the tile the enemy was on with a farther back tile. Before I even implemented them, though, I knew it would greatly exacerbate the playability nightmare. So I quickly replaced those devices with more traditional guns and traps.

Still, in the middle of a wave, it was nearly impossible to recover if one of your towers became disabled. There was no point doing anything during a wave except sit back and hope your defenses hold. Obviously not that fun. I finally made several large changes to make it possible to recover from a few disabled towers.

1. Added a device that changes the colors of any tile so as to activate it in one click.
2. Enemies originally attacked by randomly changing the colors of a tile. I changed it so that they rotate the tile left or right (much easier to undo).
3. Enemies used to remove any tower on tiles they attacked, now they leave the tower but disable it.
4. Enemies used to attack (and rotate) tiles adjacent to towers. This would disable the tower without making it immediately clear which tile was attacked. Now enemies only attack towers directly.

With these changes in place, the game is playable, but about half the tools in your arsenal are worthless or close to it. You never need a different strategy than put a bunch of lasers, which is what players seem to be doing. So, the gameplay variety was hurt, but at least the game is playable.

In retrospect, I probably could have guessed early on that this would have happened. I think in the future I'll be more critical of complex game ideas. Thanks for reading!