Game Development in vb.Net

Question

What are the big limitations with VB.Net that prevent people from wanting to use it as a language to develop games?

Answer 1

It's not VB.NET that's the major problem, it's the .NET Framework.

Specifically, game development is generally done in C/C++ where every ounce of performance can be gained. The .NET framework doesn't lend itself to this.

With that said there are games that have been developed in .NET

Answer 2

VB.NET is no different from any other .NET language.

The perception that VB is slow is no longer the case.

Here's a list of tutorials for VB.NET with XNA (game development toolkit).

Answer 3

Speed of higher level languages usually keeps them out of "serious" game development, where C and C++ reign supreme. However, more and more games are exposing game logic to scripting languages like Lua and Python.

I've heard of indie games being developed in VB, for instance the Zombie Smashers series was developed in VB by James Silva, who recently did the game Dishwasher Dead Samurai in C# .net.

You may want to look into the Xbox Live Arcade framework (XNA) Microsoft put out. You can use that in VB or C#.

Answer 4

Part of it is the stigma still attached to vb in general of being a slow language. (Which is not nearly as much true as it used to be because of the commonality of the .net framework)

To be honest though it depends on what type game your developing, if you are doing a high frame rate, high level 3-d graphics, bleeding edge game then you are stuck writing it in C or C++ in order to get necessary performance. But if you are doing something more like what you see in many flash based games today, or even stuff that you could see in older games then IMHO you could do it in almost any language.

Answer 5

It took a long time for game programmers to even accept C++ over C due to it being "slow". I believe that soon enough the multi-core era will cause this to slowly fade because running in parallel will be a lot more important than running a single thread as fast as possible.

Keep in mind also that a lot of processing is done on the GPU nowadays with pixel/vertex/geometry shaders. So we are seeing some pretty advanced games being written in what might be considered "slow" languages.

Lastly, .NET is not slow. What makes it troublesome for game development imo is the unpredictability of the garbage collector (GC kicks in during a huge boss fight and causes lag - not so good), and any marshaling that occurs between C# and native code.

Fortunately, with a deep understanding of how .NET works, including the GC and runtimes - both these obstacles can be overcome.

If anything it would be highly recommended to prototype a game in a managed language, whether it be VB.NET, C#, python, ruby, etc... and then if it is found to be too slow you can port parts of it to C++.

.NET has managed C++ which makes interop between native and managed code fairly seamless. This allows for those really critical parts to be written natively if necessary. But I doubt this is the case. The most important optimizations at first are going to come from data structures, algorithms, and overall architecture.

Answer 6

As others have noted, .Net is not slow, but there are a few things which stand against it for game development:

1. Non-determinism of garbage collection
2. Low portability (compared to C)
3. Lack of mature game dev tools/libraries/frameworks

As for using VB.Net specifically. Dear lord why? :-)

Answer 7

You can use the Microsoft XNA Framework for graphics and a regualr WinForms application to contain all of your code. Simply install the XNA Framework and add a reference from your VB WinForms application.

If you want to take advantage of all the features XNA has to offer, you'll need to use C# with which XNA integrates nicely.

Answer 8

As for the speed part, engines like the XNA-based Visual3D.NET have convinced me it's not impossible to get good performance from a managed game engine. More importantly, the CPU doesn't appear to be much of a bottleneck in any of the demonstrations, which is the only part the use of C# has any effect on. And even when it's CPU limited, it's still only pushing 50-60% since the engine is still quite single-threaded, so there's a LOT of room for improvement on today's dual and quad core CPUs, and tomorrow's octo- and hexadeca cores. I think optimizing algorithms to scale well in the many-core era will be more important than the language used.

And the nice thing of using a managed language for the entire engine is that it's easy to use the same high-level language for game logic / AI whereas native engines might use much slower scripting languages for this.

The use of a managed language like C#/VB.NET might be limiting for CPU based things like physics, but then again, I've been quite impressed by the fully managed physics library JigLibX for XNA.

This is all C#, but I'm guessing it applies to VB.NET as well since they're compiled to the same IL in the end, unless there's some limitations in the VB compiler that I'm unaware of.