Making a Draft

• ”A goal without a plan is only a wish.” - Antoine de Saint-Exupéry

Imagine this: you spend a really long time on a level and upload it, only for it to be disliked by the people who play it and overlooked by everyone else. How can you avoid problems like this? The obvious solution is to get feedback, but quality feedback is hard to come by, especially when your level isn’t finished yet.

This issue can be avoided by creating a draft or minimum viable product (MVP) - the bare-bones, pre-alpha version of your level with only the most basic concepts in place. Use this to get feedback early into development, so you can make a level that players will actually enjoy, while saving a lot of time and energy later on. These sorts of drafts allow you to fail fast, produce at a small-scale, and access valuable feedback. This guide will guide you through the process of making one, and give some tips along the way.

When you build a plan, the aim is to help you understand and conceptualize the ideas in your head. Once you start executing a plan, that is when you start expressing your idea to others and place those objects in the editor. If someone can look at your level and immediately tell what you were going for, it’s likely well-executed. And of course, when your idea is well-executed, it gives your levels substance; they stand out from the crowd of flashy levels and carry meaning, which resonates with people and makes them memorable.

It's important to note the difference between the ideas you had in your head, and how they actually were executed in the level. Ideas are usually abstract and high-level, the same way you plan to move from point A to point B. Execution is low-level and actually defines how you're going to make those high-level ideas, like the individual turns you take when driving between point A and B.

Note that it's easy to get sidetracked when focusing on one or the other. You can make ideas so far removed from the GD editor that it's impossible to make them in-game, and you can get so focused on executing ideas that you forget what you were trying to do. It's important to prioritize tasks so you can minimize the risk of this happening.

If you recall MoSCoW from the last guide, it's useful for setting priorities and not getting "lost in the sauce" while executing your ideas.

Start your levels with a minimum viable product: as mentioned before, this will be the simplest, least ambitious set of goals. Prioritize the most crucial ideas for this MVP and ignore everything else until those parts are done. There are many ways to save time when actually building, whether it's for your MVP or everything else, but they essentially boil down to these principles:

• Use Occam's Razor - the simplest solution is likely the best. Don't overcomplicate things for no reason.

• Find ways to avoid doing tasks, so remove them from your list and don't focus too much on small details.

• Use content from existing levels to speed up your work, whether as placeholder items or copyable items (with permission).

• If you absolutely must do a task, do it as fast as possible. The next section explains things you should consider for that.

Completing tasks comes in two forms: tasks you know how to complete, and tasks you don't know how to complete. It may seem hopeless if you don't know how to do something, but there's a good process to figure out how these tasks are done. This is similar to the Scientific Method you likely learned in school:

• Identify which objects you might use to complete your task. This is your hypothesis - you're assuming that these objects will work together and accomplish your goal.

• Try conducting your experiment and use those objects to finish the task.

• Finally, evaluate the results - did things go as expected? If you finished your task, try finding ways to do it more efficiently. If you couldn't finish it, try seeing where things went wrong and adjusting your hypothesis.

You'll often hear people say to practice and experiment, and this is a fairly efficient way about it. Once you learn new ways to do something, you can use these methods to complete your tasks. And of course, if you already know how to do something, you can just do it without needing to do the full experimentation process.

Failure is one of the most important parts of creating, and it's crucial to handle it well and bounce back quickly. The best creators are those who respond well to failure and adapt accordingly. As you can expect, there's a process for this as well.

• Identify why things didn't go to plan by checking where your low-level logic doesn't match your high-level plans. For example, if you want an object to rotate around a point (a high-level plan), you need to set up your Rotate triggers properly which is a low-level act.

• Once you've found any mismatches, try to find a solution based on this knowledge. You know your own levels best, which makes this process better than immediately asking others to help. There's also the Solving Problems guide if you need help making solutions.

• If you can't make a solution yourself, then ask others for help. Start by giving the high-level explanation of your goals, then provide the low-level specific that you're struggling with. For example, you may say "I want some decoration to rotate around a point, but nothing happens when the rotate trigger is activated" and provide a video showing how you set up the triggers.

It's a good idea to get used to failure - after all, it happens a lot as a creator. But when you fail, try to fail fast so you don't waste too much time. This helps you try new ideas faster and saves a lot of time working on your levels.

Due to the prototypical nature of MVPs, you should focus more on making things quickly rather than making them look good, which is why placeholders are used. Feel free to take assets from other levels, or copy how they do things just to get a grasp of how your level will work. As long as you replace these assets with your own original work in your final level, it’s not necessarily stealing.

In fact, you don’t need to put much thought into your placeholders at all. For example, the animatronics from Five Nights at Freddy’s have their current names because Scott Cawthon, the developer, became attached to the placeholder names he used for them.

In short, make something playable, really. Visuals and glamor are secondary.