Three Years of Development: What have I learned?
Today I want to talk about my game and the path I was walking for 3 consecutive years, about the mistakes I made, lessons learned.
About my game
Heptyl is a classic indie first-person shooter, set in a closed Soviet city, struck by a viral outbreak. During the Cold War, the USSR converted a major industrial city into a secret facility to develop bacteriological weapons, mobilizing top scientists. Following the Soviet collapse, project logistics deteriorated. Negligence during an experiment caused a pressure imbalance, rupturing a filter and releasing bacteria. Troops sent to contain the incident quickly lost control, overcome by an unknown virus.
The government sends a specially trained agent into the quarantine zone to find the cause and eliminate the disaster. The player must explore dangerous locations, fight non-standard enemies, overcome obstacles, descend to the bottom levels of the laboratory and uncover the truth.
Choosing the Right Tool
Before you even begin working, it is also worth considering which tools will be best suited to your needs. What engine should you use? What renderer? What material pipeline? What visual style fits your game? Unfortunately, you cannot always determine what you require without first experimenting with several different options. But the choice of tool should always be technically and logically justified. I can never understand why some small projects such as Visual novels or simple 2D platformers use heavy commercial engines.
Initially, I chose the Quake engine with the BSP level format, running on DarkPlaces. Although it is technically possible to fit large levels into the engine and make them playable, the BSP format imposes real constraints on open-world design. BSP visibility compilation assumes mostly enclosed architectural spaces and each realtime light with shadow casting in such spaces compounds the performance cost. Compile times for large maps grow significantly, slowing the iteration cycle. Could I have predicted these problems? Of course. The engine is purpose-built for corridor shooters and arena combat, not open-world exploration. Understanding your engine's architectural assumptions before committing to a level design philosophy is one of the most important decisions you can make.
Level Design
Many beginners start building levels without fully grasping the process or visualizing what they are creating. It happens like this: you feel a surge of inspiration, sit down, and start placing geometry without thinking about how the level will integrate into the game or how its sections will connect. While it is technically possible to build a level first and then invent a purpose for it, this is rarely a good approach.
Instead, begin with a complete plan. Think it through thoroughly, step away to let your ideas settle, think it over once more, then start building. A solid level plan should address:
- Objective. What is the player's primary goal in this level? What is the hook that pulls them forward?
- Obstacles. What stands in the way: a special enemy, a puzzle, a unique mechanic?
- Style. The environment should follow a consistent, defined visual style.
- Difficulty curve. Difficulty should escalate with the player's progression through the level, not spike randomly.
- Mechanical variety. Alternate between combat, puzzle-solving, platforming, stealth, and exploration to maintain engagement.
- Non-linearity. Multiple paths and optional approaches give players agency and increase replay value.
- Uniqueness. Each level should offer something that distinguishes it from the previous one: a new enemy type, a new mechanic, a new environment.
Was I following any of this? My levels had ideas, but I was guided by my own whims rather than by a systematic approach. The result was levels that felt improvised rather than designed.
Gray-out first, decorations later.
The city location was looking very simplistic and flat, lacking normal beautiful vegetation, details. In order to conceal that, my friend came up with an idea to cover it with snow. Although a snow-covered Soviet city looks highly atmospheric, the decision was made to abandon this concept. Many assets (such as the birds) would have appeared aesthetically unappealing, and implementing new mechanics would have necessitated removing existing ones, as well as overhauling the level design among the whole game. That gives us another rule. Know your story's time of a year, time of day to make the story logically finished (for example you can not use a boat in a frozen lake. Stay in gray-out layout unless you are 100% sure with the final map layout.
Fill your spaces
Although huge empty spaces can evoke a liminal-space aesthetic and give off nostalgic Source-engine vibes, empty rooms are generally a sign of incomplete design, not deliberate atmosphere. A small, densely filled level is almost always better than a sprawling open space with nothing in it. Emptiness should be an intentional choice.
Assets
Sometimes, I was unable to create what I want simply because of lack of texture, props, sounds, etc. It is very important to have a significant source of assets before starting making. Textures.com is a good resource, but very limited and low quality (free). You should start making your own asset bank using phototextures and your own objects. Free assets and over-popular assets destroy the representation of the game. It automatically looks like crap. Your own low poly unique model is always better than AAA high-poly free model that you can find on the internet.
Proper project organization
Proper project organization is one of the most basic and most important skills to develop, especially when working with a team. Materials belong in a materials folder, textures in textures, sounds in sounds. Each file should have a proper name and a format, not just 443631_puke-freesound.ogg. Do not be lazy, always convert files to your target format and rename them immediately upon import. The cost of renaming a file is seconds; the cost of finding the right files in a disorganized project three months later is hours. This is the most basic and important skill you should learn, especially when operating as a team. I still can not understand how some projects make it to the release without this fundamental rule. Always track the asset license and try to give it a proper credit.
Stay away from big goals
Initially conceived as an arcade shooter on an old-school engine, the project has evolved. I sought to create a shooter in a Soviet-era setting with an open world and a post-apocalyptic atmosphere, where the player could influence the environment and freely explore the world. Inspiration came from such cult games as S.T.A.L.K.E.R. and Half-Life 2.
However, it soon became obvious that for a single developer, creating a completely open world, and not just placing ready-made assets from sketchfab, is an extremely labor-intensive task. In addition, the gameplay became less dynamic, losing the drive of old-school action, and technical capabilities did not allow for the implementation of full realism.
Systematic approach and schedule
System > Emotions. Always maintain your project like you are working in a huge company. Set schedules, document your thoughts and changes. Do what was scheduled and what is more realistic to accomplish instead of doing what you like or feel doing at this moment. Instead, just log your idea and keep working on what matters, until it is done. This will save you a lot of time in the future.
Playtesting
What is obvious to you, not always obvious to a player. As a developer you already see what you are trying to do and what is the proper solution. However, not everybody is built the same. Sometimes people may overnuke it and come up with completely different solutions than you expected. That is why live playtests are important.
Game Difficulty
Most of the people are not as experienced in gaming as you. As a developer you are aware of every mechanic in the game, you can not be surprised, you always know where you should go. Therefore the game should not be challenging to you. If it is, it will be a nightmare to an unprepared average gamer.
Learning vs. Doing
Sadly, learning is less exciting than building. There is always a temptation to skip the research and jump straight into implementation. And this does work, in a sense. You will get past the immediate obstacle and produce some kind of result. But the solution you arrive at through trial and error is almost never the best solution available, and the time you spend fighting a problem that someone else has already solved and documented is time you will never get back. Actually spending time researching and learning may give you a better solution that will save you a lot of time in the future and improve the quality.
Lack of social skills
Just like any other field, game development requires communication. No one can learn about your project, provide feedback, or help you playtest if you do not share your work and properly communicate with people, posting development progress, maintain a social media presence, participate in game jams, engage with communities,etc. This is still the hardest part for me.
Most developers tend to think along these lines: first we’ll build the game, and then we’ll handle the promotion. The result is a finished game, but no audience. No one knew about it, and no one was waiting for it. This is one of the most common reasons for failed releases. Start building your community on day one. Share your work in progress, even when it is rough. The connections you make during development are as valuable as the game itself.
The future
The future is hazy. It is safe to say that AI has transformed game development. A vast number of tools are emerging that allow for the generation of every type of content. From sounds and images to entire game engines. Fighting against this is futile, though exactly what to do remains unclear. Nevertheless, I will continue working on my project and striving to preserve its authenticity.
Tags: level design,mapping,gamedev
Comments