Category: Game Design

Have you noticed a change in the way a game is developed throughout the years?

This is a doctoral thesis sort of topic. The short answer is that everything is changing, all the time. There is no stasis, period.

The simplest way to look at this is hardware and tooling. In the past, you could code your own engine and that wasn’t an insane thing to do. Now it is. There are too many good free-or-cheap engines available for indies, particularly with options that only kick in with costs if you actually succeed. But even a game engine that is huge is not complete without a lot of other middleware, and that will vary from project to project in terms of what you need. This goes for AAA and indie games. To pick one random example: very few AAA companies are hand-modeling all the trees in their game world now. They’re using SpeedTree or another middleware tool to get the results they need and move on. The old joke about lots of artists just sitting around modeling rocks? Nobody is actually doing that, unless the rocks are really specific and impactful for some reason. People are using middleware like Megascans or Quixel to get actual high-resolution scans of physical rocks, and then the environment artists are doing scene composition with those. Some artists are of course doing their own photogrammetry to bring in custom things, but in the general sense why would you pay someone to do that when there is middleware that is cheaper? Have your artists work on something more unique and impactful than the literal rocks.

In the past, there were many limitations with RAM and available CPU and GPU processing. There still are limitations, of course, but it’s on a whole different level now. You can go for something vaguely photorealistic on pretty low-end hardware now, or there’s a thousand ways you can go for a stylized effect. Again, middleware is often really helpful in finding a stylized effect that you want. You need artists to have an eye for this and not just slap a filter on with no sense of design, but the analogy I would give is that there is a supply chain, now. In other words, metaphorically speaking, ten years ago if you wanted someone to “paint your house,” you would hire someone to come out, look at your house, and sit right there and then find just the right pigments and create paint on the spot, then paint your house with that paint, using brushes and rollers they carved themselves. As you can imagine, this is a silly amount of expense. Brushes and rollers are mass-produced and cheap to buy. There are stores where you can get any color mixed with ease. So instead you pay the painter to go buy those supplies and then just paint your house, and the whole process is bother higher quality and cheaper. To torture this analogy a bit, now the painters are going to be doing much more complex paint jobs, though, rather than just picking a couple of colors and applying those. If you look at this and can see why it’s acceptable to have a supply chain that leads up to physical art (who makes their own paint or brushes by hand, and why would we expect them to?), then the same should be true of the virtual supply chain and the endless, endless middleware out there. Someone else already did a lot of the things that you need, probably better than you can, so just license that. But that doesn’t mean that you’re suddenly qualified to just throw things together and expect a good result. Artists are needed now as much as ever, but they are able to focus now on the actual art.

Programming and every other sub-discipline is the same. Are you going to spend two years with your programmers making a general engine that will be outdated by the time it’s finished? That’s foolish. You’re going to license another engine. This isn’t cheating, this is more mature ecosystem. In film, do you expect the director to construct her own cameras and dollys? Of course not. She buys or rents those. She may or may not have a custom costume department, or might contract with a company that does nothing but specialize in costume design.

Anyone that is a “one person show” is still standing on the shoulders of giants even if they try to do all the things themselves. So trying to do absolutely everything yourself is a backwards way of thinking in my opinion, and a bit of a masochistic way to work. You can be an auteur and still use middleware. If anything, that can give you more chances to be involved in all the possible parts of the process.

All of that was internally-focused. Focused on how games are made, not how they are sold. When it comes to those external factors, of how games get sold and what the market is, that is no less dynamic. Every year the market is a bit different, and things move more and more digital. The competition from other companies small and large is more and more fierce, because there are more people trying their hand at this. A lot of them are terrible at it, but there are still an ever-increasing number of people who do a very excellent job. Some of these people you will never be able to compete with because they are a team of talented young folks living in their parents’ basements, working 90 hour weeks for 5 years, to put out a work of utter majesty before disappearing forever because the business was not sustainable. Other companies you can’t compete with because they create unsustainable conditions for their workers, and rely on them burning out before their 30s but just hiring new talent out of school. There is an endless supply of of excited new talent, so a company can freely burn out their staff and have turnover without losing their ability to output amazing work.

We tend to focus on the creative leads, who also work long hours but stick around longer because their life is not quite so grueling. But under them is an ever-churning mass of people with hopes of one day getting that sort of job, only to have those hopes dashed when they realize there are only so many openings. My advice is to not work for a company like this. And if you are trying to create something on your own, then be sure that you consider what your lifestyle is like for yourself and those who work for you. Do you want to have a company culture that allows people to have families, and take vacations? Then you need to budget for that. And you probably need to accept the fact that this will make you slower, and have a lower-production-values end product than your less-ethical counterparts.

Then again, if you can carve a niche for yourself and connect with people, and find whatever balance works for you, this is how you can still be around a decade or three later, when everyone else burned out long before. I love my job and still intend to be doing this 30 years from now. I definitely don’t have everything all figured out, but I have learned that I should not try to chase certain dreams if I want to keep any of my values. Maybe someday I’ll have infinite money for some magical reason, and then I can chase those dream projects. Then again, maybe all I need to do is wait for middleware to mature even more, and no magic will be required. For now, I do what you should do: try to pick something with a scope that you can hit, with production values that are pleasing but not going to bankrupt you financially or morally, and then see what happens. If you truly plan on making this a career, then whatever you’re working on right now is not your last game. Don’t feel in a hurry to “do it all now.”

Try to keep your project times to just a couple of years if you can, so that not all your eggs are in one basket and so that the market doesn’t move on while you’re building your game. And above all, only do this if you actually love the process itself. If you don’t actually enjoy this sort of work, then being able to weather the ups and downs is going to be next to impossible. Games are fun to play, but making them is a serious and difficult discipline even in an ethical company. If you don’t actually love the art and science of it, you’re going to have a very bad time indeed. There are much easier industries to get a steady paycheck from if you are a programmer in particular, if the game development process doesn’t speak to you on a level beyond just money.

The future of indie games looks bright to me, but it’s also a bit of a maelstrom. If that sounds good to you, then come on on!

What tools do developers use to make an indie game?

If you want, you can code your own game engine. I don’t recommend it. I had coded my own from 2002 through 2009, but later ported my custom engine to Unity 3D in 2010. It’s a different time period now, and you want to be able to hit PCs, macs, consoles, and who knows what else.

Unity 3D and Unreal Engine are both fairly straightforward to learn, and both have pros and cons. Personally, I believe that Unity is better in terms of general flexibility and making something truly unique. You can also have something gorgeous in that engine; it has plenty of power. But Unreal makes it faster to have something gorgeous. It is harder to prototype in Unreal, though, in my opinion.

If you are making a 2D game — a challenging sub-market now — then you can use all sorts of 2D engines.

If you’re making a 2D or a 3D game, there are then dozens of products that you will need to use for a ton of different purposes. Every developer uses different things, and it’s impossible to generalize.

I’ll give a partial list of the software that I use on my projects of the moment, just to give you an idea:

  • Unity 3D as the main engine
  • ZBrush for sculpting (I have also used Sculptris and Mudbox, but prefer ZBrush)
  • 3D Coat for uv unwrapping and digital painting (parametric and otherwise).
  • Substance Painter is also great for what 3D Coat is good for, and I also used that on my current project, but overall I prefer 3D Coat.
  • MooTools Polygon Cruncher for general optimization of large models. Though sometimes I do this work directly in ZBrush.
  • Maya for certain types of modeling, although personally I don’t use it — but some contractors do, and I use the fbxes they create from that.
  • Google Docs and Google Sheets for communication with team members and design documents.
  • Adobe Audition for sound editing. Audacity is a free alternative, but less powerful in many ways. I have dozens of plugins for various kind of sound editing in Audition.
  • Various sound banks for foley sound and ambient sounds and sound effects. I’ve collected from a few dozen sources over the years, and at this point I have a few terabytes of compressed material to pull from.
  • Soundminer for poring through those sound banks and pulling out the specific sounds I am looking for based on metadata. You’d be amazed how much time this saves.
  • TextMeshPro in unity for proper text rendering and optimization
  • TexturePacker for external sprite atlas generation (you need this even for 3D games because of UI icons).
  • Amplify Shader Editor (this is a core tool for how I create shaders in Unity. You likely don’t want to just use the standard off the shelf shaders).
  • FinalIK by RootMotion for inverse kinematics support if you’re doing character animation.
  • iClone and Character creator for character design and animation. There are plugins there for facial motion capture and various forms of body motion capture.
  • PolyFew for in-engine final optimization and LOD creation. Use unity’s LOD system if you must, but it’s possible to code a more efficient version yourself.
  • Lighting Box for unity (there are HDRP and other pipleine versions). These help you to get away from that “unity feel” in your games.
  • Feel for unity — this helps you give more impact to motions, and generally just spice up things so that actions don’t feel rigid. You can use this even during your prototyping phase for that first 5 minutes, because the way things react does impact us emotionally and it’s not cheating to use this sort of thing in the same way that good graphics or audio might be considered cheating at the early stages when you are wondering if the game is fun or not.
  • Rewired for unity — if you’re supporting controllers and a variety of control schemes, and you need key rebinding during gameplay, then you need a solution like this one. I’ve used a variety of such solutions on various projects, as well as coding my own from scratch. For the broadest possible spectrum of platforms, Rewired is currently the one to go with.
  • TortioseSVN for source control, with as the provider. If you prefer to host it yourself internally, then VisualSVN Server is not expensive. If you prefer Git, then that’s also fine. Git is more flexible in some ways, but more complex in others.
  • Visual Studio 2019 for coding.
  • Notepad++ for xml editing.
  • VisualSVN for Visual Studio SVN integration
  • Bandicam for video recording
  • Photoshop for everything 2D
  • FileBoss for mass file operations
  • FreeFileSync for moving things around easily during the “push a new build” process. It’s faster and more accurate than using batch scripts.
  • Batch scripting for the actual compile process (this is faster and more accurate than other alternatives). Robocopy is a key part of these sort of batch script chains.
  • WinMerge for file diffing when looking at logs.
  • FMOD can be a great tool for audio, although I am only planning on using it and have not done so in a project yet.
  • Blender for certain kinds of 3D editing. It’s the easiest tool I know of when it comes to outright deleting certain parts of geometry by hand.
  • iDrive for nightly backups so that I’m never losing my work or my purchases.
  • Google Drive for certain large files that need to be shared with the team remotely. This pairs well with FreeFileSync, which can pull and push from there.

And… there’s literally multiple dozens of other tools that I have used or do use, but less frequently. Don’t be afraid to code your own time-saving tools from time to time, especially if you’re going to be doing this for a long time and see places where you can save some time.

What are the different phases in a development cycle when creating an indie game?

My first advice is to go watch the series on Film Courage where they interview Jack Grapes. He explains his philosophy on Method Writing, on which he teaches courses and has written many books. There is not a 1:1 analogue with game development, but as he himself notes, his concepts apply to any field of work. He explains the role of failure and authenticity in leading to future success far more succinctly than I can.

Now, to your question in specifics. I find that the question is broad enough that you’re likely to get very poor quality or very contradictory answers. “Here is the method I used to make a game” is certainly something a first-time indie can tell you, and “here is the formula I use for this series” is another answer that a repeat indie with a series (“spiritually” connected like what Supergiant Games does, or literally connected with proper numerals).

If you are looking to mimic the success of some other game, but you have a twist, then that also has its own process.

I have been making indie games longer than all but a score or two of other folks in the world, so my perspective is a bit different. My observation is that most people pour their soul into a first game, and then if it does well or poorly, they are probably pretty wrung out by the end of it. Most people do not make a second game, and if they do make a second game, it’s rare that that one does as well.

My own experience over the last 12 years has been that I’ve made I think about ten released titles, and something like twenty released products (so that includes DLCs). I have had to recall one game from Early Access and refund players because its prospects were so poor because of decisions I made (In Case of Emergency, Release Raptor), and I’ve had half more than a dozen projects that got some way through production or preproduction and then were scrapped for some reason, or transformed into something else entirely than what I set out to make at the start. Stars Beyond Reach is the one with the most publicity, but even my title A Valley Without Wind (the first one) started out top-down and was in magazines, and then went sidescroller before release. I got a lot of flack for that, and people questioning loudly in comments sections if I knew what I was doing.

The answer? NO.

I have no idea what I’m doing on the one hand, but on the other there is a method to the madness. So let’s zoom out to the phases of understanding a project, personally, as you create it. At the very start of a project, you have some sort of core idea. I have long referred to these as “Immutable Design Goals.” In other words, these are the core things about your game that must be true at the end for it to be the game you set out to make. When I was making my first commercial game, AI War: Fleet Command, which in all has generated more than $2m USD for my company, I had a few: 1) “I want to feel like Ender Wiggin.” 2) “I want to be able to play multiplayer in this with my dad and uncle.” 3) “I want all of the feelings of power and scale that Supreme Commander gave me.”

From that point, once you know your immutable design goals, you can set out on actually doing preproduction on a game. The way I did this for my entire career is wrong and backwards, though, I am now convinced. You can use a suboptimal process for making a game and still make a masterpiece, by the way — you just won’t understand, not truly, how you did it. And you’ll always wonder “how can I do that again?” My suggestion is to use a process that actually process that you can understand why things work. With our game Starward Rogue, and our other title Tidalis, both of which were devestating commercial flops but quite popular with players and critics, this is the process I used. Clearly a good process is not tied to commercial success. Luck plays a role, but so does how you communicate about the game, and how you onboard players.

What’s the most straightforward way to onboard players to a complex game? The unfortunate answer is… there is not one. A very complicated game will typically require understanding many interlocking concepts in order to truly play it and have fun. In other words, with a sufficiently complex game, you as a player can’t understand the complexities of the late game (and all the majesty and fun that might be found there) until you understand not only the mechanics of the many subsystems of the game, but also how the expression of those mechanics plays out over time and experience. Most people will not stick around that long, especially in today’s market.

A better approach is to stick with games that have core central systems that are fun in under five minutes. I don’t care if you’re making the next Crusader Kings or if you’re making a casual puzzle game or a “brainless” action brawler. If you can give players something that they understand in five minutes, that they enjoy for its own sake, then you’re on the right path to onboarding them. Because it doesn’t matter how amazing your game is when you finish it — if it takes players 30 minutes or 5 hours to really “get it,” then you’re playing with fire. You may find success with that, as I have multiple times, but you may also find that the market gives you a miss, which has also happened to me multiple times.

I bring this up, because this is the second phase of game development. You need to develop some sort of “vertical slice” of your game that gives 5 minutes that is enjoyable. Again, let’s assume you want to build the next super-complicated RPG, 4X, or MMO. I don’t care what it is. You need to have an absolutely rock solid 5 minute experience for people before you go beyond the basics. As noted, this is backwards from how I have actually developed most of my games in the past, but I have come to believe that it’s imperative to mitigate risk in today’s market. Attention spans are not long, and if people are not hooked in some fashion very fast, then they will move on. This of course applies to press demos and conventions, but also just people organically trying your game on Steam and deciding if they want to refund it. If you can’t give them some fulfillment in five minutes, you’ve made a terrible mistake.

It is going to take you a long time to get a compelling five minutes. With an individual or team working full-time, it’s likely going to take you months unless you get very lucky. I strongly suggest that any art or music that is happening during this time be of the pre-production variety, because what you are creating at this stage is not something that should have integrated art or music yet. If it’s not engaging without music and without stock ugly graphics, then it’s not going to be truly engaging with gorgeous graphics and a wonderful score, either. Pretty graphics and beautiful music and perfect sound design can elevate a game for sure — but that’s for later. At the moment, all it can do is distract you, or make your game seem more fun than it is (others, later, often won’t share your sentiment, but you’ll find out too late).

So, during this early period where you know what the general goals of the game are, and where you are working on that 5-minute vertical slice with placeholder graphics, you can also be conceptualizing what the graphics pipeline is going to be like, and what the sound design might be like, and what the visual style would be, and so on. But keep these separate. Don’t put the pretty graphics and sound onto your naked game skeleton yet. Wait until that 5 minutes is fun.

You are going to fail, and this is expected. Your very clever ideas on paper will never work in practice — again, unless you are very lucky. Even if you have made half a dozen games before, even if you are a veteran of 30 years, THIS new project is new, and you don’t know what you are doing. You know how you made something else in that scenario, but you still don’t know how you will make THIS new game. So you will fail. Over and over. You will be very frustrated, and think that maybe my idea of the 5 minutes of compelling gameplay is not a good one. “If only people could play the late game, this would be fun, I bet.” But don’t listen to that voice!

When you have failed at this enough, eventually something unexpected will happen and it will be fun all of a sudden. Some combination of ideas that you never would have come to while staring at a design document suddenly coalesce and are fun in PRACTICE, not just in the hypothetical.

I am of the opinion that traditional design documents are a great evil for new projects. I have written extremely detailed design documents for a number of projects, and every one of them suffered for it. What you need is a general idea of your goals, and then to get a prototype of a vertical slice. AFTER you have a working vertical slice that is fun, then it’s time to start working on a design document. You need a roadmap for the rest of the project now that you have a central core that is fun. But you can’t even start this until you have a working core. Design documents are an amazing tool for revising a project, or adding onto it (DLC), or expanding from that central working core. But having any sort of design document prior to having a fun core is a profoundly dangerous thing. It gives you a sense of security that you should not have: “Well, this game is not any fun yet, but this is just the start of it. When I finish implementing the design document that is so brilliant, it will be fun.” Trust me: it will not. Or if it is — in that event that you are incredibly lucky — then you now are back to that same problem of onboarding new players, because they have to play much longer than 5 minutes to find the fun game you made. That’s the absolute best-case of that sort of design style, and it’s not a very good one.

Once you have a core vertical slice that is engaging to play (I keep saying fun, but not all games are meant to be fun — some are emotionally affecting instead, or intellectually compelling, or just pique curiosity to no end), then you have to start being creative in a new way. Games are not five minutes long. In order to give 5 minutes of fun, you had to create some sort of systems and controls to let the player interact with your game, and probably to let the game interact back. Now it’s time to start thinking up variations on this, and how you can layer on new rules, new complexities, new antagonists, new scenarios, new powers or abilities, in order to expand from this core nugget of fun into something more complex while still retaining the central spirit.

During this next process, a design document is a great idea. But even so, don’t treat it like a design bible — again, a terrible mistake. The proof is always in the pudding. Whenever you add something new to the game, you have to ask yourself if this adds to the experience, or if it actually drags it down. A great example of this, in my opinion, is the Yoshi’s Island series. The core mechanics are pretty okay, but it’s not as strong as the main Mario games. What keeps these games especially niche, however, is the fact that there are so many collectibles and items that you get graded on at the end of the level. Normal Mario games allow you to play a level in a way that lets you run through very fast and enjoy the speed and grace of your actions. And they often have collectibles that reward you coming back to a level you played before and exploring further, and more slowly. Similarly, they also have slightly-hidden paths that allow you to run through the level EVEN FASTER if you wish. That’s a great design! All of the parts are in service to the core fun that is running and jumping with Mario. The Yoshi’s Island series has running and jumping and throwing eggs, which is already not as compelling based on how it was implemented. But even worse, you’re constantly saddled with these expectations of getting a good grade at the end of each level, and you feel like you’re doing poorly if you don’t slowly comb through the level for each stupid collectible. It’s not a fun thing to come back to: it’s an upfront chore, or at least that’s how it feels to many people.

This is where it becomes impossible to talk in generalities. Are all collectibles and end-level scores bad? Absolutely not! Some games thrive on them. But you would never be able to tell which ones are actually fun or not based on a written description of those games. You can only tell by playing them, which is why that initial vertical slice, and then further endless prototyping and experimentation, is so important. Hotline: Miami is a great example of a game where the end-of-level scoring is done to perfection. My Friend Pedro is an example of it being done semi-poorly, but not so much that it completely ruins the game as happens with the Yoshi’s Island later entries. (Remember, the later Yoshi’s Island games have the benefit of nostalgia and a giant franchise on their side; they would never make it as indie games without those characters.)

Anyhow. You will keep building and building on your core 5 minutes of fun, constantly evaluating everything that is new for whether it should stay or if it should be cut. If you aren’t sure, then that probably means it should go. Past some certain point, you will still have a pile of ideas that you COULD do, but that you haven’t tried yet, and you will realize “hey, this is already enough; this game is quite big now.” So stop adding ideas and get to polishing. If you keep pushing every last idea, then your game will be over-sized but under-polished. I’ve been guilty of this many times.

At this point, get the graphics to be as good as you can. Work on the music, the sound design, the achievements, any voice work that is needed, and so on. If you are looking for a publisher to fund a game, now would be the time to try to find one. Or if you want to do a kickstarter, then now would be the time to do THAT. Maybe you couldn’t afford art or music or sound before now, or you can’t afford the programmer expertise to really optimize the game. Well, okay then, that’s fine. At this point you can show people something that is demonstrably fun, and also “complete except for hair and makeup.” When you run a kickstarter, DO NOT promise more features. Make it clear that this is about funding the art and music and optimization or whatever. Give people a vertical slice (more than 5 minutes, but less than your whole game) to actually play.

Graphics and audio and the trailer and such — and the game of the game, for that matter — are the first things that people will see about your game, and many will not click a link to see what it is if even the name turns them off. All of these things are important! But especially as a new indie, you can’t be worrying overly much about these things before you actually have a game that is fun.

I used to tell people that games are not fun during most of development, and then at some point suddenly they are. And this remains true. But my strong belief now is that you need to hit that point sooner than later in the project, or stop working on a given project. If you can’t hit a point where you have a fun 5 minute game, then you need to stop and move on to a new concept. This happens sometimes, and that’s okay. Not every core concept is worth hanging onto. If you are not willing to admit defeat and throw away a “great idea” that you can’t execute, you’re setting yourself up for failure. Remember: if you plan on this being your career, you always have a chance to come back to that idea sometime in the future, in a different time when you know more. If it’s that great, then you’ll eventually figure it out, probably while driving somewhere or in the shower. But you do not have to figure it out right this moment. If you’ve hit a brick wall for months, and you’re starting to get truly frustrated, perhaps take a break and at least try a side project. Sometimes that “side project” turns out to be a major winner. This was the exact scenario that happened for me with the original AI War. It was just this little side project from the “main game” I was working on. I released the main game years later, after finishing it, and it bombed hard. It is widely disliked (though loved by an incredibly tiny minority) and has an overwhelmingly negative response on Steam. My side project made buckets of money, is still frequently put on best-ever lists for its genre, and so on. Don’t be afraid to “kill your darlings,” as they say in writing.