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.

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.

Abandoned Mine has been an interesting experience in diving into the Creation Engine and getting myself familiar with the tools and practicing some design fundamentals. That said, there's elements that I've taken away from the experience that would have helped speed up design and iteration time and would have made it better quicker. These lessons I call 'answering the why': creating an answer to your design question before you actually get the point of asking it.  These questions  are ones that you generally wouldn't think about if you are both inexperienced and/or getting swept up in your idea: 'is this space the right size?', 'do I have all of the gameplay sections I want to explore?', 'what do I do now?'. The biggest aspect of this is understanding how to plan, take iteration one step at a time, and play test as soon as you can. I'm going to be taking the steps of what makes each progressive pass and breaking them into digestible chunks over the course of the next week.

Within design as a whole, the act of prototyping is a common practice; in architectural design there is AutoCAD and blueprints, web design has mockups, artists sketch. It’s a universal language that is used for very good reason, so it’s no surprise that we’d see this as a common practice in many aspects of game development, but it’s a simple step that is forgotten about by even some experienced developers.

This idea of paper prototyping may not be exactly what you think it is. Generally you won’t be making origami versions of mario to jump around your platformer in mind. It’s creating the most basic form of your game concept and making it playable as quickly as possible. It does not need to be elegant, your main character may just be a square, it won’t matter. What does matter is getting your idea out in a way that someone, including yourself, can play the thing outside your head.

Now, why is it important to get this out? Well, when you think of a game concept, at one point or another you’ll have to make some important decisions, like how high does this character jump, how many enemies will be here, should the player be able to go both left and right? These are all things you could arbitrarily chose, but if you do, are you really making a decision? Is your game better? The truth is almost always no. Where these decisions are truly made is from seeing the game being played and hearing feedback from players. Be prepared to have an idea chewed out and ripped limb from limb, but remember that the process of making a game is not one voice, you need this if you want to be able to make the right decisions for the game that all of these players and you are trying to make.

While not everyone needs this step, some can develop levels and other aspects perfectly fine through entirely digital means, what paper prototyping can do is speed up a process that is key to making a truly fun game: fail faster. Fail faster is important for reasons that we mentioned in the previous paragraph: every criticism is a move forward that you cannot do on your own. This act of fail faster moves beyond this idea of paper prototyping; you’ll need to constantly hear feedback and have people play your game as often as you can from that point forward. From what you receive and figure will make things more fun, iterate on your prototype, make those decisions, and even above that, ask questions, would it be more fun for items to spawn around the player as time goes on, instead of hard setting them? Does the player stay in the air too long? Some of these questions might not get answered until you build digital versions, but being aware of these options are important to not get tunnel vision.

Anyway, with the amount being done on my other project this week, it’s been on my mind quite a bit. On good news, once I get enough tested I’ll be throwing more details on the project on here as soon as I can.