I give up.
apparently I’m an idiot like the rest of the people who spend huge amount of money each year for a xamarin subscription and all the other idiots who were able to work till now without having the source code of each framework they use.
People do “framework” as you saying yet they call it “engine”, specially when they reuse it in different game, because engine is what i said, fundaments of for a game and it can be reusable. And doing simple engines is not that hard as people talking, they think that if you do engine you need to do complex tools and giant code base and such, make it do everything, when majority of engines are done to power specific kind of games. If you looks on quake, it practically had editor as a sperete software, yet people call it a engine, not to mention that engine was made by single man. Speaking of editors, you are aware of fact that UE4 editor is build on top of UE4 engine it self and when you package a game you only building engine without editor modules?
I still think you incorrect and you don’t understand how UE4 is build and you won’t be able to master UE4 as long as you think that way, mark my words 
Again Unreal (unlike Unity which was made more like game maker) was made just for single game, it was initially not ment to be a “engine” of your definition “to provide content creation tools and make games”, initially it was just level editor for game called Unreal in your definition of “engine”. But again i only assume that, i don’t know if Epic really wanted to sell engine when they been building Unreal, or they just though they can do other business with what they made once Unreal was out, Jazz Jackrabit 2 also had nice editor, but it was more primitive. Also as i mention above if you grab UE3/UDK it feels you install some kind of empty game and build on top of it, because there was no project system at all, it’s actually new feature in UE4
I also think we kind of lost, but it all started with discussion in C# can do in UE4. To back that discussion, C# in UE4 sould be plugged to UE4 framework as much as possible, make it feel like you coding in similar way to C++, or other way around, text form of blueprint.
I don’t think you are idiot, i just think you little overdressed with C# and as result not trying to explore what C++ can do because you think it too old and primitive and potentially hard to use… for me it was black magic until i tried it few months before UE4 was released, something clicked in my head… maybe i matured to it
Just a question, are you a professional developer? How would you describe your knowledge in computer science?
UE4 is built like every other engine out there is built, if you’ve been doing this a while you should know it’s all the same the same stuff different developer.! I’m not sure what there is to “understand”?
Simple as this, it’s whatever takes me the least amount of time to get to my end goal and keep the lights on. I don’t really care what’s in the engine if it speeds up dev, I have years worth of work without anything on top to deal with… If there is a problem I have the experience to fix it, it still doesn’t mean even as someone has worked on engines and messed around with them for years I’d ever dare attempt to dive to the centre. As soon as an engine starts becoming less cost efficient than a custom “framework” or Engine then I have to re-evaluate it’s purpose.
As much as I’d love to spend years noodling about with systems, in a commercial environment it’s not an option. Not to say I won’t fix core issues if I need to, or add tools if I require them… But for some indie’s even that could be too much of an ask…!
Personally, don’t see the point in C#… You can split and classify BP’s, get instant feedback and it’s not hard to convert. UE gives you less rope with GC and automation if for some reason you decide BP’s aren’t good enough.! I like OS, It’s allowing me to think about bolting on systems like Umbra, even though I’d prefer Unreal to sort a deal out :D, well it is in Unity.
Different engines, different workflows.!
Whatever, i would change your mind and you don’t change mine I think you limiting yourself for no reason
Get Visual Assist X. How anybody works in C++ or any large codebase without it is beyond me.
We do it all the time (within reason, and by ‘we’ I mean our Tech Manager). Most recent things I can think of:
- Writing extra ‘bits’ to the GBuffer, so that we can properly render and travel through Portals.
- Integrating PS4 / Xbone dev kits (which you will have to do if you ever want to ship to those platforms).
- Projection Matrix modification that allows us to do portals on Occulus.
EDIT: Just read the rest of the thread. By the looks of it we’ve finished this debate now… that’s probably for the best.
Looks like you didn’t saw minecraft-like projects made on cs engines. You lost much. More advanced graphically. More complex, wider world visibility. And fps tens of times higher.
Better not put cs and java together 'cuz their speed is not even close. Better comparison is cpp AND cs against java.
So after all of this madness:
xamarin is now, free, open sourced, MIT licensed
mono is now, free, open sourced, MIT licensed
Now under the EULA, mono (C#, VB, F# and class libraries) can be fully integrated and comply, free of charge.
How awesome is that!!!
That’s pretty great, hopefully they’ll revive their mono for UE4 project.
Here’s my short Twitter conversation with Xamarin boss Miguel de Icaza,
Maybe something will eventually come out of it. Maybe for easier deployment Epic could just add another Engine version to the launcher.
I don’t mean to bring up old topics, but this is interesting.
C++ in UE4 is excellent. Its a very well exposed subset. The pattern of exposing functionality to BP and then using BP as high level design tool is phenomenally robust.
C# would be cool but not really a necessity, as C++ is so well done in UE. What could be amazing is however F# integration - as that exposes a really productive functional style that imho could rival BP in terms of speed of development. Anyway its awesome to see Xamarin decouple from their for profit licensing (thx Microsoft) work on the UE integration.
Unreal with C# scripting would be invincible.
Wow, so Unreal-C++ extends C++ with
- Headerless programming
- Async/Await structures
- Auto-properties
- Immutable collections
- Partial classes
- Object and collection initializers
- (P)LINQ
- Extension methods
- Safe structures instead of having to deal with pointers/memory adresses for gameplay scripting
- Yield-Keyword for iterators
- Oh, and access to the whole .Net-Framework
- …
That’s awesome, didn’t know that. All the Unity developers must be stupid as C# is obviously the wrong choice for component-based gameplay programming! Why did no one ever tell them?
There is now another option at Epics mercy, https://code-orchestra.com
Plenty of videos and blog articles on it. Epic continues to say no to fair, equitable, and sustainable terms for C++ extensions (their right since it’s their engine) to the detriment of the community.
A few simple clear agreements (SLA’s, transfer rights, etc…) would easily address Epic’s concerns; it would expose UE to millions of devs and potentially open up a large talent pool for UE-based studios. A fair and equitable solution is easy to reach if Epic Games is open to it.