I haven’t advertised or updated this blog in a while, so: hi, I'm Sean. I've been working on games part time or in a hobbyist fashion for over 8 years. During close to 7.5 years of that time I've also worked a full time job at the same time, about half of that time I've been a solo dev.

This has been a challenge. Making games is hard, there are a lot of disciplines to follow, it's easy to get wrapped up in too many things and end up working in circles. So, to keep things as consistent as I can without burning myself up, I stick to some core principles. I’ve outlined the things I’ve learned to prioritize to keep myself going.

1. Your body needs things (And, no, not that coffee)

Easily the most consistent thing I do that keeps me energized and motivated is eating and sleeping at regular times and taking the time to wind down with those things. That means stopping to do those things; I'm not thinking about my game while I'm cooking, sitting to eat, or winding down for bed. Its so common to hear people skipping a meal, or only getting a few hours of sleep a night because they wrapped themselves too much into a project. That is a fast road to hard crashes and rough work. So stop, plan dinner, relax, eat, and breathe.

2. Scoping

On the subject of time: projects are going to take longer than you expect, that's just normal. Now imagine that when you have only a few hours in a day you can dedicate, to this on the daily. Nothing is going to go as expected, so lower the chance for that to kill motivation for the day, week, month, or the whole project. Take your concept and scope down. Good. Now scope it smaller. Not sure how to do that? Cut the fluff -- the ‘maybes’. If there isn’t any fluff, you probably have too many core features. Cut some of those.

3. Go outside

Talk, be social, go on walks, and use this to help find or create community. Going out can help to bounce ideas off of, learn new techniques, and just de-stress if it's needed. But it's crucial to not lock yourself in your house for a month to work on a thing. Sure, maybe you need a weekend to finish a feature, but to then extend that out is a surefire way to start ignoring your own deadlines, and the more you stay isolated the higher chance you have to get yourself stuck in your own ideas without feedback, or taking into account a line of thinking you just can’t reach on your own.

4. Scoping

There's no way you've done this enough, so, do it some more!

5. Efficiency

The bread and butter of making good things: being efficient. This takes its own time, research, thinking outside the box, and tools, but it's going to save you a ton of slogging. Apply some of the techniques you found going outside, or that one thing that one person suggested you tried once... Or dedicate some hours in a week to just look stuff up and try some different tools. I try to keep around 20% of my dedicated development time dedicated to finding and applying new efficiency techniques.

Conclusion

You may have noticed by now that every single one of these are a self care technique, and that is by design. These are all pieces that I've had to learn to -- going completely out of balance when working in my off time have had bad repercussions before, repercussions that I wouldn't want anyone to go through. So, please, be kind to yourself. Doing any hobby everyday takes dedication and discipline, but I couldn't be propelled to keep going for years at a time by just those cold hard focuses.

Make the games you love to make, and feel good about it too.

Welcome to the Apoco-lips. (I'll see myself out) This game stars a happy and friendly robot sent to calm the slightly disturbed masses by means of kisses.
This was created for WizardJam 5 over the span of 4 days.
I did the code and much of the design.
Come play it here: https://timegentleman.itch.io/the-robots-lips (Windows only, sorry Mac and Linux users!)

(If you want to play the game in question before I rip it apart, it's over on Itch.io.)

Just two weeks ago I was trying to put together a video game in 72 hours. I had a concept that I knew I could build in that time and I ran with it, even if it wasn't the most unique or interesting thing. This turned out to be one of the best decisions I could had made working with such limited time, even though the game I built sucks. Like, really sucks. 

The game isn't fun or interesting, there's no good feedback when a shot is launched, making the base gameplay stale. The wind system doesn't shift in a way that makes it interesting, and is more of an annoyance. There are usability issues everywhere as I did not plan the UI around the background image I drew hastily in 20 minutes. (and was one of the last things I did before the deadline) So with descriptions like this, it's not surprising that I did not hit any sort of quality standard, but I am still proud of the experience.

Quality in creative works in a hard thing to achieve. I liken it to a dragon you are trying to chase, in a dark non-euclidean void. It seems so simple: its right there. Making the assumption that you just need a little push towards it and you'll reach that goal is an easy one to make. However, you find very quickly that making it just a few inches in that direction is much much harder than one could imagine. That difficulty is where you learn as a creator, and far too often I see and hear of those with inspiration simply give up as they find they can't find the right path to success. This is a part of the process that should be celebrated, as you are actually creating, with success and failures just being the result of it all. You know the whole saying of "It's not about the place, it's about the journey"? It's overused and cheesy as could be, but its so very applicable in being creative.

So, back to making things that suck: what does having a project that, in your eyes, fails actually mean? It means you've learned. Back to my weird depressing analogy: you've navigated part of this maze before. You now know that doing one thing will be good for a project of that type, and you know many things that are bad; you can cross off those paths the next time you tackle the same subject. This is important. You aren't going to make just one game, one prototype, one texture, one model. You are going to make many, and how you slowly make your way towards quality. This is just a step for me, part of that journey.

Update October 9th 2016: due to the sensitive nature of part 2, no matter which way I've written and re-written it, it does not come off in the constructive way it should. As such I not be publishing part 2.

I've been adding a little bit more to this project bit by bit and wanted to show what's happened with it since. I'm going to be focusing on creating more puzzle elements both in a way to keep production simple and try to have the command system have a bit of an auto-aim to make hitting objectives feel more satisfying instead of busywork.

So, a this point you've built your level: it feels the way it should with encounters and puzzles feeling well rounded and interesting. The design at this point should invoke every aspect you were designing for, all without the artistic flourish of lighting, clutter, and maybe a little tweak here and there. This is where you make things pretty and effectively communicate player path for those unused to your level. This also is going to take several attempts, this isn't like the other passes where you do one, test it, and usually it all checks out. You'll see a little thing out every now and then, you're going to find ways to better optimize that particle effect, or use that rubble in a much better spot. Polish passes likely would never end if you let it, so at some point you will have to declare it "done" at some point or another.

Complete is what it sounds like, with some caveats. This is where fixes start happening, anything you had to do to quickly go through the last pass (see kitbashing) gets finalized with proper art, and aspects beyond the golden/critical path gets some love. What parts do you focus on? Well that depends on what your own tests during the Gameplay pass was. Realistically that should mean "all of it", but keep in mind that aspects that are more art driven, like lighting and clutter may not be in that category. At the end of this pass, you should be able to put the current state of your level in front of a player and only feel bad about it, but not cause them to feel the same. The tests from this should help aim you where to begin your next pass: polish.

This is where rubber really starts hitting the road. Using the results of your tests of the Layout stage, you should have a good idea of space in your environment and build on it. It is going to be ugly kitbash it if you have to, even if it only sort of works. That isn't important, what is important is that it can work and be tested. This is a step that often many folks get hung up on, begin worrying about little details that should not dealt with. That said, I'm going to contradict myself and mention that some basic optimization should be done now. It may seem odd with crude nothings in place, but it is still part of a good pass and should be tackled. It also avoids problems like the image below where aspects like RoomBounds or RenderVolumes just wont fit right in the space you had intended. Next up we're going to be looking at a bastardized 'ship-it' quality tomorrow.

Uuuugghhhhh

With a solid plan in, now is a time to think about layout and space. At an early stage, this can be a little paralyzing or overly liberating, it shouldn't be either. This is where we take this blog series' namesake into mind and reference the previous step where possible. This should help organize the outline in a more logical fashion with as few questions left to your overly excited brain. Now don't get me wrong, you'll want some of that in there as it will help shape aspects such as the player loop, but rely on it too much and you'll end up with spaces and concepts you cannot build or are too complicated to communicate to the player. Rely on your head too little and you'll end up with a nondescript floor plan filled with spaces that have no sense of self or history. Its a balancing act that does figure out with a little experience and luck.

It all starts with Planning. This is even before layout is thought about, and should be simple and short but lead into the actual building of the layout. You need to be able to summarize what is special about the level: history of the place that may not be surfaced to the player, main kit and size. This will help focus and ground the design, as the summary will do as I said it will: answer questions. If your summary is not a good reference to figure out whether you should put a specific room, then it is either too broad or too specific. (And if you are following the 1-2 paragraph limit, chances are it is too broad) This also stops making any design decisions in any other part of the project which would be harmful in taking up not only your time to then stitch into what is on the screen, but also other team members who then have to create any art or code, should it require it in a different project.