Blueprints are a toy. Which serious Unity dev would use UE4 without C#/F# or UnrealScript!?

50/50 isn’t only for game.
game development has its constraint as any other computer speciality.
I have no practical experience with those but
big data, I’m guessing that TB, PB that goes daily in even bigger databases must have it constraint if you want to be able to exploit those data with efficiency (even more with data that are of the unstructured form).
same apply for high frequency trading programs

ok, I want an unoptimized-sloppy-bad-code detector in the next version of UE editor :slight_smile:

If I really wanted C# in UE4 I would gather a group of like minded and approach Microsoft about it. Maybe start by contacting the devs of the UWP branch. MS have a bigger incentive to get C# (with .NET Core) usable with UE4 than Epic do, but I’m sure Epic will be supportive of the effort like they reportedly was with Skookumscripts development.

(I like C# and would love to see solid support for it. But Epic need to keep its focus, which in this case means making sure the support for third party languages is rock solid.)

You should probably follow Sweeney on Twitter first. Then you wouldn’t be posting such suggestions as I don’t think M$ would be forthcoming after blasted them so many times :wink:

Where is the function signature? And how does return work?

Because in F# it is possible to return values without a return keyword. And in some cases, unlike in C#, F# won’t require a class either. Yeah, neither does C++ need a class for a function. However, given fact C++ does have headers, it ain’t ideal for scripting in anyway.

Yeah, that’s a logical thing to do. I’m also still unsure which language to use I the first place. I want code noise reduction, too.

Actually, I even would prefer to choose a custom language. The Node Graph is defined by some kind of text already. It just read and than the nodes are rendered.

I want more questions answered to myself. Like, some nodes do have more than one execution pin. I was wondering how to translate that into an text editor that could show multiple source blocks next to each other.

I understand what you are saying. But I said that in the other thread of mine already. I’m not thinking now as a “game designer”, or “game programmer”. I do think now as a programming langue designer or tool developer. What I do shouldn’t be confused with the excuse that I don’t understand something or find it too hard.

I was making an extension for Unity called Essential State Machine. It was supposed to be a perfect mix of PlayerMaker and NodeCanvas. Obviously, this project is dead now since I’m strongly considering to stay with UE4. But I noticed back then already that such things indeed need time. I will only take notes and raise some ideas regarding UE4’s “thick” programming solution for now.
M$ is implementing a module system for C++. Let’s see how this is going to turn out. Headers are obviously not ideal for “scripting”. So a module system for C++ would change a lot.

Blame id Software for my “technological ambition”. Quake 3 wasn’t just some perfect game for me, but also an icon of technological superiority. And programming itself alsways mattered to me.

So node graphs are a toy that looks like Lego. And C++ is the hideous sister of C#. :smiley:

Its not enough to think as developer of some specific field, you need to be the developer of this field or atleast tying to become one. Its really easy to sit on your couch, think about problems and teach how other people should do stuff, especially if your teaching its just a course and not actual implementation.

Why having a function if you don’t need it? Isn’t this what you looking for? Noise reduction, simplification and all that stuff? I only implemented your example in python, which in this case, achieved better the goal than C# and F#. Your examples did required a function, because those language required, just like C/C++ require at least a function.

You are never satisfied. You are one of those “my way or the highway” kind of guy.

Well, right there you contradict yourself. Quake 3 was written in C and the follow up engines were written in C++. Apparently Carmach didn’t think C# has use in game development.

C# would rather be hideous offspring of C++

I honestly don’t get the particular obsession with C#. Like yeah, it’s ok, I have no complaints.

If the primary concern is cross-pollination of skillsets among gamedevs(write c# everywhere!), that’s a dead-end argument in the tech field, you simply can’t expect or rely on every tool you use always supporting your particular language. It’s nice if it does happen, but it’s an unreasonable expectation to have. On top of that, if your goal is to open development up to the largest amount of developers, UnrealJS solves this issue better, JS is significantly bigger than C# in terms of practitioners.

If the primary concern is a text based scripting language, Skookum and UnrealJS solve this, not only do they solve this, they solve it quite well. I’ve been using Skookum extensively and if given a choice, would choose it over a C#(and I have extensive professional C# experience), it brings a lot to the table and I think people write it off too quickly because the syntax scares them, but once again in tech you have to adapt.

I just don’t see a valid argument for C# in particular that doesn’t ultimately boil down to some form of “I learned C# in Unity and don’t want to put in effort learning something else”, which to me is already a bad position, because the syntax of C++ vs C# vs whatever is not that much of a barrier. Even if UE4 was based on C# out the gate… learning the engine API is 98% of the work, not C#, so those skills you bring over are not even valuable enough to hinge onto so tightly.

All that said, I would like Epic to officially support a high level text based scripting language, whether it be C#, JS, some text based BP language, officially support skookum, anything. Right now SK is the missing piece of the puzzle for UE4 use imho, but I’d prefer a standard we can all rally around, and don’t particularly care what it is.

Btw, is a good example that should put to rest argument about BP vs the rest of the languages: https://www.unrealengine.com/blog/building-bears-can-t-drift-for-console-release

PS4 game made with BP only !!!

BP is not a language and can’t possibly be better than a text language.

So, the fact that it gets the job done (e.g. making complete games without touching C++ and releasing them on any available platform) doesn’t really mean anything to you? Then you are using wrong engine and you are in the wrong field altogether! (and in the wrong forums perhaps too)

Imo blueprints are fine. We tend to use a mix of C++ and blueprints, I don’t see the beef with them to be honest. They are great for non-programmers, and they are also fine for most game logic. Old school programmers will prefer text based approaches, they are easier for a lot of things. People who are not programmers though will find blueprints easier. That having been said, I started in 6502 assembly more than 30 years ago, definitely fall into the older school category, but I find myself using blueprints quite a bit and think they were a great addition to the engine. The fact that the materials, blueprints, animation scripts follow similar visual formats makes it easy for people to grasp the code, which is fine. And it’s quite easy to interface between C++ and blueprint.

The argument that blueprints are not a language is beyond silly. It’s obviously a high level scripting language. Because it has a visual representation doesn’t make it any less of one.

Exactly this! I’ve studied game design, went the artist direction and we used Unity for our bachelor project, that was 8 years ago. Unreal was not available for free back then and I still regret not having used/learned UDK in the first place! It’s just so much superior in so many ways. Of course can use the engine he likes but for me, Unreal is the way to go after having played with Unity for over 6 years now. You truly see the years and years of experience Epic has.

Letting the artists have access to the game-logic via Blueprints was THE next step on improving the Engine, there are far more artists than programmers out there and if you have a big team of contributors to a project it’s just super efficient. And I also see no problem to implement functionality in C++ later on if needed. All those little extra editors/tools in Unreal (Persona, Cascade, Sequencer, Material Editor) are huge programs in itself you have to learn first to master them. Last but not least the visual representation of UE4 Editor is so much better. I had to use Unity 5.3 at work recently and wow, was I bored by the gray UI. And of course Unreal is now for free, another huge bonus. So for me, Unity is the toy, who would seriously use Unity for games when he has Unreal ? :stuck_out_tongue:

Oh and the people from Epic are the only human beings on this f**ed up planet who could make me learn C++ 2 years ago - as an artist. Just because I wanted to know what it’s all about and be able to make my own mutliplayer experience. Thanks for that btw! :smiley:

1 Like

I’ve already said before that I find BP not readable and completely different to programming. Also as an indie hobbyist (I code and create art) I don’t want to be compiling C++ either!

I’ll use any free engine I please, friend. And no, BP is not a field.

Can’t really agree on that matter. If that tool(Blueprints) allows to complete same task as programming(Release a working product on multiple platforms) and development process based on same basic principles as programming on C++/C#/Java/Basic/Any other language you like then it’s definitely not completely different to a programming.

goes ~le me posting this again…
~le story of a Mel, a real programmer:

https://www.cs.utah.edu/~elb/folklore/mel.html

Which serious Unity dev would use UE4 without C#/F# or UnrealScript!?

None. Because any serious Unity dev would stick to Unity because it’s the best tool for him/her.

Which serious UE4 dev would use Unity without any of the stuff UE4 has that Unity doesn’t!?

None. Because any serious UE4 dev would stick to UE4 because it’s the best tool for him/her.

Stop comparing UE4 to Unity, they’re different, if you’re happier with Unity and offers you better results and workflow, you’re not just wasting your time, you’re forcing yourself and us to a lot of frustration.

I made a crude first concept with Photoshop for a custom language. I hope there are no mistakes in there. It’s a text based language but it also allows to make use of that what node graphs do well: Visualizing the execution flow.

This is a normal Blueprint graph. Some old stuff I did for prototyping some time ago.

This is a text based language that is also able to make use of the execution pins in node signatures. Functions like “ConsumeEnergy”, are divided into execution blocks which are text based code parts.

Another look without all the red. I just go ahead and give this concept of a custom language for UE4, the name Blackprint.

So far, I can see how Blackprint can actually even take the best of both worlds, node graphs and source text. Of course it’s too early to say if this really could work out this way, however.

  1. First advantage over nodes are the comments. Just type the comments down, the execution blocks are all text. No eventual readjusting of the comment background if nodes are added or removed.
  2. Like node graphs, Blackprint also does visualize executions. Every time you call a function, or even macro with multiple exe pins, after the execution block the function was called in, more empty execution blocks will appear automatically. Invalided execution blocks that got their calling function deleted, are put on a list so that their code ain’t lost and can be reattach to another execution block entry point. Marked by the arrow.
  3. Like with source code where one would just type down a variable’s name to access it, you can do the same . So no extras dragging of connections lines to another node which can result in Spaghetti.
  4. Obviously since this is text based, you won’t have to drag around nodes to layout if any nodes are added or removed.
  5. Text is far more compact than a node. And compared to C#, Blackprint does have code noise reduction.

In case it ain’t obvious. That green “ClampFloat” is a pure function. So, the input comes in front of it, and the output comes after it. Just like with nodes. Also, since in a node graph, a pin can have a default value, a keyword like “def” to use a pin’s default value, also should be introduced.

In my free time or on weekends, I will do more side by side comparisons to see if my idea is worth it, or can be done. Flow control is unexplored so far. But events should work fine. Every execution block entry point, which is the arrow, is a spot where also an event should be able to tap in. I mouse click on a fat arrow, could show a list of possible events that could fire the execution block.