Unity Issues

[Ripper]

Probably a conversation for another thread, but as far as I can tell, Unity would have no trouble with this level of FPS. I don't think the garbage collection should be a big problem there (the engine itself and its essential functions are C++, it's just the scripting that's c#), and there's whole FPS frameworks among the others on the store that run fine. I think the main reason that more ambitious projects don't go for Unity is that you can't modify the engine code, which can be restrictive. But for an FPS at this level, I'd be very surprised if there was a roadblock that justified scrapping development

 

[Ripper]

You can't? From the comments of Dark Crystal Games devs, they modified it quite heavily. I didn't ask for details, maybe they meant something else like modules on top of it. It must be pretty risky to start modifying the source code, though.

From what I've heard of the Tactical Adventure people, Unity wasn't without its performance problems. Obviously there are still serious issues with recent cards, performance issues also popped up in the Pathfinder beta once they started adding light effects. The loading time for relatively small maps is quite high as well.

Now, maybe those devs are not using it properly. But either way, that confirms what I said earlier, using complex frameworks efficiently is bound to be difficult no matter how shiny their IDE is, because of their complexity and the hardware variety they have to support these days. Compared to that, engines of the 90s were pretty basic and straightforward.

I looked at the current status of Unity. They've put the source for parts of the engine on github for reference purposes, but you're not allowed to modify or redistribute it, even as a binary. It seems you can negotiate access to the full source for an undisclosed sum.

When you talk about devs perhaps not using it properly, I've no idea how good that particular studio is, but my general impression is that the issues we tend to see in Unity are more a function of the much lower budget folks that use it, than problems with the engine itself. Like, for instance, the issue of garbage collection that often comes up, that can be managed if a studio has the right skills. You can force manual memory management in C# if you really want to, or write a piece of C++ code and call it from Unity, to handle memory allocation if too much garbage is being processed.

I think Unreal is good, but it's not a panacea. You've got the option of using their visual scripting system, but again, if you start getting performance problems you don't understand, you're still going to need to get the C++ ninjas in to sort that out. Apparently, from what I've read, that's a quite a common job opening - experienced C++ game programmer needed to fix our game that works, but runs like shit.

 

[DArtagnan]

Well, I don't know how "professional" inXile and Obsidian are - but I would imagine they're not exactly inexperienced. Games like Wasteland 2 and PoE are both infamous for significant GC-related stuttering (or "spikes" in terms of FPS drops). PoE 2 is particularly bad in this way. It has to do with it being forced on the main thread only - at least for past versions. I'm sure there are ways around it, though - but I bet it requires a less convenient way of allocating memory in your game - and many experienced developers are probably not crazy about adapting in that particular way. People like doing things the way they're used to.

I'm guessing they just accepted the stutter - or never noticed it. I know several people have played through PoE and PoE 2 - claiming there's no stuttering. Some people just aren't sensitive to that sort of thing.

So, regardless of what "professional" developers can do with Unity - it seems certain that even very experienced developers have struggled with it in the past - and we're talking about isometric RPGs that don't rely on fast and smooth responses to the degree a modern shooter would do.

So, again, Unreal definitely seems a much better choice for a new developer with minimal experience developing shooters from scratch - especially if it's true that Unity has issues with console conversion on top of that, though I have no idea in what way.

 

[Ripper]

Well, when we talk about experienced development studios, it still depends on what skills they have available, to a large degree depending on their budget.

Is it actually well-established that those games had stuttering that was caused by garbage collection? There's tons of possible causes of hitching, and people tend to hear these things and repeat them without necessarily a sound basis for it. I'm not saying that wasn't the problem, but I doubt the problem was the Unity engine itself (the fundamentals of which don't use garbage collection.) If the problem is related to GC, it's almost certainly because of the game logic the devs created on top in C#, and there are definitely ways around that if they wanted to avoid the unpredictable GC behaviour.

I much prefer Unreal myself, but I don't know how much I would say it's recommended for beginners. All you've got there is Blueprint scripting and C++, which sometimes you really need to use, and most new devs find the complexity of C++ quite a barrier.

 

[DArtagnan]

Well, when we talk about experienced development studios, it still depends on what skills they have available, to a large degree depending on their budget.

I don't think budget necessarily relates all that much to skill. I mean, Obsidian is an extremely experienced developer - with a very long history of making games.

Budget usually relates to the amount of developers on a project and the amount of time planned for development - more than some kind of measurement of experience.

At least, how "experienced" a developer is - is too variable to measure in that way. I certainly know my share of developers with fat paychecks who don't know much beyond shit.

Is it actually well-established that those games had stuttering that was caused by garbage collection? There's tons of possible causes of hitching, and people tend to hear these things and repeat them without necessarily a sound basis for it. I'm not saying that wasn't the problem, but I doubt the problem was the Unity engine itself (the fundamentals of which don't use garbage collection.) If the problem is related to GC, it's almost certainly because of the game logic the devs created on top in C#, and there are definitely are ways around that if they wanted to avoid the unpredictable GC behaviour.

Unity uses its own garbage collection - and it's a confirmed problem by both modders and developers of these games. We must remember that Unity is just an engine based on code - like anything else. There's obviously GC and memory allocation involved.

There are mods to alleviate these problems with Unity games. You can google "Special K" for instance - which is by some tech guy who's made a bunch of mods that deal with a wide variety of issues in all kinds of games.

You can easily find countless examples of performance issues related to Unity GC.

Here's a random official quote from learn.unity.com:

Garbage collection is an operation that occurs as part of how Unity manages memory. The way that our code uses memory determines the frequency and CPU cost of garbage collection, so it's important that we understand how garbage collection works.
In the next step, we'll cover the topic of garbage collection in depth, and provide several different strategies for minimizing its impact.

I much prefer Unreal myself, but I don't know how much I would say it's recommended for beginners. All you've got there is Blueprint scripting and C++, which sometimes you really need to use, and most new devs find the complexity of C++ quite a barrier.

Not for beginners of smaller projects - or projects that don't focus on performance.

But for a modern shooter? Unity certainly wouldn't be my first choice.

To each his own, though.

 

[Redglyph]

I looked at the current status of Unity. They've put the source for parts of the engine on github for reference purposes, but you're not allowed to modify or redistribute it, even as a binary. It seems you can negotiate access to the full source for an undisclosed sum.

Usually those undisclosed sums are quite high. Besides, if they start modifying the source code, it means maintaining the updates (I doubt a pull request will be taken by the engine owner). Valve did that back then by modifying id's engine, but I'm sure they took it from there.

So that must have been something else on top they adapted for Encased, perhaps Unity has add-on modules like Godot.

Well, I don't know how "professional" inXile and Obsidian are - but I would imagine they're not exactly inexperienced. Games like Wasteland 2 and PoE are both infamous for significant GC-related stuttering (or "spikes" in terms of FPS drops). PoE 2 is particularly bad in this way. It has to do with it being forced on the main thread only - at least for past versions. I'm sure there are ways around it, though - but I bet it requires a less convenient way of allocating memory in your game - and many experienced developers are probably not crazy about adapting in that particular way. People like doing things the way they're used to.

I haven't really seen stutters in PoE2, or very occasionally, but I'll pay more attention next time. The level loading times are long for the content though. In Kingmaker, it could also take a while before items to loot were appearing, and it increased with the game progression (Pathfinder games never forget the loot, it remains there). It was never very quick to load the levels either.

So there are performance issues within the rendering, partly because they have to face the new cards, partly because it's hard for devs to see the impact of new features (like multiple lighting sources). There are loading issues that may or may not be the dev's fault. And other issues that are more likely in the scripting, and possibly the GC.

I saw there were including Mono libraries, so at least they are more or less independent of the OS.

Maybe a skilled dev can try and customize the GC and other problems, but is that in their skillset? Once such problems arise, it's often far from their comfort zone. And it's not their job, if they rely on a game engine. So devs starting who are not familiar with a new engine will spend a lot of time, either discussing with others and trying to understand and fix the problem, or working around it by changing the engine or the way they are using it.

Isn't there a significant difference between the licencing of Unity and Unreal too? I looked that very long ago, and past a number of copies, the fee was much higher for Unreal. I haven't checked recently.

PS: we should move all those posts elsewhere :lol:

 

[DArtagnan]

Yeah, I think we've bogged down the thread long enough with mostly off-topic stuff.

Interesting enough and all, but perhaps a bit exhaustive and academic for my tastes

As for PoE 2 - the stuttering gets very apparent once you reach Port Maje - the first town in the game. Every 30-90 seconds - you will experience a significant frame drop, which is incredibly annoying if you're sensitive to that kind of thing. Unfortunately, I'm very sensitive to it. No, it's not related to hardware - and I know because I've tested it exhaustively on multiple systems and multiple patch versions. It's also happening on console versions, by several reports.

I spent literally weeks trying to solve it - and I finally came to the conclusion that you can alleviate it to a significant extent by limiting the amount of threads dedicated to the game process. For whatever reason, 3 threads seems to be the sweet spot for me.

It's still there, though - just lessened.

 

[Redglyph]

Thanks to whoever moved the posts here!
And sorry for the OOT outburst

 

[Ripper]

I don't think budget necessarily relates all that much to skill. I mean, Obsidian is an extremely experienced developer - with a very long history of making games.

Budget usually relates to the amount of developers on a project and the amount of time planned for development - more than some kind of measurement of experience.

Money relates to how many man hours (the more technical ones being more expensive) get spent on the various aspects of the game, no matter which studio might be making it. Devs have often talked about shipping games with known issues, because money is that tight, and they just didn't have the time and resources to fix and optimise everything. I think that's been more often the case with Unity-based projects.

Unity uses its own garbage collection - and it's a confirmed problem by both modders and developers of these games. We must remember that Unity is just an engine based on code - like anything else. There's obviously GC and memory allocation involved.

Yes, of course it's based on code, but that doesn't mean there must be GC going on as part of the engine itself. As I said before, most of the Unity engine, like almost every other major engine, is built with C++. And one of the main reasons for that is that is because games are realtime and performance sensitive, you want absolute control of memory behaviour, which is what C++ gives you. That's good for performance, but manually managing memory efficiently and safely in the context of a game engine requires much more skilled programmers.

The reason C# is used for the scripting is because it's much more approachable, and there are far more people out there comfortable using it. But, with that comes the chance of people using it badly, and causing problems for themselves. Whenever you use a garbage collected language, you have the potential problem of a large GC occurring when you don't want it. But there are ways to mitigate it.

There are mods to alleviate these problems with Unity games. You can google "Special K" for instance - which is by some tech guy who's made a bunch of mods that deal with a wide variety of issues in all kinds of games.

I had a quick look, and I don't see anything about how Special K fixes GC issues in Unity.

You can easily find countless examples of performance issues related to Unity GC.

I can find some examples of people on forums saying it, but nothing that looks very authoritative, to me.

Here's a random official quote from learn.unity.com:

Garbage collection is an operation that occurs as part of how Unity manages memory. The way that our code uses memory determines the frequency and CPU cost of garbage collection, so it's important that we understand how garbage collection works.
In the next step, we'll cover the topic of garbage collection in depth, and provide several different strategies for minimizing its impact.

I think you misunderstand what that article is talking about. It's worth a read, and it's explaining to devs that the game code they create in Unity (in C#) is going to be subject to GC - then it discusses all the ways to approach your game code in ways to minimize any issues. But they also explicitly state that the core Unity engine code does not use GC, only the C# code you create.

 

[Redglyph]

C# is a great product. The language is fantastic (IMO) and its evolution has been very well managed by MS, which is not an easy feat in programming languages because of back-compatibility.

It's very clear and flexible, much more approachable indeed. Yet with enough features for very complex programming. And very good integration with the MS frameworks (which are more restricted to the Windows OS unfortunately).

But bytecode and high-level come at a price. I don't know when and how often the bytecode is JIT compiled in the case of Unity, it may be an issue in games sometimes but only the first time new code is met. Some years ago I was trying to compare performance of code in C# and Java, it's always been difficult to profile because of this initial phase.

So while I understand why they offer the possibility, my instinct still tells me C++ would be more appropriate (IF the programmers know what they're doing), even for what's above the engine. While that's only scripting, it still involves managing a lot of objects. Or perhaps most of those objects are not managed, only pointers to C++ instances? Still, the collections must be made and unmade all the time.

 

[DArtagnan]

@Ripper;

I'm not claiming to understand anything about this in-depth - I just provided you with a random quote that specifically states that code within a Unity game uses GC when running on the Unity engine (as I would assume is the norm). Whether it's part of the "core engine" or not - I have no idea. If it's written entirely in C++ and they don't use GC collection (which IS a thing in C++ AFAIK, at least to some extent) - then I stand corrected.

But it's obviously going to be a part of every single Unity game out there - and the performance issues seem related to the "default" coding approach by a whole host of professional developers. Again, they're probably not used to adapting to this kind of memory allocation or whatever the requirement would be to avoid performance issues.

I'm not that tech savvy in terms of these things - and if there's an easy way to avoid improper memory allocation - it's certainly sad that I've had to endure several games that had so many issues related to this.

I just know that I've seen many games with these issues, and I've seen developers comment on it being related to GC - whether Unity-specific or not. I can't immediately recall if this was on the Obsidian forums or the Steam forums - maybe both.

As for Special K - it's a framework with a whole host of fixes and tweaks.

If you really want me to find something for you, here:

https://steamcommunity.com/app/560130/discussions/0/2572002906843374108/

But I think that's about it for me in this debate. I'm sorry if you guys really want to go on about it, but I consider it pretty secondary to my original point regarding System Shock Remake and its delays

I do remain firm in my experience with Unity games and how they tend to have relatively serious performance issues - especially when contrasted with Unreal Engine games.

Whether that's 100% incidental or not, I can't say - but my gut feeling is that it's obviously not.

 

[danutz_plusplus]

I use C# and .NET in my daily job, but in a completely different context (cloud/web). I was always fascinated about how Unity runs C# code alongside native code. My only other exposure to such a thing was a short job I had on a product that performed memory injection into apps as part of its way of working. This product had code that constantly switched execution from native (C++) to managed code (C#) and back again, and it was wild to see. It also had memory/stability issues due to the complexity of all of this, which of course led to crashes situations near-impossible to debug.

Back to Unity, I believe I later read that they wrote a C#/IL to C++ transpiler, so that it no longer needs to run under the mono runtime, and thus no longer needs GC? Not sure if that eliminated the runtime/GC completely, but it sure sounds like it. I also have no idea how successful that was.

https://docs.unity3d.com/Manual/IL2CPP-HowItWorks.html

 

[DArtagnan]

Money relates to how many man hours (the more technical ones being more expensive) get spent on the various aspects of the game, no matter which studio might be making it. Devs have often talked about shipping games with known issues, because money is that tight, and they just didn't have the time and resources to fix and optimise everything. I think that's been more often the case with Unity-based projects.

Oh, and this bit - I forgot.

Again, I really don't want to go on about something so secondary to the original point - but your claim was that skills of developers largely relates to budget.

I think that's very, very not true

I mean it would be great if it was - but I think you're quite aware that's obviously not how reality works when it comes to compensation.

We can talk about some very theoretical ideas of how Unity games are subject to shorter development times and tighter budgets - but that's outside the scope of my point that budget doesn't necessarily relate to skill, and - indeed - I often think it misrepresents skill. Otherwise, we'd have no indie games with small budgets that had talented developers - and all the most expensive AAA games with huge budgets had the most talented developers. An obvious untruth if there ever was one.

Just wanted to address that, as it would be a little rude to ignore it.

But, again, this whole derailing is a little too academic and "I think, you think" for my tastes.

 

[DArtagnan]

One final bit - just to provide "authoritative" proof of how Unity defaults to a certain kind of GC that CAN cause performance spikes.

In other words, exactly what I've been saying all along.

https://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html

Unity uses the Boehm–Demers–Weiser garbage collector, a stop-the-world garbage collector. Whenever Unity needs to perform garbage collection, it stops running your program code and only resumes normal execution when the garbage collector has finished all its work. This interruption can cause delays in the execution of your game that last anywhere from less than one millisecond to hundreds of milliseconds, depending on how much memory the garbage collector needs to process and on the platform the game is running on. For real-time applications like games, this can become quite a big issue, because you can’t sustain the consistent frame rate that smooth animation require when the garbage collector suspends a game’s execution. These interruptions are also known as GC spikes, because they show as spikes in the Profiler frame time graph. In the next sections you can learn more about how to write your code to avoid unnecessary garbage-collected memory allocations while running the game, so the garbage collector has less work to do.

Sorry about the RPGWatch mess of weird symbols

But I trust the source will back me up.

Anyway, I think that's not relevant - because it occurs to me we've been talking about different things.

Ripper seems to have been talking about the "core engine" - which is not the same as the "Unity Engine" from my perspective.

I guess I've been talking about Unity as a whole - or the "Unity Development Suite" - if you will.

Now, I can't say anything about the core engine - because I have no idea how it's coded or how it allocates memory. I know that memory is handled, though

In that very same way, I think the developers and the tech-guys I've seen bitching about this - have probably been talking about the "Unity Development Suite" - and how it does GC - which needs certain knowledge or insight to handle properly, to avoid these spikes.

In short, I don't think any developer has said that it's "Unity's fault" - but that the performances issues are because of GC in Unity.

They could very well all be at fault - I just don't think it means they're "inexperienced" or "unprofessional" - they're probably just subject to a certain way of thinking - or, as Ripper mentioned, on a tight schedule.

I hope that clears things up enough

 

[Redglyph]

Yes, without using the engine it's awkward for me to argue with anything beyond sharing what similar experiences I had (which may apply ... or not). It's interesting to discuss this but I'm fine to leave it at that for now; it's not he first discussion we have on the subject and perhaps it will come back again

How much time do you think it would take to get a simple game environment with one of those engines, like a basic isometric view and a little guy the player can move? I've been tempted a few times to mess a little bit with that and try a few AI algorithms, but I'm afraid this could take way too much time.

I use C# and .NET in my daily job, but in a completely different context (cloud/web). I was always fascinated about how Unity runs C# code alongside native code. My only other exposure to such a thing was a short job I had on a product that performed memory injection into apps as part of its way of working. This product had code that constantly switched execution from native (C++) to managed code (C#) and back again, and it was wild to see. It also had memory/stability issues due to the complexity of all of this, which of course led to crashes situations near-impossible to debug.

Do you mean bindings that allow to access native code from managed code? It does looks a bit like black magic I've done it on a few rare occasions too in C# and Python. It's sometimes a bit tedious to create the binding, and of course the native layer must be thoroughly tested independently to avoid the situations you describe as much as possible.

 

[danutz_plusplus]

Do you mean bindings that allow to access native code from managed code? It does looks a bit like black magic I've done it on a few rare occasions too in C# and Python. It's sometimes a bit tedious to create the binding, and of course the native layer must be thoroughly tested independently to avoid the situations you describe as much as possible.

I'm not sure I remember exactly, but I think managed to unmanage was via PInvoke. The otherway around I can't remember.

 

[DArtagnan]

How much time do you think it would take to get a simple game environment with one of those engines, like a basic isometric view and a little guy the player can move? I've been tempted a few times to mess a little bit with that and try a few AI algorithms, but I'm afraid this could take way too much time.

It depends on the implementation.

If you do a 3D game - an isometric perspective is as simple as changing the camera angle.

If you want a "2.5D" sprite-based isometric game (Like Underrail, for instance) - you're probably better off creating a tile-based engine, which is a little more tricky - but there are a zillion tutorials and downloadable world-builders for that purpose in the asset store.

For animating characters, Unity comes with a built-in Avatar - with a rig that's easy to animate and with full standard controls, meaning you can more or less drag and drop the model into the game and use standard WSAD controls for movement during run-time.

All you'd need is a flat plane with a rigid body component as the ground - and it would work.

So, the basic functionality you're talking about is simple - and I could make a simplistic isometric game with a character moving around - jumping over obstacles etc. in a couple of hours probably. It wouldn't be very exciting, though.

Unity also has very easy-to-use tools for terrain generation and stuff like path-finding, which I've used in one of my projects. I have a Diablo-type game that I've made - mostly based on tutorials, free assets and stolen pieces of code - but there's basic fighting, spell-casting, looting, progression, primitive inventory management and so forth. There's even sound effects and such.

For custom characters, you can literally download character models and whatever animations you want - and combine them, if they both support the right formats. So, you could download a fairy tale princess - and then download military style tactical animations, including crouching and prone positions - and apply them to the princess.

It's more or less that simple.

Obviously, it takes time to learn the Unity bespoke methods and syntax - which is based around Game Objects and Components.

You have to learn how to reference each individual component and how to manipulate their properties - but it's really not very hard.

 

[Alrik Fassbauer]

I tried to play the game "Bayala" for the movie of the same name (a bit too childish for my taste, but I just wanted to try it out because it is very colourful and still far away from any "standard" Fantasy …) which is based on Unity, but I couldn't get it to run. I really have no idea, why. The screen just remains black.

One day, however, a lot of months ago, I started it, then went somewhere else to do other things - and after 10 or 20 minites later I came back - and it suddenly ran !

I really have no idea what had happened.

 

[Redglyph]

It does sound easy to start "playing" with Unity. Maybe I'll give it a try, even if my C# is a bit rusty (perfect excuse to dust off LINQPad, if you know that tool).

As for PoE 2 - the stuttering gets very apparent once you reach Port Maje - the first town in the game. Every 30-90 seconds - you will experience a significant frame drop, which is incredibly annoying if you're sensitive to that kind of thing.

I have just checked and can see it, every now and then it will freeze for 1-2 tenths of a second, it's quite visible. At least Unity seems to take the time into account and the moving bodies, like the sea gulls, reappear at the expected position as if they didn't pause.

I'm not too bothered by that but I understand it can be annoying. There are a few imperfections, like the animation of running characters that doesn't match their ground speed (they seem to slide on the ground), music that have one instrument failing when the mouse goes over a clicking part of the interface, the silly 5-year-old news that still appear on the menu screen… They stand out just because for the most part, this game is really polished.

 

[Ripper]

One final bit - just to provide "authoritative" proof of how Unity defaults to a certain kind of GC that CAN cause performance spikes.

In other words, exactly what I've been saying all along.

https://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html

Yes, no-one's disputing that GC is going on - it obviously is, as discussed, when our game logic is scripted in C#. But this again is talking about the specifics of their implementation of the C# scripting, not how the engine itself (the renderer, the physics, the I/O, etc) operates. If you read the page, it's talking about what to do and not do in your scripting to cause spikes in GC, and discusses options like incremental collection, disabling it, and so on.

All I'm trying to get across is that when people complain about GC in Unity, that's not some strange problematic behaviour in the engine, or that Unity is somehow doing bad GC - it's simply the result of using a GC language for a game script, which, if users don't design in such a way as to avoid spikes, can cause themselves problems. So the bit I'm keen on, is that people don't get these ideas that go around like urban myths, about that darn Unity garbage collector! And the bit I was looking for something more authoritative on, is the idea that specific performance problems are definitely traced to GC issues at all, rather than just unsubstantiated assumptions passed around.

Oh, and this bit - I forgot.

Again, I really don't want to go on about something so secondary to the original point - but your claim was that skills of developers largely relates to budget.

I think that's very, very not true

I mean it would be great if it was - but I think you're quite aware that's obviously not how reality works when it comes to compensation.

We can talk about some very theoretical ideas of how Unity games are subject to shorter development times and tighter budgets - but that's outside the scope of my point that budget doesn't necessarily relate to skill, and - indeed - I often think it misrepresents skill. Otherwise, we'd have no indie games with small budgets that had talented developers - and all the most expensive AAA games with huge budgets had the most talented developers. An obvious untruth if there ever was one.

Except that's not what I said. My point is that different skill sets generally have different values in the market, and therefore different costs - not that there are no talented developers working at lower budget productions. If, as an example, you want an experienced C++ graphics programmer to work on a modern 3d Vulkan renderer for your game, that is almost certainly going to be more expensive than someone that can build levels in Unity and do some C# scripting. That latter guy might be a brilliant young talent of game design working his first job, but, by and large, that hardcore technical skill is going to come at a high hourly cost. And, in relation to what we've been talking about, the more hardcore, low-level work you need to do, that's generally going to push the budget up - to a point that most indies won't want or be able to go there.