Jump to content
  • Advertisement
  • 02/14/14 11:42 AM
    Sign in to follow this  

    Getting Games Done

    Production and Management

    • Posted By Orymus3

    Get Games Done

    This article is aimed at hobbyists/indie developers with limited spare time to dedicate to their projects. It seeks to help them increase their motivation (and finish their projects) all the while improving their working environment setup and productivity. From past experiences, I have learned that the single most important factor to get games done lies with the ability of the developer to deliver increments of functionality at a steady pace. Essentially, a project will only get done if an external eye to the project sees consistent progress throughout longer periods of time. The odds of succeeding are also generally tied with the ability to deliver these increments at more or less regular intervals. There are many reasons why a developer that sets out with the best of intentions will end up being unable to deliver functionality over time, and these reasons will end up killing the project. Rather than discussing the symptoms here, I'll explain my way of overcoming them.

    Implementing a Development Routine (5,1,1 Routine)

    To establish sustainable development over long stretches of time, a developer needs to have a Routine. This mental construct will initially be forced, and eventually become a habit, so that the majority of threats endangering the project will be met with fierce and effortless resistance. Different developers will prefer different routines, of course, so bear in mind this works for me and may not work for you. However, the idea of a Routine remains universal. I call mine the "5,1,1 Routine"... I accidentally created the 5,1,1 Routine during one of my hobby projects, and decided to stick with this method as it allowed me to meet three very important objectives:
    1. Remain motivated with the project by working on fun features most of the time.
    2. Deliver shippable increments of functionality regularly (sustained velocity).
    3. Perform a constant health check of my code with limited effort.

    What is the 5,1,1 Routine?

    The 5,1,1 Routine is a representation of the workload in a given week in regards to three axis.

    5 Dev Days... (I deliver a new feature or improvement) 1 Refactor Day... (I cleanup and optimize the code) 1 Rest Day... (I don't look at the project)

    What are Dev Days?

    This methodology assumes that my codebase is healthy enough to allow me to develop new aspects of the game five days per week, which is what will keep me motivated to continue my work on the project. During these five days, I will develop new features with the quickest possible route in mind, regardless of how "unclean" it will look. The reason for this is twofold:

    a - We're developing an entertainment product (game), and fun is hard to catch. Rarely will the first implementation feel right, therefore it's better to be able to try several messy ways in a single day than to try a single clean way. b - These dev days are meant to keep my motivation high. The fun comes from seeing new things working in my game, not from clean code. The more new stuff I get to try, the more excited I get about the project as a whole. I don't feel wrong because I know that 90% of the things I'll try will end up being discarded, thus won't harm my codebase much at the end of the day.

    Usually, I'll want to deliver something new EVERY day. To achieve this, I like to keep the JIT / DWYN attitude.

    JIT (Just-In-Time): While generally employed to relate to inventory, one can correlate this with information flow in regards to decision-making. Essentially, postpone any technical decision until later. Code your new feature quickly and don't have any foresight about how it can be reused (you can always use your refactor days for that anyway). Do what you need (Lean): A good way to prevent over-engineering, this tells you to code exactly what you need and nothing more. When you refactor later or need to build a more complex mechanic that leverages the same logic, you can always revisit, but assuming that you will and over-engineering will result in tremendous amounts of time loss.

    What is a Refactor Day?

    If you've been developing for a while, chances are you've quit on many projects solely because they reached a point where it would take too long to implement any new idea. This can be explained as technical debt. Though I spend five days per week adding stuff without caring much about how clean the code is, I discipline myself into adding an extra day per week where I am not allowed to develop anything new, and rather, I seek only to clean up my codebase, refactor, etc. In other words, I deal with my technical debt. Note that I use the term discipline to represent that I not only force myself to refactor but that I allow refactoring a very specific amount of time. This allows me to ensure I do enough refactoring so that I can maintain my development velocity, but not too much refactoring, which would pointlessly halt development altogether. This is used as a means to prevent me from falling into either the prototyping mood (which can never amount to shipped large scope projects) or the coder's mood (where the technological thrill outweighs the goal of delivering a game). In the methodology known as Test-Driven Development (TDD), the goal is to reach a functional state as quickly as possible and then refactor. This is usually done within a few minutes. In 5,1,1, this Routine is stretched across a development cycle of a week. The other advantage of having a sixth day dedicated to refactoring is to keep a general understanding of the project. Since I spend five days looking at the new code, I don't want to lose sight of what the rest of the code base looks like, and how I can find ways to optimize/refactor. It also ensures that I'm still familiar with the codebase when I get back to development on the next Dev day the week after. I used to be the kind of developer that tried to get things done through weekend development sprees believing that having longer stretches of time would be more beneficial as my concentration would be easier to muster. It turns out that the amount of concentration required to undergo these sprees is largely due to forgetting a lot about the codebase in-between sprees. As a result, I find a lot more value in spacing that development time across a week and retain a constant understanding of the codebase. For more information on refactoring (and clean code), see
    ">this video. I went to college with this guy, and he's grown into a very successful indie, so I was amazed to watch this video after completing this article.

    What if 5,1,1 breaks?

    It's entirely possible that the 5,1,1 will break, and though this is not desirable per se, it exposes any threat so that it becomes actionable. Determining that the 5,1,1 is broken is fairly simple and can be answered with a very simple question:

    Did I deliver an increment of functionality on each dev day?

    The key to 5,1,1 is to understand why the method broke, and how to fix it. One of the most common reasons for the cycle to break will be that a specific class, function or segment of code is currently in a state that makes it impossible to deliver new increments of functionality on each dev day. This could be due to code readability, unnecessary complexity resulting from multiple iterations, or any other logical issue that could be dealt with on a refactor day. When this occurs, I willingly choose to sacrifice one of my dev days and turn it in an extra refactor day (turning that specific week in a 4,2,1), knowing there's a very specific goal to be attained in order to restore my cycle. I generally refrain from using the 7th day (rest day). The rest day should, most of the time, be sacred. It is a day that keeps everything in equilibrium and allows for this routine to last. No matter how asocial one might be, there's always a time when other things need to get done, and having a routine that leaves room for this is essential. It's also a good way to stay clear from burn-outs.

    Ways to make refactoring fun

    Some developers refactor too much and over-engineer. If you are one such developer, I recommend reading this article. For the more gameplay-oriented programmers, however, refactoring is often perceived as a pain, a necessary evil, and is often cause for grief. We've already addressed a way to build up momentum and motivation by having five dev days, but unless you come to your refactoring day with a plan in mind, you're still likely to loathe it. There are various ways you can approach this, but the important thing here is to prioritize the work that makes the most sense all the while keeping your sanity above ground. My personal approach is to come with a specific goal in mind. It could be that I have identified throughout the week a very painful bit of code that I need to deal with recurrently that could be refactored into something more intuitive and easier to use. It could also be that I happen to think that I've broken enough encapsulation rules to try and fix this before it becomes spaghetti code. The key here is that your recent development cycle is still fresh in memory, so you know where you've struggled, and what you have stained with poor (new) code. Whatever the problem you may have identified, make sure that it will reduce your development time for new features. That way, you won't feel like you're shooting in the dark. Also, make sure to vary your method and focus from week to week to keep things interesting. It's a good way to make sure it does not feel redundant over longer stretches of time.

    Ways to make each dev day more efficient

    Here is a short list of tools and techniques that can help you stay focused and gain velocity. These are software that I have used in various projects. Please note that while I suggest specific software for each category, it may not be the most suitable for you, but it doesn't hurt to know where to start looking. Source Control (SVN / GIT / Perforce) I'm always surprised by developers (generally "lone" wolves) that don't use source versioning. These allow you to do many things at once with relatively little effort:
    • Share your source code with somebody and allow more than one person to work on the project at once. Though you may not plan on having anybody else contributing to the project at this stage, it's not a given that it will never happen.
    • Prevent data loss when your development setup unmistakenly breaks. A simple checkout will restore your project a few minutes away from where you were at.
    • Help you establish a "system." By establishing the rules of "when to commit," you have a more healthy relationship with your development cycle.
    Also, when looking for free hosting for source versioning, I recommend: Assembla. Task / Bug Tracking (Trello, Assembla) As an indie, it's easy to fall prey to the misconception that it's possible for one person to "know-it-all" because of the scope of the project. Even if it were accurate, it would take such a toll on a person's memory that the impact in everyday life is not desirable. Rather, the use of tools that allow you to track tasks and ideas is preferable. I use Trello for my projects. The key here is that a simple tool allows you to do more. Trello has the advantage of being flexible (create your own workflow/categories, the ability to add checklists, etc.). Furthermore, it works on mobile, making it also good at taking notes in the context of a project (rather than in a standalone app). What I like about Trello is that it allows you to create one item (say, a feature) and break it down in many sub-checklists. This way, you can contain within a single feature the necessary logical components, the assets you might need and other requirements, the polish ideas you have along with any bug or optimization requirements you might have. Thus, your Trello board can be a collection of high-level features that display something along the lines of "Feature name - 10/93 items". Continuous Integration (Jenkins) A bit more recent perhaps than other items listed here, the concept of continuous integration is really something to delve into. It allows you to minimize the amount of time lost "building" the project and makes it simple to screen a build whenever you want. By default, it will build a version after every commit you make. Versioning might prove catastrophic at first, but you'll get the hang of it. I'll admit that I've never looked at alternatives to Jenkins. The gain I've experienced when first using Jenkins was so great that I did not bother to compare, but there may be better ways to do this out there.

    How to get Games Done

    You may follow all of the above and still not get games done. That's because while you may understand how to "get there," it's possible that you have no idea where "there" actually is. Say you want to go to Newark's airport, and I tell you it's somewhere along the New Jersey Turnpike, it's quite possible you'll end up god-knows-where along the turnpike because you have no idea what an airport looks like (arguably they've done a pretty good job at putting signs up, and well, there are planes, but without prior knowledge about what planes are it won't help you much). Making games is no exception. If you know your way around development tools and have a development cycle, it's possible you'll miss out on completing a project, despite being highly motivated. If this is your case, here are a few things to bear in mind as you define your overall development "strategy" (something you should think about before starting, and iterate on as time passes by).

    Have a clear idea of what you want to demonstrate

    What you should have at this stage is a "game vision." In simple terms, you should be able to describe the end-user experience before the software is built, knowing that some things will need to shift along the way. You should not know everything in finer d?tails, but you need to have this sort of high-level interpretation of how it will all come together. A good way to confirm that you have a clear idea of what you want to demonstrate is to try to explain your game to a friend using as few words as possible, and yet hype them. If your friend starts saying "oh and you should do this and that..." you should probably ignore the specifics, but you'll at least know you've come up with an idea that is fertile ground. Your job then will only be to squeeze out the fun where it really is and exploit the fun-vein to a maximum.

    How to scope & iterate (MVP)

    As a game developer and designer, your role is initially to demonstrate fun gameplay. The core of your job should be to build a skeleton of the game you want to build, by focusing on its most important aspects (what makes it unique, fun, etc.). If you're not going for original gameplay, and rather focus on execution, then there should be fewer unknowns in regards to what's fun early on, but timing will still be critical. Don't assume that just because you are doing a final fantasy rip off, the same pace should be used in exploration and combat just because it worked for these games. The next logical step is to build an MVP: Minimum-Viable Product. In essence, the MVP represents the minimum your game can ever be. It's a condensed game that contains very few mechanics. However, each mechanic will be brought to complete fruition. The process to get there is to build the skeleton first. Prog-art, your prototype, check what works, what doesn't. Then iterate until this part makes sense. Then, proceed to the next core gameplay mechanic. Once each CORE gameplay mechanic feels right, hone them. Develop each of these mechanics until you feel like your game is a polished gem, with much untapped potential. Play this build over and over again and ask for feedback. THIS is your MVP. If anything happens tomorrow, you'll have at least achieved that (the minimum your game can ever be to deserve to be called a game). Instead of being a shady prototype halfway through completion of the next uber MMORPG, you'll have achieved a shippable game that may just lack depth. Why is this critical? Because from now on, you can release this game anytime you want, and you know the quality you are delivering. In fact, you knew the quality you were delivering every step of the way, never worried about whether other mechanics would feel right or not. Knowing that you can release anytime alleviates the pressure of the unfinished project and helps you keep a high motivation. It's much easier to think in terms of polishing a final product than to get everything missing for release. While you may spend the same amount of time on the game, you've had a lot more control on overall quality, always working on that which has more value and always judging of new feature's value based on their coherence with what is established. This is a mindset that takes some getting used to, but over time, it's something I've grown incapable to avoid based on the sheer benefits of this approach. The drawback to this approach is feature-creep. Having an MVP in hand puts you in a state of mind where you need to consider the features you feel you need to add to complete the greater experience. The problem is that you might get excited about way more features than the game would normally support. There's no real rule to determine when you've entered the feature-creep lane, but if you find yourself months beyond your MVP and still have a lengthy list of things you'd like to add, consider releasing first and adding whatever you need based on user reviews instead. If the game allows it, consider metric-driven development if at all relevant.

    Set Deadlines

    Let's face it, there are many reasons not to set deadlines. This is likely a hobby project, and the truth is that you might enjoy the indefinite nature of it. I won't argue here as I have plenty of side projects of my own that don't have a set deadline. The key difference is that I did not choose to make these a priority and I did not determine I wanted to get them Done. The premise of this article is that you want to get this game done. If this specific project does not fit this criterion, you are more than welcome resuming work on it without actually applying any system or deadline. Just know that it is likely to fail/fall in an indefinite hiatus at some point. There's nothing wrong with that. As a matter of fact, it's better to toy with many ideas at once and choose to only pursue the most fun. Once you've browsed over your projects and have identified the one you really want to complete, then it's time to trade the safety you had knowing there were no "rules" for a system and actual deadlines. Deadlines shouldn't be daunting. You are not liable for a contract here as you would in the corporate world. Rather, think of deadlines as goals, ways to keep a macro idea of where you are headed. I personally like to think of my own deadlines as extremely lax and vague, but they allow me to place tangible milestones in time and give me an idea of the commitment I need to put towards achieving what I want. For example, your first milestone could be just a prototype, and it may take as many milestones as you want just to get to the MVP. Don't try to be too micro. However, you're only likely to make your milestone definition irrelevant as time passes by. Also, don't put an exact date on a milestone. Depending on the scope, a specific week or month may be enough. I personally use quarters of a year and calendar events as references ("I'll get this done before Christmas, and this somewhere in Q1 2014). You don't have to stick to your milestones if the circumstances change (if a core gameplay element isn't as fun as it should and you've chosen to take the time to fix it or find alternatives) but you should always have a broad plan of where you are headed days, weeks, months from now (task tracking helps, especially in the form of notes for "later"). The mere effort to project your project in time is what matters, not the end result. Pat yourself on the back if you meet a deadline, don't focus on the deadlines you miss and simply keep in check the reasons why you have failed. Are you overthinking things? Are you still working on the MVP? It's possible that you'll find out you've been feature-creeping. If you are, learn to let go, push these ideas through Trello instead, and focus on what needs to be done first. Perhaps you'll discover your game vision has grown blurry? Take a pause, reassess what you think the game should be, how it should feel, then resume work. It's pointless to work on fun bits of the game if they can't become part of the greater whole and feel coherent with the experience.

    Random Thoughts & Rants

    Here's a short list of practices you might want to set up. These are mostly aimed at team work environments (2+ people). Weekly Reviews One good practice is to do weekly team review. If you can afford it (even over Skype), this is extremely helpful in setting everybody's expectations straight and keeping the vision clear. It's also a good opportunity to discuss potential features, solutions to some problems, and more importantly, evaluate the level of fun resulting from the current implementation. If using the 5,1,1, you can probably do these every other Rest day. Internal Playtesting If you're working on something on your end while others work on something else, it's always good to send them something partial as you are progressing with minimal information. If possible, seeing them manipulating it is ideal, but comments can also work. It will give you an idea how intuitive what you're doing is and will grant you impressively useful feedbacks. The often forgotten effect of doing this is keeping the motivation across the team. This article does not discuss teamwork much, but it is critical to leverage each other's motivation to keep the boat afloat in larger teams (or risk chain reaction of demotivation). Experiencing what others are doing and receiving a stream of comments on what you are doing keeps the dialogue open. You need to use each other's mind as much as possible to make this the best game it can be. External Playtesting Often discarded... sadly. You need to get out there and let people play your build. Ideally, you want to see them in action (moreso than team members). Be aware of who these players are compared to your target audience (this will let you know which part of the notes you are taking will be truly relevant). There are various ways to do this which doesn't fit within the scope of this article, however. I recommend reading further on the subject of defining your target audience through the big five. Leadership (who owns what) As the team becomes larger, it's important for roles to be clear. By "who owns what," I'm not referring to the final product and legal ownership of the end-result. Rather, I'm discussing about who should have final say on what matters. The best approach I've used this far is to allow everyone to pitch into everything, but give the final say to the one most proficient with that discipline. For example, I do some programming on my projects, but it's not uncommon for my partner to have superior programming skills, and I tend to grant him the final say in everything technical. Likewise, I tend to have a clearer vision of the end product (especially when I'm responsible for initially creating the high-level concept) and like to keep final say in design matters, but not all. To keep other team members motivated on the team, I also break down the design into various features/components. For example, if making a tactical game, though the game may be my original idea, I may end up being teamed with a Tactics Ogre // Final Fantasy Tactics freak. Why not share design ownership? There may be reasons not to share this ownership, though. The important part is to make sure that ownership is clear for everyone to avoid people feeling like they are in control until denied later. Confusion on who owns what can be a real team killer as it turns out, and it's better to gauge team member's assumptions early on (and tell them outright where they might not have authority) than to lead them on until you need to squash their dreams by imposing your vision.


    If you do all of the above, you may not make a great game, but you'll at least complete it, knowing that you've completed something that is as good as you could make it. The difference if you lose hope is that you'll have something to show for instead of nothing. Putting that "decent project that could've been so much more" on your website might draw people to you, either in the form of potential players, or collaborators. Never under-estimate the value of completed projects when gauging for partners. It gives people faith in your ability to get things done, and with the number of indie developers lurking about, this is key to forming bigger teams or relationships. What you'll learn from this experience will also help you on the next project, and the next... until ultimately you release games in the state you want them to be. It can take 4-5+ projects before you get there, but hopefully, this method will make the journey less painful, and leave you with tangible proofs of your efforts. If you have your own system, let me know! I'm always curious about how other minds work, and how people manage to motivate themselves. Though my system allows me to complete games, it's not perfect, and I'm always looking for ways to further improve it. Cheers, - M

    Article Update Log

    28 Jan 2014: Created Draft, modified templating from the original file. 2 July 2015: Updated broken link.

      Report Article
Sign in to follow this  

User Feedback

Create an account or sign in to leave a review

You need to be a member in order to leave a review

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

There are no reviews to display.

  • Advertisement
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By leomide
      Dear developer colleagues,
      The hobby game dev Indie Team leomidestreet Group is searching for new members.
      We develop in our free time and work on our own costs.
      We don't have donations yet or game income.
      We don't have any game released yet.
      We are currently working on a Pong relaunch.
      We cannot afford to pay anyone money for their work (but a part of the participated game dev income is guaranteed in a fair amount determind by the work done)
      Currently we are looking for:
      Programmers in C++
      Model Designers
      Graphical Designers (Artwork, Textures, Materials, etc)
      Sound Artists
      Effects Designers
      Animation Designers
      We are working currently with the Unreal Engine Version 20 for our project Pong+
      A future project after Pong+ is already planned but still secret because of its never before seen story elements.
      We are a singleplayer Story and RPG Game Dev Team.
      The Pong Project is just to start with something easy to make a name and possibly get a little money with that we can push the team.
      We also take rookies (as long as they have at least enough skills for a simple game like Pong)
      Contact about the mail: leomidestreet@gmail.com
      Please attach examples of your work and which position you are looking for in the mail.
      with biggest hopes
      your leomidestreet Group Team
    • By GameDev.net
      Hey there, fellow indie game dev. Let’s cut to the chase: you’ve got a game that you've either just started working on, or maybe it’s already late in production and you need to start building its home on Steam, or maybe your page already exists but it could use some improvement. Whatever the case, you want your Steam page to be as efficient as possible, bringing in good traffic and converting it into wishlists and ultimately sales. I’m going to try and use what experience I’ve gained so far to help you do that. You can either read the disclaimer or jump straight into the thick of it below.
      First off, this is a long, loooong post. Don’t say I didn’t warn you.
      Everything I’m going to share falls into either a) common knowledge that is readily available but a hassle to put together from different sources, b) my personal confirmed experiences and experiences other devs have shared with me, or c) some personal speculations. Please keep this in mind, and don’t treat this post as a foolproof guide to surefire success on Steam. I have not released anything on Valve’s platform yet; my game has had a successful Kickstarter three years ago, I’m gearing up for a release soon, I’m currently at ~8500 wishlists, and I’ve learned a lot by both stumbling into good ideas and fucking up majorly. If I am wrong about anything, please correct me in a comment.
      Throughout this article, I will use my own game as an example, mainly because it was my vehicle to experiment and try to better understand Steam. The intention is to bring everything I’ve learned together in one convenient place, and make optimizing your Steam page easier for you than it was for me.
      Quick terminology index
      Wishlist (addition) - A number that goes up when some poor unsuspecting soul likes your game and throws it onto his “I want to play this later but probably never will” pile of shame; Visit - An unfortunate Steam user has actually landed on your page; Impression - Someone has seen a capsule (a visual asset) of your game on Steam. What you want is to convert these rare, Yeti-like sightings into visits (and, ideally, wishlists & sales);CTR (Click-through rate) - The percentage of impressions that actually end up in visits to your page. It’s important, but wishlist additions are way more important. Existential dread - What your life turns into from the moment you become hooked on checking Steam traffic and wishlist stats daily.  
      1. When do I launch my Steam page?
      Short answer: As early as fucking possible.
      Long answer: Still as early as fucking possible, but with a caveat that I’ll touch on below. You probably already know this, but - prior to actually releasing your game and becoming an internationally adored indie superstar - your main goal in life on Steam will be to accumulate wishlist additions (simply called wishlists from here on out for convenience). That’s what you should care about most, and focus all your efforts on. It therefore stands to reason that the longer before launch your page is up, the more wishlists it can accumulate. One year is not too long. I’ve had mine online since August 2018 and we were late as hell because of bureaucratic issues.
      Now for the caveat I was mentioning: don’t launch your page unless you are sure that you have the best video & visual assets and text descriptions you and your team can come up with. Your first day on Steam is bound to net you a lot of exposure and wishlists - significantly more than most days afterwards. Steam’s elusive algorithm will also start judging your game based on how it performs in this first critical day, so please take it very seriously.
      Please do not launch your Steam page without a trailer! This will make your game look bad, or as a low-effort move on your part at the very least. We’ll dive deeper into trailers below.
      This is our first day on Steam in terms of wishlist additions:

      Your first day on Steam is crucial wishlist-wise
      We did have a trailer, screenshots, and decent copy. Major fuck-up: no tags (more on their importance below). It could have gone a lot better.
      Also, already having a community that you can bring in and positively influence the numbers day one will help. A lot. If you do, make sure you let them know in advance when your page launches, and remind them that very day via social media. Just like on Kickstarter, it’s best to have that moment zero critical mass for a snowball-type effect.
      Always use “wishlist now” as a call to action basically every time you show your game in public:

      "Wishlist on Steam" is now your mantra
      Tl;dr: Bring your Steam page live ASAP but only once you have the best trailer, screenshots and text possible, and ideally with a community boost to boot.
      A quick aside about your game title: in case you haven’t yet named it, keep in mind that certain words fare better than others in Steam searches. I’m not saying name your game “Souls Battle Royale Roguelike Simulator 2021”, but it’s something to keep in mind.
      My game is called Gibbous: A Cthulhu Adventure. I have indeed intentionally chosen a title that the average mortal would have a 0.008% chance of spelling correctly on their first try, BUT it also has both “adventure” and “Cthulhu” in there, which (at least for the time) count towards nice “search suggestions” impressions on Steam. This means that once you start typing either “adventure” or “Cthulhu” in the search bar, my game pops up:

      Search suggestions can get a lot of eyeballs on your baby
      Yes, “Gibbous” is hard to spell and remember and nobody knows what the hell it even means, but on the other hand, good luck finding a specific game with “heroes” in its title by wading through Steam search results. It’s a trade-off, choose carefully.
      Alright, let’s start actually breaking down the Steam page.
      2. The Trailer
      As I’ve said above, don’t launch your page without one. There are great articles out there about how to approach trailers; I will not go super deep into it, you’re better off reading posts like this one by people who actually know their stuff. I’ll just touch on some do-s and don't-s, and some generalities.
      Show off your best gameplay footage up front (it can also be a cutscene if it’s relevant or it helps set the scene). If you plug Google Analytics into your Steam page (more on that below), you’ll notice a lot of users spend no more than half a minute on your page before moving on, and they’re probably checking out your trailer. 
      Try and hook the viewer within the first moments of the trailer, don't faff about
        Unless you sink your hook into them within those precious seconds, they’re off to the next 50th game released on Steam that day. If your game has both a story and voice acting, make sure that the lines you use in your trailer help set up the premise without spoiling too much. Choose wisely, and choose hard-hitting stuff that summarizes the plot or drives atmosphere. Look up free trailer SFX packs on the internet if “epic” is what you’re after. I like this one, but there are probably a bunch out there. There’s also freesound.org that only requires free registration, but keep in mind you will have to credit attributions in the description. I would not advise using royalty-free music in your trailer, unless you don’t have original music in your game. Whatever is unique or representative about your game - put that stuff up front and highlight it hard. They’re called hooks for a reason; please read Ryan Clark’s excellent post about what constitutes a hook and why they should be on your mind constantly when designing your game. And your trailer. If you can think of anything visually or audio-wise that can set your trailer apart and add a bit of wow factor, it would be great. In our case, I used parallax-scrolling 2D layers on my characters to give them a neat 3D effects (reddit post about it here). If the genre and tone permits, and you think you can pull it off, funny helps. Humor is great at retaining people’s attention. Check these trailers out to see what I mean. Again, only do this if people other than your spouse and that one coworker whose promotion depends on you have told you that you are, indeed, a funny guy. Watch a lot of indie game trailers.  
      Don’t start your trailer with a logo (or, God forbid, multiple logos) unless you are a well-known studio, or it’s two seconds tops. I know you spent entire days making it look amazing in After Fx, but gamers don’t care about anything but the game. You have a few precious seconds to make them stay and watch, please don’t let your ego squander them. Don’t go above 2 minutes unless absolutely necessary. Most trailers are about a minute and a half long, and it seems that they’re lately trending towards a minute. We’re all easily distracted idiots - plan accordingly. Not really a “Don’t”, but be very careful if you choose to go for the “epic trailer” feel. If you mess up the mood, or your visuals are (unintentionally) clashing with the bombastic music and sfx, it might have the opposite effect of what you were intending. If you’re unsure, just show it to someone who you know will not spare your feelings (actually, do this, period). Don’t rely on feedback from friends and family. They love you, but they’re liars. Filthy, filthy liars. If your game revolves around a strong narrative structure, don’t do what most movie trailers tend to lately and just give the entire story away. Jesus Christ, what the hell, people!  
      Trailer generalities
      Depending on the genre, it’s sometimes a good idea to think of your trailer as an entire story told in a minute, a minute and a half (again, not giving everything away! Just teasing its high notes).
      Ideally, it should have an intriguing hook up front, a meaty middle part that shows it off efficiently, and a crescendo to a high point and / or a denouement. Read about the peak-end rule and think about how to efficiently apply it to your trailer (and your game).
      Keep in mind that a lot of users have trailers muted by default; if yours relies on audio (especially in the beginning), it might not make sense to someone watching it muted. My trailer starts with the main character asking “You wanna know what my problem is?”. This is meant as an audio hook to ramp up curiosity from the get-go; my solution to the trailer being muted was having the very first thing in the trailer be the text “PROBLEM?”, hopefully making you curious enough to un-mute.

      Sink the hook in early, keep the text snappy and intriguing
      3. The top-right short description
      Probably the most important copy element on your page. Just like the trailer, start strong and try and get their attention immediately. As you can see, I went with crazy cultists and a talking cat; think about what’s impactful about your game. Sum it all up in the middle part, and end with your tagline (mine is “Comedy cosmic horror made in Transylvania”). If you don’t have a tagline, come up with one.

      Sink the hook in early, keep the text snappy and intriguing
      Keep in mind that there’s a character limit - it’s somewhere between 200 and 300. If your page is localized into other languages (more on that below), be very careful when entering this text in languages you don’t speak, because I’ll be damned if I understand how that goddamned character limit can fluctuate like that.
      4. The release date
      There are actually two aspects to this: the forward facing one (what the users see), which can either be a date or custom text, and a tentative release date that you enter in the Steamgames back-end. You can change both as often as you like, but it’s not advisable to overdo it. As for the forward-facing one, if you do go for custom text then try to be clear and concise, e.g. “Coming soon”, “2019”, “TBA”, or “Never, lol”. Don’t use this space to beg for wishlists, I’ve seen that backfire in very ugly ways.
      5. Tags
      According to Steam, tags can help determine what game has you in their “More like this” section. Choosing your tags so that they drive the right kind of traffic your way sounds easier than it is, and you’ll probably have to experiment a bunch, but what is important is to use all your tag slots available. My biggest mistake for a long time: only using 3 or 4 of the 15 possible. I was an idiot; you don’t have to be.
      I strongly advise you to read Steam’s documentation on tags. There’s very important information there that devs (myself included) typically just skim over. Here’s the tl;dr: tag order itself doesn’t seem to matter, but only the first 15 (out of 20 possible) tags count toward who the algorithm decides to show your game to.
      Apparently there’s talk of Steam intending to reduce their importance within the ecosystem, but for now, it seems that they’re pretty damn’ important, so treat them with the proper respect and attention. And a touch of reverence and fear.
      Anyone can tag your game, but you as the developer wield way much more power when you mess around with them. You can ban and reinstate tags at your will. You can encourage people to reinforce your tags, thus affecting their order, but it’s finicky stuff. What you do yourself is easier to control. You apply tags by clicking the plus button on your Steam page, logged in with your dev account:

      Do it.
      Ah, but what tags to apply? Good question, and I doubt anyone but Valve holds the definitive answer. Truth be told, I’ve just experimented until I’ve seen good results in both the traffic results and on Steamlikes, which is a neat site that shows what games have you in their “More like this” section. The more, the merrier. My game currently has 44; to put things into perspective, Sekiro has 2000+. I’m not exactly sure how all of this works - it might heavily rely on popularity or revenue. Your guess is as good as mine, you can go bug the Steamlikes guys on Twitter about it.
      You can also use custom tags you come up with, but other than the dubious satisfaction of wasting an important slot on “totes adorbs XD”, there’s not much to be gained. Check out Steam’s handy Popular Tags list and go from there. Look at games similar to yours. Note that Valve do encourage you to use “rarer” tags that better describe your product, rather than widely used ones such as “adventure” or “action”.
      A quick disclaimer: just getting a lot of traffic doesn’t equal automatic wishlist number increase. The two things that heavily factor into that are quality - which is, uh, subjective - and just how relevant your game is to the people that you’re steering in your page's direction. I suspect that driving a lot of irrelevant, non-converting traffic your way might actually hurt your game rather than help it. Also, it’s reasonable to assume that popularity is a big factor here, but I don’t think it’s ever been confirmed by Steam.
      6. Main description text
      You can let loose here, but keep in mind that there’s only so many words a gamer can silently mouth his way through before the irresistible siren call of the next browser tab yanks them away. Your best bet is to have a more detailed description (2 or 3 paragraphs), and a bullet list of key features.
      You can now add animated gifs to this section. A good idea, but be very careful about file size. In their announcement, Valve warn that “If we see a store page with a large load size (e.g. 15MB+), we may remove any animated GIF's to ensure users can actually visit your page.”
      Just snicker derisively from your 100 Mb/second fortress and check your page load in Chrome by pressing F12 and choosing the Network tab - it’s under “transferred” (thanks for the tip, Alex). I’m sticking to just one gif, so my page load is right under 15MB.

      Keep your page load under 15 MB to be on the safe side
      7. Localization
      In case you’ve decided to localize your game into more languages, congrats - it’s a wise decision. As soon as you’re positive about offering a certain language, enable it ASAP in the Steam back-end. This will significantly help drive traffic from speakers of that language your way. Again, the more the merrier, with EFIGS being the standard, but Russian and Chinese becoming more and more popular. Keep an eye on your Analytics to see where traffic comes from (more on that below).
      If you do localize, please make translating your Steam page a priority. Actually, even if you don’t have the budget to full localize your game, just translating your page into major languages will help.
      8. Social links
      Pretty much self-explanatory: plug in all your youtubes, twitters, facebooks and twitches, plus your website. Speaking of your website, Steam now offers widgets that, when clicked, automatically add your game to the clicker’s wishlist (mental note: add one to our website).
      9. Awards
      Flaunt’em if you got’em.
      10. Achievements and trading cards
      People really seem to like these things. People are weird, but you’re here to give them what they want, not what they need. Incidentally, that’s what gamedev’s really all about.
      11. System Requirements
      Much like talking to the pharmacist before a romantic encounter, please be honest and realistic about what you need in order to perform optimally.
      12. Back-end Safari
      Steamworks’ back-end is a wild ride. Let’s jump in.
      First off, the really important stuff: graphical assets! Let’s talk capsules, first and foremost, since screenshots are pretty much self-explanatory (just choose the pretty ones, and positively no concept art).
      Laura Bularca goes into size and other in-depth stuff in this very helpful blog post. My advice is to have two nicely rendered promo images ready - a big’un and a small’un. Easy!
      The big one - We’ll call him George. Make sure George’s source file is big enough to serve as page background (1438px x 810px), and clear enough that he can be resized and used as the main promo image above the short description. Also clearly display your logo on this latter one, so it’s easily readable at every size.
      The small one - We’ll affectionately call this one Junior. Unless they are magically whisked to your page via your evil marketing machinations or just pure bad luck, versions of Junior are likely Steam users’ first contact with your game in the wild plains of Steam. I am recommending that this little guy be a different image from George, because if you just downsize his detailed, lushly rendered bigger brother you’ll end up with a busy, unintelligible mess.

      George & Junior are brothers, not twins
      As you can see, Kitteh, our feline protagonist, features prominently in both George and Junior (apparently it’s called “staying on brand”), but Junior is way simpler, so he can be easily read and understood at first glance.
      That’s because - like in nature documentaries - Junior has to survive in the very hostile conditions of a quadrillion other thumbnails around it screaming for your attention, and - unlike in nature documentaries - he wants to achieve the exact opposite of camouflaging himself. Also notice that I’ve increased Junior's subtitle so as to improve its readability. Valve are very adamant about the entire game title being included in Junior, so make sure to abide by that rule when submitting assets for approval.
      An effective trick for testing Junior’s efficiency is to take a screenshot of e.g. the New and Trending row of capsules, superimpose your capsule in Photoshop on top of an existing one, and ask a friend or your Nanna to check it out sight unseen, being honest about which of them grab their attention and which don’t. Survival of the fittest and most readable. George and Junior are brothers, and equally important to your game family. Make sure they look related, make sure they’re as pretty as possible. Further watching: check out Valve’s Tom Giardino beautifully explain the concept of capsule readability, with examples. Actually, just watch the whole thing, there’s very useful stuff about trailers in there that I’ve echoed in this article, it’s very good.  
      Store traffic stats
      I never got either math or graphs, but I find myself returning daily to this collection of numbers and pretty colored lines you can find as a tab in the “Marketing and visibility” area of Steam’s back end. You should too, since it’s the best way to gauge how your traffic has been doing the previous day.
      You’ve got a nice big visits graph, an impressions graph that isn’t visible by default, but is a click away, and a detailed traffic numbers breakdown below, divided into a boatload of categories.
      You can “mute and unmute” specific traffic sources on the graphs to see how they’ve been faring, and it never stops being interesting, educational, and terrifying to compare visits to impressions. You can worry about CTR, but don’t obsess about it, because it’s relative and very dependent on how much traffic you are getting. Before starting to appear in search suggestions, my CTR was way bigger; now it’s a fraction of what it was, but daily wishlists have gone up, and your daily number of wishlists is the only thing that matters, really.
      As a general rule, you will of course want your external traffic to be strong, but how you market your game outside of Steam is a whole different discussion we won’t go into here.
      Each traffic report category can be clicked to reveal subcategories. There are way too many to go into detail about here, but the “Other product pages” category is where you can gauge how strong your tag-fu and capsule game are.

      This is good daily information, stay on top of it and use it wisely
      Research all categories via Steam’s documentation, and keep an eye on them daily. For me, at least, this page updates every night at around 12 AM CET.
      As stated before, no matter what you do, you want these to go up every day, or at the very least not plummet. If you’ve done your homework, they should at least be stable, or gently rising.
      Good news for fans of tension and suspense, you can get a hefty dose of both by checking your progress every day around 12 PM CET. Not much else to say other than restate that doing good in this area is what all of your on and off-Steam efforts should be focused on at all times.
      I know a bunch of folks who’ve lost a lot of weight, and the thing they all have in common was not letting one day slip by without weighing themselves, regardless if it proved exhilarating or discouraging. Always being aware of where they were motivated them to stay focused on the task at hand. Same with checking wishlist additions daily - sometimes it feels good, sometimes it makes you shake your fist at the screen in anger and dismay, but at least you always know where you’re at.

      Your heart stops. Then you remember Steam only shows you yesterday’s wishlists, never today’s.
      Google analytics
      Stick it into your Steam back-end. That sounded worse than intended. It’s the tab right next to the Store Traffic Stats. Congratulations, now you can spend the rest of your days up to launch with one eye permanently fixed on GA’s real time results. By the way, Steam almost always shows me ~2x the traffic GA does. I have no idea why that is; if anyone does, let me know in a comment.

      Plug & pray
      Streaming your game live on Steam isn’t just a neat way of showing it off more than in a trailer and a bunch of screenshots, it can get you some super nice exposure via tag pages.
      Here’s what you need to do: download OBS, join this beta broadcast group, then read all about setting up the stream here, go here to get your stream key (aka token) and to pick a server. Go into OBS, choose “custom” as a streaming service, paste in your server address and your token/stream key, and fiddle around with the stream settings until they match what Steam recommends in the previously linked relevant page. I won’t go into OBS scene set up etc, there are plenty of tutorials on YouTube; don’t worry, it’s not exactly rocket science.
      The broadcast will appear at the very top of your page, and, more importantly, it will appear on your main tag page if it reaches at least 10 viewers, and if other broadcasts with more viewers aren’t already hogging those slots (they are).

      Anything over 10, really
      E.g. my main tag page is “adventure”; usually there’s 1 to 3 active streams at any given moment. Any user that scrolls to the very bottom of the tag page can see your stream there if it's above 10 viewers. Another chance at decent traffic, so do consider it. Don’t forget that you can click “Show Chat” and be insulted in real time by smart-asses with nothing better to do. Delightful.
      Other back-end stuff
      Here are some other important things that might be easy to miss in the intimidatingly dark and twisted corridors of Steamworks:
      Genre: Tick the appropriate box for your game. Also tick “indie”, maybe. Keywords: To be honest, this one is still a bit confusing for me. Mine are a bit of a mess, since they're a combination of stuff similar to my tags, and intentional misspellings of my title so that people typing it wrong can still reach my game (i.e. gibos, gibbios, ktulu, chtulu, etc). Saving and publishing: Whenever you are editing your store page, saving does not mean your changes are reflected in the page automatically. You need to hit “publish to public” in order for the public-facing page to reflect how you’ve now made it uglier and more confusing. It’s on that tab they've sneakily labeled “Publish”.  
      13. Steam page discussions
      Pin a thread about your Discord server. You do have a Discord server, right? Make a Discord server. Be nice. Gamers will ask when the game is coming already, constantly. They do not do this to annoy you, they do this because they care about your game, and that’s huge. Someone actually cares about what started out as such a beautiful thing, and now gives you headaches and nightmares and uuuurgh! Be thankful and respectful and as honest as possible when you lie to their faces that it’s almost done and right around the corner. But seriously, be honest and nice - there’s no situation where this advice doesn’t apply. Some of them will also say that they won’t buy your game unless it’s translated into their language. Solution #1: be nice and, if this is true, reassure them that it will be available as soon as budget permits. Solution #2: localize your god damned game already. But, again, be nice. There are exactly zero scenarios where you freak out and let loose on a potential buyer and things end up well for you. It should come naturally, but if it doesn’t, clench your teeth and at least try to be nice. Don’t leave discussion threads unanswered, especially the ones consisting of direct questions to you, even if you don’t yet have the answers. Be honest, and I think I already mentioned being nice a bunch, so let’s move on.  
      14. Wait, that’s it
      I’ll stop here, this was already a lot to take in at once. Congrats if you made it all the way through, you are probably super dedicated and you want to give your game the best shot at success on Steam possible. You’ve got the right attitude, now you just need a Steam presence to match. I really hope this guide helps you find your audience with less hassle - ultimately, it's all about connecting the right customer with the right product, and everybody wins (but Steam wins more).
      If you feel this post has been helpful or interesting, consider thanking me by wishlisting my game and telling a friend who’s into narrative games about it. We’re about to launch soon, and it’s as scary and stressful as it’s exciting.
      Note: This post was originally published on Reddit and is reproduced here with the kind permission of the author.  The author is developing Gibbous - A Cthulu Adventure and would appreciate wishlists on Steam.
    • By jamesmh
      Hey everyone, my first post because I’m curious about the tools that other game developers and writers use to make their stories.
      I currently work as a writer in an Australian game studio. I have a background in writing and developing stories for Films and TV but I’ve found the switch to game writing to be challenging and increasingly time consuming. We have been experimenting with different techniques for writing outside the writer’s room pen and paper stuff, particularly different ways of visualising or modelling stories, potential character arcs etc. I was wondering if anyone has used any software or tools they recommend?
    • By Cara Lu
      I am a business school student but I really don't like those banking or consulting stuff. To be honest I was planning to go to a design school but my parents rejected it.
      I am good at painting but how can a foreigner have an art design job without a related degree. ( I'm from China and the industry there is really disappointing you know)
      Maybe I can start from some backstage support jobs?
      Please, give me some advice. Very appreciated! 
    • By Zen++
      Look at Studios like Naughty-Dog, Eidos-Montereal etc... and take a glance at their Visuals and "cinematism".
      This makes me wonder, which  Requirements or perhaps API should you learn in order to land into these AAA-Studios? 
      Also what should you study in Uni to better your chances even more?
      Thanks in Advance, this is a newbie question so ples don't reply to harsh ,thanks.

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!