10 rules we wish we knew while developing this naval strategy game.
It’s been 10 years since the release of Oil Rush, UNIGINE’s first game powered by our proprietary engine. Video games are not our main domain, but the development of the Oil Rush game helped not only to demonstrate UNIGINE technology in all its glory but to make it even better.
From the initial concept to the first working prototype, Oil Rush was a journey full of difficult decisions and amazing discoveries. Those three years, while the game was being created, were both painful and exciting. For this article, we picked out 10 things we wish we knew back then and would like to pass on to anyone who is working on their first game development project.
1.Development of the first game will take longer than expected
When more than a couple of people work on a project and the ambitions are rather big, it is inevitable. Just a year after the start, it seems like we are already close to completion. Then the concept changes and half the game has to be remade. Then it turns out that not everything works as it should or does not fit together: and all of it should be fixed.
Later, it turns out that most modern PCs could not handle the game. Then 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 obvious will require a lot of effort (hello, localization!). And that’s how three years go by instead of one or two.
And this is without taking into account all the work that had been done but didn’t come useful. Or what was tried out, but could not be overcome. The first was a playable port on the PlayStation 3, that was never released. And the second was Japanese localization.
2. Early community support is very important
We started collecting pre-orders and giving away early versions of the game around the middle of the development process. Besides the money that helped finance the development (we used our own funds) it gave us powerful psychological support.
When your project is anticipated and people have faith in your team, it’s a huge spirit booster.
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. Then the concept changed, and floating islands were lowered from heaven into the water, and it became a mixture of “Waterworld” 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 test out the prototype yourself, you will not understand if there is fun in it. The more creative iterations, the better the project ends up being.
4. Experiments with the genre need to be clearly articulated to the players
People who wanted to see Oil Rush to be a classic RTS got a completely different game: no direct unit control, automatic unit production, and focus on very dynamic tactics. No matter how we tried to explain it in the game description, we still received a portion of negative reviews saying “this is a bad RTS”.
Probably, we should have paid more attention to the genre specification.
5. The game is made for the gamers
It’s very sobering to have focus tests where you are forced to silently watch people play your game for the first time. It’s exquisite torture of sort: you could complete any level with your eyes closed, but they never use the game mechanics you spent weeks optimizing, simply ignore 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 a few levels that were too difficult for average gamers: and they gave up playing.
6. Developing a game powered by your own engine is a double-sided coin
It’s bad because the engine still needs to be written, or refined, along with the game development. And the effort is usually not worth it when you can just license another engine (often for free). In our case, the engine already existed, but we had no experience in game development. And we would have to get documentation with development tips from our future selves (even this article would come in pretty handy).
But still, it’s a good idea. After the development of the game is completed, you will end up with a refined engine and a very experienced team who knows it like the back of their hand.
7. Even if you pay a lot of attention to quality assurance, you can miss a critical bug
We tried very hard to make the game technically stable throughout the development process. Before the release, we tested the latest changes for 25 hours in a row. 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 complete the first levels!
Almost the entire team is already quite drunk, the developer who could help is on vacation and has no access to the Internet — it looks like a dead end. Fortunately, the bug was fixed pretty fast: the producer sent suspicious code fragments to the lead developer via SMS, and he reported back what to fix. The build was rebuilt and published within a couple of hours and almost none of the players seemed to notice the problem.
In conclusion: after the release, you need to be ready — something will inevitably come up, no matter how thoroughly you checked.
8. For your first game, just to break even is a big success
Oil Rush has not become a renowned strategy game or an all-time hit but has found its audience. Not only we broke even but made some money off of the game. And for the first project, we consider it to be a great success.
Just open the Wikipedia page of any major studio and see how many games they released before the one that the whole world fell in love with.
9. Don’t stop after the release
The entire development team was so exhausted from those last tense months that they couldn’t even hear the game’s name.
Yet we released several updates and fixed all the bugs we missed the first time, but that was it. Of course, the game would not have become radically different, but if we worked for a couple more months on polishing the difficulty level in the campaign, Oil Rush would be much more interesting to play. Or, have we added multiplayer to the mobile version, it would have significantly increased the game’s audience.
10. It is extremely important to bring the project to release
The experience we gained by releasing the game on 5 platforms and multiple venues is invaluable. Just developing a game and releasing it are two different things: only after the release, you would find out what the “second 90% of the work” is when you already seem to have done the first 90%. This is extremely useful to small indie teams, who often have a bunch of unfinished projects. A consimilar experience can be gained at game jams. We recommend them to everyone.
Now the UNIGINE team is working on a new unannounced game, and all the Oil Rush experience helps us avoid a lot of mistakes in the process.
To celebrate its 10th anniversary, we’ve made Oil Rush free forever on Steam and Google Play!
On January 25th, we hosted an anniversary livestream of the developer team playing Oil Rush. It was nice to see multiplayer come to life again: after all these years, people still remember. The broadcast was hosted by Den Shergin, CEO of UNIGINE.
