/tech/ - Technology

If you're asking this question then it literally doesn't matter. Pick the engine whose logo you like most and use whatever it uses.

>>17389
>If you're asking this question
I'm not. It's already been decided, but I'm still interested in the topic in general.

>>17393
C++ and C# live in different headspaces.

C++ is designed for manipulating data which is the most fundamental job of a computer. It's a very ugly language that carries tons of historical slime, but it's never going to die because of how powerful and versatile and lax it is and because no new language dares to compete with it at the same level. Also most high-performance libraries and OS APIs and whatnot are written in C which is basically the same language except with less features, so you can just lift C libraries/code directly into your C++ codebase.

C# is designed for soulless corporations who want to hire disposable code monkeys and not have them blow things up too badly. I wouldn't call it a bad language, but as a garbage collected object-oriented language it kind of leads you astray and discourages you from learning some things that you should learn if you want to become a good programmer. It's good when there's a big disconnect (communication + skill level) between who created the thing (engine dev) and who uses the thing (You), but it doesn't help prevent incorrect code, it just makes the explosion smaller. A crash is a crash, if there's no risk of hackers or something then it doesn't matter what language crashed. You CAN turn C++ into something similar, but it's way more of a "do whatever you want with your computer, kid" language.

Lua is designed by and for retards who can't learn to program and who hate you and everyone else and want it's users and anyone who interacts with said user to suffer as much as possible.

>>17394
Yes, from what I've been reading, I understand the appeal of C++. It is very performant and enables more interaction with the machine, which is why it's been a staple of gaming. 

>but it's never going to die because of how powerful and versatile and lax it is and because no new language dares to compete with it at the same level
I've been reading a a little about Rust and it seems like it's the one trying to portray itself as doing this, but I don't think it will. Around the web, Rust hasn't been having a good track record with game dev because it's unnecessarily complicated, which slows down productivity and some issues with compiler performance. I thought this was funny, because it seemed exactly what I had expected, learning a little bit about what Rust is and it's definitely not the end-all that its proponents claim. Just from how it's described, I would imagine it to be antithetical to game dev. 

>C# is designed for soulless corporations who want to hire disposable code monkeys and not have them blow things up too badly. I wouldn't call it a bad language, but as a garbage collected object-oriented language it kind of leads you astray and discourages you from learning some things that you should learn if you want to become a good programmer. It's good when there's a big disconnect (communication + skill level) between who created the thing (engine dev) and who uses the thing (You), but it doesn't help prevent incorrect code, it just makes the explosion smaller. A crash is a crash, if there's no risk of hackers or something then it doesn't matter what language crashed. You CAN turn C++ into something similar, but it's way more of a "do whatever you want with your computer, kid" language.
And this brings us here. From what little I've parsed, I think C# is a good language for what it's for. Decent performance, quick and adequate features. If I want to make a game, I want to be able to try ideas in a stable environment and be able to iterate them quickly and keep doing so. GC takes a lot of work of the hands of the dev so you can focus on the game, not to mention that it's easier to make it stable. C# continues to get better and I think it is a very good all-around choice for the task of game development. 

>Lua is designed by and for retards
This was my impression as well.

Of course, you are right that one should learn low-level things like manual memory management to become a better programmer, but I think productivity is the name of the game in this field.

>>17395
Rust isn't lax, though, I'm aware of that. I'm just saying it portrays itself as the immediate contender to C++.

>>17395
Rust only competes with C++ if you turn on unsafe mode, which is like saying that D competes with C++ if you turn off it's garbage collector. The language's major assumptions are baked into the language design and libraries and resources and community and whatever tool/engine uses it.

>GC takes a lot of work of the hands of the dev so you can focus on the game
And it's not just about GC and memory management, and the idea that GC only makes things easier only looks like that because you don't have to learn about memory. Sometimes it's actually easier to do a thing in a low level language (especially in a properly architected codebase) than it would be in a higher level language. When you need to actually put data somewhere and move it yourself, and when everything is made up of just data and functions, it makes you see the world in a different way, it teaches you how to keep things simple, and gives you a better understanding of what the computer has to do when you want to do something. In fact if your goal is to learn and not use the language, I'd recommend C even more than C++ because C guarantees that you don't go into a wrong direction.

The biggest problem with C++ (let alone C) is that using it effectively requires a lot of knowledge that doesn't come naturally. As an easy example, you should absolutely avoid using C-style (zero-terminated) strings, but you have to know to avoid them and how to do it easily. There's also memory management patterns that I consider essential, for example re-using slots in an array instead of allocating/deallocating objects, and using a temporary/scratch/arena allocator that lets you dump miscellaneous data (like formatted strings) into a big buffer and then reset it all at once later so you never have to call free() on whatever you allocated. I don't even know where you would learn all these things.

All that said, most of my high level language experience is in Javascript, I don't know how many of it's inconveniences are shared by C#. I don't think C# has pointers or anything equivalent, which makes certain things very annoying because you don't have control over the difference between copying an object/variable, and referring to it from somewhere else. OOP also encourages you to design objects that are hard to copy.

>>17394
>C#  [...] as a garbage collected [...] language
>>17397
>D competes with C++ if you turn off it's garbage collector
Point of order, there are (as you note, clunky and somewhat contrarian) ways of doing the same thing and manually managing memory in C#. Most notably for vidya development, the Burst compiler is commonly (ab)used in Unity for this exact purpose.
>Rust only competes with C++ if you turn on unsafe mode
Rust is explicitly designed with the assumption that most codebases must incorporate at least some unsafe code. The idea is instead that by distinguishing between them, it will be both easier to be cautious enough with unsafe code, and to become conscious of when seemingly necessary unsafe code ends up actually possible to refactor. This is much like the traditional gamedev practice of writing performance critical sections in ASM/C, while noncritical game logic is in some kind of script like the aforementioned Lua. Or for that matter...
>You CAN turn C++ into something similar
Aside from various handrolled additions, modern C++ is gaining features such as smart pointers.

>>17397
I know what you're saying and I am going to learn a language with manual memory either concurrently or after C#, probably C. All I know is that I like the C# ecosystem with what I've read about it. Stride is integrated into .NET. It can make games for Windows, Linux and Mobile and I can use MAUI to expand into mobile apps if I want. It seems like MS is pushing reasonably well for # to be a multi-platform language and that appeals to me.

>OOP also encourages you to design objects that are hard to copy.
I don't know much, but feel free to explain if you want. 

>>17398
>Point of order, there are (as you note, clunky and somewhat contrarian) ways of doing the same thing and manually managing memory in C#. Most notably for vidya development, the Burst compiler is commonly (ab)used in Unity for this exact purpose.
And I would also assume that writing less messy code will tax the garbage collector less? C# seems like it continues to be optimized and become more performant. I was reading about stuff like forced garbage collection and if a competitive game like Naraka: Bladepoint, that was made with Unity can have a thriving pro scene, there must be ways around the supposed performance spikes, because I never noticed any when I played it.

Another thing is that I think memory safety does have a place in game dev. I remember modding Fallout 4(hate that game, but wanted to mod something) and one of the mods was talking about how the LOD textures used way more memory than they were supposed to, which negatively impacted performance and the mod fixed that. The Creation Engine is written in C++, so I would assume that traces back to the pitfalls of manual memory management. I also recall reading about Cyberpunk 2077 performance (never played it, never will) and apparently that game had some performance issues, potentially due to a memory leak and RedEngine was primarily written in C++.

>>17398
>there are ways of doing the same thing and manually managing memory in C#
The problem with higher level languages is not always the language itself, and I don't think C# is inherently much "slower" than C++, and whatever the difference is doesn't matter for 99% of games. The bigger problem is that when the language hides the most absolute fundamental things about programming from you such as copying a struct, it trains you into the wrong kind of programmer and gives you a wrong idea about how things work and how you should do things. Copying a struct should be just a=b, you just set the data to another variable or into an array or where ever, but in C# you have to call a "method" b.MemberwiseClone() to do it. That method might very well be doing the exact same thing as a=b does in C++, but it's hiding this fact from you and making it look like you need to call some function or mysterious algorithm to copy whatever magical construct your "object" is, who knows where it lives and how, you're not supposed to know or think about it. It gets even more retarded in higher level languages like Javascript where people often do something like JSON.parse(JSON.stringify(b)) to copy an object. The problem is not that you have to type those words, it's that your understanding of what you're actually doing is obscured.

>assumption that most codebases must incorporate at least some unsafe code
>This is much like the traditional gamedev practice of writing performance critical sections in ASM/C
Performance is based on reality though, you optimize the path that your profiler shows to be very hot or take the most time. How do you know what to write in "safe" vs unsafe Rust? It sounds similar to "clean code" to me, people just say it arbitrarily because they heard someone say it, or in this case to deflect criticism of Rust.

>>17401
>in C# you have to call a "method" b.MemberwiseClone() to do it
No? Aren't structs value types in C#? You'd only have to do this for a class. That said, structs in C# are garbage, because they behave otherwise like objects (they can inherit and so on), so unless you're really careful about how you use them they might allocate memory anyway.

>>17399
>Linux
>I can use MAUI to expand into mobile apps
>MAUI
Lmao. MAUI was DOA, it was shipped in an unfinished state with lots of bugs, with no official Linux support, while Xamarin was deprecated by Microshaft.

OP, please don't use C#, for the love of god. Yes it has a lot of nice features and yes, the ecosystem is vast, but it locks you into shitty practices where none of the developer tools are truly free. They are full of telemetry and other crap. There's no proper free debugger. Nuget distributes your libraries in binary form. I could go on.

If you don't mind a garbage collector then take a look at D. It was even mentioned further up in this thread. It strikes a nice balance between high level and systems programming, and the metaprogramming and templates are god tier (but you don't need to care about this for now). For game dev you can use any graphics framework with C bindings. If you want to get into game development, I recommend starting out by writing your game from scratch instead of using an engine. Start with 2D, it's piss easy. You can use SDL for example, it's very easy to use, and there's tons of tutorials available online. Learn D or whatever other language you pick first, then start learning SDL or any other framework. You can use tutorials written in C once you know how to do things in your chosen language.

>>17402
>Aren't structs value types in C#?
In C++ structs and classes are basically the same so I had assumed they are in C# too, I've never made anything in C# so my knowledge of the details is surface-level. And turns out you CAN pass things by reference by using "ref". Maybe you can program in a C++-like way by using structs instead of classes and using ref.

>they behave otherwise like objects (they can inherit and so on), so unless you're really careful about how you use them they might allocate memory anyway.
A class is going to always allocate memory anyway, so I don't get your point.

>>17401
>The bigger problem is that when the language hides the most absolute fundamental things about programming from you
Don't mystify C too much. Far too many people act as though heaps, pages, malloc, etc., are real things that correspond to hardware instead of comfort abstractions peculiar to the C standard lib (and OSs that have grown and calcified around it). C is indeed lower level than many languages, but it does have its own idiom.
>How do you know what to write in "safe" vs unsafe Rust?
Anything that absolutely must use unsafe features, or that would be unacceptably slower without them. Aside from security, the intended benefit is so that when you have to track down the source of e.g., certain types of memory leak, your attention can be focused intensely on as little code as possible.
>It sounds similar to "clean code" to me
No. Perhaps a clearer analogy than performance tuning might be privilege separation. Think of how even when writing something like a large and complex device driver or OS, as little code as possible should actually touch hardware, run in kernelspace, have filesystem access, etc.

>>17402
>I recommend starting out by writing your game from scratch
Holy LOLs that is textbook anti-advice if taken at face value

To clarify a little. Becoming a decent developer should involve learning assembly, a lower level language such as C, and understanding a modern OS's internals, so writing throwaway toy projects is a reasonable way to do that. But that should IN NO WAY imply that the codebase resulting from "I want to write a vidyagaem" should progress directly from nand2tetris or whatever into a completely handrolled modern engine for your first SERIOUS REAL game.

Even if you end up using a precanned engine and do no actual coding, that basic knowledge of how software actually works will protect you from a ton of pitfalls, let you choose better tools more reliably, and give you the freedom to tweak things when necessary.

>>17405
There are no methods or objects or ownership or borrow checker in the CPU.

>>17406
Sure, but none of that exists after compilation in binaries nor any standard library it builds against.

>>17403
>A class is going to always allocate memory anyway, so I don't get your point.
As far as I understand, structs are stack-allocated classes in C#. Declaring one as a variable won't allocate anything by default, because it's on the stack. But as soon as you pass it as a generic parameter, by implementing an interface or extending another struct, it will magically become heap allocated. This becomes extra confusing since you can mix and match classes and structs by implementing the same interfaces, and call the same functions. Using them with inheritance becomes virtually useless from a performance standpoint. But not like it really matters since pretty much all the language features allocate anyway.

>>17405
>Becoming a decent developer should involve learning assembly
You have to start somewhere, but you need to pick a good middle point. There's no point learning assembly, because it's not relevant to your game development skills. The compiler will optimize your game for you, the only thing you need to do is minimize allocations and I/O. Everything else is irrelevant until you encounter a measurable slowdown. And at the other end, if you start using an engine, you won't learn any fundamentals, you'll just learn the engine instead. Tough luck if you find it doesn't suit your needs further down the line. Why bother with any of the things you listed if you can start right now by writing a simple 2D game loop without an engine, and learn everything as you go? It might even become decent code on the second or third rewrite.

>>17407
You might as well call Javascript a bare metal language with that attitude.

>>17402
>Lmao. MAUI was DOA, it was shipped in an unfinished state with lots of bugs, with no official Linux support, while Xamarin was deprecated by Microshaft.
Typical, but things do improve over time and it just got an update earlier this month and even in its rougher, earlier versions, some people made it work. 

>OP, please don't use C#, for the love of god. Yes it has a lot of nice features and yes, the ecosystem is vast, but it locks you into shitty practices where none of the developer tools are truly free. They are full of telemetry and other crap. There's no proper free debugger. Nuget distributes your libraries in binary form. I could go on.
Kek, I appreciate the concern and will listen to any, but nothing is perfect and I don't expect it to be. 

>If you don't mind a garbage collector then take a look at D. It was even mentioned further up in this thread. It strikes a nice balance between high level and systems programming, and the metaprogramming and templates are god tier (but you don't need to care about this for now). For game dev you can use any graphics framework with C bindings. If you want to get into game development, I recommend starting out by writing your game from scratch instead of using an engine. Start with 2D, it's piss easy. You can use SDL for example, it's very easy to use, and there's tons of tutorials available online. Learn D or whatever other language you pick first, then start learning SDL or any other framework. You can use tutorials written in C once you know how to do things in your chosen language.
I want a GC language. I want ease of use and productivity for game dev. I want to get shit done.   Not only is Stride scripted in C#, but the engine is written in C#, which means I'll have better proficiency at manipulating it.

>>17408 
>it's not relevant to your game development skills
Until you run into something like "what is the difference between a stack and register machine", "what is cache hierarchy" or "what format should my floats be in", where even a simple understanding of ASM will make life infinitely less confusing because you already know the answer to questions you wouldn't have known you need to ask yourself.
>It might even become decent code on the second or third rewrite
It might also be an siren song tarpit between /agdg/ foreverdev and actually finishing even a pretty simple modern 3D game.

>>17409
The difference is (e.g.) the GC in JS must exist at runtime, rather than being statically evaluated away at compile time.

>>17411
>GC in JS must exist at runtime
As a programmer typing letters, especially as a beginner, it doesn't make a difference. You're equally detached from what you're telling the computer to do.

The CPU doesn't have almost any of the features that higher level languages give you, the reason you should learn C is because when you use it you're forced to do mostly the same shit that the CPU does. You can "um ackchyually" all day about how the CPU actually does all kinds of things behind the scenes, but as far as the interface we have to interact with the CPU (the ISA) goes, all the CPU does is move and do operations on data. The only real "features" that exist on top of that are jumps (i.e. ifs/loops) and functions, and that's basically all you use in C. You could argue that structs don't exist in the CPU but then you're getting to a territory where it would be almost impossible to program anything sophisticated without that feature.

Things that are managed by the OS such as memory allocation don't count because it's impossible for a program to implement those to begin with, you can only call the OS API.

>>17412
>you can only call the OS API
Let's put it this way: If your lang's runtime requires GC, you're at the mercy of the entire world intermittently grinding to a halt in unpredictable ways. That's WAY MORE intrusive for a lot more applications than any of the antics the OS or the MMU get up to.

>>17413
I'm not sure if you're just sayin' or if you're locked onto this fucking performance shit that I've specifically been trying to avoid for every single reply I've made in this thread.

The problem is not the performance, the problem is that you're not learning to program properly because the language is hiding how the computer works from you.

>>17414
Ah, yes. In that case, I would say the architectural assumption in something such as Rust or Ada that unsafe allocation must be used even rarely, still makes them equivalent to C or Pascal requiring that dynamic allocation be used regularly, so far as demands on programmer knowledge are concerned. That is wholly different from something like Java or Go, where you simply can't do it.

That said, even programs simple enough to be written entirely in safe Rust won't be as hands-off as in a GC language.

This entire thread is full of bullshit.

>into programming and have been looking at what engines use what languages
Your core game logic takes up so little of the computation that it doesn't matter unless you're trying to implement features the engine does not already provide or you don't like the language you're supposed to write the game logic in.

>The differences that I've read between C++ and C# is that ++ is more performant
These languages have absolutely nothing in common.
C# is like Microsoft's Java. It is compiled to bytecode and runs in a virtual machine using GC.

>>17413
>If your lang's runtime requires GC, you're at the mercy of the entire world intermittently grinding to a halt in unpredictable ways
The predictability depends on the actual GC the language uses. It could make huge collection runs occasionally or small ones more often.
For most purposes it's irrelevant though. GC is just an advanced reference counter. Both GC and RC are used in basically every single desktop application out there despite most of them being written in C and C++.

Reference counting is when the structure you're allocating has an integer of how many things point to it and then when destroying pointers or references to it you also reduce the reference count visa verca and if it reaches 0 you free it. It's not fucking magic.

>>17416
Rust is similar to C++, not C. The standard library fully relies on C++-like features.
>Ada, Pascal
Are you trying to turn this thread into Reddit?

>unsafe allocation
All allocation is inherently "unsafe". Malloc takes a while and it can always fail. Even the stack can overflow.

>>17395
>It is very performant and enables more interaction with the machine, which is why it's been a staple of gaming.
Nigger, both are general purpose programming languages. They are both staples of everything. Yes they are staples of gaming. What does that even mean? And no, your game doesn't and shouldn't do any fucking "interactions with the machine". It should stick to game logic, graphics, input and audio.

>>17397
>Rust only competes with C++ if you turn on unsafe mode, which is like saying that D competes with C++ if you turn off it's garbage collector.
Rust, D and C++ all compete with each other. D's GC is optional and it has a BetterC subset for doing low level stuff, just like C++ has to rely on C or disable exception handling and whatever. Same with Rust.
They are all native-compiled high level multi-paradigm languages.

>>17422
>GC is just an advanced reference counter
Most languages with GC are also designed with the assumption that you'll be allocating everything all over the place. This is not part of GC directly, but it is indirectly.

As an example, in C# you can mutate and concatenate strings as you please without having to know or care how any of it happens or what the string variable even is. By comparison, string constants in C are in static storage, you can compare the equality of 2 string constants just by their pointer addresses.

>>17422
>Your core game logic takes up so little of the computation that it doesn't matter
Stalker Anomaly's scripts are fucking slow as shit and you can't fix or optimize any of it because they're made in Lua. There's no way you could implement half of that game's mechanics with nothing but Lua scripts.

>>17422
>GC is just an advanced reference counter
It should be obvious that we're talking about automatic GC, that's the part which imposes unpredictability. RC (like any GC) can be predictable if done manually, ARC has the same fundamental limitation as classic mark & sweep.
>Even the stack can overflow
Good point, though stack allocation is generally far less treacherous than heap.
>It should stick to game logic, graphics, input and audio.
Depends on how many weird low level platform features the engine hooks into, and even so, some core logic features (*cough* pathfinding *cough*) can bring high level scripting runtimes to their knees.

>>17422
>These languages have absolutely nothing in common.
Never said or implied they did, although every source says C# was influenced by the other C languages, among others like Java, as you said.  

>Yes they are staples of gaming. What does that even mean?
I get that C++ is one of the top 3 languages. I'm just saying that not everyone uses it and those that do or do not have reasons as to why. You could say Lua is kind of a staple of gaming than many other languages and I don't think that'd be wrong, even though it's a lesser used language. C is a general purpose, popular language, but is less used than C++, C# and Lua in game dev from what I've seen. 

I already stated I'm a noob and am interested in learning as I don't know much except for what I'm reading from others.

df2f5fa1640e8396aef47739aef2a9b018172c7f51733fbb8c7d93466d183b77.jpg
[Hide] (68.6KB, 640x896)

All I've come to understand from this exchange of 'tisms is that Yuzu > Ryujinx, supposedly.

>>17425
Constants are static storage in every language that has real constants. Has nothing to do with GC at all.

>>17426
What about World of Warcraft, Payday 2, Dota 2, Crysis?
No one ever complained about those using Lua. All the Valve games use a Lua knockoff language called Squirrel. Like Half Life, Portal, Counter Strike, you name it.
Squirrel has objects and stuff for convenience but it's much slower than LuaJIT. But guess what? They don't give a shit and no one ever complained.

>>17427
>that's the part which imposes unpredictability
That is simply untrue. D and Nim only run the GC when you do an allocation. So if your code contains no allocation GC will never run. Both also have very short collection pauses unlike most other languages.
Usually you can also trigger collection manually or stop the gc from collecting. (Both can be done in Lua for example)

Malloc itself isn't predictable if you want to be pedantic about it.

>>17428
>although every source says C# was influenced by the other C languages
They say a lot of shit. And I'm telling you NO. C# is a Java clone. It works the same as Java with a different syntactic sugar. Java has a lot of syntactic sugars itself that also run on JVM (Java, Kotlin, Scala, Groovy, and Clojure).
C# is a language that runs on .NET Common Language Runtime, a Microsoft VM that runs certain bytecode. CLR bytecode is made with languages like C#, F#, VB.NET. Yes modern Visual Basic is run with the same VM as your C# code. That makes them close friends. It does not make C++ and C# close friends. VB.NET, F# and C# all use the same underlying datastructure representation and types and you can easily pass datastructures from one language to the other natively.

>C is a general purpose, popular language, but is less used than C++, C# and Lua in game dev from what I've seen. 
I'm not even going to go into this. If you want to do game dev, you pick an engine and the engine will FORCE you to use a certain language. You don't get a choice.
Arguing about this is a waste of time.

>>17430
>Constants are static storage in every language that has real constants. Has nothing to do with GC at all.
Holy shit this site is populated by braindead zombies. Way to completely miss the point.

>>17437
Be precise and brief.

>>17430
>What about World of Warcraft, Payday 2, Dota 2, Crysis?
>No one ever complained about those using Lua. All the Valve games use a Lua knockoff language called Squirrel. Like Half Life, Portal, Counter Strike, you name it.
>Squirrel has objects and stuff for convenience but it's much slower than LuaJIT. But guess what? They don't give a shit and no one ever complained.
Are there any other reasons for them to choose Lua/Squirrel besides ease of use or is that pretty much it? 

>If you want to do game dev, you pick an engine and the engine will FORCE you to use a certain language. You don't get a choice.
I know. 

>Arguing about this is a waste of time.
I'm not arguing about it.

>>17395
>productivity is the name of the game in this field
It is precisely this mentality that makes modern game run like shit, both in terms of performance and reliability. Game "programmers" are just code monkeys that equate "adding a boatload of features" with "high productivity" so they just write whatever slop "feels right", never sparing a thought to optimization, both in terms of performance and design. The concept of technical debt is completely alien to them.

How long does it take to learn a coding language?
I was just thinking of using AI to code for me and as long as it works just using that, Is it worth learning to code if I only want to game-dev, I remember learning bare basics to mod some unity games like 5 years ago but I don't remember anything and why learn when you can yell at AI to do it even if it's shitty by coding standards?

>>17441
When I say productivity is important, I don't mean at the expense of technical competence. Performance and optimization are things that I seriously value as a longtime gamer and I'm even going with Stride, a free engine, because I don't want to be involved with any of the corporate engines and their practices. Relax. Vidya is an art first and foremost to me, not a product. It's about materializing my vision, not making profit.

>>17442
I had a retarded friend just like you who thought he could use AI magic instead of learning how to program. It is all fun vibe coding until you want something slightly complex and the AI is unable to generate code that actually works (nevermind it being "shitty by coding standards") and you have no way to make it work or even try to explain what you need with a better prompt because you don't know anything about anything.
AI isn't a magic wand, it is a tool. A tool that can do most of what a monkey can, yes, but any tool still needs a bare minimum of competence to be operated.

>>17443
>Vidya is an art
That's a fine way to look at it.
By the way, I am curious about something, so I wish you would tell me this: what if you were learning to draw/compose for the first time just to make a game? How would you try to get started and what level of visual/musical quality do you think you could reach when you treat this skill as a means to an end, rather than something you have passion for?

>>17445
>what if you were learning to draw/compose for the first time just to make a game? How would you try to get started and what level of visual/musical quality do you think you could reach when you treat this skill as a means to an end, rather than something you have passion for?
Luckily, I see none of those things as a means to an end. I appreciate the arts. I've been casually involved with music before and I've always wanted to be involved in the visual arts for other projects. That's what I like about videogames - they bind multiple forms of art together. I feel the same way about programming. I know C# isn't the most technical language, but I still want to be as proficient and knowledgeable as I can with it, when I eventually get going more.

I so regret growing up in the era of OOP languages. OOP takes the fun out of programming. C is a simple, good language with nothing to get in the way. But Cpp...

>>17447
>I so regret growing up in the era of OOP languages.
You can still program in COBOL if you want. The cops can't stop you.

TempleOS_4.05_session.png
[Hide] (24.8KB, 640x480)

>>17447
> C is a simple, good language
This one is, the others not so much.

>>17451
>runtime
>interpreted to ASM
>doubles as shell lang for REPL
TBH, in spite of the name, the attempt to  combine C with BASIC unintentionally(?) ended up a lot more like a Forth than either of them.

>>17458
Good.

Stride.png
[Hide] (3.2KB, 512x512)

Unity is not a benchmark for C# performance in gaming because Unity is not a C# engine. Only a legitimate engine, actually written in C#, is a real indicator of performance.

>>17950
Unity isn't even a game engine it's just a spyware tool for some retarded faggots which just happened to be a engine in the first place it was nothing more than A bait and switch
Always check if a shit is unity and run it inside a bottle without any network connection.

>>17951
Sounds reasonable, but I just don't like how Unity has always been the metric by which C# is judged in gaming, even though it's not appropriate to do so. Unity is a C++ engine with C# tacked on a result, so of course performance suffers. With Stride, it's built in the same language that it's scripted in. You can go into the engine and do whatever you want to it. I would never and will never use Unity.

>>17954
Also, the same thing applies to Godot. You're not getting a true C# representation. A game engine should always have the same language as what it's scripted in. Enough of this bullshit of tacking on C# to appeal to the Unity crowd. Unity is a cancer and shouldn't even exist.

Unity and Unreal are cancers. They've made game development too accessible and the landscape suffers as a result. C++ is a demanding language, but now any bum can jump into Unreal thinking the engine is going to carry them and create buggy garbage. Same thing goes with Unity; it's produced countless examples of indie slop by people who don't take programming seriously. C# is a great language for game dev, but dumb shit like Unity and Godot tarnish its reputation. Fuck Unity and fuck Unreal. Game dev needs more gatekeeping, not more "democratization".

Here's definitive proof of what I'm talking about: Stride with Bepu, a physics engine written purely in C# smashed both the old Bullet engine that was in Stride (written in C++) as well as Godot and Jolt. Higher, more stable FPS, better culling because the engines aren't going through an abstraction layer and more realistic looking physics to boot. 

https://www.youtube.com/watch?v=vWkrQ55wwMo

>>17957
>>17959
Note C# does have real performance costs, and while they aren't using the more extreme unmanaged C# solutions like Burst I mentioned >>17398 upthread, the Stride devs are mindful of some guidelines they hew to for keeping bounds checks and GC under control:
http://archive.today/2026.03.06-161217/https://web.archive.org/web/20230522103850/https://github.com/stride3d/stride/wiki/On-Garbage-Collection

1442299960345.jpg
[Hide] (88.2KB, 600x600)

>>17951
>Unity isn't even a game engine it's just a spyware tool for some retarded faggots
Those aren't mutually exclusive. Unity being a bad game engine with spyware doesn't disqualify it from being a game engine, just as your post's English being terrible doesn't disqualify your post from being written in (atrociously shitty) English.

>>17387 (OP) 
Start with Godot. You aren't going to finish your game otherwise.

>C++
You can learn it later (if you want), but you should use Godot first. C++ is just too complex language. Your first game doesn't need to be written in C++ (or some other language) because of performance reasons. GC won't ruin your first games.

>Lua
I like Lua because it's simple and easy. It's even easier than Python. But it's usually embedded into other programs to be used as scripting language. If you want to go pure Lua route then use Love2D.

Csharp-LETTER.png
[Hide] (45KB, 1640x664)

>>17970
>Note C# does have real performance costs
Indeed and that was something I had to weigh into my decision when selecting an engine. I broke it down like this:

You can have absolute performance like with Bevy and Rust, but then iteration and alteration is much, much slower,; the engine is itself is more difficult to modify and the ability to make your game moddable is reduced. The same things apply in lesser degree to C++ engines. 

C#, when used in an engine that's also written in C#, can have very good performance, along with better memory safety than C++. It will always iterate faster and the engine is much easier and able to be manipulated than if you're addressing one in C++ or Rust. C#, IMO, is a great all arounder for game dev. C# hasn't even reached near its full maturity and every time .NET gets updated, so does Stride, leading to instant performance boosts. 

>>17977
>Godot
No, I'm not interested in scripting C# onto a C++ engine. Stride even has better physics performance than Godot:
>>17959

always_open_source.jpg
[Hide] (34.7KB, 626x385)

>>18009
You started this thread claiming you were "dipping my toes into programming" and that you had found C# and Stride, and that you were "leaning towards" them, later asserting that you had already decided. A beginner such as yourself should not have such an assertive attitude, but of course, what you really meant in your OP was something along the lines of "give me examples of other technologies and I'll tell you why C# and Stride is superior". Yes, god forbid you use anything that doesn't lock you into C# completely. I think it's pretty obvious who you are and what your goal is.

>>18009
The idiots at novell and xamarin working on behalf of the microkike nudevs that used to develop the c# compiler were all fired over a decade ago. The only new thing in c# is the stdlib being randomized using an army of pajeets and chinks like yourself and thats going away with ai randomizing it, also known as dotnet. The lang version has been stuck at 7 for over a decade, the only thing changing is the stdlib being made more shit. kys

>>18046
> A beginner such as yourself should not have such an assertive attitude, but of course, what you really meant in your OP was something along the lines of "give me examples of other technologies and I'll tell you why C# and Stride is superior".
Look at the date I made this thread and now look at the date of the post you're quoting. I've had time to think over the options. 

I looked at Rust and Rust engines because of nice memory safety and performance, but the iteration speed is much lower. 

I looked at C++ and Wicked Engine and O3DE, but C++ is even more verbose than Rust and the iteration speed will be slower. 

Those are the languages that would give the most performance, but at the cost of fastest iteration speed and lots of overhead in game dev, especially for someone working by myself. 

I looked at Zig and Mach, but Mach is still in its infancy and Zig still pales in comparison to C# in iteration speed. 

C# is great for iteration and Stride is a fully mature engine that will soon be able to be used on Linux. What you give up in some absolute performance, you get in development speed and less friction. C# is already less performant, so using it in an engine that's written in it top to bottom is important for getting every last little bit out of it. I made my decision weighing the pros and cons of each. I'm allowed to make an assertive choice. 

>>18053
t. moron

>>18060
>Look at the date I made this thread and now look at the date of the post you're quoting. I've had time to think over the options. 

>Anonymous 26/11/2025, 02:34:51 No.17387
>I'm personally leaning towards Sharp and have been looking a lot at the Stride engine

>Anonymous 26/11/2025, 17:30:16 No.17393
>It's already been decided, but I'm still interested in the topic in general.

15 hours. Wow. That's a long time indeed.

>>18060
Prove the anon wrong then? Is there a csharp compiler with a bse lang version beyond 7?

kotlin-logo-full-da13fdb1bd71fd55cca52612962eafed.png
[Hide] (38.6KB, 2435x528)

korge-512.png
[Hide] (13.7KB, 512x512)

>>18067
>>18078
I've now moved on. I was very passionate about learning C# and Stride, but that's changed with continual research. I'm now and probably going to stay on Kotlin and KorGE. I don't want .NET's baggage. I get almost as much productivity, but with more safety and performance with Kotlin/Native. 

That's what's funny. Goofballs call you a shill and then you drop the thing they accused you of shilling after you realize it's not right for you, no matter how passionate you previously were about it.

>>18086
If you need productivity and are willing to use a garbage collector, why not lua instead of kotlin? I mean java itself isn't that bad, but kotlin is like cancer for reproducability. I guess you could use lua with kotlin technically.

always_bet_on_duke.webp
[Hide] (194.1KB, 864x1080)

>>18086
Remember the most important rule of gamedev, especially for amateur first timers: Rewrites kill games.

Niggers, you've been arguing about this shit for four months now. OP is probably just trying to advertise stride3d here otherwise he would have made his choice back in 2025.
This entire thread reeks of Reddit.

fyrox-728x364.png
[Hide] (16.8KB, 728x364)

>>18100
I've switched to Rust and Fyrox, now, lol. That's my current thing. Like I said earlier, I don't want to use an engine that's written in a different language than what it's scripted in. It hurts performance and makes it more difficult to modify the engine itself if you want to. I've dumped C#, dumped Kotlin and am going to learn Rust and just deal with it. I'll have better performance and spend less time debugging. At least Rust is getting less verbose. 

>>18103
Noted. 

>>18108
>you've been arguing about this shit for four months now
Huh, arguing is bad, now? 

>OP is probably just trying to advertise stride3d here
Can you at least read the thread before making moronic accusations? 

>This entire thread reeks of Reddit.
Based on what? You probably use "Reddit" the same way that Redditors use "Nazi".

c73fb55bc021062160598aa6468884d8.png
[Hide] (1.7MB, 640x1000)

Just start messing around with an engine at this point instead of overthinking it too much. A lot of how good an engine is varies depending on your personal taste, skillset, and the type of game you're making. You won't know how good an engine clicks with you until you've tried it, and when you've tried enough different engines, you'll have a decent enough feel for their design philosophies that you'll be a better judge of whether an engine is a good fit for you or not.
For example, there is a very specific kind of dev who loves Love2D. He likes or is at least tolerant of Lua's quirks. He can't get enough of the framework's architecture. He loves having to roll his own tile-based scrolling system or use a bunch of third-party LuaJIT libraries, as this lets him cobble together the ideal framework for his game with nothing extra. Some of these people have released great games with it, and some of them made crazy money (Balatro being the most recent example).
But not everyone is this guy. If you hate Lua, want something even more minimalist than Love2D's APIs, want to write your own engine, or like Godot's scene system or some other engine's overarching design philosophy, you're way better off just using something you like even if it has downsides which Love2D lacks.

A lack of understanding of this is part of why /g/ and /tech/ gamedevs rarely go anywhere. They waste a bunch of time arguing about languages and engines, seethe at /agdg/ anons for using whatever they want (proprietary or not), and all the while neglect making a fucking game. Much like Rust's game developer scene, which has barely shipped anything and is full of people sperging at each other to do the "right thing" and making generic frameworks for hypothetical gamedevs who aren't themselves. Last I checked, the Rust scene has produced exactly two real games that aren't just tech demos for Rust devs to point to and go "See? You can make video games in Rust, it's possible:" a town builder called Tiny Glade and a hydrofoil racing simulator. As far as I know, neither of these wasted their time on the horrible Rust community, as they just did whatever they wanted with tools they liked and thus just made gaem.

It is a bit humbling that *most* I can hope to do is to barely understand what men smarter than me invented. It took me a week to comprehend and implement primal revised simplex using sparse matrix/vector arithmetics and Bartels-Golub method to iterative LU decomposition with decent performance for problems in my domain, most of the time spent deciphering various mathematical notations whitepapers take for granted. And I still don't fully grasp geometric sense of convex rotation. At least it was fun, but there is no escaping being a midwit.

>>18138
At least you're (I assume) looking to make a technologically mediocre implementation of your (no doubt brilliant and inspired) new ideas, instead of retreading old ideas with as much bleeding edge technological optimization in implementation possible as your first project, like this guy:
https://invidious.nerdvpn.de/watch?v=CJ94gOzKqsM

>>18138
>primal revised simplex using sparse matrix/vector arithmetics and Bartels-Golub method to iterative LU decomposition
I am going to say this as harshly as I can so you really get the point:
Coming as someone who studied numerical linear algebra let me tell you that there are graduate students in numerical linear algebra who would have no idea wtf you just said. You are so deep inside either imposter syndrome or Midwest sandbagging that I don't know what I can possibly tell you at this point other than your so-called performance issues are deathly serious psychological and esteem issues as opposed to intelligence.

>>18147
You're giving me too much credit. I am exactly retreading something that was thoroughly explored for optimisation in the 1990s and more-or-less solidified in set of "state-of-the-art" industry standard techniques by 2010s, at least as far as LP optimisation solvers go - most variations past this point seem to focus on heuristics for picking best-suited scaling and pivoting techniques for a particular problem and avoiding degenerate states. And my domain is as trivial as finance.

>>18218
I only participated in uni for a limited time but from what I've witnessed, merely being seen at every lecture scores you higher in than actual understanding of the topic and it's tangents, so at least in some extremes it may be testing the bureaucratic/conformation aptitude more than anything else. While I don't discount that someone brilliant may choose to stick around, it is doubtful that act of graduation alone is a meaningful achievement.
Thankfully, scihub and researchgate are around, so there is no need to be academic environment to have access to whitepapers, but while I can make a working implementation after cross-referencing the arbitrary notion syntax for several days, the understanding is only tentative and amounts only to consuming and regurgitating essentially, being entirely dependent on someone truly impressive to kindly share their findings, as it's the whole other level of banging head against the wall, an actual frontier (or at least was at some point).

>>18128
Update: I'm sticking with Kotlin and KorGE. 

As to Rust and any game engine related to it, I'm not interested. I'm taking up the D language. I think D is a very good and underrated language. The most complete engine offered in D is the Dagon engine, spearheaded by a very productive and focused Russian man who's spent 10 years building it by nearly himself: https://gecko0307.github.io/dagon/

So, as of right now, my game dev languages are Kotlin and D and my game engine choices are KorGE and Dagon.