Its very clear that c# is superior to vb.net for game development, but I make very small games in vb.net(comparable in size and complexity to pong clones), and have not had any issues with vb so far. My questions is: At what point is performance noticably affected by the language, compared to the same game coded in c#? Does it become bogged down when handling complex graphics? The way it interacts with hardware? all of the above?

The reason I ask is because I enjoy making MUDs, and I like to make each game a little more complex then the last. I assumed because its not a resource intesive game to make it didnt matter, but i wanted someone elses opinion on this.

VB.net and C# essentially compile to same intermediate code, so for most applications there is no discernible performance difference.

However, VB.net lacks language facilities for "unsafe" code, which allows C# to use pointer manipulation and dereferencing for high-performance memory access.

Direct pointer manipulation and dereferencing are very useful features when you manually manipulate large arrays of data, such as pixels of an image. VB requires you to marshal such operations (essentially performing redundant copies of the data) to get the same access, which will slow things down.

If you mainly load your graphics from image files, then the loader and renderer already implement the high-performance logic so you don't have to worry about it.

So if I understand correctly, I am safe to continue with VB.net for my MUDs, but should think about C# if I plan to add pixel-based movement? Most of the graphics in the game i'm working on currently are static images loaded from a file, with only a couple exceptions to some menu stuff that is animated.

Use VB.NET until you're coding and thinking "Oh golly! I wish I could use a plain damn pointer in here!".

There is effectively no performance problem using vb.net. the bigger problem is the lack of examples. However, if you are comfortable reading c# examples, you should be fine.

For example, you can use OpenTK to access OpenGL. You can use monogame/xna.

However, if you know vb.net, then you already know c#. It is just a different syntax for what is basically the same language.

So if I understand correctly, I am safe to continue with VB.net for my MUDs, but should think about C# if I plan to add pixel-based movement? Most of the graphics in the game i'm working on currently are static images loaded from a file, with only a couple exceptions to some menu stuff that is animated.

Don't worry about it, VB.Net is fast, modern PCs are fast(and by the time you actually release something they will be even faster), pixel based movement and animation is computationally trivial and if you need to do some really heavy data mangling there is most likely a highly optimized low level library available that does it for you regardless of what language you use.

Unless you have a very good reason performance should be the last thing you consider when you choose a language, your primary concern should be platform support(The language you use must work well enough on your target platforms) and after that you should look at things that enhance your productivity (language features, tools, libraries, etc), performance is only a concern if your language makes it difficult to reach your performance targets (and you are almost guaranteed to run into a situation where your chosen language makes it slightly difficult to reach your performance target long before it makes it anywhere near impossible).

I would still recommend looking at C# though but not because it will make your applications magically faster (it won't) and not because it lets you write unsafe code to squeeze a bit of extra performance out(if you need to write alot of unsafe code you might aswell use a low level language) but because it is a very nice language to work with and it has a huge community and tons of great tools.

VB.Net shares the same compiler/JIT/Runtime technology as C#, and they've had a decree of maintaining feature-parity for awhile now. You can basically think of them as two dialects that speak differently but otherwise have the identical capacity for communicating powerfully. C# is neither faster, nor slower than VB.net in mainstream terms -- I suppose its possible that the patterns one or the other encourages might be marginally slower or faster in specific cases, but you should mostly be free to defy those patterns. I don't hesitate at all to say that, between the two, use what's most comfortable because neither has a clear performance or expressive advantage. I happen to think that C# is the better language, myself, and probably a significant majority would agree, but that's no good reason to dump VB.net if you're already familiar with it.

That said, there are ecosystem differences -- as I said, most people seem to prefer C# by a significant margin, and so its easier to find people to help you out if you're writing your code in C#. Likewise, there tend to be more tutorials and references written in C#, and also some of the VB.Net code you'll find are straight-line ports of the C# version, which may not yield idiomatic VB.net. Moreover, most .net libraries are written in C#, so you'll eventually want to be comfortable at least reading it. All of those things combined tend to mean that any VB.net programmer who sticks with programming long enough eventually will also pick up C# (except, perhaps, those whose job is solely to maintain large, legacy VB code bases, as sometimes exist in enterprises).

If you were new, and asking the question "Should I learn C# or VB.Net" I would hands-down recommend C#, but since you are coming already with VB.Net experience, there's no need for you to drop what you're doing now to take a break and learn C# before returning to your project. You will probably (want to) come to learn C# before long, and that's a good thing, but let that come to you as you need it is my advice, unless you are simply itching to learn a new language, or are finding that not knowing C# is holding you back right now.

Note that you can mix languages within a VS solution. If you want to experiment with C# in the context of your game, just add a new C# class library project and implement a class there. It will be seamlessly callable from your VB.net projects once you add its reference therein.

I honestly don't think that many developers actually use the C# unsafe functionality provided by

https://msdn.microsoft.com/en-us/library/chfa2zb8.aspx

and

https://msdn.microsoft.com/en-us/library/ct597kb0.aspx

I find that most hobby developers use C# because products like Unity (or traditionally XNA) provide their APIs using these languages. Unity in particular does not allow the unsafe facilities of C# anyway for certain platforms like the WebPlayer exporter.

If you need pointer access (and many hobby / indie games probably don't) then calling a native C/C++ library from C#/VB.NET is usually the more popular choice.

So really, C# and VB.NET are pretty much interchangeable by most .NET developers and their limitations are pretty similar so whichever syntax you prefer is probably a good enough choice. C# is more popular however so there are perhaps more code examples around the internet if you need them.

That said... I really like C++/clr since I can write in something very similar to C# and thus get the safety of a 100% managed language but then seamlessly utilize native C/C++ code directly without swapping between languages or loading in external libraries. I wish Microsoft would port that compiler to platforms I actually use though :'(

Its very clear that c# is superior to vb.net for game development, but I make very small games in vb.net(comparable in size and complexity to pong clones), and have not had any issues with vb so far. My questions is: At what point is performance noticably affected by the language, compared to the same game coded in c#? Does it become bogged down when handling complex graphics? The way it interacts with hardware? all of the above?

c# is another syntax for the compiler, but the same optimizations and backend. When Microsoft lost in curt, because their J++ made extensions to Java without permission, they simply created a new parser for java alike syntax for the VB compilers, called it c#.
The reason why some people claim VB is slow, is because it was always slower than C++ written code, that's why it had a very bad reputation back then. Obviously, MS cannot push c# with that bad reputation, that's why they claimed things about c# and stopped talking about VB. (That's also why they had to rename the VB runtime, it was a big reason for the performance problems e.g. garbage collection. now you call it .Net).

Now some think "MS says c# is just as good as c++, then it must be way faster than VB", which for technical reasons is nonsense (as explained).

So, everything you can achieve and do in C#, you can do in VB. The only differences are syntax and politics, you can ignore what differences others try to find.

happy coding