10 rules we wish we had known while developing this maritime strategy.
Article previously published in our blog on DTF.
Oil Rush, our first game on our own engine, is 10 years old this year. The main activity of our company is not exactly games, but the development of Oil Rush helped not only to demonstrate UNIGINE technology in all its glory, but also to make it even better.
Three years, while the game was being created, is both painful and exciting time. In this article, we have selected 10 things to consider when developing Oil Rush. Many of them will be useful to you if you are working on your first game development project.
1. The development of the first game will be delayed
When more than a couple of people work on a project and the ambitions are rather big, this is inevitable. Just a year after the start, it seems that we are already close to completion. Then the concept changes, and half the game has to be redone. Then it turns out that not everything works as it should or does not fit together – the first has to be repaired, and the second has to be finalized.
Even later, it turns out that most modern PCs will not “pull” the game – we come up with an optimization method on the go and work it out for many months so that performance increases, and simplifications in mechanics and graphics are not noticeable to the player. Those subsystems that seemed elementary will require a lot of effort (hello, localization!). So three years pass instead of one or two.
And this is without taking into account the work that was done, but was not useful. Or one that tried, but did not master. Among the first is a playable port on the PlayStation 3, which never saw the light of day. And among the second is Japanese localization.
2. Early Community Support Is Important
We started collecting pre-orders and giving away early versions of the game around the middle of development. In addition to some real money that helped finance the development (recall that the game was made with our own funds), this gave us powerful psychological support.
When your project is expected and people believe in your team, this is a huge plus for your mood.
3. Everything will change, and that’s okay
Oil Rush was originally planned to be a tower defense game set in the skies, where fortifications were built on floating islands and flying enemies attacked from all sides. As a result, we released a game in the indirect control strategy genre. At the same time, the floating islands were lowered from heaven into the water, and the style changed to a mixture of “Water World” and dieselpunk. This is how the dystopian world of the future, engulfed by the oil fever, appeared.
Some concepts look good on paper, but until you play the prototype yourself, you will not understand if there is a fan in it. The more creative iterations, the better the project will be.
4. Experiments with the genre should be clearly communicated to the players
It’s not very clear from the video that this is not a classic RTS
People who wanted a classic RTS in Oil Rush got a completely different game – no direct unit control, with automatic production and a focus on very dynamic tactics. No matter how hard we tried to explain it in the descriptions of the game, we still received a portion of negative reviews about “this is a bad RTS”.
Perhaps, it was necessary to pay even more attention to the explanation of the genre.
5. The game is made for the players
It’s trite, but it’s easy to forget about it during development. It’s very sobering to have focus tests where developers are forced to silently watch people play your game for the first time. Compare this to torture: focus group participants do everything wrong! You can already pass any level with your eyes closed, but they simply ignore some of the features, or use them completely wrong!
It’s especially important to remember that you’re making the game for the players, not for yourself, when setting the difficulty levels. We argued about this for a very long time within the team, but Oil Rush came out with some levels that were too difficult for average gamers – and they just quit playing in these places.
6. Developing a game in your own engine is both a bad idea and a good idea
Graphic features of the engine for 2012
The bad one is because the engine still needs to be written, or refined in parallel with the development of the game. And the effort is usually not worth it when you can license someone else’s (often also for free). In our case, the engine already existed, but we had no experience in creating a game. And we would have to get documentation with development tips from the future from ourselves (even this text would be useful).
But still, it’s a good idea. After the development of the game is completed, you will have a polished engine, as well as a team trained on it.
7. Even if you pay a lot of attention to quality control, you can miss a critical bug
We tried very hard to make the game technically stable throughout development. Before the release, we tested the latest changes for 25 hours in a row. And now, Oil Rush is published on Steam, we have a launch party – and then it turns out that the game has a critical bug that does not allow you to pass the first levels.
Almost the entire team is already quite tipsy, the developer who knows this piece of code is on vacation and without access to the Internet – who will fix it? Fortunately, the bug was quickly fixed: the producer sent suspicious code fragments to the developer by phone via SMS, and he dictated where to fix it. The build was rebuilt and published within a couple of hours. Fortunately, almost none of the players noticed the problem.
Conclusion: after the release, you need to sit at the ready – something will definitely come out, no matter how you check.
8. For a studio’s first game, even just paying off is a big success.
Oil Rush has not become a cult strategy game or an all-time hit. But she found her audience, paid off the development and brought some money from above. And for the first project, even this is a great success.
Just open the Wikipedia page of any major studio and see how many games they released before the one that hit the whole world.
9. No need to stop after graduation
The entire development team was so tired from the last tense months that they no longer had the strength to look at Oil Rush.
Yes, we released several updates in which we fixed the missed bugs, but that’s it. Of course, the game would not have become radically different – but if we had worked on polishing the difficulty level in the campaign for a couple more months, then it would have been much more interesting to play it. If we added multiplayer to the mobile version, this would also significantly increase its audience.
10. It is extremely important to bring to release
The experience we gained by releasing the game on 5 platforms and multiple venues is extremely valuable. Just developing a game and releasing it is a different matter: only after the release you find out what the “second 90% of the work” is, when you already seem to have done the first 90%. This is especially useful for small indie developers who often have a whole bunch of unfinished projects. Partially similar experience can be gained at game jams – we recommend it to everyone.
Now the UNIGINE team is working on a new unannounced game, and all the experience of Oil Rush helps us avoid a lot of mistakes in the process.
* * *
Also on January 25, an anniversary stream and a game with developers took place. It was nice to see multiplayer come to life again and players create rooms where they fight against each other for possession of the oil. The broadcast was hosted by UNIGINE Executive Director Den Shergin.