4

I'm writing a strategy game in XNA and VB.NET. This technology combination looked like quite a good choice, right until I decided I would like to switch to MonoGame (but keep my game logic in VB.Net intact).

The problem is that MonoGame currently does not support VB.Net. I did some research and it seems I have basically two options:

  1. Rewrite my code to C#
  2. Write a small C# wrapper around MonoGame and turn my Game Logic code into a library

Needless to say, both of these options suck. Am I missing another option here? I don't mind giving considerable effort into making this thing work in MonoGame, but rewriting just isn't an option.

My findings so far:

While browsing the web, I stumbled across a MonoGame template for VB.Net. While it looked to be just what i needed, it crashed upon loading even after running a plain new project. I then proceeded to google for the error, but got nowhere near running the thing.

To explain my technology choice (because someone will ask):

Why XNA? I used it before, I'm familiar with it and even though it's outdated, it suits my needs perfectly and should still work for a couple years.

Why VB.Net? I have huge experience with it and I prefer it's syntax over C#. This is important to me since I'm writing a rather large-scale strategy game and keeping the code clean and understandable is essential.

Why not C#? Experience. I worked with C# for a little over a year, but it ain't natural yet. VB is.

Arides
  • 111
  • 7
  • Off-topic: learning another language is fun! It's hard to step-off your main one but it's worth it! (There's a vb to C# converter that can help you: http://www.developerfusion.com/tools/convert/vb-to-csharp/) – joppiesaus Nov 11 '14 at 14:14
  • 1
    You're completely correct! However the 'language' I'm trying to learn this time is 'strategy game coding'. It takes quite some learning & thinking to get the game logic working, so I didn't want to mix it with learning another language. As for the converter, it's definitely an option. Thanks! – Arides Nov 11 '14 at 16:24
  • There's some workarounds to get XNA/Monogame working with F#, particularly around the content pipeline, which may be applicable to VB.Net see http://neildanson.wordpress.com/2013/08/13/f-and-monogame-part-4-content-pipeline/ – Phillip Trelford Nov 12 '14 at 07:31
  • Awesome! I managed to make the VB.Net template work, so now I'm standing before dealing with the missing ContentPipeline of MonoGame. I'll definitely give your suggestion a shot, Phil. Thank you! – Arides Nov 12 '14 at 20:43

1 Answers1

3

I found a solution. A failry painless way to make this work was the MonoGame template I mentioned earlier. There are several small issues with that approach, but nothing too problematic.

Issue #1: Error when starting MonoGame Project.
After running a new VB MonoGame template project, a nasty error is thrown upon startup (System.TypeLoadException in mscorlib.dll). This happened since the template reference an incorrect version of MonoGame library (I'm using windows and there was an android library linked to the project). Solution: Remove the MonoGame reference from your new project, and use browse to add back the correct version.

Issue #2: Content project missing in MonoGame.
MonoGame does not have a Content Project, but rather a folder called 'Content', which honestly behaves just like the project. Just add all your content from the XNA content project to this folder and it works. Amazing!

What it failed to do however is loading sounds and fonts from uncompiled content files (e.g. myFont.spriteFont). For MonoGame content, sound and font files had to be replaced with their compiled version from the XNA project.

Plus there is one small nuisance - each content file must be marked as 'Copy always' or 'Copy if newer' (default 'Copy Never'). I didn't really find a way to change this for all of them at once, but it doesn't take that much time.

Issue #3: XNA project was automatically resolving imports.
XNA project had one 'Syntactic Sugar' advantage. I never realized it until i switched to mono, but I never saw a single line called 'imports' in my XNA project. I made massive use of this, having many small classes which consisted only of few lines and used a 'list' of 'Vector2', etc. After porting to MonoGame I had to go through several hundred compile errors due to missing imports.

I'm still wondering whether this was caused by the XNA project or some other config in Visual Studio itself, but I must say I liked it. If you know something about this, please do share.

Conclusion:
Looking back, the process of porting to MonoGame took me about a month to figure out - but when I finally had all the pieces, the entire process took about 4 hours for 100+ source file + 100+ content file project. I'd say the guys at MonoGame did a tremendous job, and so did the gentleman who modified the template to work with VB.Net.

Arides
  • 111
  • 7