Mono relicensed under MIT - C# for UE4 can come back?

Development Cinematics & Media
75

Well, that’s the rub. It is easy to say, but much, much harder to actually do. C++ is verbose and hard enough by itself for newbies. But even expert C++ coders pull their hair out with all the added complexity of the macro system that EPIC has thrown in. Now C++ is great and if you really want to learn it, you can spend the time. Then you can spend the time to learn the extra layer that EPIC put on top. And then you can get to work making games with Unreal and C++. In the meantime, two or more years will have passed in your quest to go from zero to hero.

Some people will never just get used to Blueprint as they find it too messy. People like that seem to prefer textual coding. But so many of these people find C++ too difficult or too time consuming and really want a good middle ground.

And that is where the efforts of people like @ come in with C# (Mono) for Unreal.

However, some people will find learning C# too much, so in that case there is
It is awesome and people should really check it out.

However, some people will find that they don’t want to learn another scripting language like and want to use a language they already know like Javascript.

So people like that can use Unreal.js here, here and here

Personally I do not want EPIC to spend resources trying to support other third party languages. EPIC is good at making game engines and should not divert resources away from that. I really want the community to support third party languages. That is the beauty of having Unreal open sourced.

So currently people have a choice.

People can choose from:

C++
Blueprint

Unreal.js

And if Xamarin decide to host C# (Mono) by @, then C# can be added to the list.

Choice is great.

I support choice

76

To be fair, it’s out of Xamarin’s hands now whether a Mono-UE4 integration goes live. Microsoft’s acquisition and open sourcing of Mono saw to that - all it really needs from this point is a sticky thread, or lots of attention.

I do see what you mean, but you need to understand the macros that UE4 adds are to save a LOT of bootstrap code, to make your code utilize the reflection system of UE and to make your code participate in UE’s garbage collection.
Without it, there’d be no way to interface your code from Blueprint, which as Epic had announced somewhere, in the intended layout of thing would take place (C++ is intended for systems and backend bits, Blueprint is intended for content).

Unreal.js is a great option, I tried but couldn’t learn - it’s too different to what I am used to. But as you say, choice is great, I also support choice.

I’d personally love to see this Mono-UE4 go live, I’d maybe even use it for some things, but all I was saying is that you’re going to have far more flexibility if you learn to use the tools that the engine was built around, than if you use tools that were built around the engine. In this case, C++ would provide the greatest flexibility.

77

@Fabsterpal You are absolutely right. C++ does provide the greatest flexibility. I don’t think anyone has any doubt about that.

Programming is like having two glasses. One is completely full of water and it is called “Power”. The other one is completely empty and is called “Simplicity”.

You can pour one glass into the other, but the amount of water will always the same. The more simplicity you want the less power you will have.

It is just as simple as that. It is a universal law of nature.

In other words, there is no “best” solution. To anything. It is, and always will be, a matter of choice.

People who choose C++ will have raw power but no simplicity.

People who choose Blueprint will have simplicity at the expense of raw power.

C#, or Unreal.js are equivalent to both glasses being half full.

I’m a two glasses half full kind of guy.

78

No, just no. Yes a language can complicate things a smidgen in what you can express, but really In terms of simplicity and language, the simplicity is irrelevant because what you write is only dependent on you. You make it simple. the language doesn’t define how you express your code. you determine that. the language just says how to write your expression syntactically. Yes, it’s easy to write bad code in C++, but it’s easy to write bad code in any language, that’s not a fault of C++ alone. anyway, language complexity is user dependent. :wink:

I think a huge point to remember is that, familiarity with a language is often mistaken for simplicity, and unfamiliarity is often mistaken for complexity.

You know what’s not simple? ASM/Other ML. Also just handling multiple languages, is unnecessary added complexity. I don’t get the point of scripting languages alongside C++ and BP for ue4. It doesn’t add anything but a new syntax, at cost too.

79

I think a huge point to remember is that, familiarity with a language is often mistaken for simplicity, and unfamiliarity is often mistaken for complexity.
[/QUOTE]

@SaxonRah I have seen your tutorials and know that you are quite skilled with Unreal and that you most certainly know what you are talking about.

I think it is my fault that perhaps you misunderstood. My comments were directed to the case of absolute beginners who had never programmed in any language before. That is what I meant when I used the word “newbies” a few posts back.

To paraphrase George Orwell…

“All languages are complex, but some languages are more complex than others.”

80

When the C# in UE project was canned back then it was because Xamarin was not open source. Now that Microsoft has acquired Xamarin and

That M$ acquired Xamarin sounds good to me, because M$ shows initiative. They bought the creators of that Unity Debug plugin and made it available for free. They are even implementing the module system for C++ now. Since M$ created C#, they probably will also have great interest in promoting C# in the game developing world. Which they already did (free Unity debug plugin), now there is opportunity to do another push with the Unreal Engine 4.

I can’t help but to wonder if M$ kept innovating like this. If they ever would give C# a native code support. Once C++ has gotten its own, all they would have to do next is to purge all the **** syntax in C++ and only keep the necessary native part, and then just implement it as a “C##” for C# itself.

Yeah, it is my hobby to stroll in the woods looking for fairies. :slight_smile:

81

I think a huge point to remember is that, familiarity with a language is often mistaken for simplicity, and unfamiliarity is often mistaken for complexity.
[/QUOTE]

That’s true. Though C# does have things in common with C++, well, for obvious reasons (hint: C# derives from C++ and Java). I think that LinuxURU might have used the wrong word here, but actually meant something else. And that would be that C++ is tedious to work with. If you always have to add something to that what already would be enough in another language, even if it is not complex, it just would increase the tedious redundant work factor and time to do other things. C++ likes to do this a lot. E.g., headers. Headers aren’t even native code related, but C related.

Those who come from C#, they do know that it takes to write code. They know the algorithms. But then, they try C++ only to find and think: Great, time wasted. In C# I already could have implement all this like 3 steps earlier. And why the heck are they still headers in C++? So, why would I event want to use C++? Because of performance? Yes, but only if needed. And it in many cases it is not need. Would I want to use C++ just because the engine doesn’t support C#? Well, maybe. But only because I do not have any other choice.

The conflict between C# and C++ programmers is a war between fangirls and geeks. The fangirls are hurting more C++ itself than actually advancing it. If the C++ programmers, and C++ creators would only refrain from finding excuses. Yeah, there are C++ programmer who would try to tell you that headers are a “good thing”. Seems those devs need a lesson of C++ history. Then we maybe we could use C++ itself now and really wouldn’t have to bother much whether C# could come to UE4, or not.

Just to remind the C++ fangirls. C# first appeared in 2000 and had a module system. It wasn’t even the first language with a module system. Now, it’s 2016. 16 years in real world are like 32 years in the computer industry! And guess what? C++ STILL has no functioning module system. M$’s work is still experimental. And worse, this still doesn’t mean that UE4 can make full use of that once it’s implemented by M$. Because so much time has passed with not even a simple limited module system that Epic may have used just to get started somehow.

This C++ fangirlism, is nothing more but a pride parade. They know that in 2016, C++ actually sucks. And that at least some C++ devs only use it, because they do not have any other choice, and not because it actually would make sense. Give C++ programmers the choice, and some of them would switch to C# instantly. Unity showed nicely that a C# on top of a C++ won’t hurt performance that much. But of course the fangirls didn’t even notice that, didn’t they? Because we need full spectrum native code power on the higher levels of our games, huh? Well, maybe on a smartphone. Yet funnily Unity somewhat still dominates the mobile market. (Yes I know there is a C# to C++ converter now)

AAA C++ programmer can afford siting on their fat a$$ getting paid by some AAA publisher. We the indie devs, only get paid when our game is done (somewhat at least) and is available on Steam!

I hope that I don’t have to remind the AAA crowd, that we the indie devs are obliged to create innovative gameplay (at least I’m). And we are NOT interest to make another main stream bleh game, such the new Tomb Raider series by Square Enix. Which means we have to research a lot of gameplay mechanisms, we do need tons of rapid iteration and can’t wait until C++ has finally decided to get it’s compiling done, or considered not to screw up with Intellisense yet again.

Right now, it seems that my C++ code requires additional 2x builds only to shut up false IntelliSense errors. Cool story…. -.- (maybe I could fix this)

I don’t know how a C# would be with UE4. I haven’t tried the 4.5 C# version of UE4. But obviously, I’m not yelling here for a C# support, actually I’m yelling here at the C++ fangirls, because C++ isn’t good enough itself, but it actually could have been already. I trust that Epic games will make the right discussion regarding C#. And I would even accept a no as an answer. Meanwhile until we get something new to hear about C# and UE4, I"m going to have some fun with Skookum script…

… yes I know. The obsession with perfection and superiority can lead to insanity. (hey, it is ok. I’m already insane…)

82

just spent 2 days learning Skookum. I am already in love with it.

Now going to try to do full simple game with it so maybe my opinion will change, but imo if they make skookum first class citizen then I could care less about c#.

Wish it was direct from epic though because the docs suck and slightly concerned about getting burned by third party which always seems to happen.

83

any news from Miguel?

84

yes i would like to know too, any updates?

85

So how is it with actual game coding beside of “level scripting”?

86

I like it so far. Still in early stages of a simple moba. Just doing that type of game to learn skookum. All i have done with it so far is stuff such as basic enemy ai, spawning enemies etc. I prefer skookum over behavior trees now with the built in concurrency and ability to tweak the ai as the enemy runs around in game. Have not actually done any level specifc things such as missions etc yet if that’s what you mean.

Basically I just use blueprints for what they should only be used for (IMO)…setting up and configuring meshes with data variables. Skookum creates a class per blueprint that you can add code to. And its easy to add to the base UE classes as well. I have not done much with composition via components yet.

87

Interesting, Can you elaborate a little more on that? Did you create your own behavior tree in Skookum or how do you control the decision-making of your AI? Some code examples would be awesome too.

88

I did not create a behavior tree I just use the builtin concurrency stuff races, and syncs they have to basically create one in code.

For example rough psuedocode


_start_behavior()
  loop //our main ai loop
    race
    _follow_path //follow waypoints unless an enemy is found
    _detect_enemy  // if an enemy is found this race is over goto the next stage of the ai
   ]

   //we found an enemy follow and attack until we dont have one anymore other
  race
    _follow_enemy //follow the enemy unless he loses us or dies exit this race
   _attack_enemy
   ] // once this race is over we got back to top of the loop and follow path etc.
  ]

They converted the butterfly example which is probably the more involved ai example they have and better than anything i have.

t/butterflies-are-skookum/282

89

Cool thanks. do you think this can work for more complex AI though? I mean behavior trees aren’t specific to UE4, they are pretty much state of the art for game AI these days. the main isn’t really concurrency but just how the various tasks and conditions are managed without getting bogged down in an endless sea of if/else statements. Maybe I’m misunderstanding it all :slight_smile:

90

I dont think you get bogged down in an endless sea of if else statements because you call coroutines simultaneously. Coroutines are methods that run over many frames. Once those coroutines reach an exit condition then you act appropriatly just like in a behavior tree.

For example the _find_enemy coroutine checks for an enemy every second and if one is found then its done and now you can proceed down the tree or whatever.

Having said that I dont necessarily think skookum ai programming is better or anything than ue4 behavior trees. I just prefer to avoid any and all visual wiring / programming.

I’m sure complex behaviors in skookum will be just as complex as complex behavior trees in ue4 :slight_smile:

91

You could still use Skookum in those blueprints that are wired to the behavior tree. But you’d still get the benefit of the visual behavior tree which is pretty neat. That’s how I thought Skookum would most likely be used to code AI, so the statement to use it instead of behavior trees confused me a bit. The butterfly example works without behavior tree in both the Blueprint and Skookum version mainly because it’s simple.

If you have a complex enemy that needs to run away when health <= 10%, but only if the player is more than 5m away and only if there isn’t a cover near and no other allies are there to help unless yadada and dozens more factors, this gets out of hand quickly without the facilities that a behavior tree offers. I know more or less how concurrency works in Skookum but I guess I have a hard time wrapping my head around how it can be used to manage these junks of tree-like tasks with sequences and fallbacks etc.

92

Thats what I think is so great about skookum. If visual stuff is your thing you can mix and match.

For me when I look at 100+ wires of blueprints i see a disaster thats probably 10 lines of code.

Likewise when I look at behavior tree I see its nothing but loops, races, syncs, waits, callstacks etc :slight_smile:

And I much prefer the skookum workflow of code, code, code vs stop, code, compile, stop, code, compile

:slight_smile:

93

I view Skookum script as a “level script” language because of that what I saw from its demos and in the Call of Duty 1 map scripts. And judged by what you do with your moba and AI. COD1 map scripts do the same. They spawn an AI, they command it to move around or even talk. These script languages can set also objectives, but they are not used do more than this.

Taking a Lane Pusher MOBA as an example. The minions would move out and march forward the enemy core. There could be specific objectives, behaviors, map states. A “level script” can do this. Not all MOBAs have only one single map like Dota 2, though. Heroes of the Storm got more than just one battleground. However, the skill/ability/fight system would get more complex.

My concern is that Skookum script couldn’t handle this complexity. And judged by my first look at the IDE, it seems that Skookum script mixes the “Object Browser” and the “Source Code/File Tabs”. That’s why I just bluntly say that I prefer C# over Skookum script. C# ain’t just a scripting language, it’s C++ but in managed form and without headers, compile time and IDE problems.

94

C# has plenty of compile time. Less than C++ sure but certainly not none.