Learning From Unity After 15 Years of GameDev with Custom Engines

I started developing custom engines 15 years ago as tools like Unity did not really exist back then and it was pretty rare or expensive for projects to use a third-party engine. For the month of April I took a different approach and jumped into Unity to explore work-flows and different tools. I also wanted to explore the idea of releasing an asset pack to focus on improving my art skills and try increasing the income of my game development adventure.

The art pack never happened because I shifted gears in the middle of April since my LudumDare game was a lot of fun. Before LudumDare I had created a very small infinite-runner-like game to dip my toes into Unity, then I ported some portions of Turbo Boom! just to keep investigating without wasting time designing a new game. During LudumDare 46 I created Eggcelerate! and was rated 12th. I continued a post-jam version which you can grab now on itch.io, or check out the trailer. It is eggcellent and filled with rotten yolks.

Eggcelerate! took 3 weeks to create and supported the exploration of more tools and work-flows in Unity. I didn’t get the chance to explore everything, like particles, shaders, and other special effects however I got the basics. I wrote down many work-flow improvements and ideas for editor tools along with some pain points I’d like to avoid in my own tools. I will return to share a post-mortem that will discuss the art lessons I had while doing the art for Eggcelerate!

From my notes I found 5 major items from Unity that could improve my work-flow and engine tools.

Camera Gizmo

One of the first things I will be adding to my editor is the camera gizmo. This allows changing to or from orthographic mode and alignment with a world axis. While orthographic mode tends to break my brain, it is super useful when placing certain items with an aligned view; say looking top-down to place the checkpoints along the racetrack.

Vertex Snapping

I also found vertex snapping to be super useful as well. Just press and hold V, select a vertex from one of the selected items and then drag toward a vertex in the world for automatic placement. However I did notice Unity got extremely slow with this when I had added some corn-fields in my world. While that definitely increased the number of vertices; my dragging wasn’t anywhere near their location and I would have expected some broad phase collision to have reduced this lag. This one will definitely take an effort to get right and will be useful in more situations than the specialized implementation of my segmented track editor.

Editor for Bounding Volumes

If it were easier my first task would be adding the bounding volume editor. My present work-flow is to adjust numbers in C++ or JSON data and recompiling or hot-loading until the debug display matches expectations. Dragging this around is far faster, though takes more infrastructure than I presently have available. It is perhaps the most valuable of the additions which would make collision volumes easier to create.

Components

My framework has a concept of entities, though not completely component-based. I went with a behavior system that allows for code-reuse and sharing. Only one behavior is active on an entity at a given time and can be popped off a stack. After playing with Unity I believe it would be in my best interest to add a more typical component-based system to my entities for more code sharing.

Wild-and-Free Mindset

A significant improvement to the work-flow I had in Eggcelerate! was just not caring about things. This is certainly a balancing act and too little care will lead to significant development issues. In the prototyping stage the speed of development outweighs almost everything. While I do prototype my projects early on, it isn’t as quick or nimble. I suspect this comes from many reasons, but changing into Unity flipped my brain into a wild and free mode that I haven’t experienced for a while.

I was primarily focused on features that would be desirable yet some Unity tools rubbed me the wrong way and I would like to avoid them in my own tools. Some of this is just the nature of tool development and others might be personal preference.

Having Bad Defaults

This will be hard to avoid in practice, but having good defaults go a long way to making a smoother experience. I found many defaults in Unity to get in the way. Having an AudioClip set to “Play on Awake” for instance was extremely frustrating and at one point led me down a rabbit hole to try fixing a bug where a sound was playing when it shouldn’t.

User Experience

It was annoying that the keys to translate, rotate, scale and such were mapped to qwerty keys, but R didn’t rotate, and T didn’t translate. I’ve heard this is the same in Unreal and other engines, though it hurt my brain. I had to constantly press all the buttons to find the widget I desired; just moving the order of two of the most common tools could reduce that guess-work significantly. The big picture here is to keep the user in mind when developing tools. I can see qwerty being useful to users with experience from other engines with similar hotkeys, but as a tool developer we must ask are we just following a convention without purpose, or could it be better?

Load Times

Unity took ages to start especially so once asset packs were added to the project and I didn’t consider those to be very heavy. This isn’t a massive issue as exporting and processing items will always take time, but it was all at once and felt disruptive, perhaps more so from a streamer perspective. This was also faster than all the times I would need to rebuild my engine libraries. It would be useful if my editor did not take forever to load a project.

Play Mode Crashing

Near the end of the month Unity started crashing on me and in the logs it seemed to come from a bad SSL certificate; that is the best guess I have from my experiences and I saw other developers commenting on it. This wasn’t very fun, nor did it seem useful to me as a developer having opted out of analytics…

One thing I missed from my own editor was the ability to hold shift and drag and object to create a duplicate. This works so much smoother, in my experience, than pressing CTRL-D just hold shift, drag, drag, drag and you now have three extra copies of the object.

While that stuff could be smoother there are a few reasons to choose Unity over building a custom engine. If you are building your own or thinking about doing so, make sure to consider the following:

Time is Money

The most obvious benefits of using Unity is not investing a substantial amount of time and effort in creating your own engine, adding support for all the platforms, and dealing with inevitable bugs that would otherwise be worked out. This can be huge financial savings as time and money are strongly related from the business perspective.

Great for Prototypes

Unity is GREAT at prototyping games and this was a driving force behind it for years. I will almost certainly be using it in my adventure for future prototyping needs because of the mindset shift I mentioned earlier where it allows me to be a lot more wild and free. It also contains many things my engine does not which would let me test more ideas faster. After finding an idea I like I can then move into my engine and do what is necessary.

Importing from Other Tools

The import process from Blender to Unity was extremely smooth, I assume the same for other tools. Just add the .blend to the Assets directory and automagically the mesh objects inside are converted to fbx and Unity formats. This means just hitting save will automatically update the contents in-engine. My custom engine supports hot-loading of mesh assets but I need to both save the blend file normally, and export it. My exporter does support batch exporting already so the friction has been reduced, but processing the blend file directly is a very interesting thought. This is likely far too much effort for a solo-developer given the actual value.

Mass of Information

Another advantage to using Unity is the mass of information available. When you want to solve a common problem, like perhaps a chase camera, it is quite easy to google and find what you need. Sometimes the asset store will have a full solution ready to go, though I didn’t use any in my exploration. This is not a huge advantage, but when prototyping it certainly sped things up.

Generic Use Case

Unity is good for generic use, it can make first-person shooters, platformers, role-playing games and everything in between. However I am remaining focused on racing games, and a custom engine will allow me to specialize the tools to fit those needs. This specialization will allow for faster development times in the specific case of racing games, though it may reduce the ability to make other game genres.

After a month of exploring Unity my thoughts have changed slightly. I was expecting to never touch it again but instead will likely use it for prototyping new ideas and during game jams. For long term projects the lack of low-level problem solving and code architecture would cause me to burn out. I will continue to use my own engine for many reasons:

1. I am specializing in racing games and can specialize my engine for those needs.
2. I enjoy code architecture, watching a structure grow and interact with other portions.
3. I enjoy having complete control over how something works.
4. Avoid issues with poor documentation, kinda, and API breaking updates.
5. Finally I started 15 years ago when Unity did not exist, and engines were rarely used, it is the way my mind works and this is why Unity isn’t worth it for my larger projects.

For my indie adventure I choose to build my own engine and specialize it for racing games to keep my sanity during the long-haul.

When making the choice for yourself, consider that your needs are likely different than mine. As a hobbyist a generic engine probably makes more sense than a specialized one as it allows more options. From a business perspective it depends on more. While the cost of most commercial engines is tiny compared to building a custom one, at least these days, there is some advantage in specialized tools. A business may also not wish to deal with API breaking issues while updating the tools. That said for game business with no genre in mind an engine is a massive boost and from my previous experience pitching to publishers, a popular engine could increase potential partnerships.

Go have fun balancing eggs in Eggcelerate!