Reputation: 711
What are the big limitations with VB.Net that prevent people from wanting to use it as a language to develop games?
Upvotes: 5
Views: 4845
Reputation: 11
Those who say that the Net is slow are wrong. At run time, the just-in-time (JIT) compiler translates IL into native code. IL code has a lot of advantage. You can write game with C#/VBNET and use framework as Monogame or FNA (that is the reimplementation of XNA). A game write with monogame/fna is multi platform
Upvotes: 0
Reputation: 49609
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#.
Upvotes: 11
Reputation: 16513
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.
Upvotes: 1
Reputation: 30636
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.
Upvotes: 0
Reputation: 2268
As others have noted, .Net is not slow, but there are a few things which stand against it for game development:
As for using VB.Net specifically. Dear lord why? :-)
Upvotes: 0
Reputation: 513
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.
Upvotes: 8
Reputation: 4199
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.
Upvotes: 1
Reputation: 300489
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).
Upvotes: 0
Reputation: 43815
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
Upvotes: 3