When my contract job wrapped up I started to work on a new game in Unreal Engine. After some play tests and 5 months of development I gave up. Despite making games for four years by that point I STILL made such an obvious rookie mistake: I gave myself an 𝐢𝐧𝐟𝐢𝐧𝐢𝐭𝐞 𝐚𝐦𝐨𝐮𝐧𝐭 𝐨𝐟 𝐭𝐢𝐦𝐞 and an 𝐢𝐧𝐟𝐢𝐧𝐢𝐭𝐞 𝐚𝐦𝐨𝐮𝐧𝐭 𝐨𝐟 𝐬𝐜𝐨𝐩𝐞. // Why is it that in University we're able to finish the game projects we get assigned as homework? We may not like what we created, but we 𝑐𝑟𝑒𝑎𝑡𝑒𝑑 something. We may wait until the last minute to submit, but we 𝑠𝑢𝑏𝑚𝑖𝑡𝑡𝑒𝑑 something. Was it the pressure our professors put on us? Was it the weight of the money we spent on tuition? Perhaps. But let's entertain an alternative: We completed these game projects easier because the ideas we had were 𝒇𝒆𝒂𝒔𝒊𝒃𝒍𝒆. // What makes a game idea feasible? As I mentioned earlier there's two things: 𝐭𝐢𝐦𝐞 and 𝐬𝐜𝐨𝐩𝐞. The two check & balance one another but You really want to define time, and I'll explain why. // Scope is declared within the bounds of time. If You have a time limit of 7 days to work on a game, you have to narrow the scope down to something that is feasible in 7 days. Otherwise, your game gets 𝐝𝐞𝐥𝐚𝐲𝐞𝐝. Worse, your game 𝐧𝐞𝐯𝐞𝐫 𝐠𝐞𝐭𝐬 𝐟𝐢𝐧𝐢𝐬𝐡𝐞𝐝. Scope is also more difficult to quantify. If You often reflect upon your skills and have a good estimation of how much content You can develop over time, then perhaps You can quantify your scope. But that logic gets messy once You begin creating games with small teams, because to quantify the scope you'd now need to calculate how much each of your team members are capable of developing over time. // Time is the better choice to define, because no matter the team size everyone has to narrow their scope of the game to fit time. In all things time also creates a sense of urgency; a now or never situation. How many times have you shopped online and been ambushed by a One-Time-Offer urging you to 'act quickly' before this deal expires? Lastly, time encourages us to put the brush down and make us decide that our work is 𝑓𝑖𝑛𝑖𝑠ℎ𝑒𝑑. We can work on a game for as long as we want, but it will never be a finished game until 𝑤𝑒 𝑑𝑒𝑐𝑖𝑑𝑒 𝑡ℎ𝑎𝑡 𝑖𝑡 𝑖𝑠.

I've been using Unity for 5 years, and I started using Unreal Engine over a year ago (My therapist asked me what I was waiting for to start using Unreal). If You can code in C# or C++, or if you can visually script in either engine, You're going to have an easier time making a game than someone who can't. But what if You're an artist, designer, or a sound engineer and You don't know how to code? What if You're a Writer? // You COULD learn to code and make games in either engine, but if you're working solo chances are a big game engine like Unity or Unreal for your vision is overkill. For some developers coding is just a means to an end. It makes no sense to spend months learning a skill if they don't have to for their games. Luckily, there's a much easier way to make games, and it's not named Unity or Unreal Engine. // With the rise in the number of Indie game developers, there's also been a rise in the number of ways you can make a game. And the best part is, no matter your craft, you can make a game with these tools and not write a SINGLE line of code. // 1. GB Studio - GB Studio is a game maker designed specifically for making, you guessed it, games in a Nintendo GameBoy format. - For those who aren't confident in their composing skills (like me), GB Studio has a way for You to write GameBoy-style music and SFX. - For non-programmers, GB Studio uses a visual scripting editor for all of your game's logic. - For artists and non-artists alike, a tool that specializes in making pixel art is your best friend. When I was in university I relied on Piskel for all my pixel art. Another option is Aseprite, but it comes with a one-time price of $20. // 2. Twine - Twine is a great tool for any developers who want narrative to be the primary way your players experience your game. - This is a great tool for those who aren't confident in both their programming and art skills, but can write a great non-linear story.

Tell me if this scenario sounds familiar: You've worked four consecutive days on a new game you're excited about. You're proud of yourself for having the discipline to get through the exhaustion You feel after work, and even prouder for not doom-scrolling on your phone or playing video games or watching TV with all your free time. But after what feels like months worth of work on this game, You're dissatisfied because you don't see any desired results. The game isn't playable yet. You spent longer than you should have trying to fix that annoying bug (you couldn't fix it). You have three more ideas You want to add to the game. // On your fifth day You decide to stop working on your game an hour early. You tell yourself You worked really hard this week and You deserve a reward: A night out with your friends! Or maybe You're not a fan of going out. Maybe You reward yourself with a night of playing video games or catching up on that show You've been hooked on. Then it's the beginning of the week again. You come home from a long day of work and spill yourself on the couch. Between all the stimulating activities You did on the weekend and the stress at work, You try to muster the strength to sit at your desk and work on your game. // You work for 30 minutes. Then You reach for your phone and scroll on social media for 5 minutes. Then 5 minutes becomes 10... 10 becomes 20... and You know the rest. It's so easy to scroll for so long because the reward comes easy; You don't have to wait at all. The reward of releasing your game, however, You have to wait until You finish working on it. Your game which, by the way, STILL isn't playable yet. The thought of working on your game makes You uncomfortable because now it feels. so. boring. So you end work early again, not knowing it'd be another few months before You start again. // What actually happened is this: your consistency deteriorated because your patience ran low. Now, I think breaks and small rewards are great, and highly recommended no matter what kind of work you're doing. It's just the healthy thing to do.

When game development students graduate, one of three things happen: A) they immediately get hired at a game studio. B) they take a break to recover from college burnout, and then they start applying to jobs C) they take a break, and the break never ends. Chances are that most of you here fell into either B or C, and if you did that's okay, I did too. I didn't try to make a new game until the temp job I landed reminded me that it was, well, a TEMP job. Suddenly I found myself scrambling for a job with no new skills or projects to show since my graduating. I even tried making my own games, but it had already been so long since my last project that I made many of the same mistakes that beginners make that prevent anything from truly getting finished. It wasn't until after 6 months of unemployment, and 15 months after I graduated that I learned what was causing me to struggle. I wasn't consistent with starting and finishing games. Believe me, I was working on something every day of the week for those 6 months, but the problem is that I was trying to make games that were too big for me to complete. You could even say I had a scoping problem, and you'd be correct. In my second year of college my professors had us make 14 games in 7 weeks, and in my third year we made 10 in 15 weeks! But in my final year we had to create 1 game in 10 months. Just. One. Game. So adding 10 months to work on one game alone with the 15 months I'd spend trying to create another game on my own, you bet I felt the pressure to produce something PERFECT after all this time. Whenever I think of perfection, I think of this story from Art & Fear: " The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.