Binding dynamically to LGPL code is no problem for commercial projects at all. The only thing creating trouble is platforms where you cannot allow the upload of a new version of the LGPL code or where dynamic linking is forbidden. There all usage of LGPL code enforces the GPL or LGPL upon your code and all other code. Which you are most probably not allowed to do.
So you dont need another license using Mono as long as you are linking dynamically and do what the LGPL wants you to do.
Looking at projects using WebKit or Chromium solutions for browsing in a game. I have no idea how they do that, because when you use either of these solutions you will be using LGPLed code, its hidden in large parts of Chromium and its the license of WebKit.
See, Unity uses C# via Mono and they handle the licensing for you. If you download Unity, free or pro, you can use C# without concern, assuming you follow Unity’s license of course.
With setup for Unreal, it’s not as cut and dry. I think it’d probably be easier/cheaper for most indies to just learn enough C++ to get by. Besides, with all the macros and such Unreal uses, Unreal’s C++ feels a lot like C#.
I suppose my only with is that it might discourage people from using C++ despite how easy Unreal makes it.
Unreal does a good job of surrounding you with the tools you need to make easy use of C++ and avoid boilerplate code. Most of the complexities of C++ are hidden behind macros and classes available for your use.
I don’t like the idea of having different languages operating the same role in parallel like you see in Unity. Mono thing also apparently requires some license to use/distribute which means its not even applicable to everyone that already has an Unreal license. That means barriers to sharing code.
I’d have been unlikely to start using Unity if the only option were UnityScript. I know others who wouldn’t have started using Unity without it, since it’s similar to ActionScript. Portability of knowledge is key. Imagine C++ never existed before Unreal 4, and now everyone wanting to use Unreal had to learn C++ from scratch. Pretty hard sell if you ask me.
That’s why major operating systems each pick a language, and to develop for that platform you must use that language. Right?
For me the compilation times are a lot worse. When I do small incremental changes it takes around 10 - 25 sec. But once I program a bit longer and create a few new classes with will go up to a minute and I am on an SSD.
If I could reduce that time to a few seconds that would increase my productivity by a huge factor. Also C# has a lot better IDE support, VS13 for me without VAX doesn’t work at all. I usually would just use VIM with a few plugins but unfortunately the support for those plugins is horrible under windows.
But Linux support seems to be right around the corner.
Mono support does also mean F# support. I am quite excited about the the mono bindings.
Also hot reloading (c++) at the moment seems very buggy. Most of my crashes are due to hot reloading but probably gets fixed in the future.
The only thing I am worried about is the quality of Mono, I have heard many horror-stories about it. Has anyone here experience with Mono?
From what I read that’s pretty much how it works. Which is nice, but I think it’d be nice to go a bit deeper in integration than that. For something like Lua or Javascript or SkookumScript, using the Blueprint bindings makes sense, as conceptually I feel they occupy the same “abstraction level range” as Blueprints. But C# feels inbetween C++ and Blueprints, not a sidestep from the latter.
The C# bindings are generated from everything exposed to Blueprints. Plus a few other things, but they weren’t incredibly clear about that.
So you don’t have free reign, you can mostly only do what Blueprints can do, just in a text-based language people (especially Unity converts) are already comfortable with.
I thought that they wrapped every c++ class but I think you are right, they just create a binding for every blueprint exposed class. Now the quality of the mono port depends on the quality of Blueprint.
Now I don’t have much experience with Blueprints, what are the limitations? It seems that I can expose everything what I need via the blueprint bindings.
The above already have but yeah, it doesn’t root directly into source, it can only touch the previously exposed things. Whatever way you look at it, it’s still a wrapper into the C++ side of the engine and always will be. IMO that pretty much makes it a ‘scripter’ in instance, the same way Blueprint is. I’m not going down the C# vs C++ route (I don’t know enough to have that debate anyway), but it’s just another barrier between you and the real part of the engine. It’s only going to put limitations on you in the long run.
To me, it just makes no sense. It’s a good excuse to add C++ to your language utility belt if you haven’t already, and you can avoid the inevitable constant changes to Mono to keep it up-to-date. You’ll have to learn the Engine function calls and libraries one way or the other. I see no benefit of using instead of Blueprint, especially given that you have to pay for it and get zero support and knowledge base.
Well, the benefit you get is the libraries and runtime. For example, it’s trivial to add a web communication layer utilizing reflection, or parse files, or chew through data tables: these things require a lot of boiler plate in C++ and are language features in C#. You can only interact with the engine through the type system Unreal exposes, but you can interact directly with the system via Mono. It’s also going to run faster than Blueprint, compile faster than C++, and for a lot of people typing is going to be faster than wiring BP (not to knock on blueprints, but as a programmer they have limited utility). I know C++ very well, but I still see the benefit in C#.
That said, the reason for request to elaborate was because in context “it” was C#, so it sounded like you were saying C# was just facilitating communication between C++ and C# which made no sense.
Biggest Blueprints’ drawback is any of you may wakeup someday and discover that your character controller BP is simply corrupted and only god knows why. Than you’ll waste some time looking for the last backup you have where Editor doesn’t crash when you try to open the blueprint and lose some extra hours reworking what you’ve done the day before.
Blueprints crashing Editor when you try to open it is not uncommon, plenty of complaints on AnswerHub.
Also there are bugs with function libraries and some other smaller annoyances. A solid scripting API where you can code while the game is running may be valuable. But Mono, hmm… I do not trust too much.
The solution to problem, for Blueprints and code, is source control.
That said C++, C#, etc… feel a lot more natural with source control than Blueprints do. Epic’s done some great work on that front, but at the end of the day source control is meant for text. Yes, even Perforce.