Just started using it and I am installing PLUGINS!! No more VS Express madness!! :eek:
There is a conversation going on here about it: Visual Studio 2013 for free! - C++ - Epic Developer Community Forums
Blueprint documentation can be used with plugin as it automatically creates C# bindings based on functions and properties exposed to Blueprint. There can be C# specific functionality through the help of partial classes, though that can be just added documentation along side Blueprint docs.
I’ve been looking along side Blueprint docs/posts/answers when I was converting C++ template projects to C#. It felt kind of odd but you wouldn’t be nearly as lost as you’d think.
Anyway, I personally really hope that .NET open sourcing will allow us to get rid off ridiculously priced versions of mono.
is exciting news, but I would still rather see C# with Mono or .net as a first-class programming language for the engine. For one, I still have a lot of valid, well-designed and engine-agnostic code, I used with Unity. Also, there are just some features like reflection (even for binary-only third-party libs) and attributes, that make programming editor and gameplay stuff more concise and a lot easier. Epic seems to have tried mirroring some of the features with macros, but in my opinion, that solution doesn’t come close to the flexibility .net/Mono reflection unless you modify the source of third-party libs to hook into it somehow. And that’s a no-go to be honest. I also can’t shake the feeling, that C++ programming and the way the macros and overrides are set up in the engine and the editor are more messy and time-consuming then they would be with C#. Not that I’d know much about it though, as I haven’t had the time to check out UE4 yet, apart from some tutorial videos, that scared me more than anything else.
Oh and yeah, the version of Mono in Unity is just too old to represent C# and the current capabilities of the Mono/.net environment. There are boxing bugs, an ancient garbage collection algorithm and weird AOT compilation problems among other things, that shouldn’t be there and that were fixed ages ago.
Would it be possible or advisable to use C# not only as some scripting language replacement, but also for low level game logic (input controls, network replication, various event handlers&triggers, camera, persistence to SQL server)?
The long story.
I’m somewhat experienced C# developer, mostly enterprise apps and web sites. I haven’t coded in C++ for years. I’m just beginning my experiments with Unreal Engine and trying to think of my ideal workflow, but there seem to be some pieces missing, and one of them might - or not - be C# support.
When thinking about coding vs blueprints, it seems reasonable to assume that blueprints are most convenient for fast prototyping and implementing high level game logic. Although you can use blueprints to implement some core features (I liked blueprint networking tutorials), such blueprints tend to get messy with multiple RPC calls, variables, event handlers and event triggers and what not. My understanding is that game level designer should not worry about network replication and input controls. Level designer should have more abstract view. Thus, if I understand correctly, networking & input belongs more to coder’s view, right? And now for coders UE4 has only option for C++. I’m not sure if it would be wise to deal with low level code (input, networking, maybe even SQL database access) from C# but I really would love to because C# seems so fluent, clean and simple language compared to C++, and it is so easy to add external libraries.
Now about scripting. C# might be a great alternative to blueprints or Lua scripting plugin. But there is one thought on my mind. If we can use C# or Lua for scripting and if we are able to modify and reload these scripts at runtime, then wouldn’t it be a good alternative solution to have ability to modify and reload blueprints at runtime? I imagine that we could save a blueprint as a separate file (binary or even XML or JSON) and throw it on the UE server replacing existing blueprint script. Could it be possible? Are there any technical issues with ?
In summary, in ideal scenario I’d like to program low level game logic in C#. I’m talking about the things which currently can be done in blueprints but don’t quite belong there. And for scripting, I would be good with blueprints, if only it was complete scripting solution with ability to reload scripts at runtime. And C++ would be the best where it excels - really low level stuff, OpenGL/DX draw calls, networking packets etc.
Without some additional wrapper code (intimate knowledge of the codebase), I don’t think C# support of any kind will be here quickly. Sweeney said something in the other thread about there being an alienation problem with slightly different C# syntax, and a few other reasons why they probably won’t add . That seems fair to me, I just disagree (little features like array bounds checking alone are helpful for me) and will make my own custom solution that’s probably not suited for general use. I will try to release it open source though.
I’m looking at , it seems like it does exactly what I want. https://csscriptsource.codeplex.com
There are a few issues with what I’m attempting. Mostly I am just calling directly between c++ and c# using little gem called UnmanagedExports (VS plugin; requires VS Community).
-
String marshalling is messy and confusing and I’d rather go without it. Especially for speed e.g. FindGameEntity(“OnFire”) on Update(). So I might get around passing strings altogether (and use hashes)
-
I want my C# codebase to debug and recompile while the game is running. So that means a separate VS instance and some kind of remote procedure calling. (I might use named pipes or websockets)
-
Avoiding c++/cli is cleaner and makes for less maintenance and chances of messing up.
-
Going the plain dynamic C# DLL route (LoadLibrary/FreeLibrary) looks a bit weird to me because in .Net it hangs onto the DLL until the program exits, and I’m not really comfortable with the solution.
-
I will avoid adding BP support for my solution because I already personally find it difficult to read and implement the UE4 documentation examples, it’s just me, I’m not a natural programmer so I’d rather not.
Thanks, xXxFishAndChipsxXx, for sharing your ideas. is really interesting stuff and I wasn’t aware of potential of CS-Script and UnmanagedExports for use in UE4.
I myself have had some experience with C++/CLI and exposing C++ classes to C#. It was my own C++ DirectSound abstraction layer library and it was pretty simple, but still I had some struggle to get it right with pinning pointers, marshaling data etc. UE4 is much more complex than that, and I agree that it might get too messy to go C++/CLI path.
Still, from UE4 side I’d like to see Blueprints becoming a complete alternative to scripting with support for saving individual actor and level scripts to separate files and hot-reloading at runtime just by recompiling and overwriting Blueprint “script files”.
Ok, I know topic is getting a bit old, but i wanted to put my two cents in.
The thing is that I’m a Unity user myself, there are many problems with Unity but those are not related to C# Itself. for god knows how many months, i can’t decide to turn toward UE, you may ask why? C++ ! that is the reason i never tried UE. and those who simply shake argument off telling others to use blue prints, i can say only one thing, i want to be able to code, for me personally reading and writing code is much much easier than using those visual scripting tools. also, think about it, if you would want to go for an RPG game, can you imagine how complex your blue prints could become? Be sure that in less than a month, if you go back to some of those blue prints to add some more functionality you would not be able to make head and tail of that blue print. so stop saying that blue print can be used instead of scripting language. and if you ask me, if epic wants to win the hearts of many unity developers, they only need to add c# support. as simple as that.
Why are you so afraid of learning C++? I to was reluctant at first, coming from a Java background. But the code you write fro UE4 is not so different from what I would write in Java. They even have garbage collection in UE4 for Objects and Actors, which account for the vast majority of cases. Truth be told it took me less then a week to get a good grasp on how C++ work in UE4.
1 - C# is being used by any in commercial business. Like C++ when people tought that assembler was the way to AAA games
2 - No single company uses it in AAA games, because there are no quality graphics engines written in C#, see Unity as example. Indeed, it is growing up, as easy coded than unreal.
3 - As bussiness software developer, i can tell you that C#, compiled using #unsafe, is accurate as C++ in custom memory and pointers management, but ALSO can be managed, dealing with these messy system’s things.
4 - C++ is like assembler: OLD, OUTDATED, and TESTED. Thinking that C++ is the only way will bring companies to die, as when Assembler was the AAA roadmap. C# and CLR managed games are the best option to develop from today to the future.
If Unity scripting languages were LUA and ‘javascript’ would we be having the same discussion over and over about C#? I don’t think so.
What is fascination about C#? Me and many others don’t understand obsession, and maybe, that is why type of discussion is always reappearing and degenerating into C# vs C++. We just don’t understand why you want Epic to incorporate C# as a scripting language if both the code source and several scripting languages, Skookum, javascript and C#, from third parties are available.
Well Javascript is… Javascript and Skookumscript is an incredibly esoteric programming language with its syntax quirks. C# is more than just a scripting language too. Just because you personally don’t want it doesn’t mean that there can’t be alternatives.
I never said I don’t want it. I’m quite confortable with both C++ and C#. All I’m saying is that I just don’t understand the obsession for specifically asking Epic to implemented that particular language. There are no movements asking Epic to implement Lua, Python, Ruby or any other language.
If you need C# because of easier syntax, than either Pascal or Python are way better options.
Python is probably the least performant scripting language you can implement. LuaJIT is probably the “best” pure scripting option but Epic’s efforts to implement Lua didn’t go far.
C# is generally considered to be a top tier language actually. It won’t suit every need because it’s managed, but for its purpose it’s pretty solid. Syntactically its light years ahead of c++, and the third party library support/.NET framework if you use it is second to none. If the performance of C# + UE4 on Mono is even close to on par with native c++ after compilation, I’ll never write a line of c++ again 