I kind of wish I had used another engine

News & General Discussion
1

Over the last decade of grinding away and learning Unity, the communities been very supportive, and regardless of its shortcomings, Unity’s been a decent engine to work with, and the journey from just rendering a few cubes running around on a plane to entire expansive worlds has been a level of fun I can’t describe.

Now looking back, though, after having gotten something on a console, I wish I had just used Unreal Engine or SDL2 with C++.

The reason for this, is that i feel really ‘locked in’ now to the Unity ecosystem, and having now been pretty much trained to use C# day in and day out, now realizing that every console’s SDK is written in C++, all of the AAA and AA studios use C++, because technically making games involves systems programming no matter what you do, as you need to access the file system of the hardware you’re using, the input, audio, etc…

I feel like after what happened, that it’s like I don’t own the very thing I’ve created after all these years. I only create 2.5D JRPG-like games like 90s square soft games like Xenogears, and I wish I had just stuck with C++ and made a toolset that was tailored only for that one thing.

A huge mistake, I wish I had at the very least kept my entire codebase for the tools I’ve spent years developing abstracted from rendering and Unitys animators, and especially ProBuilder, and Unitys GameObject class and made a custom Scene format so I could have just used Unity as a renderer and for its console support only.

In general, I wish I had used Unreal Engine or SDL2 and/or a custom renderer for graphics, because in starting C# I already had used C++, and strayed from it due to ‘ease of use’.

You know, the most valuable thing you end up making are your own personal tools, tools which you hope to use for decades to come. While a game may take anywhere from 3 months to 3 years to create, your tools that you develop could potentially stay with you for 5, 10, even 20 or more years. For a game, using Unity for a project to get in there, finish it with a team in less than a year, then get out is fine…but for a toolset, I don’t think Unity is a good choice.

Again, I don’t feel now I even own what I created, and in the next few years will probably just create it again after my current series of games are finished, in Unreal, or use SDL2 with C++ for my next project. Now I have 7 years of Unity and C# on a resume with 0 Unreal Engine. Oh well, I guess we have to learn the hard way sometimes.

I really really really really wish Unity just natively used C++. In my view there’s no point in having this whole tech in IL2CPP, just so that we’re all trying to avoid what? Complexity? It wouldn’t have been so much more complex to have C++ scripts instead of C# ones, you dont have to use all the extra C++ features. In fact, I’d argue Unity would be more stable and easier to manage for Unity Technologies. C# isnt that much more simple, especially once you get into Events, delegates, interfaces, etc…John Carmack himself said that he’s of the opinion that it’s better to just use a single language.

2

Before I started using unity I was on my way of making a custom engine.

Then I downloaded unity and after a month or two learning the engine, realized that I can prototype in half a day that which will take half a year from scratch. That was “an important lesson” and it felt like everything I learned was a waste of time.

Then unity did their stuff with their license. That was another “important lesson” which made me think that learning unity was a waste of time.

9415586--1318994--upload_2023-10-18_5-55-52.jpg
9415586--1318994--upload_2023-10-18_5-55-52.jpg700×1680 310 KB

So, I guess, welcome to the club. There’s a saying that roughly translates as “If you knew where you’d fall, you’d put a mattress there”, meaning you never know when things are going to go sideways.

And regarding C#. Every engine has ONE feature developers are utterly fascinated with and refuse to let go, no matter what. In Unreal it is blueprints. In Godot that’s gdscript. In Unity it is insistence on using only C# with no C++ API.

3 Likes
3

Yeah this feels like a bit of a “hindsight is always 20/20” moment. It’s just human to look back at the choices we made and wonder what we could’ve done differently. But no amount of ruminating will change what was, and you just gotta deal with what is.

2 Likes
4

Holy fricking moly NO!
Doing complex stuff in C++ is a pain in the butt - I know it since ~30% of my day job is C++. Already the fact that for every single refactoring action you need to modify a cpp as well as a hpp file is such a blocker leading to worse code quality (unless corporation forces you in which case work just become inefficient).
Wouldn’t C++ have its whole ecosystem and existing devs nearly nobody would use that language now that languages like Rust and GO exist. For games content it is not the ideal language.

Btw. in Unity we have Burst for when performance is required.

1 Like
5

I’ve used C++ and it really isn’t that difficult to use. It’s just all the library dependencies that can be a pain, not the language itself. I believe most C# users could easily learn C++.

But I do sometimes wonder which is more likely to happen first, C# becoming as performant as C++ or Unity finally adding C++ support.

Perhaps they’re afraid to add C++ support because it could become another stepping stone for Unity users to escape the Unity pond. :hushed:

6

C# is supposed to get some gains from introducing Net Core in 1-3 years, however as I said, when you want max performance in Unity you use Jobs with Burst or ECS which is aiming to be Burst compilable (and allows just for comfort, to attach traditional code).
Burst can well compete performance wise with C++ and is a magnitude safer to use.

C# is used as a scripting language and does its job very well with that.

No way Unity will add more C++ support to the end user. They have spent A LOT of effort procentually reducing the Cpp side of the ecosystem. The vast majority of new features the last 5 years came as packages - C#.
Btw. if you really want C++ you can always attach a DLL.

2 Likes
7

We live now and not 1-3 years later. Burst, Jobs and ECS are unity-specific dialect, which makes them not very different from GDScript. C# is less safe than C++, because it lacks certain bug prevention features like const correctness.

Nope.

If you “attach a DLL” you’ll be able to neither write editor extension nor new components nor interact with the engine in any meaningful way without a ton of glue.

Doing it this way will reduce the engine to the level comparable to raw libsdl, and in this case what’s the point.

1 Like
8

We had that discussion before. And I entirely disagree again as will likely do most people. Hence why C++ is the “shoot yourself in the foot” language…

Yes it’s not 1-3 years later but performance of the language is not a major problems as many thousand games show.

2 Likes
9

Well, it’s not too late to add more stuff to your toolbelt, the wrong move here is doubling down and self deluding yourself into staying with Unity hoping things will magically get better in… 1-3 years or some bullshit, or convincing yourself there are no viable alternatives somehow.

1 Like
10

I’ve been using C# and unity for a long time now, and even though we’ve hit some speed bumps as of late, I wouldn’t change a damned thing.

I don’t feel limited by the language at all, i’ve been able to do all the things I wanted to with the code, the engine could have a few more graphical capabilities, but it runs on every major console, and can even publish to web.

To be frank, I’ve never understood why everyone is so obsessed with getting more performance out of things, i’ve never added fun into my game and thought, “this would be even more fun if the engine could do this 100x faster”. The ease of use of adding new features for most projects is still 100% the bottleneck to a game being better, which makes Unity still the best tools for many projects.

The grass will always be greener, had you learned C++ you would have likely burned out and never got as far into your current project than if you’d had Unity.

There is no perfect solution, and Unity is actually pretty awesome in so many ways even with the recent happenings. Maybe Unity dies a slow death, but other engines will rise and fall, some of those engines will run C# and it will absolutely be easier to make great games in them. If one of them figures out the graphics pipeline you will have the best of both worlds and none of this work will be squandered. Pipelines can be learned, especially these days with all the communities and searchable resources, it’s the discipline and overarching logical practices that really matters.

We’re going through a time of change, the industry is going a bit crazy, the world at large is kinda nuts, but there is absolutely nothing stopping you from making a great game in your lonesome still with Unity, in fact Unity is still one of the absolute best if not the best engine for a solo dev to compete with and that’s not going to change for several years.

You can lament that you don’t have tools from 5 years ago, but I guarantee you that if you started learning a new language now, in just a few months you’d be writing better tools in that engine than you could have 5 years ago.

As others have said no point harping on the past, everything is 20/20 in hindsight, and we as human sacks of meat can tend to fixate on the bad and go down rabbit holes of regret. Don’t lock yourself into a singular workflow, play around with other engines and languages on the side.

Here’s the cold truth: Unity is still the best engine for a small team or solo dev to make a fantastic game. Get to it.

7 Likes
11

Reading through people’s replies has made me feel better about the situation to a degree. I have to cone to terms with the fact that I’m now a Unity developer.

I guess the Unity debacle recently raised a point. That is, that my tools are tied into this engine, and now it has an always online requirement, which means that your work passes through Unity Technologies authentication system, in a way they’re held in a vault and Unity Technologies has the lock and grants you the key. This is an always on requirement…they hold a lock on what’s essentially your private research and study.

When you’re planning on the next 10, 20, 30+ years of your life doing this work, you have to think that you’d want portable code I guess.

2 Likes
12

“Most people” is a logical fallacy. Ad populum.

The primary issues of C# are use of GC, nullable values and lack of certain C++ features one of which is const correctness. Some of those are extremely unlikely to be addressed. Additionally the benefit of C++ is using industry standard and not a dialect like Burst/Jobs/ECS. Note that those things can be viewed as an equivalent of vendor lock-in.

And yes, we had this discussion before. Your dislike of C++ is a personal preference. There are people who do not share your preferences.

The issue with the post I responded to is “Just use a DLL”. That part comes across as insincere/disingenuous. Because you can’t “just use a DLL” to the same extent. If I could do that, I wouldn’t be touching C# and we wouldn’t have those discussions.

3 Likes
13

Don’t consider yourself a Unity developer, think of yourself as a C# developer that knows Unity.

Careful what you wish for. Artists have been clamoring for better and better tools and now the genie is out of the bottle with AI. There’s something to be said for gamedev being hard, and if you’re able to meet those challenges and make something great despite it all, it makes your project stand out. If it was easy, everyone would do it! So take solace that there is no clear path, there is no easy road, it means you have a snowball’s chance in h*ll if you can finagle your project together against the millions and millions of other games out there.

2 Likes
14

I don’t think this is realistically possible. Language has nothing to do with it, really. If it were only a matter of translating one C# to C++ it would actually be relatively easy. Language isn’t really a big deal.

The real problem is that have very different APIs with designed around completely different paradigms and you’d be interfacing with the API at every step of the way.

Maybe your experience is different, but my current project relies heavily on engine features. My code is basically just a thin smear that communicates between built-in engine features. Sure I could write an abstraction layer between the engine and my logic, but then I’d have almost nothing left :hushed:.

15

Godot and MonoGame are excellent alternatives for someone that wants to make 2.5D games using C#. The former if you want a game engine and the latter if you want to build your own. I wouldn’t spend any more time with Unity if you’re not happy as like @AcidArrow mentioned the situation is not going to improve.

2 Likes
16

I’ve been playing with Godot in 3D lately and if you don’t care about terrain tools being built into the engine (and lets face it, unity’s have sucked and been behind pretty much all the time) and don’t mind writing shaders, its honestly actually really good! Yes its not at the level of unity, but due to the fact that I don’t have to fight the engine so much, I still in the end get more done in Godot than unity

Word of advice for anyone evaluating Godot - learn GDScript first - its an awful scripting language and will make you want to pull your eyes out, but its good for quickly figuring out the engines API and how it works. Once you know that, learn the C# side (which has some small differences but overall is documented well) and you will find it a very similar experience to unity in terms of workflow speed at that point

EDIT: A seasoned unity developer will learn it in a weekend :slight_smile: Good luck to anyone looking at these alternatives! Monogame is also great, FNA too!

1 Like
17

There is an open source third party terrain system in development.

https://github.com/TokisanGames/Terrain3D

2 Likes
18

…but in order to for example get a job in development and transfer that knowledge over, or even if you use for example Stride engine, the C# you’re using may be a bit different right? I mean Unity isn’t using .NET 7.0.

Learning C# it is to a large degree transferable, but the features of .NET 7 confuse me right now, for example there was a video like ‘Are Events Now Useless/Obsolete?’ on YouTube, that confused me.

19

That looks really good. Unity built in terrain is simply not good in my opinion, particularly the terrain data thing, how it creates the terrain data file in the root folder instead of where the terrain asset actually is is pretty dumb.

What I’m going to start doing is just writing an abstraction layer from now on, so making my own Terrain data format, then write translation code, so that way one could use any terrain system available, just change what’s inside the translator, but everyone time I get into this idea of writing an abstracted toolset, I get to this idea of like…wait…why am I even using Unity I the first place, and it leads back down the rabbit hole of writing the abstraction layer in C++.

1 Like
20

I’ve been trying bits of it, but haven’t gotten far yet. One thing I really like is that I can just pull in a gltf file and it will have materials configured automatically.

However, it doesn’t play with autorig and mirror modifier. You get half the mesh. So I got sidetracked into building my own rig from scratch. Looks like skeletal meshes are handled in a bit old-school way.

That sounds like a bait title that should be skipped. Youtube these days seems to be focusing on wasting as much time as possible and not providing anything useful. This is something worth keeping in mind whne browsing it.

Would be best to pour over “new features” texts and see if anything catches your eye. For example, this is a random text description of C# 7 new features:

https://devtut.github.io/csharp/c-7-0-features.html

1 Like