Lessons Learned

Abstract:

Just a roughly structured list of things I have personally learned during my time working on games. Might be useful to someone to avoid making the same mistakes I have witnessed or committed.

Subject descriptions:

General – Games; Game Design; Game Development;

General Terms:

Game; Design; Production; Development;

Keywords:

Game Design; Game Development; Project planning; Lessons learned;

Publication Date:

Continuous project since 2023

1. New Project:

• When establishing a new project don’t try to do something that is currently trending, find something that could evolve from the evolution of the current trend or fills a void in the current trend;
• A complete pitch needs to come with an understanding of (if applicable) how the player wins/loses, how the game starts/ends, a mental video of how the game plays, a mental image of how the game looks, and the capability of the pitch owner to communicate this to the team or at least the relevant people that can create mockups and prototypes for it. If the pitch does not have these things it’s worthless;
  • All the mentioned elements are subject to change during the actual production but there must be a solid “this is what we aim for” at the start and it should only be changed if there’s a good reason to do so;
• Design Pillars/Unique selling points/Loglines need to be established before a pitch is complete;

2. Communication:

• Strongly communicated project goals; To do this effectively a strong and capable team lead and vision keeper is required; Effective methods are Design Pillars/Unique selling points/Loglines;
  • Any decision will have to be considered in relation to the core goals of the project to estimate if something is worthwhile or if the goals need to be adjusted;
  • Make sure that the communication baselines (Pillars/Unique selling points/Loglines) do not invalidate each other. Ideally, they should either directly support each other or address different sections of the project that won’t conflict too much;
• Proper metrics for levels, art, and mechanics; So basically anything that should be consistent throughout the project needs to have and follow established metrics;
• Definition of final/good/ready-to-use for assets and features; This will either require an example for each state to compare assets and features against or an established process that each asset/feature has to go through to get through each state;
• Properly documented features, technical implementations, and art guidelines that people have to read up on before working on new features relating to existing systems;
  • Owners for each feature category that enforce the previous statement and serve as information hotspots about their features;
• High-level production plans that are always accessible to each team member and are updated frequently;
  • The team should be aware of the next few milestones (at least for the next 6 months) and what type of work wants to be completed for each of them;
  • Try to set a project deadline even if you don’t have one at the moment. Additional time can always be used for polishing or additional game sections;
• Established naming conventions for folders, engine files, and files outside of the engine that could be relevant to the development process; These naming conventions have to be documented and need to be enforced by the entire team;
  • The same is true for elements that support the game like game and meeting recordings;
  • Give the team access to the naming convention and allow them to add new conventions if they need them. If they are unsure they can ask someone that should be responsible for this document (Design can do that but someone in code that has experience with the art elements of the product is usually more suited here);
    • Either way, this will allow keeping track of the files used for the project and will highlight bad namings early since they are written out so everyone can see them;
• Have milestone branches in your version control so you can always go back to previous milestone versions to compare things against each other;
• While working with a client try to work out what exactly the client wants and ask questions about suggestions made by the client. There are frequent situations during which the client asks for something that causes lots of issues but the client asks for this because they think this would make it easier on the development team;
• While working with a client, establish why something requested would be an issue and what would be needed to resolve it, the client should be aware if a change would increase the costs/duration of a project;
• While working with a client, use a routine delivery date for produced work, something like an updated build every 1st Monday of a month;
  • If possible give the client access to version control so they can check things without disturbing the development team outside of the scheduled delivery date;
• Don’t use acronyms or coined names when communicating anything. The exception here could be commonly known things (if it is not the first thing Google tells you when you type this in it’s not commonly known). Doing this will frequently cause unnecessary miscommunication because while it feels smart to use these short forms it also feels dumb not to understand them so people will frequently not ask for clarification;
  • For anyone asking what a coined name is: “A newly invented word used as the name of an ingredient, product, or brand”; I think this proves the point. Obviously, if there is no easy way to describe something it might be necessary to rely on these practices but try to keep them to a minimum;

3. Culture:

• Focus on motivated and capable people and allow them to drive features forward by giving them ownership over this feature and access to the necessary resources;
• Don’t push a false narrative, address problems with the team in case something is not going great; Ask the team about problems they can see with the development of the project;
  • Celebrate only successful milestones and aim for a “we can do this better” mentality for unsuccessful ones instead of having the same celebrations;
• Unless legally impossible, make every piece of information available to the team;
  • Try to create NDAs that are open enough so team members can talk about what they are doing. The NDA should really only cover elements that are specific to the developed projects; Have NDAs limited to a time frame so people can share information a few years after the project has been released;
• Take note of people that are happy as long as they can do what they want and have no real interest in improving themselves or the product they usually tend to be happy in unproductive projects;
• Try to keep the team around for at least two weeks after a project has been published last planned patch has been published. This will allow for fixing high-level issues if something comes up after a project has been released to the public. The team will be mainly idle during this time but this is usually worth in exchange for the ability to act quickly;
  • If affordable give the team ~1 month’s worth of holiday after a project has been concluded and the safety period has been completed. This will allow everyone to clear their heads for the next project. Increased the likelihood that people will stick around for the next project. If people leave they will frequently leave during this period so it does not mess with any plans. And makes sure more team members are present when the next project starts reducing the number of catch-up meetings required while also creating a more solidified picture of what the project should be in more members of the team;
    • If you plan a post-launch patch (which you should) this holiday section can be placed between the project release date + safety period and the patch release date. Or simply be placed after the patch date + safety period;

4. Quality:

• Set a baseline quality level for each element of the product that would require one (Art: House; Interior; Forest; Vista. Level: short sequence; metrics: Combat: Example gun/sword/weapon);
• Have a single person take ownership of each game element that can be grouped together;
  • This person is responsible that the desired quality is reached;
  • This person can ask for resources to accomplish this;
• If you know that something might be an issue act on it (if it is unclear test it); Do not just assume that it will work itself out;
  • If it seems reasonable that an issue would work itself out when new already planned features are added or because of something else that happens in the future take note of this issue and test it when the elements that should have fixed it are in the project;
• Many issues will be presented when a large-scale audience uses the product and try to schedule a patch for your project ~3-6 months after release while you develop the project. This patch should be dedicated to issues that have been found after release not to finish stuff that did not make it;
• If you strive for the inclusion of accessibility options decide on what you want to cater for at the beginning of the project; Plan your features with these options in mind;
• Repetition/Grinding/Waiting/”and other elements usually defined as bad” can be good inclusions to a game, don’t shy away from these systems, but try to establish them in a way that respects the players’ time and have a clear answer for why this improves the product;
• Try to think about which art/game elements could be combined in one asset and how to set up streaming volumes while creating the first/prototype level;
• Figure out what elements players are using to orientate themselves in your world; Are these elements sufficient to navigate through the game?;
• Think about where/when you want players to stop interacting with your project. Is this enforced? If not what are players left with after this point?;
• Try to keep systems uniform, even if you have asymmetric elements think about where they overlap and if they would benefit if they would overlap in more situations;
• Create a quick and dirty prototype at the very beginning of the project that showcases the very basic product from a design point of view; Then create many technical prototypes to see if the desired features can be developed in a good way;
  • Not every project is a good idea if the early prototypes show glaring issues try something different;
• Check for similar projects early in development and see what you can learn from them and think about why your project makes sense in a world in which these projects already exist;
• A well-polished project has higher quality than one with many features or a long playtime;

5. Scope and Planning:

• Estimate the time required for any feature so that you have ~60% more time than what you expect to need;
  • If you use less time it can either be used for polish or moved over to another feature;
  • Polish at the end of the project/after all the core elements are at a functional basis; Plan time for polish usually ~20% of the project production time + whatever time could be saved during the different stages of development;
  • Plan with an empty time at the end of the project ~2 months for each year of development; This time can be used to counteract bad time estimates or just be used as more time for polishing at the end of the project;
    • While this time is specifically planned as a buffer for other features it should be noted that the project will likely be better if the time is used for polishing;
• Give every high-level element a dedicated time frame based on what you would expect it to take*1.6;
  • If you are faster or slower than this time frame future features must be addressed to get the schedule back in line;
• You can frequently get in your head by getting stuck wanting a specific feature that causes many issues. It is often a good call to think about alternative solutions. There are often easy outs that will have almost no effect from the user’s perspective;
• Schedule your game/patch releases to Tuesdays/Wednesdays to allow for quick crisis management if something should go bad;
  • If you want to avoid the releases of other big projects do so on a weekly basis;
• Don’t bite off more than you can chew start with a small thing and make it bigger during development;

6. Feedback and User Testing:

• Don’t take testing at face value. Try to figure out why something is an issue and only go with the straightforward solution if you agree that it is the correct solution or you can’t figure out what the actual problem is (This will likely bite you later but there is not always a clean way);
• Not every note of feedback is valid, try to discard things that will not benefit the project (Evaluation must be on a case-by-case basis);
• Testing is great for finding the issues of your project, clarifying how relevant expected issues are, getting information on how users will behave in specified situations and making an evaluation between a selection of solutions. It is not a good tool to find a specific solution to a problem. The solutions should be based on an approach directed by design that can use testing information to get a better understanding of the issue, not based on feedback that comes from the tests directly;
• Feedback does not always need to be addressed immediately if something is valid but might not be easily fixable at the moment or might just get resolved by other things that will be added later to the project take note of the issue and test for it again later;
• During early testing avoid tutorials and helping UI/UX elements. Try to get things to a functional/understandable state without them and then add these elements as needed after the core concept of the game is established and you can test on a version that resembles the potential final product;
  • You can test these helper elements in isolation to see if they would fix/adjust potential issues the project could have;
• For live service models give access to an “experimental branch” that allows players to play with work-in-progress features; This will help with community engagement, allows determining features the community is interested in and gives good playtest samples;
  • This can even be pushed by giving players of the “experimental branch” rewards in the “main branch”;
• You can use steam achievements to check which things function well or not;

7. Marketing

• Find a name for your project that:
  • Can be easily remembered/spelt;
  • Differentiates itself from other products;
  • Gives a short introduction to the project;
  • Uses words that come up often in search machines;
  • As early in an alphabetical search as possible consider how numbers/symbols are sorted in, on your target store;
  • Hooks in famous products so you might get some of their traffic (This is dangerous since it can result in situations that make it harder to find your product);
• If you are using Steam, take advantage of the curator system;
• Send your product to suitable people that will play it in some form of public capacity;
• Offer marketing materials like trailers/screenshots/banners to whoever needs them; Try to have them available for download on a homepage;
• Build up the release of your project by having multiple resources that can be published; Try to spread out these resources for at least 1-2 months;
• Consider where people would play your project and what they would expect from it; Adjust your target hardware and features accordingly;
  • A relaxing game people want to play before they go to sleep or while watching TV → consider a handheld platform;
  • A gamejam that will be played for less than ~15min → consider a web player so users don’t have to put in additional effort to access it;
  • A large-scale game that requires the player to get properly invested → consider a platform that allows interacting with it comfortably for longer periods of time like PC/Console/Some handhelds;
• Reference older projects in newer ones if possible, this is great for the team’s morale and can tie multiple projects together;
• Find a common object that is featured in multiple projects this will help to create an identity between these different products;