Hi, I'm a beginner programmer and I've been learning coding in C# for past couple of months. Recently I've started using Unity, and I'm a little dissatisfied with not having as much control over the program as I had while I would be making console applications in C#, and not knowing a lot of times what the program is actually doing with a lot of my code. I figured it would be a good thing for me to try to learn about game engines and how they are made and work with this series, but learning another language in this stage, I think, would only make a mess in my head. So is it doable (or wise) to follow along these videos and try to replicate these concepts by coding in C#?

Edit: At this stage I don't except to be able to make a game on my own game engine, just to understand game engines better so I would be able to manipulate Unity as much as I can, and therefore have more control and make better games int it. But I also want to continuously learn and maybe be able to really make my own engine someday.

Do you want to make game engines or do you want to make games? (or do you want to end up in the *games industry*?)
If you want to make games - What kind of game(s) do you want to make?

I want to make games as an independent developer. I don't have ambitions to get a job in game industry. I want to make 2D games currently and I'm primarily interested in game design, but I also want to know how to "make" them, since I don't think you can separate those two things. I don't want to learn to make game engines so I could get a job for making engines, I just want to know more about how games work, than you could find out by just using unity, everything in the purpose of making a better game, in the end.

If somebody tells you that you need a "game engine" to make a 2D game, slap them across the face.

2D games do not require "engines".
For the most part, 2D games require:
1. a way to load textures (and atlases) and
2. push thousands of textured-rotated-alphablended-alphatested-(depthbuffer-sorted) quads to the GPU

If you don't quite like Unity, fair enough, C# has two fantastic alternatives:
a) MonoGame - framework
b) OpenTK - OpenGL wrapper (and extras)

If you pick MonoGame, you're done, you can write your game straight away.

If you pick OpenTK, you'll need to write roughly 500 lines-of-code to get (1) and (2).

This will include a couple calls to OpenGL, but most of 500 loc would be loading atlases, bitmap fonts and putting vertices in appropriate vertex arrays based on texture/blend-mode.
OpenGL 1.1 has vertex arrays (glVertexPointer, glTexCoordPointer, glDrawArrays), and it's all you will ever need.

If you'll need custom shaders and rendertargets that will be couple hundred more LOC.

All in all, still dead simple and easy. Which is exactly what we want.

Hey David, by the way, while I am new to game programming, I have been working with C# for some time now so if you ever have C# questions or need a hand, shoot me a message!

Hey, thanks to both of you for help! :)
I looked at MonoGame and it seems like a thing for me. I'll still continue with some small projects in Unity, but I'm going to gradually transition and learn to work in MonoGame, so when I start something bigger I'll have the skills.

Hmm, can't you just create a DLL in C# with the respected DLL name and run with the Handmade hero Game engine? I never done this before, nor have any experience creating a DLL in C#.

C# by doesn't export native functions. You won't be able to load it from native exe and call C# funtionality directly. You'll need to instantiate full .NET VM to execute C# dll code. At that point it probably would be easier just to rewrite exe also in .NET.

Aww, that would of been really awesome if you could but I guess you just can't have one part not use the .net and the other part use .net? Makes Sense.

popcorn
Aww, that would of been really awesome if you could but I guess you just can't have one part not use the .net and the other part use .net? Makes Sense.

It's more complicated than that. But I'm willing to explain because I recently whiteboarded this all out for some friends.

So .NET's DLLs are not actually "native"/machine code... They actually have human-readable (but it can be tough) code called CIL - Common Intermediate Language code.

C and C++ produce native language code which is binary code that the processor can read and execute. Even though .NET refers to the CIL DLL files as "assemblies," they are completely on a different spectrum from actual C/C++ DLLs/.EXE files.

What happens with C# when you build your application is it gets turned into CIL code that I mentioned above, then you actually distribute that CIL code... You never actually distribute* machine-language code to your customers/clients basically.

This is why C# code requires whats called the .NET runtimes/.NET Framework/CLR (take your pick, they all mean the same thing basically) to run. The .NET Framework has another program that is "always on" in the background of computers that have it installed called the JITer, which stands for Just-In-Time Compiler. The JITer interprets the CIL code that is in your C# DLLs and files, then AT RUNTIME (when the user actually double clicks the executable, it gets finally compiled down into actual machine code on a case-by-case basis. What this means is that only the parts of your program that the user actually needs to use get compiled as needed, rather than your entire program. So if a user only uses a few functions in your program ever, the rest of the program will actually never be compiled to machine code ever. With C and C++, all of that doesn't exist, your entire program just goes straight to machine code and you are distributing machine code. Note that there are different ways to link your code in such as dynamic or static linking, but nevertheless, it's still compiled down to machine code all the time.

That whole .NET process has its ups and downs, but generally, it requires unnecessary bloat and overhead (the user must have the .NET Framework installed or else the code obviously is completely useless), plus there is performance loss associated with so many layers of abstraction involved. Because of the bloat required to run the CIL/C# code, for example, you cannot program small embedded devices which have limited memory with C# because they cannot fit the .NET runtime crap on their chips. It's like with anything: You get more convenience and it comes at a cost... That is, if you find C difficult, which many people like Casey do not. I actually find C easier than C# aside from occasional memory quirks.

The upside is that the CIL code, because it is compiled at run-time (when the user executes the program) into machine code rather than by the programmers right away, it can do things like examine what type of machine it is running on and then try to optimize the actual machine code for that type of machine. Another cool thing (I guess), is that since multiple languages are part of .NET and all compile to the CIL, technically your buddy can program in Visual Basic.NET and you can program in C#, and they will end up being the exact same code anyway and can be packaged/work together pretty easily.


That's all I'm going to explain because other things get murky, if you go check StackOverflow, you'll find guys arguing back and forth about the pros and cons of all of this, and whether or not the CIL code resembles "Bytecode" which is basically Java's version of the CIL.

And don't feed into the hype, we're all entitled to our own opinions of course, but I'm of the school-of-thought of Casey when he thinks the whole .NET/JVM thing is a load of crap, but that's just me. That said, I am a C# programmer and I do use C#, I just prefer C whenever possible. In the end, if you are satisfied and the game works well, who cares? :)


*I've heard it's possible to actually pre-compile C# code into actual machine-code ahead of time but I've never done this and it doesn't seem to be a widespread practice. Even still, not sure how that would align with C code.

Todd
Because of the bloat required to run the CIL/C# code, for example, you cannot program small embedded devices which have limited memory with C# because they cannot fit the .NET runtime crap on their chips.

Oh yes you can - https://developer.microsoft.com/en-us/windows/iot

Typically for these devices you do AOT instead of JIT. Ahead of time compilation. Pretty much do all the work (and more) that JIT does at runtime, but do that on your dev machine, and deploy only native code (+metadata). Xamarin does this with Mono for deploying .NET apps on iOS devices (because JIT on iOS is not allowed).

You can easily nowadays do AOT for desktop apps with .NET Native toolchain: https://msdn.microsoft.com/library/dn584397.aspx There are alternative compilers like LLILC: https://github.com/dotnet/llilc

Hence I said:

Todd
*I've heard it's possible to actually pre-compile C# code into actual machine-code ahead of time but I've never done this and it doesn't seem to be a widespread practice. Even still, not sure how that would align with C code.

I've heard about AOT, but that's it. I prefer native so I have no reason to do it. If you need to do it for your project or at work or whatever, be my guest. Microsoft IMO has made great strides and they're doing a fantastic job with open source, .NET Core, and that Win 10 IOT system you showed looks awesome as well. However, at the end of the day, they are MS and they have a corporate agenda which is why I try to steer clear when I can. But I'm also somewhat paranoid.