Tag: c#

Posted on

On the state of Unity

I kinda want to say something about Unity that hasn’t been said before… but I really can’t. I turned my back to Unity as a commercial tool years ago and I just hope, I never have to return to it.

5+ years ago, I was very happy with Unity. The tool is easy to extend and build simple stuff in. Then I released my first game with it – simple and on mobile – and thought: Mobile is shit, I will never go mobile again. Then I switched to Unreal. Now I never want to touch Unity again as well.

My main problem with Unity is that there is no structure in what it wants to do or be. The pricing model was always horrendous, the feature releases suboptimal and the quality of anything was always bad. Unity never felt to me like a professional tool after using Unreal.

Maybe because I’ve seen Unreals code which feels like a piece of software that grew organically while working on a game. Maybe it was the high amounts of pitfalls Unity made in its own design compared to Unreal (e.g. not having an equivalent to FName and FText).

A lot of stuff in Unity feels silly in hindsight (remember UnityScript?). And a lot of features never came out properly. With Unreal (for 4 years now) I do not only see improvement everywhere, I also see the abandonment of features when the replacement is there and usually the replacement is better.

Unity has – at the point of writing – 3 different render pipelines (legacy, URP, HDRP) which are incompatible. It has 3 different node editors that you need to understand. It has 2 ways of scripting (GameObject based and ECS). And it has moved a lot of stuff into packages that never feel native.

Unity is a train wreck of a software. I do enjoy working with it at game jams and such, but I could never think about using it again as a base for a big title because it feels to me like a house of cards. And instead of trying to make the base more stable, they always just add more cards on top.

This post was originally a thread on BlueSky, but I felt like it should belong here.

Posted on

Creating a fontsystem

Because in a game it is somewhere required to use a line of text, most game engines are able to process fonts on the fly or on startup. XNA supports so called “spritefonts”, a system that uses xml-files as informationcontainer. These xml-files are saved as “*.spritefont”-file, but even inside they reveal their truth: The first line is an xml-validation.

But xml can’t be used to tell the graphics-processor what to draw, so XNA compiles the information into an xnb-file which is just a collection of bitmaps that are connected to Unicode-Characters. When these characters are called, the font provides the required infomation about them.

The problem is: This system can’t be used on the fly, but in compiletime. And thats the problem. I don’t use the regular contentpipeline. I load my stuff into the engine when I need it, spritefonts don’t support this behaviour.

I had to create my own font-system.

The *.gef-system

I created a system that saves characters into a binary-file followed by bitmaps representing them. I will write an article about the file-architecture sometime, but the current article will be about the creation of the font.

The encoders and the decoder are both extracted from the core-assembly of the game-engine. The reason is simple: I wanted an external tool for the creation of the fonts.

I know there are some simple rules about creating object-oriented assemblies and these tell me that one class has only one job and one purpose. Same goes for the assembly itself. I want to have it as a standalone linked-library. The engine uses the decoder, the tool the encoder, but instead of splitting these up, I create an independent assembly. And there is another thing that I want to mention about the independent assembly: I can update and build it without rebuilding a whole gameengine.