I don’t know C# so I can’t say how fast development is with it. Going from what I have learned from UE3 to UE4, I am happy that there is both blueprint and c++. I would never use blueprint only to make a game unless that was a very very very simple game. Even then I would be tempted to make my pawn, controller and game mode use a c++ base class in case I needed something that is not exposed in blueprints. However with a BlueprintFunctionLibrary you can workaround those issues most of the time.
To say that blueprints are a toy seems intentionally antagonistic to me. It undermines the work of developers who have used blueprints and basically calls them stupid for using them over other options. All I can say about that is that you are wrong to demean blueprints in such a way, both in a professional and logical manner. It reminds of the old argument between programmers in chatrooms that went something like …
I use Javascript because it’s fast.
Javascript is rubbish. I use Java.
Java is rubbish. I use visual basic.
VB is rubbish. I use C++.
C++ is rubbish. I use C.
C is rubbish. I use Assembler.
… and it goes on until one elitist with self-absorbed opinions ragequits.
Yes, you do have a very good point. Aside of not having headers, and better InteliSense, or faster compile time in C#, the rest is quite the same compared to C++. It is kind a lot though, if you wanted to… Node graphs don’t have headers either.
I suggested that in order to make things a bit more “different” to C#/C++, that such a language may use F#/SkookumScript like code noise reduction. The obvious advantage of F# is that it can handle quite complex situations from what I heard. Though, I can’t tell if “complex” scenario for gameplay code, may not be occurring so often that it really could make much of a difference after all. I lack experience with F#.
I made the argument that F# is less typing, lack of semi-colons, curled braces. Well see for yourself is some simple F# code.
<EntryPoint>]
let argv =
let console = System.Console.OpenStandardInput
if argv.Length = 0 then
printfn "There are no arguments!"
else
printfn "Arguments are:"
for i in argv do
printfn "> %s" i
let value = System.Console.ReadKey(true)
0
This what it would look like in C#.
using System;
class Program
{
static void (string] args)
{
if (args.Length == 0)
{
Console.WriteLine("There are no arguments");
}
else
{
Console.WriteLine("Arguments are:");
foreach (string argument in args)
{
Console.WriteLine("> ", argument);
}
}
Console.ReadKey();
}
}
If I look at C#, than back at F#, the F# code is kind of easier to read. And yes, it is “=” in F#, not “==”. Also the “0”, which is return, is a must. Or it won’t compile the F# source. I didn’t have to put the into a class this time either.
F# is open source and cross platform so Wiki (it’s a girl) said.
Rahahahhahhahhaha… The has arrived. Everyone else has already made some great counter arguments to the OP. So I won’t waste anyone else’s time with rehashing that.
@ Just create your own Game Engine using F#, C++, C#, and sell it. Since that’s obviously what you want others to do for you, why not do it yourself? Then maybe you’ll start to appreciate what’s currently available and why it is the way it is.
You cheated mate! Bold text vs almost invisibly thin text. I wont even go down into whats actually more readable as thats actually completely relative to the individual.
Its all down to what you are used to, this thread is as useless as maya vs blender threads. Just use whatever the F* you like best and stop ****talking things that are clearly not bad!
How much time did you waste moving from BP to C++?
How complex is “complex” in your game?
What is your game?
And before I even continue, have you ever programmed with C#? Two years for two games? Names? I know for sure that there are Unity devs, and they need two years to finish just one game.
Besiege, or Cities Skylines, they do take their time. Yeah, I do understand that there are multiple factors why a game may be fast or too long to develope. I just want to make sure that it ain’t the programming. Sorry, but given the fact that Epic Games mostly made engines for AAA. I can’t really trust them with indie game development. Well, I hope I’m wrong. Unity in the other hand does have a lot of experience.
Whining != Critic.
And nope. I started to design the UNBREAKBLE universe two years ago(sorta). I couldn’t have finished one game by now. I’m not making a Flappy Bird. I’m the only dev on the project so far. And it will remain this way until I finally settled on UE4 or Unity.
Are you a programmer only? Well, that would be cute.
I wrote the lore foundation for the UNBREAKABLE universe that spans over a three ages. I explored the game design (with programming) for an FPS Rogue Lite, Hacking Simulator, Open World Top Down RPG shooter, City Builder, First Person Caster, and the current open worldlish Survival-Build-Up rogue like-likeish Tower Defense. I set the art direction, and make the first assets for the two characters and world.
The first year was with Unity. Now in the second year I moved to UE4. Yes, I can program too. You see, I’m one of those artists… I used C# in Unity, so no PlayMaker. You know why no PlayMaker? Better don’t ask how the actual devs in the Unity community view PlayerMaker. I programmed a game from the ground up with C and OpenGL/OpenAL, so wihtou Unity engine or any other framework.
I’m not working more than 3 hours a day. So? So, that sentence I quoted above, it didn’t end with a question mark…
No, the first sentence makes a lot of sense. If you actually read the second sentence right after it.
My first sentence said that “C++ ain’t on par with C#”. The second sentence explained why. The second sentence said that C++ isn’t as fast as C# with its rapid iterations for indie game devs. How is that not suppose to make any sense?
100 people for one project? Because that sounds like AAA and not Indie. And the title of this thread is talking about indie…
Do you know the difference between AAA and Indie? I know that indie is even a lot harder than AAA. Because you will have to do everything yourself, and tools that like to waste your time, like C++, ain’t very welcome.
What do you mean? You are pretending that I actually wanted to leave UE4? Why the heck do you think I’m still and gather information as much as I can so I could choose which to use, Unity, or UE4?
I can leave to Unity right now. Unity does have actual real time global illumination along with some other stuff I may need for MagicaVoxel.
Granted, the use of the term “serious” in “which serious Unity dev would use UE4 without C#/F# or UnrealScript”, maybe have been a little too much. But again, it also said “Unity” dev. And Epic Games is a nothing in the world of indie game development. Well, UE4 is growing… UE3 never really mattered. So, have a look in this very forum sub section under the Telltale Games topic. Then maybe you will get an actual idea what this is all about.
There can be only one Death Star. And it better be UE4 than Unity… Yes, I know. UE4 is “only” two years old. There is more to come for it. So the BP may actually get more improvements that could make even me happy.
I work like 3 hours a day for two years now. First Unity, then now UE4. This is my first indie game in the works.
As a side note, I made one game before even Unity, form the ground up with C and OpenGL/OpenAL. But I didn’t ship it. It wasn’t really the time where one would sell games of all shapes and sizes. It was a Memory gave with a twist to it. So, todays mobile? Yes, it looked good visually that was the whole idea of the game engine. Yes, it looks good even today. No, I’m not going to port it over to mobile (don’t ask for happened to the source code…).
The reason computer science students need to learn C (and perhaps C++) is that it’s pretty much a requirement to understand computer architecture. C#, and especially Java (much less Python, Rubby, or similar languages) don’t tell you anything about how memory, bytes, and pointers really works. If you don’t know that, you will likely make poor choices, and/or be lost without a path forward, at some point in your future career.
Okay, I will put in my favorite language request: Please integrate Unreal Engine 4 with the Glasgow Haskell Compiler. kthxbye!
~le poor me having trouble right now with ‘iterators invalidation’ which I never had to give a *** about before
The best part is the C++ compiler see you doing that and gives no error, no warning, nothing…
Then ~le EpicGames’ engineer look at your code and see it clear like the sun and: “-Why deh *** U do dat??” rofl
I have begun to experiment with SkookumScript myself, both for mission scripting and as a possible replacement to a (really crappy) input scripting system I rigged up.
Looks promising.
Because of their existence and more to come, we just don’t understand why some people want EPIC to implement a scripting language. This is the advantage of having an open source engine. Stuff will come up, one way or another, if not by you, then by some other person or group.
That is a very good point, though in the case of SkookumScript at least, continued use and interest in the plugin should ensure the future support from its developers.
If Epic would implement every language - we could combine all the benefits.
Some people won’t understand that C++ isn’t a bad choice and implementing a C# API is less beneficial than implementing new features. The discussion will never end - I hope Epic stays strong.
It’s an astrophysics simulation game, that had to run on Androidand iOS. The astrophysics simulation running under the hood is one that I built in-house and conforms to all of the science done by Kepler and Newton over the years and is now used by NASA, if that gives you some idea of complexity. It’s now on it’s way to Steam.
This came from an original project that we worked on for a Satellite Control Station in Cornwall UK (Goonhilly). We built them an ‘experience’ which put 30 players in a room on tablets, all connected via LAN to a three-PC server system to act like a mission control center. This was all achieved within around 12 months of development time, and at the time none of us had any real programming experience, and I was the only person in the four-man team with any Unreal 4 experience.
In my spare (lol) time, I also have a competitive multiplayer FPS / RTS hybrid game in development too, which I’m developing on my own.
Nope. I came from a modding background for a few older games like Battlezone 2 and UT99 / UT3 - then moved on to applying for freelance work as a 3D, and Technical Artist. I’m also a qualified sound engineer and did my masters in entrepreneuship at the same time as the 30-player project mentioned above. You can maybe see then why I don’t really have a lot of patience for folks who don’t just get stuck in… Your idea sounds interesting, so when you’ve actually built it or started doing so you let me know.
Well good for you. I work 8 (paid) hours a day, and usually another 5/6 when I get home. I also nearly always work on my projects at weekends, and I’ve been doing all this ever since I started working in games professionally (about 2-3 years ago). I wouldn’t expect anyone else to be like that, but one of the things I love about this industry is that you get out what you put in - which filters out all the folks who are “all talk and no balls”.
Now that I’ve blown enough smoke…
The difference between AAA and Indie isn’t team size, it’s how you publish. The dictionary definition is that if you self-publish, you’re independent - aka ‘Indie’. The title of the thread btw actually says ‘Unity’ dev, and mentions nothing about indie.
In response to the thread title in question… any serious Unity dev would probably not worry about whether Unreal has C# support, because they’re too busy making games in a toolset they’ve spent time learning - and more power to them! What you’re doing right now is akin to walking into France and expecting everybody to talk to you in English.
The problem you have @ - is that you communicate your concerns with the engine by being extremely aggresive towards what’s already there. If you could put together an idea that isn’t simply “Put C# in the engine and support it like the other two languages because that’s what Unity has and what I’m used to”, you might start to get somewhere or have your voice heard. Coming up with ways to improve the existing tools and providing good examples and demonstrate why it’s needed, is a good way to get things done. Nobody is saying that the engine is perfect, but if you want it to improve you need to give better reasoning than “Unity has it” or “It’s better because I said so”.
Bringing things like Nazism and borderline hate-speech into your posts is just going to end with you getting either ignored entirely or banned. On that subject:
We do, and we don’t tolerate it. The rest of the mods have seen the original post and agree with me, so keep circumventing the rules and you’ll end up with a ban. Epic wants to hear feedback from everybody, but there are limits.
Final thing, can we stop posting silly little snippets of code trying to make them smaller and less readable, in some attempt to ‘prove’ how one language is better than another? There couldn’t be a more useless comparison.
When i started 2 years ago with UE4 i saw Blueprints and immediately hated them. I didnt want to use them and hated Epic to force me to use them (partially, AnimBlueprints ftw).
Then i though about publishing something to the upcoming marketplace, and i already had a topdown system for my own game. And, omg, no code allowed at that time, Blueprint assets only.
Well sh**, ok, i need to convert everything from C++ to Blueprints.
Fast-forward 3 months:
I fu**ing love Blueprints! Iteration is so fast (with the obvious flaws when you could do something in code with a short line and need 5 nodes in BP to do it), if i need anything exposed to Blueprints that wasnt yet, i just expose it myself, if i need helper functions (array sorting and general array handling as a prominent example) i just code that and expose it via Blueprint macros. Setting up replication is a breeze in Blueprints, as compared to the code version (and even with unrealscript i had a hell of a time with replication, making everything work correctly).
Also i often hear so many people ranting about performance, and how blueprints are so slow compared to “fill-in-anything-you-want-”. Most of these people never had any performance issue with Blueprints and dont have any idea how the VM for the managed code works. They often think “well, my function takes n milliseconds in C++ so it will take n*10 milliseconds in blueprints. bad performance everywhere!”, when its actually just the call out from the VM to native code that has a performance issue and takes time.
Agreed, a few people do have performance issues when using Blueprints. And from my experience its 99% not the fault of the Blueprints itself, but really bad coding. This is actually the real bad thing with BPs, you are tempted to ignore programming patterns or think you dont need to know what you are doing. When i see people filling up their Tick events with code and then blame Blueprints to be so slow, i really want to slam my head on my desk.
So, talking about C#, its fun. Its also slow compared to C++, since its also managed code (the people demanding C# as a scripting language wouldnt use any @Unmanaged annotations in C#). Iteration times would probably a bit faster than with BP since you dont have to draw lines. But the intellisense will never be as forgiving in searching as the blueprint search. Also i have yet to see how intellisense performs for C# on an API that would be that big.
