12 ms·

C# in Unity 2026: Writing more modern code

78 points by hacker_13 6mo ago

weli 6mo ago
A lot of game devs are terrible programmers. A friend of mine 10 years ago asked me for help with his Unity project. He is not a tech savvy person but we both took programming in high school, enough for him to make small games with a lot of tutorials and stack overflow. His codebase was horrible, a lot of logic that I would have already though of abstracting away. For example saving dialogs on json files and the conditions for that dialog to trigger for that NPC as some sort of finite state machine that can be represented with a series of sequential flags. He had a single file that was about 15k lines full of `if (condition && condition) || (condition && condition)` statements. He didn't seem to see the issue, it just worked. That's when I understood some people just care about game development and doing cool stuff and don't care at all about programming, good practices or structured code. And that's perfectly fine.
- kdheiwns 6mo ago
  Most indie game dev projects start as some small weekend project just to feel things out. Then it starts to become fun so we work on it another week. Then after a couple months we start to think that maybe the game has potential. Then we're 5 years into a project and have no clue how we got there. It becomes a giant jenga tower where moving any one block can completely collapse the whole project, so we learn the hard way that nobody should ever refactor. Pretty much the only people who do refactor end up restarting their project from scratch, getting frustrated because they can't capture their original feel of the game, then ultimately abandon the project entirely. And for professional game dev projects, it's all built on a foundation of some scrappy little indie project from decades ago. Some industries are all about making their code public and making it super clean and polished as a point of pride. Games, like movies and sausage, are disgusting to see behind the scenes. They're just piles of scraps and weird tricks that look great unless you get down and examine it too closely. And most people aren't looking that closely, so wasting that time and effort is pointless.
- grebc 6mo ago
  I’ve met plenty of these types in enterprise jobs too.
- chrysoprace 6mo ago
  Since it's a multi-discipline craft it's hard to get good at every aspect for indie development, focusing most of the effort on one or two aspects. I think the programming aspect for indie games typically matters very little unless it hurts performance or causes bugs, and the things the user interacts with end up mattering a lot more. Every web developer I've met has specialised in one area or another, even if they claim the title of "Full Stack".
  - Sharlin 6mo ago
    Problem is that this kind of code often is brittle, full of bugs and unhandled edge cases, and evolution and maintenance is horror. But if it’s all you know you might never question it.
    - chrysoprace 6mo ago
      Often but not always, and if they're a solo developer then maintenance might not be too bad as they might be able to keep all the logic in their head. I'm not advocating for that kind of approach, but if it lets people focus on things that the player will actually notice like the gameplay, graphics, sound, story or art then hey, what's a little shortcut?
    - ablob 6mo ago
      A game is finished at some point. You might not need to evolve the code any further. Why optimize for a use-case that rarely applies to indie-games?
- 999900000999 6mo ago
  If you’re a solo developer, if it works. I’ve seen worse in enterprise shops and then I’ve gotten into nasty arguments with people who don’t care about programming. They can’t be wrong. C# is a high level language that can handle a degree of sloppy programming. I was working on a small tool yesterday. It was easier to vibe code it from scratch in C# than to modify an existing Rust project. The only weird part is VS Code Copilot couldn’t figure out how to build it via the dotnet cli and I had to install VS Studio. After that everything was fine.
  - orthoxerox 6mo ago
    I would say that C# is "less colored" than Rust. Handling a moved argument, a borrowed argument, a copied argument is different in Rust, you have to think upfront about memory lifetimes. If you are wrong the first time, changing the ownership is not a simple localized refactoring.
    - 999900000999 6mo ago
      To be 100% fair, it’s much easier for llms to start new projects and Rust is simply a more difficult language. I have what I need working in C#, and as a C# developer I actually understand what’s going on. The only downside is now instead of having a portable Rust project, I have something which heavily leans into Windows APIs. I assume with high level languages some smart people figured out all the memory stuff.
- vhab 6mo ago
  This goes for devs in all industries, it's not a problem unique to games. If anything, the most competent developers in terms of getting the most performance out of hardware are game developers.
  - deleted 6mo ago
    [deleted]
- captainbland 6mo ago
  I think as a solo developer there's actually a good argument for increasing code density and coupling (things which in large multi developer projects are seen as spaghetti), as it can help you keep a lot of that code in mental and visual context at one time. It loses flexibility and readability for others, but you don't usually have enough time to concern yourself with such flexibility if you're working on a project by yourself, and you're not concerned about onboarding other developers and having them understand your code. The upshot is then that as a single person "bad code" is often highly effective code, and "clean code" is expensive code that buys you a lot of stuff you don't need or want. I say this as a boring enterprise developer who at work is highly concerned with appropriate abstractions etc. imo there's no universally good approach, what is optimal is context dependent. Although there are some core features of code like consistency and strong conventions which are fairly universally helpful, this represents a small fraction of best practices.
  - grebc 6mo ago
    This is pretty anti-thetical to most good practices but the older and more experienced I get the more(13 years as a C# dev) I think copy & pasting sections of code is wayyyyyy more appropriate than extracting into a method/class/library or other forms of abstraction. Everything starts out with good intentions when someone comes along and says “hey you could make that an abstraction” and I just clench my jaw because I’ve seen that happen so much and then that simple clean abstraction eventually ends up being a horrible 1000 line monster that barely anyone understands and no one wants to change.
    - tranceylc 6mo ago
      I agree with everything except for it being anti-thetical to good practice. I have noticed a lot of experienced devs agree with that sentiment. It has been a pretty common trend for the last few years of people breaking out of the “OOP style programming” and practices they were taught at university. I am not saying avoiding things like over abstraction is new, but I do think there is a newer generation of programmers who have been taught and warned about drawbacks from practices like that. Similarly, my anecdotal experience tells me more newer game devs are aware of basic memory practices being better than overly complex OOP code. Think flat arrays and simple cache alignment over something abstract and over engineered
- jrecursive 6mo ago
  Gamedev at a high level is similar in spirit to distributed systems or compilers in that it's intensely multi-disciplinary with hard constraints. In gamedev you have a main thread that you're always sweating about submilliseconds, especially with worker threads interfering with it. Processor, memory, bus characteristics, GPUs, cooling, etc. all matter. This leads to e.g., everyday AoS vs. SoA, pooling and burst compile, to the classic fast inverse square root because of hardware at the time. Relentless optimization of hot paths produces code that's about performance, not abstraction. Then there's shaders, which are effectively a different programming model targeting different hardware entirely. Now add support for multiple operating systems, consoles, whatever. The list goes on. Now, all of that doesn't obviate the value of design and craft, so I don't agree that it's "perfectly fine". There are plenty of programmers weak on these two axes in most any domain, but it's worth noting gamedev is a special case that significantly distorts what good code, or at least good-enough code, looks like. Games start as little experiments and end up as Frankensteins. This is their nature; you're more sculpting a thing by building it and experiencing it rather than designing it a priori with systemic elegance in mind.
  - rcxdude 6mo ago
    And that first bit only really matters if you're making a fast-paced game with sophisticated graphics. Most indie games can get away with horribly inefficient code.
- groundzeros2015 6mo ago
  I don’t see the issue. Real software problems are when the logical model is insufficient for the given problem.
- Latty 6mo ago
  To be a bit more charitable: I'd say that generally games involve a lot more special-casing than most code, and more planned out scripts (in the movie sense) of things happening, which tend to be antithetical to good coding practice, and encourage spaghetti, which begets more. In my experience, games that are procedural tend to be much cleaner code-wise, because they tend to fit the model of cleaner code better. I think game engine tooling tends to encourage bad code too, lots of game engine make it hard to do everything in code, rather things are special cased through UIs or magic in the engine, which means you often can't use all the normal language features, and have to do things in awkward ways to fit the tooling. Of course, this varies a lot by engine.
  - skeeter2020 6mo ago
    IME you have so little reuse, and ship on a fixed schedule regardless of code quality & bugs this really isn't as critical as software built with the intent of lasting a long time & evolving. The games I've worked on (in hindsight) feel a lot like "vibe-coded without AI".
- WhereIsTheTruth 6mo ago
  It's an indication that programming languages are the wrong abstraction for creative work
- leloctai 6mo ago
  The other day a professional gamedev was arguing with me that's Transform.GetChild to get a reference to a component was not a bad practice. His argument is that it's what every other firms in his area is also doing. I do hope that was not the truth and he was just trying to win the argument. For solo hobby dev it is a lot more acceptable. After all they're also terrible 3d modeler, concept artist, musician, writer, marketeer, community manager,...
  - MattRix 6mo ago
    I mean it’s not that bad of a practice, it depends on the context.
  - PacificSpecific 6mo ago
    Based on your comment it sounds like you have a personal problem with that person which compromises your argument
- wheybags 6mo ago
  Something I've noticed about software dev vs game design: software is better (easier to read, understand, maintain, etc) when you have clean, separated modules. Game design is better (more fun) when everything is connected (eg in an fps, everything relates to gunplay, damage systems, environmental destruction, in a building game, everything relates to building, the building ui, inventory, resources etc). I think this mismatch shows up in game code. Combine that with actual hard performance constraints, and if you're a "normal" software dev casually browsing some game code, it can be shocking (eg Celeste movement code: https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs https://github.com/NoelFB/Celeste/blob/master/Source/Player/...).
- badsectoracula 6mo ago
  FWIW sometimes when making games it helps to have everything in one place, even though later you may want to split things up for later projects :-P so sometimes you get big balls of mud with lots of checks everywhere for the actions you want. As an example, most of the gameplay logic for Post Apocalyptic Petra[0] (a 3D platformer/adventure/riddle solving game i made for an MSDOS game jam a few years ago) is in the entity class for the player character[1] - including things like collisions, etc :-P. It is a bit hacky, but it works. Though if i ever made that sequel i wanted to where i want to have an extra character following you around, i'd need to move a bunch of things to other more generic places so that they can be shared by both the player character and the AI. [0] https://bad-sector.itch.io/post-apocalyptic-petra https://bad-sector.itch.io/post-apocalyptic-petra [1] https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o/Game/EPetra.pas https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o...
- jayd16 6mo ago
  Solo dev also just doesn't need a lot of abstraction. You're adding a lot of noise for what sounds like zero benefit to developer and especially not the player. Game dev is also a lot more agile than other projects. Solidifying structure is just more to rip up later unless you really know what you want to ship.
- PacificSpecific 6mo ago
  You think that's bad. Wait until you see some non game developer coders (I'm being sarcastic of course. The comment I'm replying to is incredibly naive).
- slopinthebag 6mo ago
  It's also because gamedev is very highly iterative, so if you're abstracting stuff you end up throwing away your abstractions when things inevitably change. And that costs more than just changing some if statements.
tryfinally 6mo ago
Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc. [0]: https://github.com/Cysharp/ZLinq https://github.com/Cysharp/ZLinq
- drzaiusx11 6mo ago
  Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)
  - tryfinally 6mo ago
    The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.
    - drzaiusx11 6mo ago
      I assume it's not a black box anymore, but maybe that's a non-free lang extension? I had assumed linq was part of .net core these days, but I haven't gotten around to checking (10+ years since I've had a serious .net project)
      - pjmlp 6mo ago
        LINQ has always been around since it was introduced, the only non-free language extension in .NET were contracts that required VS Enterprise license.
  - WorldMaker 6mo ago
    Most .NET projects that Linq originally targeted ran in so called "Server" and/or "Workstation" GCs (.NET has had very generic public names for its GCs for a long time which were also somewhat misnomers because even some Desktop apps would run in "Server" GC and it was possible for vice versa [0]) where allocations were cheap, garbage collection was relatively cheap (because both GCs were multi-generational, had strong [but different] tuning for their generations, etc). Unity inherited a much simpler Boehm GC from Mono. Under a (single generation) Boehm GC allocations are a bit more expensive and garbage collection sometimes a lot more expensive. (A Boehm GC was much easier for C++ engine code to understand/interact with, which is also part of why the .NET modernization project for Unity got so complicated and still has such a ways to go left.) [0] Fun aside: in fact, modern docker advice for .NET is to switch "server applications" to use "Workstation GC" if you need to stack multiple containers on the same host because of differences in expected memory usage.
DarkNova6 6mo ago
What C# version does Unity currently support? 2024 I chose Godot over Unity due to its better C# support and I can’t say that I came to regret my decision.
- tryfinally 6mo ago
  C# 9, but with some hacks you can bump it up to C# 10 - actually works and surprisingly stable. Can't wait for them to finally migrate to CoreCLR, though.
  - moron4hire 6mo ago
    I got out of doing Unity development 7 years ago because I was tired of waiting for them to migrate to CoreCLR (among many other reasons).
    - pjmlp 6mo ago
      Unfortunately the way they managed to stick with MonoRuntime and Burst, kind of made more harm than good, regarding C# adoption on the games industry. Many issues people associate with C#, are actually only relevant in Unity, because of this.
- drzaiusx11 6mo ago
  Iirc the lineage of their c# came from Mono, then diverged a bit over time. Hopefully they can leave that baggage behind and just use the newer .net core, if they're not already that is... Disclaimer: I haven't looked in half a decade
raincole 6mo ago
Unity's C# has always felt like C#'s mentally challenged cousin. C-not-so-sharp. The custom == convinced me that allowing operator overloading on built-in operators is one big mistake.
- orphea 6mo ago
  Many tools can be misused. Object.Member can throw a NRE, is it a big mistake to have the dot operator?
  - raincole 6mo ago
    It's such a weird question. Yes, "dot operator can throw a NRE" is of course a big mistake. A billion-dollar mistake, you can even say.
    - orphea 6mo ago
      No, I'm not asking if "dot operator can throw a NRE" is a mistake; I'm asking if the dot operator, the ability to access members at all, is a mistake.
      - WorldMaker 6mo ago
        One take on it is that yes, the single dot operator was an ancient mistake which is why so many programming language features are about making it smarter. Properties as mentioned in this article are an ancient way to fake the dot operator into a "field" but actually make method calls. Modern C# also picked up the question dot operator (?.) for safer null traversal and the exclamation dot operator (!. aka the "damnit operator" or "I think I know what I'm doing operator") for even less safe null traversal.
- kbolino 6mo ago
  For those wondering, Unity overloaded the == operator in two specific situations, such that obj == null will return true even though obj is not actually null. More details on this archived blogpost: https://web.archive.org/web/20140519040926/https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/ https://web.archive.org/web/20140519040926/https://blogs.uni...
shevy-java 6mo ago
> The Unity engine has evolved a lot in modern days, but I noticed a trend where Unity developers are still using "outdated" techniques when writing their C# code. Some years ago I tried to get into C# + Mono. Eventually I opted for Java instead, for many reasons; I'll skip that here. C# is very strange to me. In a way I feel that C# belongs like Java in the same "post C++" family; C kind of paved the way, C++ was messy and powerful, so Java and C# would be more "managable". But I never got into C#. Java is not a pretty language, it is also quite boring, but modern Java is somewhat acceptable - you get the job done. And it is not an extremely difficult language either for the most part, just with an addiction on pointless verbosity. C# is ... strange though. TIOBE has it ranked #5 right below Java, so there must be many C# users, but I don't get to see them really in the Linux ecosystem. So where are these people all? Using Windows only? When the question is "most developers don't use feature xyz", do all of them actually KNOW these features? You can still find many java tutorial where people use archaic ways to, for instance, iterate over a collection. Perhaps it is similar to the C# ecosystem, people are slow to adopt. Or, and this may also be a reason, people could have moved to other languages. This may not be a huge percentage, but you see that some languages suddenly struggle with old devs and failing to get new devs (ruby is in this problem right now; it may overcome it but right now it is sinking hard, even though I would reason that the language is, for the most part, better than it was in, say, 2010).
- ablob 6mo ago
  C# has had the reputation of not being viable for Linux for a long time. Therefore, the people already on Linux didn't have a reason to use it or even try it. If you're already doing stuff in other languages it's hardly worth it to switch to C#. I personally use it quite a lot - but I came as a windows user writing all my utilities in C#. Also, afaik C# is mostly used in corporate environments that don't open-source their projects. You're unlikely to hear from it unless you're working on it for this very reason.
  - drzaiusx11 6mo ago
    Mono was in a usable state on Linux for literal decades before becoming official and integrated into what is core today, that is unless you needed windows forms, which much like MSFT UI frameworks today had multiple failed attempts spanning those same decades...
coinfused 6mo ago
Looking forward to when Unity will migrate to CoreCLR. Soon! https://www.youtube.com/watch?v=_t6xVfrmEWU https://www.youtube.com/watch?v=_t6xVfrmEWU
- pjmlp 6mo ago
  That soon is like a decade in the making. And with many folks going into alternatives like Godot, it means C# ends up losing the mindshare it got. Yes, you can use C# with Godot, but most folks end up with GDScript, or GDextension.
  - drzaiusx11 6mo ago
    Iirc Godot is taking the approach from both sides however and also working on a libgodot which will allow a "bring your own runtime" which I'm much more interested in than the integrated "environments" that are Unity and Godot today. I'm likely in the minority though as they only started making a library export after the all in one environment was stable enough...
  - enbugger 6mo ago
    Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.
    - pjmlp 6mo ago
      I agree, however most indies don't need them, and most pros are getting into Unreal instead. Also something like Burst is a workaround for using Mono with C#, which gets solved in Godot with C++. How's the whole DOTS adoption going?
      - enbugger 6mo ago
        >gets solved in Godot with C++ if only by rewriting half of the Godot codebase. With design choices they made, Godot will never be performant enough for RTS/Crown simulation games. https://github.com/godotengine/godot/issues/101494 https://github.com/godotengine/godot/issues/101494 >How's the whole DOTS adoption going? I'm quite impressed to what people build on top of it: https://github.com/Dreaming381/Latios-Framework https://github.com/Dreaming381/Latios-Framework https://assetstore.unity.com/packages/tools/animation/mesh-animator-animate-massive-crowds-26009 https://assetstore.unity.com/packages/tools/animation/mesh-a... and many more
everyone 6mo ago
I'm a very experienced Unity C# programmer, and I certainly don't equate "good" with using all the new fancy features of a language. Fancy features are less maintainable imo. Less programmers will know about them and they're less likely to have equivalents in other languages. Making something more exotic / confusing / hard to parse is defo not worth saving a few lines of code.. I'd much rather see a longer function using absolute bog standard elements of the language (and thus being clear, easy to comprehend for everyone, easy to modify at any point) rather than a super short, super "elegant", super "clever" solution.
- drzaiusx11 6mo ago
  Languages that seem to indefinitely grow more features over time (like c++, c#, rust, etc) evitably become bucketed by epochs unless the consuming application code also operate across the same time scales. Feature deprecations tend to go hand in hand with newer features, leaving you with basically "multiple sublanguages" in a supposed single language, exacerbating fragmentation of the community. I don't want to have the mental load of contextually understanding "which" sublanguages I need to care about depending on the year a consuming application was written. This is why I tend not to reach for new fangled features and stay with the core runtime stuff in evergreen langs.
- jayd16 6mo ago
  I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc. Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach. New doesn't mean good but a lot of these are new and good.
  - everyone 6mo ago
    I disagree about LINQ. You can easily do the same job in a little function with only stuff people learn in week 1 of programming, just for and if else and arrays. It's very clear precisely what's happening in this case, and its easy to alter. (Everyone is gonna know that stuff, not everyone is gonna be using LINQ regularly enough to understand it completely) LINQ on the other hand is like another language entirely, awkwardly squished into your C#, reminds me of SQL code inside a big string inside another language's code. It's also not clear what it's actually doing which can be death for performance in games as LINQ usually allocates shittonnes of new stuff. (I'm certainly not advocating for premature optimisation, but I defo am advocating for knowing precisely what you are writing) The benefit of LINQ is that its a bit faster to write compared to a little function, but length-of-time-it-takes-to-actually-write-code is very rarely an important constraint in my experience.
deleted 6mo ago
[deleted]
moron4hire 6mo ago
Game developers are not paid to be good developers. They're paid to be young, naive, and easily brow-beat into working unpaid overtime. I think one of my biggest problems with Unity is that it enabled a massive market of me-too "business men" who "employ" unpaid and underpaid interns to hack together asset-store-ware they then dump on the app stores. When a gem game stutters, people blame their crappy phones rather than the company who probably stiffed its developers. I've seen a lot of my friends do this constant churn of signing up for the next game shop that will hire them. Places that throw many, many red flags the second you even walk in the door. They work hard to get a game done on a budget 1/10th what it should be, the game ends up being a flop, and they never get a chance to grow their portfolio or skills to eventually get a better job. This isn't something you can lay at the feet of Unity Technologies, but I do think it is a reason to avoid Unity: the job ecosystem is just awful.
- jayd16 6mo ago
  Why wouldn't a released game grow their portfolio?
leloctai 6mo ago
Doesn't hn clean article titles? This is a classic click baity one. Most of these are just basic features. Some are unused for good reason. - Property: the inspector doesn't call your getter or setter. I do use them still because i like to centralize my validation logic. But need custom machinery to make them behave consistently. - Tuple: well-known. Good but only in moderation. - Linq: people avoid it due to allocations, not runtime. While it is possible to avoid dynamic alloc, it is not obvious and best avoided. Also the point about the linq syntax being "cleaner" is debatable. - Record: good. Lesser known as it's the newest in the article. No footguns like the other. While it is nice that this is human written, the seo format is nearly as annoying as those ai articles.
journal 6mo ago
idk, maybe the youtube algorithm just gets people to click on the video, what do they care why a video is clicked on as long as it generates revenue. so when they talk about videos being useful, take that to the bank.
drzaiusx11 6mo ago
I am not a game developer (I've made a few in the past but didn't use any frameworks besides direct libsdl calls), but if this article rings true for anyone in that field I'm a bit surprised things as basic as properties, structs and tuples are "not used" by unity devs, this is some basic stuff that has been supported even by Mono for decades. Just basic syntactic sugar though, so not a big deal either way. Just surprising to me at least.
tancop 6mo ago
c# 14 added field backed properties where you dont need that `_health` in the first place you just write `public int Health { get => field; set => field = Mathf.Clamp(value, 0, 100)`. that way you never accidentally use the internal field without the checks. problem is unity still stuck on c# 9.0 so it might be years before you can actually use this in a game
brainwipe 6mo ago
I code modern C# during the day and Unity for fun and I found this a really good roundup. It's also worth noting that Unity does all sorts of OO-breaking filth before passing to IL2CPP.
Fred27 6mo ago
As a primarily C# developer who has done some game engine work, I recently gave Godot a go for licensing reasons. Apart from some quirkiness I'm fairly impressed. Much nicer C# support compared to Unity. I've done a fair bit of Unreal C++ but to be honest unless you really need the performance that's just too much hard work. Having said that getting the code working properly with a nice 3D UI is my priority, not having a slick game with some code doing some mundane stuff in the background.
- rustyhancock 6mo ago
  I can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.
  - AppleBananaPie 6mo ago
    Never worked with it myself but I've always heard the people who do describe it as Unreal c++ because to them it's completely different than regular c++ and this must be one of the reasons why
    - PacificSpecific 6mo ago
      That's pretty much correct. I kind of have to switch to "unreal c++" context whenever I'm working in it. They have their own standard library etc
      - rustyhancock 6mo ago
        Don't forget if you make the editor access a nullptr it'll probably crash and take out any unsaved changes to blueprints!
  - Fred27 6mo ago
    I agree. I came to Unreal with only a basic level of C++. Having Unreal handle memory management for you was useful, but I can imagine the chaos an Unreal-only C++ developer might cause when unleashed on another C++ codebase.
ethin 6mo ago
I prefer Godot over Unity honestly. Not just because the engine feels better but because it's accessible, which is what matters to me. Unity isn't and probably never will be, so meh. Sure you can make accessible games in it but the editor itself isn't accessible so it kinda defeats the point of being able to make accessible games in it in the first place. And don't even get me started on Unity's licensing model. Godot's superior C# support is, IMO, just a cherry on top.
m_w_ 6mo ago
Some nice tips in here ([field: SerializeField] for example) - but as others note, it's not about modern code, as many of these features have been available for an embarrassingly long time. It's always felt to me that there's some fundamental friction between idiomatic C# and Unity. I remember, after reading about new features C# 8.0, someone wrote that C# 9 would write all your code for you, and that C# 10 would just mail you a check every month. How the times have changed...
- doctorpangloss 6mo ago
  game development for steam and mobile audiences became so inaccessible due to Unity, iOS and Android's complexity & evolution, a lot of "game" development was programmers engaging in an intellectually curious but otherwise meaningless engine-twiddling circle jerk of sorts. people with good game ideas were not necessarily able to tackle the complexity of those engines - and, based on how bad the games on Roblox are, they aren't using alternative platforms either. they just have had to spend an incredible amount of time to develop something. for everyone else, there is already basically zero audience for most games, so we're going to have heard about, "I made a Rust ECS game engine that runs on a Wiimote" or whatever, because there's an audience for blog posts on hacker news. then claude code swung everything back in the other direction. things are accessible again. does any of what the article says matter anymore? games are the ultimate, "if it looks good and works correctly, it is good" software product, nobody is going to care if you use [field: SerializeField] or records or whatever. so yeah, will Claude Opus 6 mail you a check every month? who even needs Unity?
  - jayd16 6mo ago
    What a strange take. Self publishing stores and cheap capable engines make things less accessible? I think you're saying this is because its hard to stand out with game design? But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?
    - doctorpangloss 6mo ago
      This isn't complicated. We're reading a post about engineering. Why? Why aren't we reading posts about game design? Why does engineering even matter for games? The status quo is, if you are good at engineering, you can ship games, even if they're bad. If you're good at game design and bad at engineering, before Claude code, you will not ship any games. So engineering mattered back then. Unity is very hard to use. If you want to make a game on Steam or iOS or whatever you need to know a lot of engineering. Okay, now you don't. Claude code can engineer for you. Now game designers can ship games. Do C# features matter to them? No. So does it matter for shipping games anymore? No. Will this help them make money or get distribution? Time will tell. Very different questions. It is a CERTAINTY that you don't need the developers as much anymore. If Steam had an easy way to turn photoshop files or board games into product SKUs, it would also be a different story. It doesn't. The App Store doesn't. The Switch doesn't. Are you getting it? They are still really complex to deploy for. Unity is hard to use. We put up with engineering stories because it was meaningful. Now it's not so much anymore. Now it's, what helps GAME DESIGNERS ship games? C# features? Not anymore.
Surac 6mo ago
I started using .Net with 2.0, learned the api and framework and was very happy with all the functions. i never had the need to switch to the more idiomatic idoms. Sometimes on the go i picked up some new tricks and adopted some new types. Form me a good programmer knows how to avoid cognitive overload and how things work under the hood. Why use LINQ when i can use a foreach or a hashmap. Most of the time people don't understand how i get so much performance out of C#, then i tell them KISS. And know your type system.

78 points by hacker_13 6mo ago

weli 6mo ago

A lot of game devs are terrible programmers. A friend of mine 10 years ago asked me for help with his Unity project. He is not a tech savvy person but we both took programming in high school, enough for him to make small games with a lot of tutorials and stack overflow. His codebase was horrible, a lot of logic that I would have already though of abstracting away. For example saving dialogs on json files and the conditions for that dialog to trigger for that NPC as some sort of finite state machine that can be represented with a series of sequential flags. He had a single file that was about 15k lines full of `if (condition && condition) || (condition && condition)` statements. He didn't seem to see the issue, it just worked. That's when I understood some people just care about game development and doing cool stuff and don't care at all about programming, good practices or structured code. And that's perfectly fine.

kdheiwns 6mo ago
Most indie game dev projects start as some small weekend project just to feel things out. Then it starts to become fun so we work on it another week. Then after a couple months we start to think that maybe the game has potential. Then we're 5 years into a project and have no clue how we got there. It becomes a giant jenga tower where moving any one block can completely collapse the whole project, so we learn the hard way that nobody should ever refactor. Pretty much the only people who do refactor end up restarting their project from scratch, getting frustrated because they can't capture their original feel of the game, then ultimately abandon the project entirely. And for professional game dev projects, it's all built on a foundation of some scrappy little indie project from decades ago. Some industries are all about making their code public and making it super clean and polished as a point of pride. Games, like movies and sausage, are disgusting to see behind the scenes. They're just piles of scraps and weird tricks that look great unless you get down and examine it too closely. And most people aren't looking that closely, so wasting that time and effort is pointless.
grebc 6mo ago
I’ve met plenty of these types in enterprise jobs too.
chrysoprace 6mo ago
Since it's a multi-discipline craft it's hard to get good at every aspect for indie development, focusing most of the effort on one or two aspects. I think the programming aspect for indie games typically matters very little unless it hurts performance or causes bugs, and the things the user interacts with end up mattering a lot more. Every web developer I've met has specialised in one area or another, even if they claim the title of "Full Stack".
- Sharlin 6mo ago
  Problem is that this kind of code often is brittle, full of bugs and unhandled edge cases, and evolution and maintenance is horror. But if it’s all you know you might never question it.
  - chrysoprace 6mo ago
    Often but not always, and if they're a solo developer then maintenance might not be too bad as they might be able to keep all the logic in their head. I'm not advocating for that kind of approach, but if it lets people focus on things that the player will actually notice like the gameplay, graphics, sound, story or art then hey, what's a little shortcut?
  - ablob 6mo ago
    A game is finished at some point. You might not need to evolve the code any further. Why optimize for a use-case that rarely applies to indie-games?
999900000999 6mo ago
If you’re a solo developer, if it works. I’ve seen worse in enterprise shops and then I’ve gotten into nasty arguments with people who don’t care about programming. They can’t be wrong. C# is a high level language that can handle a degree of sloppy programming. I was working on a small tool yesterday. It was easier to vibe code it from scratch in C# than to modify an existing Rust project. The only weird part is VS Code Copilot couldn’t figure out how to build it via the dotnet cli and I had to install VS Studio. After that everything was fine.
- orthoxerox 6mo ago
  I would say that C# is "less colored" than Rust. Handling a moved argument, a borrowed argument, a copied argument is different in Rust, you have to think upfront about memory lifetimes. If you are wrong the first time, changing the ownership is not a simple localized refactoring.
  - 999900000999 6mo ago
    To be 100% fair, it’s much easier for llms to start new projects and Rust is simply a more difficult language. I have what I need working in C#, and as a C# developer I actually understand what’s going on. The only downside is now instead of having a portable Rust project, I have something which heavily leans into Windows APIs. I assume with high level languages some smart people figured out all the memory stuff.
vhab 6mo ago
This goes for devs in all industries, it's not a problem unique to games. If anything, the most competent developers in terms of getting the most performance out of hardware are game developers.
- deleted 6mo ago
  [deleted]
captainbland 6mo ago
I think as a solo developer there's actually a good argument for increasing code density and coupling (things which in large multi developer projects are seen as spaghetti), as it can help you keep a lot of that code in mental and visual context at one time. It loses flexibility and readability for others, but you don't usually have enough time to concern yourself with such flexibility if you're working on a project by yourself, and you're not concerned about onboarding other developers and having them understand your code. The upshot is then that as a single person "bad code" is often highly effective code, and "clean code" is expensive code that buys you a lot of stuff you don't need or want. I say this as a boring enterprise developer who at work is highly concerned with appropriate abstractions etc. imo there's no universally good approach, what is optimal is context dependent. Although there are some core features of code like consistency and strong conventions which are fairly universally helpful, this represents a small fraction of best practices.
- grebc 6mo ago
  This is pretty anti-thetical to most good practices but the older and more experienced I get the more(13 years as a C# dev) I think copy & pasting sections of code is wayyyyyy more appropriate than extracting into a method/class/library or other forms of abstraction. Everything starts out with good intentions when someone comes along and says “hey you could make that an abstraction” and I just clench my jaw because I’ve seen that happen so much and then that simple clean abstraction eventually ends up being a horrible 1000 line monster that barely anyone understands and no one wants to change.
  - tranceylc 6mo ago
    I agree with everything except for it being anti-thetical to good practice. I have noticed a lot of experienced devs agree with that sentiment. It has been a pretty common trend for the last few years of people breaking out of the “OOP style programming” and practices they were taught at university. I am not saying avoiding things like over abstraction is new, but I do think there is a newer generation of programmers who have been taught and warned about drawbacks from practices like that. Similarly, my anecdotal experience tells me more newer game devs are aware of basic memory practices being better than overly complex OOP code. Think flat arrays and simple cache alignment over something abstract and over engineered
jrecursive 6mo ago
Gamedev at a high level is similar in spirit to distributed systems or compilers in that it's intensely multi-disciplinary with hard constraints. In gamedev you have a main thread that you're always sweating about submilliseconds, especially with worker threads interfering with it. Processor, memory, bus characteristics, GPUs, cooling, etc. all matter. This leads to e.g., everyday AoS vs. SoA, pooling and burst compile, to the classic fast inverse square root because of hardware at the time. Relentless optimization of hot paths produces code that's about performance, not abstraction. Then there's shaders, which are effectively a different programming model targeting different hardware entirely. Now add support for multiple operating systems, consoles, whatever. The list goes on. Now, all of that doesn't obviate the value of design and craft, so I don't agree that it's "perfectly fine". There are plenty of programmers weak on these two axes in most any domain, but it's worth noting gamedev is a special case that significantly distorts what good code, or at least good-enough code, looks like. Games start as little experiments and end up as Frankensteins. This is their nature; you're more sculpting a thing by building it and experiencing it rather than designing it a priori with systemic elegance in mind.
- rcxdude 6mo ago
  And that first bit only really matters if you're making a fast-paced game with sophisticated graphics. Most indie games can get away with horribly inefficient code.
groundzeros2015 6mo ago
I don’t see the issue. Real software problems are when the logical model is insufficient for the given problem.
Latty 6mo ago
To be a bit more charitable: I'd say that generally games involve a lot more special-casing than most code, and more planned out scripts (in the movie sense) of things happening, which tend to be antithetical to good coding practice, and encourage spaghetti, which begets more. In my experience, games that are procedural tend to be much cleaner code-wise, because they tend to fit the model of cleaner code better. I think game engine tooling tends to encourage bad code too, lots of game engine make it hard to do everything in code, rather things are special cased through UIs or magic in the engine, which means you often can't use all the normal language features, and have to do things in awkward ways to fit the tooling. Of course, this varies a lot by engine.
- skeeter2020 6mo ago
  IME you have so little reuse, and ship on a fixed schedule regardless of code quality & bugs this really isn't as critical as software built with the intent of lasting a long time & evolving. The games I've worked on (in hindsight) feel a lot like "vibe-coded without AI".
WhereIsTheTruth 6mo ago
It's an indication that programming languages are the wrong abstraction for creative work
leloctai 6mo ago
The other day a professional gamedev was arguing with me that's Transform.GetChild to get a reference to a component was not a bad practice. His argument is that it's what every other firms in his area is also doing. I do hope that was not the truth and he was just trying to win the argument. For solo hobby dev it is a lot more acceptable. After all they're also terrible 3d modeler, concept artist, musician, writer, marketeer, community manager,...
- MattRix 6mo ago
  I mean it’s not that bad of a practice, it depends on the context.
- PacificSpecific 6mo ago
  Based on your comment it sounds like you have a personal problem with that person which compromises your argument
wheybags 6mo ago
Something I've noticed about software dev vs game design: software is better (easier to read, understand, maintain, etc) when you have clean, separated modules. Game design is better (more fun) when everything is connected (eg in an fps, everything relates to gunplay, damage systems, environmental destruction, in a building game, everything relates to building, the building ui, inventory, resources etc). I think this mismatch shows up in game code. Combine that with actual hard performance constraints, and if you're a "normal" software dev casually browsing some game code, it can be shocking (eg Celeste movement code: https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs https://github.com/NoelFB/Celeste/blob/master/Source/Player/...).
badsectoracula 6mo ago
FWIW sometimes when making games it helps to have everything in one place, even though later you may want to split things up for later projects :-P so sometimes you get big balls of mud with lots of checks everywhere for the actions you want. As an example, most of the gameplay logic for Post Apocalyptic Petra[0] (a 3D platformer/adventure/riddle solving game i made for an MSDOS game jam a few years ago) is in the entity class for the player character[1] - including things like collisions, etc :-P. It is a bit hacky, but it works. Though if i ever made that sequel i wanted to where i want to have an extra character following you around, i'd need to move a bunch of things to other more generic places so that they can be shared by both the player character and the AI. [0] https://bad-sector.itch.io/post-apocalyptic-petra https://bad-sector.itch.io/post-apocalyptic-petra [1] https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o/Game/EPetra.pas https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o...
jayd16 6mo ago
Solo dev also just doesn't need a lot of abstraction. You're adding a lot of noise for what sounds like zero benefit to developer and especially not the player. Game dev is also a lot more agile than other projects. Solidifying structure is just more to rip up later unless you really know what you want to ship.
PacificSpecific 6mo ago
You think that's bad. Wait until you see some non game developer coders (I'm being sarcastic of course. The comment I'm replying to is incredibly naive).
slopinthebag 6mo ago
It's also because gamedev is very highly iterative, so if you're abstracting stuff you end up throwing away your abstractions when things inevitably change. And that costs more than just changing some if statements.

tryfinally 6mo ago

Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc. [0]: https://github.com/Cysharp/ZLinq https://github.com/Cysharp/ZLinq

drzaiusx11 6mo ago
Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)
- tryfinally 6mo ago
  The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.
  - drzaiusx11 6mo ago
    I assume it's not a black box anymore, but maybe that's a non-free lang extension? I had assumed linq was part of .net core these days, but I haven't gotten around to checking (10+ years since I've had a serious .net project)
    - pjmlp 6mo ago
      LINQ has always been around since it was introduced, the only non-free language extension in .NET were contracts that required VS Enterprise license.
- WorldMaker 6mo ago
  Most .NET projects that Linq originally targeted ran in so called "Server" and/or "Workstation" GCs (.NET has had very generic public names for its GCs for a long time which were also somewhat misnomers because even some Desktop apps would run in "Server" GC and it was possible for vice versa [0]) where allocations were cheap, garbage collection was relatively cheap (because both GCs were multi-generational, had strong [but different] tuning for their generations, etc). Unity inherited a much simpler Boehm GC from Mono. Under a (single generation) Boehm GC allocations are a bit more expensive and garbage collection sometimes a lot more expensive. (A Boehm GC was much easier for C++ engine code to understand/interact with, which is also part of why the .NET modernization project for Unity got so complicated and still has such a ways to go left.) [0] Fun aside: in fact, modern docker advice for .NET is to switch "server applications" to use "Workstation GC" if you need to stack multiple containers on the same host because of differences in expected memory usage.

DarkNova6 6mo ago

What C# version does Unity currently support? 2024 I chose Godot over Unity due to its better C# support and I can’t say that I came to regret my decision.

tryfinally 6mo ago
C# 9, but with some hacks you can bump it up to C# 10 - actually works and surprisingly stable. Can't wait for them to finally migrate to CoreCLR, though.
- moron4hire 6mo ago
  I got out of doing Unity development 7 years ago because I was tired of waiting for them to migrate to CoreCLR (among many other reasons).
  - pjmlp 6mo ago
    Unfortunately the way they managed to stick with MonoRuntime and Burst, kind of made more harm than good, regarding C# adoption on the games industry. Many issues people associate with C#, are actually only relevant in Unity, because of this.
drzaiusx11 6mo ago
Iirc the lineage of their c# came from Mono, then diverged a bit over time. Hopefully they can leave that baggage behind and just use the newer .net core, if they're not already that is... Disclaimer: I haven't looked in half a decade

raincole 6mo ago

Unity's C# has always felt like C#'s mentally challenged cousin. C-not-so-sharp. The custom == convinced me that allowing operator overloading on built-in operators is one big mistake.

orphea 6mo ago
Many tools can be misused. Object.Member can throw a NRE, is it a big mistake to have the dot operator?
- raincole 6mo ago
  It's such a weird question. Yes, "dot operator can throw a NRE" is of course a big mistake. A billion-dollar mistake, you can even say.
  - orphea 6mo ago
    No, I'm not asking if "dot operator can throw a NRE" is a mistake; I'm asking if the dot operator, the ability to access members at all, is a mistake.
    - WorldMaker 6mo ago
      One take on it is that yes, the single dot operator was an ancient mistake which is why so many programming language features are about making it smarter. Properties as mentioned in this article are an ancient way to fake the dot operator into a "field" but actually make method calls. Modern C# also picked up the question dot operator (?.) for safer null traversal and the exclamation dot operator (!. aka the "damnit operator" or "I think I know what I'm doing operator") for even less safe null traversal.
kbolino 6mo ago
For those wondering, Unity overloaded the == operator in two specific situations, such that obj == null will return true even though obj is not actually null. More details on this archived blogpost: https://web.archive.org/web/20140519040926/https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/ https://web.archive.org/web/20140519040926/https://blogs.uni...

shevy-java 6mo ago

> The Unity engine has evolved a lot in modern days, but I noticed a trend where Unity developers are still using "outdated" techniques when writing their C# code. Some years ago I tried to get into C# + Mono. Eventually I opted for Java instead, for many reasons; I'll skip that here. C# is very strange to me. In a way I feel that C# belongs like Java in the same "post C++" family; C kind of paved the way, C++ was messy and powerful, so Java and C# would be more "managable". But I never got into C#. Java is not a pretty language, it is also quite boring, but modern Java is somewhat acceptable - you get the job done. And it is not an extremely difficult language either for the most part, just with an addiction on pointless verbosity. C# is ... strange though. TIOBE has it ranked #5 right below Java, so there must be many C# users, but I don't get to see them really in the Linux ecosystem. So where are these people all? Using Windows only? When the question is "most developers don't use feature xyz", do all of them actually KNOW these features? You can still find many java tutorial where people use archaic ways to, for instance, iterate over a collection. Perhaps it is similar to the C# ecosystem, people are slow to adopt. Or, and this may also be a reason, people could have moved to other languages. This may not be a huge percentage, but you see that some languages suddenly struggle with old devs and failing to get new devs (ruby is in this problem right now; it may overcome it but right now it is sinking hard, even though I would reason that the language is, for the most part, better than it was in, say, 2010).

ablob 6mo ago
C# has had the reputation of not being viable for Linux for a long time. Therefore, the people already on Linux didn't have a reason to use it or even try it. If you're already doing stuff in other languages it's hardly worth it to switch to C#. I personally use it quite a lot - but I came as a windows user writing all my utilities in C#. Also, afaik C# is mostly used in corporate environments that don't open-source their projects. You're unlikely to hear from it unless you're working on it for this very reason.
- drzaiusx11 6mo ago
  Mono was in a usable state on Linux for literal decades before becoming official and integrated into what is core today, that is unless you needed windows forms, which much like MSFT UI frameworks today had multiple failed attempts spanning those same decades...

coinfused 6mo ago

Looking forward to when Unity will migrate to CoreCLR. Soon! https://www.youtube.com/watch?v=_t6xVfrmEWU https://www.youtube.com/watch?v=_t6xVfrmEWU

pjmlp 6mo ago
That soon is like a decade in the making. And with many folks going into alternatives like Godot, it means C# ends up losing the mindshare it got. Yes, you can use C# with Godot, but most folks end up with GDScript, or GDextension.
- drzaiusx11 6mo ago
  Iirc Godot is taking the approach from both sides however and also working on a libgodot which will allow a "bring your own runtime" which I'm much more interested in than the integrated "environments" that are Unity and Godot today. I'm likely in the minority though as they only started making a library export after the all in one environment was stable enough...
- enbugger 6mo ago
  Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.
  - pjmlp 6mo ago
    I agree, however most indies don't need them, and most pros are getting into Unreal instead. Also something like Burst is a workaround for using Mono with C#, which gets solved in Godot with C++. How's the whole DOTS adoption going?
    - enbugger 6mo ago
      >gets solved in Godot with C++ if only by rewriting half of the Godot codebase. With design choices they made, Godot will never be performant enough for RTS/Crown simulation games. https://github.com/godotengine/godot/issues/101494 https://github.com/godotengine/godot/issues/101494 >How's the whole DOTS adoption going? I'm quite impressed to what people build on top of it: https://github.com/Dreaming381/Latios-Framework https://github.com/Dreaming381/Latios-Framework https://assetstore.unity.com/packages/tools/animation/mesh-animator-animate-massive-crowds-26009 https://assetstore.unity.com/packages/tools/animation/mesh-a... and many more

everyone 6mo ago

I'm a very experienced Unity C# programmer, and I certainly don't equate "good" with using all the new fancy features of a language. Fancy features are less maintainable imo. Less programmers will know about them and they're less likely to have equivalents in other languages. Making something more exotic / confusing / hard to parse is defo not worth saving a few lines of code.. I'd much rather see a longer function using absolute bog standard elements of the language (and thus being clear, easy to comprehend for everyone, easy to modify at any point) rather than a super short, super "elegant", super "clever" solution.

drzaiusx11 6mo ago
Languages that seem to indefinitely grow more features over time (like c++, c#, rust, etc) evitably become bucketed by epochs unless the consuming application code also operate across the same time scales. Feature deprecations tend to go hand in hand with newer features, leaving you with basically "multiple sublanguages" in a supposed single language, exacerbating fragmentation of the community. I don't want to have the mental load of contextually understanding "which" sublanguages I need to care about depending on the year a consuming application was written. This is why I tend not to reach for new fangled features and stay with the core runtime stuff in evergreen langs.
jayd16 6mo ago
I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc. Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach. New doesn't mean good but a lot of these are new and good.
- everyone 6mo ago
  I disagree about LINQ. You can easily do the same job in a little function with only stuff people learn in week 1 of programming, just for and if else and arrays. It's very clear precisely what's happening in this case, and its easy to alter. (Everyone is gonna know that stuff, not everyone is gonna be using LINQ regularly enough to understand it completely) LINQ on the other hand is like another language entirely, awkwardly squished into your C#, reminds me of SQL code inside a big string inside another language's code. It's also not clear what it's actually doing which can be death for performance in games as LINQ usually allocates shittonnes of new stuff. (I'm certainly not advocating for premature optimisation, but I defo am advocating for knowing precisely what you are writing) The benefit of LINQ is that its a bit faster to write compared to a little function, but length-of-time-it-takes-to-actually-write-code is very rarely an important constraint in my experience.

deleted 6mo ago

[deleted]

moron4hire 6mo ago

Game developers are not paid to be good developers. They're paid to be young, naive, and easily brow-beat into working unpaid overtime. I think one of my biggest problems with Unity is that it enabled a massive market of me-too "business men" who "employ" unpaid and underpaid interns to hack together asset-store-ware they then dump on the app stores. When a gem game stutters, people blame their crappy phones rather than the company who probably stiffed its developers. I've seen a lot of my friends do this constant churn of signing up for the next game shop that will hire them. Places that throw many, many red flags the second you even walk in the door. They work hard to get a game done on a budget 1/10th what it should be, the game ends up being a flop, and they never get a chance to grow their portfolio or skills to eventually get a better job. This isn't something you can lay at the feet of Unity Technologies, but I do think it is a reason to avoid Unity: the job ecosystem is just awful.

jayd16 6mo ago
Why wouldn't a released game grow their portfolio?

leloctai 6mo ago

Doesn't hn clean article titles? This is a classic click baity one. Most of these are just basic features. Some are unused for good reason. - Property: the inspector doesn't call your getter or setter. I do use them still because i like to centralize my validation logic. But need custom machinery to make them behave consistently. - Tuple: well-known. Good but only in moderation. - Linq: people avoid it due to allocations, not runtime. While it is possible to avoid dynamic alloc, it is not obvious and best avoided. Also the point about the linq syntax being "cleaner" is debatable. - Record: good. Lesser known as it's the newest in the article. No footguns like the other. While it is nice that this is human written, the seo format is nearly as annoying as those ai articles.

journal 6mo ago

idk, maybe the youtube algorithm just gets people to click on the video, what do they care why a video is clicked on as long as it generates revenue. so when they talk about videos being useful, take that to the bank.

drzaiusx11 6mo ago

I am not a game developer (I've made a few in the past but didn't use any frameworks besides direct libsdl calls), but if this article rings true for anyone in that field I'm a bit surprised things as basic as properties, structs and tuples are "not used" by unity devs, this is some basic stuff that has been supported even by Mono for decades. Just basic syntactic sugar though, so not a big deal either way. Just surprising to me at least.

tancop 6mo ago

c# 14 added field backed properties where you dont need that `_health` in the first place you just write `public int Health { get => field; set => field = Mathf.Clamp(value, 0, 100)`. that way you never accidentally use the internal field without the checks. problem is unity still stuck on c# 9.0 so it might be years before you can actually use this in a game

brainwipe 6mo ago

I code modern C# during the day and Unity for fun and I found this a really good roundup. It's also worth noting that Unity does all sorts of OO-breaking filth before passing to IL2CPP.

Fred27 6mo ago

As a primarily C# developer who has done some game engine work, I recently gave Godot a go for licensing reasons. Apart from some quirkiness I'm fairly impressed. Much nicer C# support compared to Unity. I've done a fair bit of Unreal C++ but to be honest unless you really need the performance that's just too much hard work. Having said that getting the code working properly with a nice 3D UI is my priority, not having a slick game with some code doing some mundane stuff in the background.

rustyhancock 6mo ago
I can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.
- AppleBananaPie 6mo ago
  Never worked with it myself but I've always heard the people who do describe it as Unreal c++ because to them it's completely different than regular c++ and this must be one of the reasons why
  - PacificSpecific 6mo ago
    That's pretty much correct. I kind of have to switch to "unreal c++" context whenever I'm working in it. They have their own standard library etc
    - rustyhancock 6mo ago
      Don't forget if you make the editor access a nullptr it'll probably crash and take out any unsaved changes to blueprints!
- Fred27 6mo ago
  I agree. I came to Unreal with only a basic level of C++. Having Unreal handle memory management for you was useful, but I can imagine the chaos an Unreal-only C++ developer might cause when unleashed on another C++ codebase.

ethin 6mo ago

I prefer Godot over Unity honestly. Not just because the engine feels better but because it's accessible, which is what matters to me. Unity isn't and probably never will be, so meh. Sure you can make accessible games in it but the editor itself isn't accessible so it kinda defeats the point of being able to make accessible games in it in the first place. And don't even get me started on Unity's licensing model. Godot's superior C# support is, IMO, just a cherry on top.

m_w_ 6mo ago

Some nice tips in here ([field: SerializeField] for example) - but as others note, it's not about modern code, as many of these features have been available for an embarrassingly long time. It's always felt to me that there's some fundamental friction between idiomatic C# and Unity. I remember, after reading about new features C# 8.0, someone wrote that C# 9 would write all your code for you, and that C# 10 would just mail you a check every month. How the times have changed...

doctorpangloss 6mo ago
game development for steam and mobile audiences became so inaccessible due to Unity, iOS and Android's complexity & evolution, a lot of "game" development was programmers engaging in an intellectually curious but otherwise meaningless engine-twiddling circle jerk of sorts. people with good game ideas were not necessarily able to tackle the complexity of those engines - and, based on how bad the games on Roblox are, they aren't using alternative platforms either. they just have had to spend an incredible amount of time to develop something. for everyone else, there is already basically zero audience for most games, so we're going to have heard about, "I made a Rust ECS game engine that runs on a Wiimote" or whatever, because there's an audience for blog posts on hacker news. then claude code swung everything back in the other direction. things are accessible again. does any of what the article says matter anymore? games are the ultimate, "if it looks good and works correctly, it is good" software product, nobody is going to care if you use [field: SerializeField] or records or whatever. so yeah, will Claude Opus 6 mail you a check every month? who even needs Unity?
- jayd16 6mo ago
  What a strange take. Self publishing stores and cheap capable engines make things less accessible? I think you're saying this is because its hard to stand out with game design? But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?
  - doctorpangloss 6mo ago
    This isn't complicated. We're reading a post about engineering. Why? Why aren't we reading posts about game design? Why does engineering even matter for games? The status quo is, if you are good at engineering, you can ship games, even if they're bad. If you're good at game design and bad at engineering, before Claude code, you will not ship any games. So engineering mattered back then. Unity is very hard to use. If you want to make a game on Steam or iOS or whatever you need to know a lot of engineering. Okay, now you don't. Claude code can engineer for you. Now game designers can ship games. Do C# features matter to them? No. So does it matter for shipping games anymore? No. Will this help them make money or get distribution? Time will tell. Very different questions. It is a CERTAINTY that you don't need the developers as much anymore. If Steam had an easy way to turn photoshop files or board games into product SKUs, it would also be a different story. It doesn't. The App Store doesn't. The Switch doesn't. Are you getting it? They are still really complex to deploy for. Unity is hard to use. We put up with engineering stories because it was meaningful. Now it's not so much anymore. Now it's, what helps GAME DESIGNERS ship games? C# features? Not anymore.

Surac 6mo ago

I started using .Net with 2.0, learned the api and framework and was very happy with all the functions. i never had the need to switch to the more idiomatic idoms. Sometimes on the go i picked up some new tricks and adopted some new types. Form me a good programmer knows how to avoid cognitive overload and how things work under the hood. Why use LINQ when i can use a foreach or a hashmap. Most of the time people don't understand how i get so much performance out of C#, then i tell them KISS. And know your type system.