Ya I understand what you mean now. Skookum is definitely a high level, game oriented scripting language rather than a general purpose programming language.
Skookum is all about manipulating your game world. If you need advanced data structures or low level networking etc you are going to have to use c++ for those parts, and then use skookum to call into them.
I wish C# and C++ supported nested block comments… the lack of support for doing that ****** me of soo much. Commenting code in blocks like that is so much easier for workflow and trying new code… But then you can only do it once… and if you want to block comment an even larger chunk of code that encompasses an existing codeblock it just screws up… stupid industry.
Its not like compilers are in effing 80’s anymore.
But yeh… how is the C# progress coming along?
I have been wondering the same thing. Seems we can’t ALWAYS have nice things. 
Still waiting on official or non-official C# + Mono support!
C’mon Epic, this is really something that would be… epic 
A couple of thoughts:
Blueprints are good but are not without drawbacks:
copy a piece of graph to another function? No, even if there are local variables with the same names.
change the type of ForEachLoop? - no, it is necessary to create a new node,
reparent blueprints class? possible but not always.
transfer variables to another class? never.
C ++
I use it about 2 months, and in fact it’s possible to write on, but I miss C#
where were folders instead of filters (you need to add again next time you recreate project after fail),
using instead of include, quick intellesence, refactoring, no manualy “Classes” folder creation for pluggins or adding pathes,
All this may seem a small thing, but in fact they are poured in a lot of time and frustration.
I wish you success, and with bated breath waiting for news about C# support.
Yes you can! You can’t copy a “Function” node (purple) but you can copy anything else. You can even paste it into a text editor to see the pseudo code of the nodes. See below for quickly setting up the variables when copied.
So long as the parents are equals (both of base type actor for example) there shouldn’t be much that needs cleaning up.
If they aren’t equals, then yes it can take some work, but you can’t just swap the base class in C++/C# without making changes either. 
You can easily do this, drop a get node for the variable in the graph, Ctrl+C, Ctrl+V in your new graph, right click the node and choose “create variable”, it will create/add it to the blueprint.
As for the C++, you shouldn’t need to manually create the folders (use the editor command to generate instead), but if you do and want visual studio to recognize it, right click on the MyGame.uproject file and select “Generate Visual Studio Project Files” then re-open the .sln, this refreshes the project to include all manually created items.
Not trying to say it’s perfect by any means (blueprints can be rather limited in usefulness depending on what you are creating), but they are great for prototyping and scripting purposes. Blueprints (or Unreal C++) behave differently from C#, I agree, but most things listed here can be done already. 
I’m a bit hoping the C# Native compile option will be something which could help C# developers to develop with UE4.
Microsoft is working on .Net Core which should be available on Windows, Linux and MacOS. It includes a AOT(Ahead Of Time) compiler which generates native compiled binaries which means: no intermediate language. As far as I understand it does not require a virtual machine to execute. What I could not find was if the produced DLL’s are approachable like a DLL created with C++.
Has anybody more info on the AOT and what it could mean for C# in UE4?
I hope to share this view with you at one point, i just can’t get into the C++ flow as easy as with C#.
Any news on this?
Couldn’t one just compile into the byte code of the Blueprint system from C#? Because Blueprints run inside a Virtual Machine, too. This would be like a text based blueprint, but from a C# source. Maybe that’s even better than funky wrappers around C++ code.
It seem not. Either this is a good sign or a very bad one.
I’m all in favour of C# (and Skookum), but I really recommend you guys to take look at Haxe for Unreal plugin: GitHub - proletariatgames/unreal.hx: Unreal.hx: Haxe Integration for Unreal The plugin has really fast compile times and hot-reload.
I’ve been writing Haxe (http://haxe.org/) for many years (used it for html5, flash and mobile games) and I really recommend it to everyone - it has tons of really powerful high-level features and the best macro system I have ever seen.
You can play with the language and try out different examples here: http://try.haxe.org/
I never programmed with Haxe. But I like the look of it. Though I would feel better if it was on the marketplace and not just on some Github. Seems Haxe comes to a “one language to rule them all” quite close. It is a language, but it doesn’t seem to have its own runtime? But gets ALWAYS compiled/converted into another language. Kinda cool this idea, and it seems even to work.
I briefly looked at it but can you tell me does it have the equivalent to skookums races, syncs, and coroutines? I love those about skookum and make heavy use of them to solve all kinds of issues I use to struggle with…
It doesn’t have multi-threaded races or coroutines, but there’s a number of libraries that do them (you can browser all the libs at http://lib.haxe.org/, but this one seems nice GitHub - Atry/haxe-continuation: Asynchronous programming in a natural multi-thread-like syntax, escaping from the callback hell.) and making ones like skookum or unity (where coroutines aren’t on a separate thread, they’re just tick delegates) would be quite simple.
At some point I wrote a very simple class for composing and queuing tick-based delegates in Haxe and successfully used it in a project: FlowBlockList.hx · GitHub
It was mostly used to queue up lots of complicated animations and tweens.
Considering how powerful haxe’s macro system is, you can make syntax look really even neater and more lightweight, but that would require deeper knowledge of the language.
And keep in mind that haxe has tons of other amazing features and a really powerful and strict type system.
PS: I also wrote a simple C++ class specially for unreal, based on that haxe class - Utility class for asynchronous/coroutine style programming in UE4 C++ · GitHub.
Syntax is a bit bulky, but it works really well. I’ll re-write them to use ] operator like Slate at some point.
Using it, I successfully coded cutscenes in C++ same way you would do it in skookum (though in no way I’m saying it’s better than Skookum, I just didn’t know about it at the time).
It would be nice to know if anything is even going to happen with C#/F# for UE4 any time soon. So one could decide whether to go for Haxe, Skookum, or JaveScript instead.
I think the best bet for this to happen is for Xamarin/Microsoft to lead the initiative. Microsoft has a lot to win by making sure C# is usable in all major engines. I would contact them directly.
C# is my favorite language but I do not think it makes sense for Epic to do it themselves. They should focus on making sure it is as easy as possible for other parties to add additional languages.
I agree. And I keep thinking about Blueprints. Because the funny part about Blueprints is that they are actually managed code. Just not written in text based source, but node based graphs. So the engine is already designed around a “node based C#”. I guess UE4 is using something similar I saw in .Net CodeDOM. Which allows a program to generate code and even compile it.
I’m yet to learn all limitation of Blueprints. I do know for a fact that nodes can run quite soon into the problem that they are node based and not text based. So, do even we really need a C#/F# wrapped around the entire engine? Why not allow C#, or any managed programming language like F#, to pose as a Blueprint by compiling its source into the Blueprint pipeline? Yes, this would somewhat limit the C# code. I just can’t tell if that would even matter in the end.
By the way, I keep mentioning F# not only because Xamarin did that, too. But because F# with its stark reduction of “code noise” reminds me of Skookum script. And that code noise reduction is kind cool. I saw some impressive comparison with F# vs C#, and it just amazing how a simple code with F# was like 5 times less to write compared to even C#. 0.o
And F# and C# like each other, M$ says…
Something to think about here for those weary of blueprints; There’s a new in 4.12 that makes blueprint scripts run as fast as native code, without any code!
See more here: 4.12 Released! - Announcements - Epic Developer Community Forums
Just to throw my little 2 cents here.
I started out with C# in Unity, and honestly I can’t believe how C#-like is UE’s C++. You guys do know that you don’t really need to use pointers on everything and everywhere? For game logic anyway. Passing by reference is sufficient 99% of the time. Unless you want to go hardcore and edit engine source, I really don’t see how C++ is different from C# except a few minor differences, though I do admit it’s a little bit messier.
BP is essentially visual C#. In fact BP is better than PlayMaker, so there’s another reason not to dump man-hours into a C# wrapper.
On the other hand, I really think F# will be quite the addition to UE4, and if they go for it that pretty much means C# support as a byproduct.
So either way, if you need C# badly, that either means you’re writing stuff in C++ that looks messier than the same thing in BP, or cramming all the logic in 1 BP and can’t be bothered with C++. I mean, after reading all the posts in the topic, I get the feeling that everyone who genuinely want C# basically see it as a glorified drawer where the code looks neater, which is a good point, but seems kind of overkill.
Ultimately though, I think the more tools we have to work with, the better it is. But I don’t think it should be at the top of the agenda here…I mean come on guys, judging from the current state of the documentation, I doubt that another section for C# is gonna make it better. Maybe I’m just an idiot but seriously there are times that I have no idea what a certain function is doing. As in, there’s 3 words explaining it. So I think at this point in time, C# would make things even more confusing. My vote (which is insignificant) would be to consider C# after the VR rage has passed and after the docs are updated.
The VR rage will not pass and the documentation will always need to improve 