Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Co-Opportunity: Lessons Learned Working Full-Time

    - Jake Carfagno

  • 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 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.


comments powered by Disqus