My Attempt at Making A Game, Part 1 – The Design Document and Outlining the Goals

The process of designing my self-made game project is underway.

Something I’ve read about a fair amount before, and have taken lessons on, is the creation of a design document. Before I ever start modeling maps in Blender, building script in Unity, or try to assemble actual code – it was important for me to sit down and define the scope of the project.

Where to start? Well, broadly, I had a few goals I wanted to hit regardless of the idea that struck me most. The project needed to be:

-Iterative, so I could build a foundation for the game with basic gameplay, test for function, and then add to the framework
-Realistically something I could complete on my own within a year’s time
-Fun and replayable – at least, to my own sensibilities of such
-Visually straightforward – no need to learn complicated real life-emulating shader code or imbue models with tons of details and animations
-Supports single-player and multiplayer gameplay, with a lean to asynchronous multiplayer

That meant, despite still having all those design docs from my WoW-ripoff MMO concept, it was out. It also meant discarding a complicated RPG – if it was going to use RPG elements, they would need to be added to a flexible framework where the core gameplay was simpler. An FPS was out – I want to make something a bit slower-paced, and on top of that, the type of asynchronous multiplayer I framed as the concept wouldn’t really mesh with an FPS. Art style will come later, but the image in my head is something colorful and bright, probably a close analogue to something like Clash of Clans – exaggerated, simple character forms, bright environments with little details added, easy to run on nearly any hardware.

The vision that first came to me was a game about climbing a mountain – it would stretch my comfort with modeling and force me to learn how to make nice looking, naturally-flowing rock features, but would also work well with the art style I had in mind. I could see an indie-style narrative metaphor, where climbing the mountain would be a symbolic journey as well as a literal one.

With that very rough outline in mind, I had to conceive of the actual gameplay. I didn’t want it to be just a race up a mountain, so what can you add? Well, to fit the concept of iterative, modular gameplay, if the core concept is a race up a mountain, it gives me a lot of room to grow and bolt-on to it. I could model a mountain, build a base game script that would allow a player-controlled avatar to run up it, and see how that worked and felt. I could then add a timer to time out how long it took to climb the mountain. Then I could add variable pathing, like random routes per session. Now we’re getting somewhere!

Then, the game could add enemies, so you’re not just testing your ability to maintain control over a character on a fixed (or variable) path up one mountain. If you add enemies, though, then you likely need to add combat. So what if you add RPG classes, one at a time, with a fixed ability set? Now you can fight them and deal with them in different ways. Cool. Then you can divvy out the class abilities and tie them to progression of some sort, so the higher you climb, the more varied the combat gets. Now you want to make lots of checkpoints where combat becomes the challenge, but those need to spread out too, so that each random route through the mountain has the same number. Then you can add a leaderboard for that asynch multiplayer function – race to beat the best times up the whole thing. Then, hell, if you can find a way to support it, if your classes are already going to be RPG archetypes, why couldn’t they just be a party, and you could make the game scalable to allow a solo player or a group of players able to tackle the mountain!

All that sounded interesting and engaging to me, and so I wrote out the design based on this concept. It meets all my goals for the game:

-Iterative: The gameplay loop can be unfastened and bolted together in an order to make development simple. Does running up the mountain work? Great, now add the route randomness. Each piece builds on what came before, so I can ensure each piece works and they progress in difficulty of implementation, so I can read up on the basics, get a basic framework playable, and then try adding to it.

-Realistically doable in a year: The core model is simple enough and wouldn’t carry a high asset or development cost. Having one map with random routes means not creating tons of modeled landmass, piecing together a world, or anything of the sort, and from a gameplay design perspective, I can put all the work into making sure the one map and the point of variation on it are fun, so I don’t spread thin over more maps. Using RPG archetypes means there is a model to draw from and so I can spend less time thinking of truly brand-new RPG characters.

-Fun and replayable: Fun, well, I hope – but the idea sounds like the kind of simple thing I could sink my teeth into. Replayability is easier to judge on paper – having random routes and some ideas about how enemy spawning behavior would work can paint a picture of a game that is broadly replayable as each session can have a unique element. I do have some secret sauce in a sort of creative bastardization of the WoW Mythic Plus system, but that is a bit hazier and requires some iteration before I feel confident sharing that!

-Visually straightforward: A colorful mountain with simple, high-brightness textures and oddly-proportioned character models should mean that my lack of nature/human modeling skills is less of a handicap. It also means that there would be a limited amount of stuff where I fear I can’t make it, so if I do end up looking for third-party assets, it would be a smaller collection needed!

-Supports single-player and multiplayer with asynchronous support: You can just race up the mountain alone as many times as you want and test your time against everyone online, or could, perhaps, race with friends to complete it together. Seems like that meets my target!

With that foundation set, the next phase begins. Unity is downloaded and installed, and while I’m unlikely to have much more to say about the game this month, I’ve got a few Unity courses lined up and I’m sure that next time I might even have some sketches to share!


One thought on “My Attempt at Making A Game, Part 1 – The Design Document and Outlining the Goals

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.