It’s kind of funny, because this was the exact line of reasoning I had when I began my career before I got my first job. I wanted to start a project that I could do by myself, and I thought that a visual novel would be able to check all of the boxes - learn about all sorts of systems while still being able to do something creative. It seemed simple enough - display images, play some sound, display text properly timed with the music. It did eventually prove to be too large in scope for me, mostly because I didn’t know much at the time, and the total amount of work necessary to complete the project was much more than I had thought. I didn’t have access to it at the time but, if I were you, I would use an out-of-the-box game engine like Unity, GameMaker, etc. to build my first game. It lets you learn the basics without forcing you to do everything.

The main issue here is that doing a lot of this work isn’t trivial. Creating an engine takes a long while, especially if you aren’t familiar with what’s necessary to make it work efficiently. Then there’s all of the art assets - they need to come from somewhere. Beyond that, you’ve still got to use the systems and assets you’ve built to create the game itself. These are all tasks that can take a long time for a single person to complete.

If you want to write your own engine, there’s a large amount of foundation work that needs to be done before you can even get to anything that resembles the game itself. Here are some of the systems you’ll need to write if you wish to do this:

This doesn’t yet include the gameplay stuff, like keeping track of player stats and variables, branching dialogue, and things like that. This is the very basic core systems needed to even think about gameplay.

Then consider things like the art assets you’ll need. For a visual novel, you need a lot of character art. But you’ll also need a lot of environment art - where will your story take place? How will you put that together? You’ll also need UI - every game does. Every icon, every button, every window, every font, every menu will need its own art and layout somehow. Will you draw it all? How will you put it together? You’ll need to compose the music, sure. But are you going to arrange it? Record it? How will you go from the composition to the finished piece? And how many pieces will you need for the entire project? This doesn’t begin to look at the character art or animation requirements. There’s a reason a lot of fan visual novels are very bare-bones in terms of production quality.

Remember, this is all stuff that’s needed in addition to coming up with the game design like who your characters are, what their story arcs will be, and how the player will interact with them. A huge amount of this work is at the foundation level - it isn’t the game so much as it is the stuff necessary to begin building a game. It could take you months of work setting this foundation before even considering your storyline. Instead, I would suggest working with an existing engine like Unity or GameMaker. It takes care of most of the foundation work for you - you don’t need to worry about file formats, capturing inputs from hardware, or rendering to the screen. Instead, you can focus on how you want to build the features you want. And… scope small. Always try to scope small. You don’t need to make your first game your magnum opus. It’s a lot more encouraging to finish what you start, then start a second project with more knowledge and experience. Start small, then add to it as you go.

Related Reading:

Got a burning question you want answered?

Whenever you write any document, as with any content you create, you need to keep your target audience in mind. Design documents are generally read by the designers who will be creating the content and the engineers who will be implementing the technology to make the content possible. As such, you need to anticipate what each of these groups will want to see and provide as much information to each group as needed, because the main point of the document is to minimize the instances of people asking the author questions about how the feature should behave in certain circumstances.

You’re being way too ambitious. What you should be doing is game jams. A game jam, for those who do not know, is when you gather a small group and bang out a playable game within 1-7 days. Within that time, your team has to design and implement an entire game, from start to finish. Obviously, you won’t be producing AAA work within such a short span with such a small team, but you will learn some of the most valuable skills to a game developer by doing (and finishing) game jams. Specifically…

Scope Down

Nothing helps focus you like having a hard deadline. You can take a much more honest look at what you think you are capable of doing if you give yourself a very short time limit. Figure out what it is you can do within the time allotted, and then do it. Scoping too big is what brings down amateur projects the vast majority of the time.

Fail Faster

A lot of game development is iteration. With a looming deadline, you don’t have time to screw around and you can’t commit yourself to long labor-intensive features or content without being able to tell that it’s worth doing. What you can do, however, is find something and iterate on it. The longer the schedule, the harder it is to predict what will actually happen. Keep it agile, try different ideas, and don’t be afraid to toss them and think up new ones.

Finish What You Start

The goal for game development should never be to make your magnum opus on the very first attempt. It won’t work, and you’ll learn things you never knew you needed to know while doing it. The short development cycle means that you’ll be able to finish what you start, and then you’ll learn ways to improve for the next time. But it’s super important to finish what you start. Everyone can start. Not everyone can finish. If you want to make this your career, you need to be someone who can carry through to the very end.

You’ll learn and sharpen all of these qualities by doing game jams. You’ve got the beginnings of a team, and you can either try something formal like [finding a local game jam and attending in person], or simply setting a goal for yourself and sticking to it. But the important thing is the follow through. Ideas are cheap. The people with the necessary drive and skill to see them through are the rarity. Start small and work your way bigger. Game jams are one of the best ways to do it.

You need to know your target platform and design to that. Whatever your lead platform is going to be should inform core design decisions like this. Are you going to be a PC game? Tablet? Mobile? If it is a PC game, is it going to run windowed or full screen? If it is a tablet or mobile game, will it be portrait or landscape orientation?

Most PCs today run at a 16:9 aspect ratio, with native resolution being 1920x1080 or 1680x1050. If you choose this, you need to consider very carefully how much of the screen your characters will take up, because it’s important for the feel of the game.

The larger your characters, the more detail and personality you need to infuse into them. Look at this example from Double Dragon Neon. The characters are large - roughly half the screen size vertically, and you can see their facial expressions and physical characteristics very clearly. The overall environment plays less of a factor here - the characters take center stage, and there is only enough room for a handful of them on the screen before things get too jumbled and confusing. You can see this through the color palette choice - the environment is all browns and yellows, while the characters pop out because of their reds and blues that serve to contrast. Keep in mind that higher resolution characters will also require significantly more art time than smaller - they have much higher amounts of detail, so they will take longer to craft.

The smaller the characters are, the more the emphasis needs to be on the environment they’re in and its level and visual design - you have all that additional screen space and it needs to be used for something. Take a look at this screen shot from Shovel Knight and the relative size of the character. Notice how many different things your eyes are drawn to in this scene - the floating platforms, the glowing book, the character itself, etc. Notice how they use contrasting colors to specifically make the traversible areas visually pop. 

What do you think this would feel like if the sizes were switched? Platforming would be very hard to play if Shovel Knight was the size of Billy and Jimmy Lee. Double Dragon might work with tiny characters, but then you’d have a lot of empty screen space most of the time, unless you filled it with bad guys to fight. But then most of the bad guys would also compress around the players anyway as they approached, which resumes the problem of too much empty screen space.

If you’re considering a mobile platform instead, you need to consider other factors. The iPhone 6 has a different resolution than the iPhone 6 Plus, which has a different resolution than the latest generation of Android phones, and each has a different pixel density. That will affect your visuals as well, depending on which device you are targeting.

In addition to this, you need to consider how the game be controlled. How much of the screen will be covered by the controlling hand? Where will you place the relevant information for the game such that the player will be able to see it while controlling it? How do you use the screen to both control the action and convey the gameplay scene?

Look at the screenshot above. This type of scheme could work for a tablet, but definitely not for a phone. Consider the relative amount of space your hand takes up. In addition, this control scheme would be terrible for left-handed players, since they would have to cover up the wave information with their hands as they controlled it. You need to take this into consideration when planning your game.

As you can see, there are a lot of considerations to make when deciding something as seemingly-simple as screen and character resolution. What you and your partner need to do is first take a step back and figure out what sort of visuals work best for the game you want to create, and whether it works for the platform you’re planning to release on. Put yourself in the player’s shoes and try to think about what sort of things the player will want to do and want to see when playing the game. Then build your game’s visuals around that. You want the player to have all of the information that he needs in order to have fun and minimize frustration. And then take a breath, because you’ll then need to figure out what sort of technical constraints you have to work within as well - how many characters you can animate at a given time without performance hitching, what your min-spec target machine will be, and so on. The list of things to consider really is never-ending, but it’s all part of the fun of creation.

Do you remember the exact details of what you had for breakfast last week? How about the wording for the email you wrote two days before? There’s two main reasons you write a design document. The first is, as you said, communicating the designer’s vision to others. But you should also write it for the second reason - it’s hard to remember specific details later on.

The alternative is making it up as you go, which has a host of its own problems. A lot of ideas you have about things as you start will be discarded as you go, and you should try to think about how all of the parts of each system fit in with each other before you begin, or you’ll have to scramble and hack things together to make them work. 

If you’re doing the implementation of the work yourself, it is a tremendous help to have a document to refer back to if you don’t necessarily remember specific details of features. It also helps serve as a reminder and overall estimate for how much work you have left to do, and a way to gauge your estimated finish date. 

One of the biggest problems that design documents are supposed to alleviate are to help track all of the little fiddly implementation details that aren't easily remembered - things like edge cases, UI elements, formulas, and so on. You might come up with some great ideas for spells or combo bonuses or monsters, but that sort of thing is really tough to implement later if you don't write down the details.

Cinematics have been a big thing ever since the 8-bit NES days. The purpose of the cinematics is to help tell a story and evoke an experience, a feeling in the player. Not everyone will be super receptive to this, but it has a rather large effect on most of the audience and does a lot to immerse the player into the situation. This sort of feature mostly eschews “gameplay” or “graphics”, but it is still extremely popular because it helps establish believability and characterization within a game’s scope. Whenever you’re trying to tell a story with characters, the cinematics become important. It isn’t terribly important for a game like Minecraft, League, or Hearthstone, but cinematics are a natural extension of any game where telling the story is the primary emphasis.

It’s important that we as developers continue to evolve tools, technology, and design to help provide for players who enjoy such things. We can use Bioware games as an example of the western pioneer for such content, as well as an example of how such content has evolved over time. Let’s break down something of a sticky point for a specific subset of players: RPG romances. Be forewarned: Spoilers for Baldur’s Gate 2 (2000) and Dragon Age Inquisition (2014).

The main issue with features like this is that the gameplay they provide comes at the cost significantly increased system complexity and difficulty to maintain believability. What seems simple to start with doesn’t stay simple very long. If you go back and examine how the old games handled it, you’ll often find that they didn’t really put a whole lot of effort into it either - and if you logically follow these features through to their conclusion, they generally don’t add up in terms of cost to benefit ratio. But that’s just theory. Let’s take one of your examples here and break it down: What’s really involved with shooting somebody in the leg?

This subject is another one of those that I could probably fill an entire book with and still not scratch the surface. Most of understanding the breakdown of games (design or otherwise) comes from context and experience - once you’ve had to build something for yourself, you become cognizant of the sorts of issues that would come up. The more things you build, the better you get at recognizing the aspects you’ll need to consider in order to build a new thing. However, in my experience, the biggest difference I consistently see between a professional developer and a layman is the ability for a professional developer to recognize the scope of specific features and view them as their own separate modules. If you want to be a real designer, you absolutely need to be able to break down features into their component parts.

In order to understand what a progression system is used for, you need to understand the concept of gameplay loops. Let’s use Call of Duty as our example today, since it’s a great case of a non-RPG game that successfully integrated a progression system into their gameplay.

I spoke with one of the senior designers on my team about this particular matter, and here’s what he had to say.

Recruiters/HR actually like design degrees. They aren’t experts in the field, so they are the ones that are impressed by big words. If you have a degree in game design from some accredited university, you’ll typically be on the faster track to getting your resume passed to the Hiring Manager. HR will more likely set those resumes aside after they first get all the candidates with real professional experience. 

If you are getting a degree, you should consider who it is you want to work for. If you obtain a mobile development degree, it means you’ll either be starting your own studio, or trying to get hired by a mobile studio where they probably won’t have a large HR department where the degree will come in handy. It may, however, help impress a smaller mobile studio if you have relevant coursework making actual games for iOS or Android, or possibly the mobile studios under the larger game publishers like Square-Enix and Electronic Arts. In that regard, a degree will likely get your resume passed to the hiring manager.

The hiring manager, however, doesn’t care as much about your degree as she does about your actual experience. When she goes in to interview you, she wants the answers to three primary questions:

What this means is that you’ve got to bring project experience to the table, and you need to be able to answer critical questions about the projects you’ve worked on. We want to know what you’ve done, but also why you did it. So we’ll typically ask questions like:

We’re always looking for strong, critical thought because we need to be able to kill our (figurative) babies. We need to be able to make the hard decision to scope, change, and streamline the features we love, as well as flesh out and improve the features we don’t. We need to be sure our new hire can be useful in doing tasks like this for the good of the project, and with an eye toward the future.

These are the sort of skills you’ll need to bring to the table regardless of whether you get a degree in game design. Our last hire had no design degree at all, but wrote 14 different mods on his own and could answer all of our questions about them. He ended up beat out several candidates with design degrees. Remember, a degree will help you clear that first hurdle, but the second one will be up to you. You’ll need to demonstrate your ability to do actual work and get along with the team members. I hope you are up to the challenge.

The general use of a scripting language over a more powerful and complicated language like C++ is that it is mostly designers who are doing the scripting, and not programmers. Scripters aren’t usually required to know as much about programming as engineers - they have a different skillset, are generally cheaper in terms of salary, and generally fill a different role on the team. They need to know the basics, for sure, but (as I said yesterday) they can get by without needing to know the real nitty gritty stuff that software engineers typically spend months or years studying.

Scripting languages are generally considered programming-lite - they aren’t as powerful, because they’ll be used for a much smaller subset of things happening. Most of the time, the scripting language only cares about things like game events. Spawn this, play VFX there, camera change that, save the game here. They don’t actually define or create the system to do these things, they just call the actual routines that do. This way, the programmers can keep a layer of abstraction from the scripters - the scripter doesn’t need to know how the VFX call actually works, he only needs to know which VFX to play and when to play it. He can trust that the script will do what it says. The engineer is the one who has to look up the VFX name and load the data, call the appropriate node, make sure it plays right in the right place, and so on and so forth. It is her responsibility to make it display correctly when the scripter makes that call, but she doesn’t have to worry about whether the player has actually started the fire or not. It’s this distinction that makes the difference more apparent - C++ is tailored for optimization at the end, while scripting languages are tailored for iteration time during the process.

C++ is a compiled language - the code is written, then compiled and optimized, and turned into a bunch of 1s and 0s that only the machine can understand. In order for any changes to be made, you need to change the code, compile it again, and reload the binaries into memory. The compiling process does a lot of optimization for you - the general result is a much faster program when everything is said and done. It takes time to do the compile-link-restart process, but you get a significantly more efficient program in the end.

Lua (like many scripting languages) is an interpreted language. This means that you don’t actually need to recompile it when you make changes - there’s an active virtual machine that is running live when you make those changes, so all you need to do is update your script and the changes will take effect almost immediately. The drawback to this is that you need to mark off some amount of system resources to run the virtual machine, since it needs to be ready to parse and run any new updated scripts. However, the ability to run scripts without compiling and building speeds up iteration time significantly, because you can make a small change and see its effects instantly. It’s much better for designers who are often tweaking or changing things incrementally, rather than engineers who care more about program efficiency. Lua itself is really good in this regard, which is why so many developers use it - the lua virtual machine usually only takes up around 300-350k of memory while it is running.

The real trick to it is deciding what belongs on which side. Scripters in Lua-land generally sticks to deciding when a call should be made - when to kick off an effect, when to spawn a dude, when to play some music, when to trigger a dialogue. The actual acts of running these sorts of events, however, should live in C++ land, because they often involve the loading, processing, and handling of data. Handling data is traditionally something you want to be as efficient as possible, which is where C++ gets to shine. The gameplay programmers provide the scripters the sort of commands they can call from script, and the scripters work within the selection of calls they have been given to create the player-facing content of the game. 

There’s a pervading myth of what “Game Balance” should be, and very few people can actually agree on what it is. It’s been difficult for lots of people to get a good handle on, and even harder to actually do without just shooting from the hip, especially in games like fighters and FPS games where the difference between the recovery on a move taking a fraction of a second makes almost no difference to a new player, but can make or break an expert. So before I go into how we achieve “game balance”, first we need to understand just what “game balance” is.

I could probably write entire books answering the questions you ask, so I’m just going to give the short answer and provide links for further reading. Hopefully that will be sufficient. If you want more, ask again with more specificity. I already get complaints about how long my posts are.

First, let me link my FAQ. It answers a lot of common questions.

AAGD’s Game Career FAQ

And next we move on to the questions:

What do game designers do?

Designers are creators of content.

Designers use tools (level editors, spreadsheets, proprietary tools, etc.) created by programmers to actually create the content. Designers are the masters of the specific, while programmers are the masters of the general. If you’re ever talking about a specific instance - this NPC, this weapon, this boss fight, this cinematic, this stat, you’re looking at something a game designer did. They are the ones who craft the level to be the shape it is, the item to have those stats, the specific character to have that personality.

Further Reading:

What are game design documents?

Game design documents are documents that game designers write to outline and explain how a new mechanic or feature works. They write these documents to communicate the details of the feature to the artists, programmers, and other designers who will have to actually create them. The document acts as an intermediary, so that these folks can get their questions answered when the designer is unavailable, as well as keeping the design straight since human memory is notoriously fallible.

Further Reading:

How does design fit into the overall development process?

Designers create documents during the preproduction phase to outline the details of the features that need implementing. Then, during the production phase, they use the tools and assets created by the programmers and artists to actually create the specific content that uses the features they outlined in their documents during preproduction. It is an ongoing process, with a lot of iteration - the artists add in new assets to use, the programmers make more features available, and the designers need to use these new features to create the content.

Further Reading:

What do hiring managers look for in game designers?

And, as always, that FAQ link again:

AAGD’s Game Career FAQ

"Do you believe that my being faster, stronger has anything to do with muscles in this place?"

Video games are entirely abstract constructs, created solely from the rules of our own making. We try to model the game rules after real ones in some amount of similarity, but things like muscular development, or traditional front-line combat fighters mean almost nothing when you’re talking about a fantasy or science fiction world that can choose which laws of physics it wishes to adhere to. There’s really only one reason why the default protagonist in video games is a middle-aged white man - the developers and publishers choose it to be so.