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;
• Make sure to have some active support for setting up version control for all and future team members this is a frequent time eater/issue collector;

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;
  • Inform new team members about the general vision of the game they should be able to understand decisions that match that vision instead of their preferences.
  • 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;
  • Show playtest footage during onboarding (at least for design)
• 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;
• Flag in your communication tools if you are currently on break/holiday ideally with timers so people can check when you will be available again.
• Don’t switch profile pictures for work-related apps frequently. This confuses folks who infrequently interact with you;
• Tag team members on messages that are relevant to them. Otherwise, they will not see it if they have lots of stuff to do or get messaged frequently;

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 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;
• Every development department should have peer reviews. To ensure work is on track and folks are informed about more than their work;
• It’s fine (and good) to chase mechanics or similar that break common conventions but avoid having many at the same time, they are time-consuming to develop and require a lot of testing;
• Ideally, the entire team plays the game frequently, but at least the design departments should have planned play sessions (sometimes including other departments) during which they play the game together and discuss what they like/dislike and how things match/work against/improve the vision.
• Don’t remove QA/Testing time for the sake of more features. Higher levels of polish will outperform quantity;
  • That being said you can poker on adding lots of features quickly during a short period and then try to fix all issues at once, doing so will risk more polish work later but allows you to get faster to a presentable product;
• Plan for a small QA session for each panning segment (~1-2d) with a small group of the team. This will keep the tools healthy and is a good step to prevent follow-up issues;

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;
• Task planning should be led by leadership and not individuals (this takes too much time), but individuals should have the last word on whether the tasks concerning them are realistic;
  • Task planning should not be used to establish what the task is but only the rough boundary and goals of a task;
• Make sure to have a roadmap that includes a rough layout of all the things needed before release to make sure that short-term plans match long-term goals;
• 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. It’s generally a good shout to dedicate ~20% of a project’s time to polish;
• Design should be ahead in the timeline compared to other development teams this allows the rest of the team to work with developed plans. To accomplish that allow other teams to pull cleanup work like bug fixes or visual improvements forward until the design team has established a lead and give design support for prototyping from other departments;
• Give employees as much control over production software as possible while avoiding common mistakes to cause issues for example have a “ready for delete” category so team members can get rid of stuff no longer needed without tasks being lost. If these options don’t exist it will likely result in people not doing the necessary cleanup steps nor informing anyone about them;
• Removing tasks for time reasons is not a justification for adding more different tasks;
• It’s impossible to know the extent of a task after the first time something similar was implemented. Most things go through multiple iterations, that is the real extent of a task;
• Try to keep folks in similar tasks for every panning segment. Switching areas of work frequently results in slower work and more errors;
• Plan for a generic pool of fallback tasks team members can pick freely if they are currently blocked or done with their work. These could be either bug fixes/generic polish/optional features that can be carried by a single department/tasks that would be actioned soon and can be carried by a single department;
• Having some version of an end-of-panning segment review that allows team members to speak out their concerns about the project is good for checking who understands the project and who needs more mentoring;

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;
  • Or create a selection of proper analytics tools;
• Allow a section in your communication tools that allows team members to talk about what they like/dislike about the product;

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;
• Steam demos
  • Steam demos are a great method to reach out to potential customers and allow players to check out your game before they buy it. This can frequently be what makes the difference in the decision if your or another game would be purchased;
  • Start a demo in a space that entices interest and shows that there is more to the game this does not need to use the usual gameplay hooks since someone playing the demo should have some interest already don’t make this section last long to goal is to show the good stuff after all;
    • The Gameplay should start with a welcome to demo screen;
  • Aim for about 30 minutes to 1 hour of game time. But allow the players to replay the demo. Make sure to fill that time with some of the best elements of the game without taking away the ending of the actual game;
  • Allow players to unlock something during the demo so they get rewarded for replaying it;
  • End the demo with an end-of-demo screen and send the player back to the start of the demo after completing it;
  • QR Code and appeal to wishlist/buy the game should be on the title screen; end of demo screen; and pause menu;
    • Use Steam API to allow for wishlist links on these screens in the Steam overlay;
    • Include a cute picture of something in the game on your wishlist screens;
  • Pushing a demo allows an e-mail notification for everyone that has already wishlisted;
    • Same for the company and publisher follower;
  • Push your demo as early as possible and leave it up constantly;
    • Even after the game released;

8. Employment

• Companies frequently tend to check their liquidity annually if something looks bad in one year changes are actioned and work resumes. But there is a good chance that these issues will come back suddenly with the next liquidity check. So build project planning and personal expectations around that;
• Assume that decisions and information depending on the business side of the project will come later than necessary. Don’t wait for it, make a reasonable prediction on what will happen and work towards that;
  • It’s generally a good approach to take the reasonably worst case if it is better you will likely not lose much from having more resources;
• Most projects feel rough until the work of all departments comes together which usually does not happen until the second half of a project development;