Working on your own game is the dream of countless
aspiring indie developers - and doing it independent of others is the ultimate achievement. We've recently released a popular series of
videos on the best solo developed games but we should note that for every successful solo
development cycle, there have been countless others that have crashed and burned. In this video we will review the main errors
that solo devs make. We are Ask Gamedev and these are the 8 biggest
solo developer mistakes. Welcome back! We make videos on how to elevate your games
and inspire others. If you want to continue the game development
conversation after this video, check the video description for a link to our Discord channel. Maybe this scenario sounds familiar - You
have a great game idea that you have been thinking about for some time, and you move
forward with development on your own. After all - it’s best to start making progress
as opposed to overanalyzing your concept and not making forward momentum. While your ambition is to be commended, this
path isn’t without risk. Specifically, you risk wasting time and effort
by working independently and not validating your ideas with others. It's extremely hard to be objective about
your own ideas, especially when you are working closely on them every day. Mechanics may seem enjoyable and intuitive
to you as the main game designer, but might appear to others as complicated, inaccessible,
or just plain not fun. A main tenet of good game design is to constantly
solicit feedback from others to validate your assumptions - and far too often solo developers
miss this principle and spend time building something that simple doesn't resonate. One of the main goals of a successful development
cycle is to always have a build ready to demo to others. A build that is always stable and playable
can be extremely beneficial - especially when it comes to those unexpected and time-sensitive
opportunities around partnerships and marketing. With indie development, you may only get one
chance at a possible publishing or marketing deal… and it can be heartbreaking to have
that opportunity slip through your fingers as a result of a build that isn't playable. How can this happen you ask? Often times solo developers don’t have to
regularly create builds for external purposes during pre-alpha development. Cleanly tested integrations of new code can
often be an afterthought to just finishing a feature or mode. The risk is of this approach is that if at
some point a working demo is needed, the developer may learn upon inspection that their build
is buggy, crashing, - or heaven forbid - not even building. Avoid these scenarios by striving for continuous
quality through clean code check-ins that are thoroughly tested in advance. If you haven’t been following the Continuous
Quality movement that is gaining huge momentum in our industry, we highly suggest you look
into it. Many major developers are now integrating
devops functions within their teams with automated testing and regular builds becoming a central
part of their development strategy. This next point builds off the last principle
of always having stable builds - and that is the importance of professional source control. As we mentioned earlier, a lot of indie developers
just start working on their game without spending a lot of time thinking about any long term
development strategy. Why delay momentum when you have the urge
to dive into an engine and get creating? Unfortunately, one area commonly ignored is
the consideration of a scalable file structure and source control solution. After all, the solo dev often doesn’t know
if the game will even be completed, let alone need other collaborators to participate in
development. So why slow down progress thinking about those
future consideration?. But as development moves onward, more and
more code and files are created by the solo developer with little regard for clean architecture
and scalable file management. This can often result in a mess of file references
that can cause lots of headaches as development advances - especially if others are eventually
brought on to help and need access and onboarding to the code. This situation can be especially risky when
local to one computer source control is used. All it takes is some failed hardware and a
poor developer could lose all of their hard work through corrupted or damaged files. That's why giving some forethought to proper
file architecture and using a professional source control solution to safely save all
development files is an essential part of setting up a build that can scale. Popular source code solutions include Git
and Perforce - we highly recommend spending some time familiarizing yourself with your
file management options if you are serious about spending significant time on your title. Supporting professional coding standards can
be work - and it's not always the quickest way to develop. Some indie devs prefer to hack their ideas
into code quickly, believing that gaining momentum with their development is more valuable
than building ship-quality code that would meet the standards of professional developers. Just get it working and don’t worry about
that best practice of having a peer review your code. While there is merit to this approach, what
is clear is that poorly constructed code can cause lots of problems if you ever need to
bring on an extra set of hands to help out… and that is common given how hard it is to
ship a game on your own. Code should be efficient, extensible, properly
formatted, and ideally be accompanied by architecture diagrams and useful code comments. Trying to layer on code quality late in development
can be very time consuming and can significantly slow down progress.. so consider reviewing
your code quality early and often. Game development is hard - and it’s very
uncommon for a solo developer to have expertise in all of the disciplines necessary to make
a great game. Even with the benefit of today's full featured
game engines that offer much of the commonly used game features - you can bet that a lot
of effort is going to be put into getting a quality game to release quality. Some aspiring devs take the difficulty of
game development one step further, and try to create their own custom engine in parallel
with creating their solo developed title. The thinking is usually that a custom engine
can be optimized to support the specific game type being developed. If the game is a success, the investment in
engine tech will make future content releases all the more efficient to develop. While there can be merit to this approach,
it adds a layer of complexity to development that the overwhelming majority of developers
simply aren't ready for. Creating your own engine requires tremendous
development forethought, and can often result in more time trying to scale the engine architecture
- as opposed to developing the ‘fun’ in the game. The common result is that the game never gets
completed because the tech work became just too overwhelming. Continuing development by migrating to a off-the-shelf
engine is often problematic as well, as the game elements are often not in a compartmentalized
structure that allows for easing porting to a different tech framework. Today there are engines specializing in virtually
all types of game types. If you are planning to take on engine development,
make sure to do your homework and ensure that their isn't a better off the shelf option
that can save you time and agony. Check out these recent video we did on the
best game engines. The majority of solo developers come from
an engineering background. Many of these people have worked in the gaming
industry in the past, and have learned about modern game engines and game architecture
to the extent that they are confident in their ability to embark on their own development
journey. As a result, many of the engineering focused
solo devs have an obvious skill set gap - the ability to make the beautiful or interesting
art content that is necessary to attract users to their game. These assets can be models and textures, animations,
particle effects, or 2D art. Making great art content isn't easy - it's
one thing to know how to use art software, and it is quite another to be able to create
a great visual style that can translate to a unique look. There are countless solo developed games with
bad art that look and feel amateurish - and they don't achieve the commercial success
their developers envisioned. Check out these legendary, indie games: Braid,
and Towerfall. Braid was created with “programmer art”
during development, and a lot of time was spent after creating Braid’s iconic art
style. When Towerfall was first created as a game
jam game, it already had an art style that many would feel comfortable with. When developing Towerfall for a retail release
though, Matt Makes Games gave the game more than a fresh coat of paint - he had all the
art re-done. For more info on how to find great art content
for your game - check out this recent video we made on how to get art for your game. We should also note - there are increasingly
more no-code engines out there for those aspiring developers that don't have programming experience. Solo Gamedev isn’t limited to those who
can code. Check out our recent video on the best of
the no-code game engines. Ensuring your game is stable and as bug free
as possible is a critical phase in development. It requires planning and foresight, as you
will want to address the bug fixing of each feature in a thoughtful manner.. Professional quality assurance teams build
test plans that work in lockstep with development. They focus on the most influential areas of
the game first, providing usability feedback in addition to major crash and bug information. Once the tuning of a feature is complete - the
test process focuses on identifying all of the edge case issues, with the development
team closing all must-fix issues before being ‘locked out’ of that area of the code
so that they don't introduce instability of knock-on effects on other game areas. Unfortunately, many solo developers don’t
follow such a structured test and bug fix process. They can often jump around the code, fixing
items in an unstructured manner - resulting in knock-on bugs and confusing deep-rooted
issues that are hard to fix. The ‘finaling’ period of a game can drag
on and on as a result, and the solo developer can often lose faith in their ability to ever
ship a clean title. So take some time when you are feature complete
and plan out a strategy for your testing and bug fixing. Look into what the professionals do - and
customize your plan to fit your timeline and game type. Before we show you the last of the biggest
solo developer mistakes, let’s review this week’s Ask Gamedev community member Game
of the Week. It’s BQM - Block Quest Maker, from developer
Wonderland Kazakiri (Which in Japanese means “Wonderland Paradise”). Made with Unity, BQM is a game builder that
takes inspiration from games like The Legend of Zelda, Super Mario Maker, and Minecraft. The game started out as a solo-developed prototype,
then went on to be turned into a full-fledged game by a team of two full-time developers,
over the course of two years. BQM can be found on Steam, iOS, Android, and
Nintendo Switch. The final solo developer mistake on our list
is the one mistake that we see most often - and that is not finishing. As countless of aspiring developers have discovered
- starting a game is relatively easy, while finishing and shipping it is tremendously
hard. The scope of work necessary to complete a
game can be significant and for many solo devs, that mountain of work doesn’t become
obvious until mid-way through development. Solo devs often don’t have a financial budget
to bring on development support, nor did they get other creators invested in their game
idea. This means it can be hard to get the necessary
support to complete a game - and many games never see release as a result. Its sad reality of our industry that many
more games are started than completed. Thanks for watching! For more Ask Gamedev, check out this video
on the best solo developed games here, or this video on the most wanted team roles in
game development!
