Kicking-off a videogame project can be very exciting. The industry is growing and a lot of space is open for entrepreneurs and startups. Whenever you feel and think you’re ready to start developing your own videogame, it is important that you know beforehand the five most common issues that you will face. Usually these present themselves in the development process because of a lack of experience, but they actually also happen with experienced teams. Here, I will explain to you these five challenges, and offer some insights to overcome them.
1- Lack of budget
The first and biggest challenge for videogame projects is when they run out of money, and finishing the project becomes infeasible. Why would a videogame that begins its development with a reasonable budget run out of resources before it’s finished? The clue lies in understanding a budget as the scope of a project’s future expectations.
Like with any other creative endeavor, videogames can always include more and better content. Books can have more and better chosen words, movies can have more and better shot scenes, and there comes a point in which the creative mind behind the project must decide how much is enough and when to stop. This temptation for perfection tends to infinity, so we have to ask ourselves what it means for a videogame to be finished. This limitation is crucial for keeping any project within budget.
Accomplishing this might look like a steep climb at first, when all ideas are still on the table and everyone is excited about the videogame’s outlook and possibilities. But the quality and quantity of assets the videogame will have must be calibrated according to the budget’s size from the start. Keeping a realistic, down-to-earth projection of the videogame’s possibilities will avoid this problem down the road.
Money running out also is symptomatic of poor planning, because realistic limits were not set from the start, and/or because task times became longer than expected. Unforeseen issues arise all the time, and planning must give space to these. Developing videogames is not an exact science. Maybe an idea looks very promising on paper, but during its implementation it starts running into problems, or it’s working in an unexpected way, and developers or artists are forced to change it. This pushes videogame producers to reassign resources they had not contemplated. Another example is when a cutting-edge technology is being tested for the videogame, but there’s so little experience with it in the industry - or in the team - that it takes time to learn how to use it properly, and it might trigger many bugs that take even more time to be corrected.
No matter how good a plan and budget is drafted, it must always include space for the unexpected because videogames are inherently a creative endeavor. However, when development teams run into any of these scenarios, there are a few solutions at hand:
- Increasing the budget, of course. Although it’s not always possible.
- Try to avoid the risky features, which requires a clear understanding of the team abilities.
- Avoid overconfidence and always think about Murphy’s law (“Anything that can go wrong will go wrong.”), make a list of what can go wrong before it happens and strategize with it in mind.
- For needed risky features, triple the time planned for those and define alternatives that could be implemented before the budget assigned to the risky features dries out.
- When calculating the budget, do it in an analytical way, but also confirm it with past experience references (comparing it with a very similar videogame’s development budgets).
In any case, avoiding this pitfall is a real challenge, and it’s better to plan ahead of time than to find solutions once a budget crisis is at hand.
2-Too much vs. too fast architecture
The very beginning of a videogame project is extremely important, especially at the programming level. When building the architecture for a videogame, there are two opposed trends that should be avoided:
- Fast but deficient architecture. The kickoff of a new videogame development is usually a project full of excitement and thrill. Thrusted by this passion, developers could try to program with too much speed in order to get results quickly. This can lead to a disordered code that, as the project progresses and expands, impedes further development, which can lead the team to later be overwhelmed by hundreds of issues anytime they change something. This is a very common problem that generates from weak software architectures.
- Overthinking the architecture. The opposite is also true, especially when developers, having learned from a previous experience, try to build an excessively solid, organized and robust architecture, like trying to define many functions beforehand. The problem with this strategy is that videogame projects tend to change a lot, as game designers, artists, producers and stakeholders want to take advantage of opportunities and new ideas that arise during development. Too much resources are invested in rigid architectures that later have to be reprogrammed anyway, in order to adapt to changes, because nobody can build an engine that “makes it all”.
A similar temptation occurs with art, where a team can invest a lot of time and resources in creating well designed characters and environments, just to realize later that the team or the director now wants a different style. This can happen both in terms of quality and quantity.
The solution to these dilemmas is to be reasonable with the quantity and quality of the architecture and the art produced at the onset of a videogame project. Concepts and designs must be validated as soon as possible, before investing more resources in expanding a videogame’s early vision. Only then can the decision to move forward with the project’s vision be better informed, and preempt issues down the road.
3-Bad planning: poor allocation of priorities
The math behind creative projects is never perfect. Non-creative processes generally are easier to plan because costs, time frames and energy inputs can be calculated for each step of the process, giving them a certain amount of mathematical certainty. All those steps are pretty known and fixed before production starts and the project specifications generally change very little during production.
But it doesn’t work that way with creative endeavors, like videogame projects, in which specifications evolve as the production advances. Visuals generally require several iterations until they’re approved. Same goes with game design: fun can’t be fully evaluated until it’s tested. Because of this, developers can’t fully gauge costs, energy and time beforehand, and their estimations are mere approximations.
The interaction between areas poses challenges too; some areas need other areas to finish their work to begin theirs, especially when collaboration is a central aspect of a project, like with most videogames. If one aspect of the videogame requires additional un-expected iterations, you end up with situations in which programmers are waiting for the artists, or artists waiting for other artists, creating gaps, periods of inefficiency which cost time and money. Addressing this particular issue requires a lot of experience, and attention to detail in the allocation of daily tasks. It becomes crucial to estimate who will be waiting for who’s work in order to avoid these gaps.
Another common problem is the failure to continuously redefine priorities within the “evolving” critical path, the one that takes into account the uncertain nature of videogame planning.
There are so many evolving steps in a videogame’s development that it becomes crucial to continuously reevaluate the critical path and redefine the proper order of priorities, and establish what must come first and what comes later. This helps avoid and mitigate dead times among the different teams.
Whereas it’s pretty simple to know when to recruit the testers and concept artists (at the beginning, and at the end, respectively), a well-planned critical path will tell you when is a good time to hire certain personnel and when to reassign priorities.
4-The human factor: balancing talents
It has become fashionable in the videogame industry to talk about crunch time, which is the almost inevitable consequence of planning issues. It has a detrimental effect on the team; it produces burnout, mistakes and demotivates.
But it is important to note that crunch time is also generated by teams with unbalanced talents. Not all tasks in videogame development require the same skill level. In all areas, there are complex tasks and easy mundane tasks. In programming, there are challenges that only the most experienced and talented programmers can solve, but there are also plenty of easy tasks other programmers can address. In art, some elements are more important than others: for example, a videogame’s main character far outweighs the importance of background NPCs. It works similarly to the film industry in which the best actors get the main roles, while less talented actors get minor roles. A team of only very talented and experienced workers will surely have some of them to perform easy and unchallenging tasks, the fastest way to demotivate them, leading to planning issues and thus to crunch time.
A better team setup is when talent and experience is balanced across teams. A videogame needs both experienced people as well as newbies that can learn from their senior colleagues. Keeping newbies and less talented workers with a too light workload is demoralizing. On the other hand, very talented people can have a heavier workload, because directors trust them to better finish tasks. But beware of overloading them with too much work, because it can also lead to demotivation that hampers performance.
Some managerial strategies invite all team members to have a say in the different processes as a way to make them own the project’s goals and priorities. Even if this can help raise morale, sometimes too many opinions and visions can lead a project astray. But the opposite is also to be avoided, because not taking people’s opinions and ideas into account will surely frustrate them too, and have a demotivating effect. Balance is key.
Finally, there will always be unpredictable occurrences: people who get sick, who quit, who take vacations, who have babies, those that fall behind schedule, and a wide variety of issues difficult to predict, and that cannot easily be integrated into a plan. The solution is to always have plan Bs and Cs as backup whenever unpredictable events occur.
5-Targeting the right hype
It’s quite understandable to let a hype drive your projects. When a product or service has an overwhelming success in any industry, there’s a powerful temptation to imitate it. The videogame sector has plenty of examples of this, to the point where we can call it a systematic practice, a “gold rush” tendency. Candy Crush’s success led an army of mobile videogame developers to imitate it in diverse forms and presentations. Fortnite triggered a rush for battle royale videogames. But these gold rushes quickly saturate the market, and developers that aren’t fast or creative enough lose their investments and efforts to a consumer market dispersed among multiple, similar titles.
A gold rush occurs when people see success somewhere, and run in that direction. But here’s the tricky part: sometimes people foresee there could be success in one specific area and start developing the idea assuming they’re the only ones working on it, when in fact they’re not. The original idea was feeded by our social collective knowledge. The more we feed from the industry’s collective knowledge, the more likely we are to have similar apparently original ideas, rather than truly original ideas. This has happened to me several times in my twenty years in the videogame industry, and it’s more common than what we think. Don’t forget that the market may be saturated by the time your idea takes form.
Hypes are frequent in the hardware sector too. When the Nintendo Switch came out, it was so successful that plenty of developers started producing videogames for that platform. A similar story happened with the iPhone’s success in the mobile videogame sector. But developers looking for pioneering projects will only reach their goal by producing videogames for future platforms and technologies. Remember that videogames take years of development before they’re launched, so by the time they do come out, the hardware hype may already be past. Studying the market of what’s being researched at the moment, and evaluating the future prospects of novel technologies, are irreplaceable tools for developing ideas of videogames that could greatly benefit from future hardware hypes.
Conclusion
Most of the issues described above require a certain level of experience to spot on time and prevent. But good planning can tackle most problems ahead of time, especially when alternative actions to roadblocks are envisioned in the early stages of videogame development, especially when part of the project is outsourced.
It is important to acknowledge that budgets are not infinite, and they do run out if precautions are not taken. Most indie developers know from the start they lack enough budget to finish a project, so they need to draft a set of fundraising strategies as the videogame development is kicking off. A flexible but well programmed architecture is one of the top priorities in order to avoid problems that could jeopardize any project. Other priorities must be well defined and placed in a critical path where personnel are hired according to the different phases of development. These personnel must not all be brilliant and experienced, but instead a balancing approach between their skills and talents must take place when implementing the critical path.
Finally, beware of current hypes that might not necessarily benefit a project. Evaluate and decide carefully and critically if it’s convenient for your project to get on board a trend, or if it’s better to bet on future developments. With these five considerations in mind, you’re off on the right foot to begin your own videogame project.
