Sponsored By

Comparing the process of shipping games using three different engines

Rogue Summoner, my third game on Steam and first Unity game, will be released in just three days. How does the development process compare to my other Steam games - one created with the Unreal Engine and the other with no engines at all?

Dan Zaidan, Blogger

September 1, 2020

9 Min Read


Hello everyone!

Rogue Summoner - my third game on Steam - will be released in just three days!
I thought I would take the opportunity to talk a bit about the development process of Rogue Summoner (which is my first commercial game using Unity), and how it compares to my other Steam games - one created with the Unreal Engine and the other with no engines at all.


Rogue Summoner is a turn-based roguelike about placing monsters in the board and letting them fight for you.


Unity was the first engine I learned back in the late 2000s (because that was pretty much the only accessible engine at that time). I never actually finished any project, and had a hard time dealing with the code complexity as the projects grew.

However when Unreal Engine 4 was launching (back in early 2014), they started releasing a series of tutorials on Youtube showing how awesome and simple the blueprint system was. And I was like: "Really? Can I really make games with that?"
So I subscribed to Unreal Engine 4 (back then it was 19 dollars per month) and started learning it.

Needless to say, I fell in love with the ability to make games without having to type code and decided to create my first commercial project.
Three and a half years passed, and I released Eliosi's Hunt into the world on Steam and Playstation 4.
Along the way I had help from a lot of talented people who were trying to finish their first big projects just like me.
It was really cool to see the engine "growing" with the game. I started on Unreal 4.0 and shipped on 4.16, in 2017. Lots of amazing tools were added along the way (UMG and Sequencer were the main ones I had to learn in the middle of development).
Evidently, by the end of the development, I was forced to do some C++ magic in the game, mainly to ship the game on Playstation and to integrate with newer versions of the FMOD audio middleware. As you can imagine, it was complete nonsense to me - but thankfully I managed to solve all the problems I had and shipped the game.
My lack of programming experience was one of the major problems in the development, especially at the end, when the bugs started to pile up.


Eliosi's Hunt

After releasing Eliosi's Hunt, I decided to take a step back and study programming... for real.
Thankfully, I came across Handmade Hero, an educational project to teach developers how to make an entire game... absolutely from scratch.
And I absolutely loved it.

There is something really special about understanding everything that is going on with your game, and being able to step instruction by instruction and see what is going on and why.
Not only it was a very fun (but challenging) endeavor, I can actually say that I learned how to program after that.
To consolidate all that knowledge - and help people learn how to program games, just like Handmade Hero taught me - I decided to create a game from scratch and stream the entire process. It would be a smaller game than Handmade Hero and serve as an introduction to it (because the series starts in full force!)
That is how I developed my second Steam game: Break Arcade Games Out.
I ended up releasing it for free on Steam, along with the entire source code.
It took something like 80 hours to program the entire game (and engine) from scratch.

You can watch (and learn) the entire development of the game here.

After some time (and some non-game-related projects), I went back to creating video games with my brother.
When we sat down to think about the project (and how we would make it) we had to decide what game engine to use.
I already had experience with Unreal Engine, and was very passionate about making games with no engine, but.... we decided to try Unity for this project.
(More on that later)

That is when Rogue Summoner was born.
I had to learn the engine while creating the game, and it was a bit weird in the beginning to go back to watching Youtube tutorials after all those years and all those projects.

But something was different.
Because I knew exactly what would take to make the game (because I had already shipped a complex 3D game in another engine) AND I was extremely comfortable with programming in general, it was a breeze to program Rogue Summoner and to learn the new tools - especially considering that in Unity most of the game architecture is created by you, and not enforced by the engine or the tools.

In Rogue Summoner, it was very important for the gameplay to be completely predictable, so the player can learn what each monster will do (no matter how complex) and plan accordingly. Because there is a lot of action/reaction-type of behaviors and they are dependent on some animations, I had to create a robust queue system so that monsters could interrupt the play, counter attack, attack on death and use several other mechanics.
But in order to create this system (and all other systems), I just wrote regular code, interfacing as little as possible with the engine systems. Because of that, I was able to quickly program the gameplay systems (almost as if I was creating it with no engine) while making use of all the regular goodies games engine provide.

So how did these experiences compare?

Unreal is clearly the most powerful one. Not only in terms of graphics but also in terms of tools. And that is a big deal. Unreal has tons of tools to help in pretty much everything you could want in your game. In contrast, if you are making the game in your own engine you would have to create all those tools yourself (or integrate an existing tool with your engine, which can be just as difficult). Unity has most basic tools, but they are not as fleshed out as Unreal's. A lot of people create tools and sell them in the Asset Store, but using those has its pros and cons.
The biggest con of using Unreal is that since it was created for big teams to create big games, it comes with a certain complexity you will have to deal with. This complexity can easily turn into friction for smaller teams. For my brother and I, since we wouldn't even be able to leverage all the features Unreal has at our disposal for Rogue Summoner, and the friction could add up and make the development take longer and require more profiling and understanding the "best way to use the engine", we decided to try a different engine. Unreal would be better fit for a larger game with more resources, even larger than our 3.5-year project.

Making games by hand is certainly a passion of mine (and apparently, of many other people as well).
But there is a pretty big con (and a obvious one): making games is a lot of work. When you are tight on the budget and can't afford to spend months creating tech for the game, it's probably not going to be a good idea to roll out your own engine.
Even though I can make game jams with no engine pretty effectively, to create a polished, commercial-quality game is another thing. The quality bar for indies keeps rising and to support all these things that make the game shine is really not trivial.
HOWEVER, (and that's a pretty big HOWEVER) making games with no engines will improve your programming skills in an unbelievable way. You will be able to organize large amounts of code as if it's nothing. You will be able to know when you should spend time optimizing the code and when it's just a waste of time. You will know when you can create a quick hack to fix a problem and when it will bite you down the line.
These skills will come extremely in handy when creating games, no matter if you use another engine.
I would not have been able to create Rogue Summoner (while learning a new engine) as robustly and as quickly as I did had I not had the experience creating entire games from scratch, and that, especially in the long run, is worth a lot.

Unity was a perfect fit for Rogue Summoner.
Even though it doesn't have systems as robust as Unreal, the fact that it doesn't enforce a certain architecture on the gameplay code (unlike Unreal) was a pretty positive point, because I could more freely program the game and not worry too much with "how the engine wants me to do it".
Of course, using it in the long term would make spending some time to build better tools for it more viable (like the developers of Ori did).
Knowing the common ways that your code could be slow also helps you avoid the pitfalls that is very common in Unity games, in regards to smoothness of the game feel. That is something the developers of Inside (Playdead) struggled with a lot to create their (immensely polished) game, and gave a great talk about it; and most of it came naturally to me because of my experience making games with no engine. Rogue Summoner is not an action game, though, and that might have been more problematic in that case.
Another pro of Unity (at least for us here in Brazil) is that almost all devs around here use Unity, and being able to learn from them is really valuable as well.

Well, I hope you enjoyed this discussion on my experience shipping games with different engines.
If you have some time, I would really appreciate if you could check out Rogue Summoner! :)
I'd love to know: what engines have you created games with? What did you think of each process?
I would love to hear your thoughts in the comments below.

I hope we can continually improve the game development process and, in turn, the games we create.
Dan Zaidan

Read more about:


About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like