Sticky Situation

What is Sticky Situation?

This project was part of a personal summer project a few of us did together where we pretended to be a small studio making a few friend-group games.

This first one was about building a shelter with your friends and then surviving a disaster that threatens to destroy your build and friends.

My Role

• Designed the mechanics and plan.
• Took this opportunity to teach myself netcode.
• Got multiplayer working.
• Got building and having synced scrap pieces working.
• Got them being able to be glued together.

Key Takeaways

1. EVERYONE NEEDS TO KNOW MULTIPLAYER CODING

I learned multiplayer coding, but because I was the only one, it meant I spent a lot of time changing others’ code to work in multiplayer. If we were to do it again, I would teach all the programmers on the team how it works from the start.

2. KEEP PEOPLE MOTIVATED

It took me about a week or so to get the hang of multiplayer, but by then motivation had slowed down. It would have been better to have multiple parts people could be working on, even if it wasn’t multiplayer.

Since then, I’ve become a big fan of having each person working on a prototype—almost as a different project. These are not meant to be merged in but serve as a way to test and get the movement feeling good, or build a weather mechanic and see which ones are fun, before we rewrite the code to bring them in.

It also lets people have independent control and keeps motivation up. It’s also fun to just focus on the gameplay, not the code.

And the best part is when you go to combine them, you can have a discussion about architecture: what’s needed, what problems are there, who’s doing what. It actually works a lot better than trying to predict it all at the start.