First, I need to apologize for the title, but as I always say, I put the "pun" in "punk". I am a student at Drexel University in Philadelphia, PA, a university that places a great emphasis on experiential learning. Through their Close School of Entrepreneurship, I received the opportunity to work full-time on my own company for six months, receiving funding, office space, and mentorship. With the conclusion of this co-op at the end of March, I’m here to reflect on what I set out to accomplish with six months to dedicate to Burning Sky Games and what I learned from it all. In Part 1, I focused on the specific goals of the co-op, which is most relevant to the game we are creating. If you're interested, you can read it here. This article is meant to be more helpful to a general audience. Now, let's get to the meat of it.

1. Prioritize “multithreading” when possible.

I’m borrowing a term from computer architecture here. The computer’s processor (a little chip that I like to think of as its brain) is responsible for the bulk of the computer’s “thinking,” and each train of thought is a “thread.” Modern processors have multiple of something called “cores”, and you can think of the group of cores as a team all working to get done a project. For us, some tasks are pretty hard to divide among a group (like writing this blog), and the same goes for computers. When that’s the case, one person (or core) just has to power through it on their own. But projects usually require a lot of unrelated tasks, and so it’s possible to assign them to different people and have them all do their jobs simultaneously. But it all starts with that initial assignment.

In computers, we call this division of tasks “multithreading”, and the opposite — a single core doing all the work — is “single-threading.” Usually, we prefer multithreading over single-threading, with the exception being when the task is so minute that it’s quicker to do it alone than to break it up into chunks, have everyone do their individual parts, and then bring it all back together at the end. To put it into more human terms, single-threading is better when it’ll take longer to communicate and coordinate with others than to just power through it yourself. Game development is hard, so at large, multithreading is better, even with the extra effort that goes into working with a team.

So, the lesson I learned over co-op is to always put my leadership responsibilities before anything else. By sending emails and Slack messages, assigning tasks on Trello, and doing anything else to delegate to others, I enable them to get their work done while I work on my own stuff. This is much more efficient than single-threading it because there’s always more for people to do, and staying on top of things as a leader will set the path for the whole team.

2. Help your team help you.

Communication is the most important and most challenging part of any group effort. It’s easy to get distracted by what you need to do and forget what others need to do for you. This point will go hand-in-hand with the first, but make sure you give everyone direction. As a leader, this comes in the form of delegation. Assign clear objectives to each person and make sure they understand how to achieve those goals. As a team member, let people know when you need something from them. It could be just a simple question, or you might be blocked by someone else’s work — that is, your work requires someone else to do something first. The sooner you speak up about roadblocks, the sooner your whole team can work together to get around them. But it all starts with you.

3. Talk to your team.

The first step to this is to set up clear channels of communication. You can use Slack, Discord, Facebook Messenger, or even just texting as long as it works for your team’s needs. Personally, I’d suggest either Slack or Discord, though there are some other options I’ve heard work well too like Twist. What’s important is that you all are using it. Set up expectations, like that everyone should check at least once a day and respond to messages within 24 hours. Another thing my team does is to have weekly meetings to discuss a specific topic, and in between those meetings, one day is designated as a check-in day. On that day, we all post a message in our check-ins channel on Slack with what we’ve been up to that week and what we’re working on for the rest of the week. It takes maybe 5 minutes per person and gives more transparency to what everyone’s doing. It also forces communication, which can help with the earlier points.

4. Work now on making later easier.

I’ll start this point with an example: there are features in Runaway that we only want enabled for showcase builds, like at MAGFest, and there are features that should only be available in the downloadable game. For instance, the profanity filter on scoreboard names is only necessary when demoing the game at events, whereas we wouldn’t want anyone to press the “Quit Game” button at an event. So I set up a system that would let me toggle in the Unity Editor whether the game is a showcase build, and each object only needs to check if it’s a showcase build when loading. This made things easier than having to manually toggle things each time I build for download versus showcase. But still, it wasn’t ideal because I had to build twice for each update I make to the game.

During Cecil Con last month, I came up with an idea that took only around half an hour to set up: take in a command line argument when opening the game that specifies if it should run in showcase mode. That way, I would only need to build once, which saves me 15 minutes each time I build. I chose to do this at Cecil Con because it was the day we released the public alpha, and I found a lot of bugs while showcasing that affected both versions. With the command line argument, I could fix the bug, build once, and deploy it to both itch.io and the showcase laptop in half the time it had taken before.

I’ve also spent a lot of time recently rewriting my code. I’ve learned a lot about how to write solid code since starting work on Runaway, and since some of the code is as old as the project, there have been many cases where I’ve had trouble implementing new features or fixing bugs because the code was honestly not too well-written. At one point, I honestly dreaded having to add to the code because I knew how sloppy it was and did not want to deal with the headache of trying and failing. Movement, tagging, and narrative have all seen some revisions in the last few months that have made it so much easier to keep adding to the project moving forward. To put it simply, I had to make sure my work supports me and not the other way around. Sure, it’s a headache in the moment, but it’ll save plenty of headaches later.

This point is especially challenging coming from an experience built mostly on classwork, where the norm is to make something quick that works, get the grade, and never come back to it. We’re rewarded for doing things fast, even if they’re not done right, and that will lead to bad habits. I guarantee it. This translates to establishing a workflow and pipeline that make everything as easy as possible for everyone involved. Think about it: we usually don’t spend much time early on organizing our group, and then things fall apart.

On a long-term project, it can be hard to revisit anything that you already have working because you feel like you’re not making progress. You’d rather work on something new so that you can feel like things are coming along. But I promise it’s worth the extra time now since it’ll save you some down the line.

5. Prepare your social media in advance.

I recently discovered a handy web service called Hootsuite, which lets me schedule posts on Twitter, Instagram, and Facebook. It also lets me add authorized users to these different accounts so that other team members can post to Instagram without me having to share the password with them. Before that, I had used a tool called TweetDeck, which only lets me schedule posts on Twitter. Whatever you prefer, I strongly urge you to use something to schedule your posts. That way, you can prepare social media when you have the time to do it. You can work well in advance, and you can set up a system within your team so that one person creates all the posts and then another reviews and schedules them. With it, you have a lot more flexibility to work when it suits you while getting in on different weekly social media trends like #screenshotsaturday or #indiedevhour.

Take some time at the start of each week to plot out that week’s posts, and then you’ll be able to rest easy knowing that it’s all taken care of. You can even let the posts guide what to work on that week: if you want to share a new feature for #screenshotsaturday but have nothing new to share on Monday, you’ll have that in mind early and can plan around it. Stay consistent, and it’ll become a habit. Then, experiment with posting at different times of day and using different content and hashtags to see what works best. Without having to rush, you’ll have much more time to think strategically. Social media should be fun, so do what you can to make it enjoyable instead of another chore.

6. Don’t do anything that’s not worth it.

As a game developer, you will be busy. There’s no way around that. You will always feel like there is more to do. Your time is valuable, so make sure you put it towards things that are valuable. We tend to fall into the trap of trying to go to every event we can possibly get into, even if it’s a full-day event in an isolated room in a basement. Sure, a few new people may play your game, but is that worth your whole day? Probably not. In economics, there’s a concept called the “opportunity cost”: quite simply, it is the options you miss out on when you choose Option A. Always be thinking about what Options B, C, all the way through Z are, and question whether A is really the best to choose.

Sometimes, timing will be the biggest factor. We had a great experience with MAGFest in 2019, but I don’t know that I will be able to go in 2020 just because it starts the day after New Year’s. And I am not gonna lie, going to the Boston Festival of Indie Games last year was difficult for me. I had to take a six-and-a-half hour train ride to Boston while lugging a suitcase, a backpack, and a duffel bag (not to mention the banners, which didn’t fit in any of my bags). On top of all that, BostonFIG was a one-day event, but I needed a day before and a day after just for travel. So, 8 hours of promotion costs 3 days of work plus time to prepare before and time to cool down after. I don’t regret doing it then, but I also don’t regret letting the application deadline pass this year without submitting anything. It was a great experience since it was my first, but I don’t think I need to do it again this year.

Unfortunately, you’re not always going to know right away what is and isn’t worth your time (and money). One thing you can try is to talk to others and see what they think. You may not be able to just ask “is it worth it?” and have a definite answer. Ask for details about what it was like: what were the pros and cons for them? Then you have to think critically about what would be different if it were you and your game in their shoes. For example, my friends at Gossamer Games are making an emotion-driven singleplayer game with a heavy emphasis on atmosphere and self-exploration. Runaway is an action-packed parkour platformer with both singleplayer and multiplayer support. Gossamer is very avant-garde in their personality, whereas we draw from punk rock. So what works for them may not work for us, but I’ve learned a lot from talking to their Director Tom Sharpe about why things did or did not work for them.

If all else fails, just try it once and treat it as a learning opportunity. Pay attention. Analyze your experience. Take notes. If you can, bring a friend so that you both can view it from different perspectives. Check in often and talk about how both of you are feeling. Then at the end, you can make a judgment call for the future. Just don’t be afraid to turn down some opportunities if the other options are a little nicer.

7. Plan against crunch, not for it.

Crunch time comes from two things: too much work, and not enough time. In school, you crunch because your teachers are overwhelming you. They forget that you’re taking more than just their class. You crunch because you didn’t give yourself enough time to get done your homework. What you thought would take 5 minutes took 20 when you only had 10. But that’s school. The game industry differs in one very important way: unless you’re the manager, you probably have no control over work or time. You just follow instructions that put you into the pit.

If you are in a leadership position like I am, then I have more to say for you. You should never treat crunch time as a last resort. It should not even be an option. I always plan so that the essential things are done when they need to be, and if they don’t get done in time, then oh well. I may ask my team for last-minute things from time to time, but I make sure they’re always minor (like a PDF edit or a quick graphic or two), and even then, I always let them know not to worry if they can’t do it. There are certainly times when I’m more brutal on myself, but that’s because it’s my choice and not something I am forcing on anyone. Even then, I only do it sparingly. I stayed up until around 1am the night before Cecil Con, and I was exhausted the day of. Do yourself and everyone on your team a favor and don’t crunch.

8. Take care of yourself.

I saved this for last because it really is the most important thing to remember: you come first. From a practical perspective, you need to take care of yourself mentally and physically so you don’t become dead weight. So if you can’t put yourself before your project, then take care of yourself so that the project can succeed. Here’s some advice on how I’ve been able to keep myself in a healthy mindset:

That’s all I have for you now. Have any tips of your own to share? Post them in the comments so others can see! I hope you find this helpful, and thank you so much for reading. I cannot wait to see what’s next for Burning Sky Games.

(Original text posted on our website)