In this post I will present a few hints that helped me finalize my game projects. My observations apply primarily to small, indie projects, the projects that we do in our spare time, without any significant budget.
Finalizing projects is not easy. Video games are an especially good example, as the number of variables and factors that are simply not possible to predict in the early stage of game development is exceptionally high and can easily overwhelm and discourage. Nowadays, as the game making technologies are getting more and more accessible and easy to use, many people try to create their own games. But only some of them actually finishes those games.
In this post I will present a few hints that helped me finalize my own game projects. My observations listed below apply primarily to small, indie projects, the projects that we do in our spare time, without any significant budget. Still, some stuff I mention is general and might apply elsewhere. The below points might come in handy no matter if you are a complete beginner or if you already work in the game industry - they are for all people who never attempted to create a game on their own.
I - Keep it simple
First of all, finishing a project is strongly determined by how we start it. When you want to create a game on your own, or with a small team, without any budget, organized management etc., the very first thing you need to accept is that you will not be able to create all types of games. Due to higher level of complication, the particular projects that we might find simply too difficult are:
Multiplayer games - those games are a huge development challenge, as they not only consist of what a single player game consists (gameplay, story, visuals etc.), but they also add a completely new layer: implementing various web and hosting technologies, which is complex and needs maintenance. Those games also require a particularly extensive QA process, which indie teams usually cannot afford.
Strategy games - they are a particular challenge because of one aspect: AI algorithms. Those games need to have complex and sophisticated behavior trees for player’s enemies (or computer-managed allies). In huge projects this aspect is sometimes handled by a separate, specialized team, for a good reason.
Story-rich games - in this case someone will have to write all dialogues and other narrative content, so, unless you have a dedicated writer on your team, consider rather simple narrative (this one is from my very own experience: in my latest project, Astrohazard Solutions Ltd., the decision to add extended dialogue content led to a huge delay of planned release).
3D games - this one is controversial, as it always depends on yours or your artist’s skills and preferences. If you have 3D skills, then it’s obvious you’ll choose to develop a 3D game. But if you can make a choice, be aware that with this one additional dimension comes much additional work, in terms of e. g. lighting, optimization and potential bugs.
Long gameplay - your project does not have to have a long gameplay, 3-5 hours might be absolutely enough.
II - Work in team
While in some aspects it’s easier to finalize your project when you are “one-man-army” and possess all necessary skills (art, programming, sound etc.), as you are not limited by other people’s time and capabilities, it is also rarely a case that you have all those skills developed on a sufficient level. Therefore, it is advisable to work with other people. The main advantages of working in a team are:
(already mentioned) additional skills and knowledge
boosted creativity and more diversified design ideas (warning: this might also lead to problems and stalls, when team members cannot come to agreement on something)
with more people comes more capacity, so more game content can be done
motivation - it really encourages you to push your work forward when you see that other teammate just added something new to the project
However, in most situations all points above are valid only if your team is relatively small (I’d advise 2-5 people) and... managed. And here comes the next part.
III - Organize it
Game development is a complex process and at some point you’ll have to break your project into smaller parts (core mechanics, story, user interface, audio etc.) and plan what exactly needs to be done. Though many small indie teams tend to minimize this aspect I personally found planning and documenting very helpful in my projects. I usually do the following things:
Game Design Document - having some general documentation on game concept and rules helps to maintain a clear vision throughout the project, a vision that is easily accessible for every person involved (which is very important, as you need to make sure that each team member wants to create more or less the same game)
Timeline - though you will probably experience many delays and miss your milestones, it is still advisable to have a rough timetable with basic stages: concept, prototype, alpha, beta, release - it keeps people more goal-oriented and noticeably increases the probability of project finalization.
IV - Create a prototype ASAP
As much as discussing and elaborating on your game’s concept might be fun, in my opinion there is nothing more motivating and rewarding in the game development process than making things actually work. Prolonged concept stage can make team tired and skeptical. You need to create a prototype fast to keep the project going. Things I find particularly important in this area are:
The purpose of the game prototype is not to make something that looks nice. The purpose is to make a very simple playable build that would enable us to test and verify our core design ideas.
Even if you plan to create your own engine for your game I’d strongly suggest using an existing engine (Game Maker, Unity, Unreal, Construct) to create the prototype. The whole point of creating the prototype is doing it fast, so you can instantly test your ideas. Don’t risk creating your own engine only to find out months later that the game is not as good as expected.
Last but not least, let your friends play the prototype and get some valuable feedback.
V - Stick to the plan
Be consistent and persistent. Obviously, if your idea turns out not funny to play in a prototype stage, you have to change it. But if you are already deep in the project, you should stick to it, as much as it’s possible. Iterate your design, but don’t change it completely.
Apart from the core idea, many new smaller ideas on how to improve your game will emerge during the project, but be aware that in most cases you won’t be able to implement even half of them. At some point you will just have to “freeze” the project. No more additional features, no more changes, just polishing. That is where the planning stage, especially the project timeline that I mentioned, proves helpful.
Games, apart from being lines of code and interactive stories, can also be perceived as form of art. When creating an art piece, you can never really determine for sure that it’s finished. There are no guidelines, or checklists, other than you arbitrarily create yourself. There comes a moment when you just have to be brave and say to yourself: “It’s done”.
Thank you for reading.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
