ZEQ2 Lite

Wednesday, August 12, 2015

Wh1t34Gl3(SAS) wrote : I should try this unreal engine one day.. I wonder how different it is from unity.

Zeth wrote :
I'd love to see a bulleted "breakdown" of what actual Unreal users feel are real advantages versus Unity in another thread.

I think the biggest difference is UE4's new "code-free code" approach with Blueprints as a visual scripting tool.

You can still write code traditionally in C++, but with Blueprints you almost don't even need to unless you're doing something really intricate and complicated.

Edit: Basically, Blueprints work like a series of flowcharts, and you just plug the nodes in to make the engine do what you want. For example, the attached image below is the blueprint node setup I used for my mêlée system. They can get really large and elaborate, and can do quite a lot. So far, I haven't come across a developmental task that can't in some way be figured out in Blueprints with enough thought.

Wednesday, August 12, 2015

That's just a node-based state machine. They've been around long before Unreal. Even Unity has more than a half dozen different ones to choose from in the asset store.







The problem largely with (most of) these is that, while they help a non-coder develop flow of logic and build basic systems, they largely still rely on single-instance flow from what I've heard. That is to say, they are hierarchial -based rather than component-based.

I assume you can inherit one blueprint from another, but how easily can Unreal's blueprints communicate with one another? Can I have a Walk blueprint and a Jump blueprint and bridge them with 3rd communication/controller blueprint? Good component-oriented design is all about standalone systems that don't have a direct reliance on other systems. Your Walk action should not have a single line of code concerning Jump or Jump checks -- but at the same time it needs to not be able to activate while you are Jumping; this is where the bridge/controller comes into play.

Having one massive class (or blueprint/state machine) for something is an archaic design pattern that VERY quickly can spiral out of control on even a moderately ambitious project. As the class grows from new features, debugging becomes more heavy-handed and redundancies starts to appear. Webs of inheritance/polymorphic chains inevitably have their own sets of shortcomings as practices of OOP can only go so far once there are enough unique systems that demand reuse of code.

Thursday, August 13, 2015

To be honest, I'm still learning a lot about Blueprints, so I'm not entirely sure what its full limitations are exactly, so I can't really answer all those questions.

I can say that they do pretty effectively communicate with each other, either directly through casts to the targeted class, or semi-directly through Interface Blueprints which act as a sort of "communication director" that receives and then sends messages from one Blueprint to another targeted one.

In the case of "jumping" and not allowing "walking" at the same time, I think it is possible by using a Blueprint Function Library, which basically lets you create the individual Functions in a single file that you can later call from other Blueprints.

For example, I just tested it real quick by creating a very simple function in a Function Library that spawned my Kamehameha mock-up which I was able to call from my Character Blueprint. So I think it is possible, yes. You can also have multiple Function Libraries, so you can keep them organized by having related functions all grouped into separate files if there's a lot of functions and you want to better sort, organize, and classify them.

The only drawback with Function Libraries, if I understand them correctly (Honestly, I hadn't thought to try using them before now, so I'm still a little iffy on them), is they don't store any variables, and use only local variables, so anything that has to be remembered after the function has completed its task has to be handled by the Blueprint that called it by passing on whatever the desired variables are to the BP that needs it.

And I wasn't saying that visual scripting is new, cause I know it's not. I was just saying that it's probably the biggest difference between UE4 and Unity, because while you mention that there's plugins for Unity to do it, it's a native tool in UE4 that the majority of the engine is built around. That's not to say it's "better" or anything like that, but I do find it rather intuitive to use.

Thursday, August 13, 2015

First question, can we see the scripts of these blueprints ? Or only this hierarchical interface is available ?

Personally, I prefer coding everything myself. Even if it takes more time (and even longer when learning), there's much more control over everything, you know your code and can explain it better (in case of open source/team work), have better chances to see/fix flaws in it and you can go more thorough in details than with this basic functions linker.

Seeing how basic is the thing, it's maybe not a great idea to rely fully on this system. You must be at any time ready to write some lines yourself.

Also, in case you make it an open source/open to team work, this system will be highly inappropriate for obvious reasons.

Quickly, you still need a moderate good level of coding knowledge to make a game (for more efficiency), and most importantly when planning to make it an open source/open to team work.

Second question. Unity 5 update was mainly the add of a new UI conception system. Using special components and functions. Is Unreal using the same kind of system ?

Thursday, August 13, 2015

I can say that they do pretty effectively communicate with each other, either directly through casts to the targeted class, or semi-directly through Interface Blueprints which act as a sort of "communication director" that receives and then sends messages from one Blueprint to another targeted one.

In the case of "jumping" and not allowing "walking" at the same time, I think it is possible by using a Blueprint Function Library, which basically lets you create the individual Functions in a single file that you can later call from other Blueprints.

A function library sounds like a shared codebase. And no, they wouldn't have any instance variables if they were simply static functions/methods. Interface blueprints sound interesting, but I would hope they would be usable on more than just a 1 to 1 relationship.

And I wasn't saying that visual scripting is new, cause I know it's not. I was just saying that it's probably the biggest difference between UE4 and Unity, because while you mention that there's plugins for Unity to do it, it's a native tool in UE4 that the majority of the engine is built around. That's not to say it's "better" or anything like that, but I do find it rather intuitive to use.

Don't get me wrong, I'm all for visual behaviour systems. What do you think the 2007 Zios Engine/Editor were all about, after all? Although I've never really been struck with enthusiasm for node-based charts for representing flow, I can see how they offer quick comprehension in simple cases.

You are correct that Unity doesn't have anything native for visual scripting (except with Mecanim's statemachine concerning animations). While I have personally already built my own component-oriented "no coding" system in Unity, I can understand that not all individuals would feel so inclined.

That all said, I don't think such visual logic systems are paramount to an engine's overall quality (performance-wise or in terms of complexity/overhead of work flow). Popularity and ease of use for traditional non-developers? Sure. However, if it was the only governing force behind successful game development, we'd see a LOT more Gamesfactory, RPG Maker, and other such 'click together' engines being widely used on commercial/indie products.

Blueprints are a nice feature to provide a less steep learning curve, but are they really the only significant feature difference in engines? Asset management/importing/exporting, API exposure and documentation, zero-delay turn-around testing on code/shader/etc. changes, intuitive and uniform editor interfaces, and abstract, backend systems that cater to any product (rather than provide a framework for one kind) are far more critical in my book.

First question, can we see the scripts of these blueprints ? Or only this hierarchical interface is available ?

From what I have heard, they flatten down to compiled code for performance.

Personally, I prefer coding everything myself. Even if it takes more time (and even longer when learning), there's much more control over everything, you know your code and can explain it better (in case of open source/team work), have better chances to see/fix flaws in it and you can go more thorough in details than with this basic functions linker.

Well, this IS coding it yourself. You shouldn't be against a visual form of it. These kinds of systems are inevitably the future since they can enable you to waste less time, offer more re-usability, and manage code better at a glance. Are they at this point of functionality yet? That is yet to be determined.

Seeing how basic is the thing, it's maybe not a great idea to rely fully on this system. You must be at any time ready to write some lines yourself. Wink

I hardly think it's basic, but yes, if you aren't careful you can create a messy, massive web of execution.

Also, in case you make it an open source/open to team work, this system will be highly inappropriate for obvious reasons.

What reasons are those?

Quickly, you still need a moderate good level of coding knowledge to make a game (for more efficiency), and most importantly when planning to make it an open source/open to team work.

As I mentioned, these are actually flattening down to raw C++ code so there should be no performance cost.

Second question. Unity 5 update was mainly the add of a new UI conception system. Using special components and functions. Is Unreal using the same kind of system ?

Unity 4.6 added the new UI handling. Unity 5 was mainly about making pro features free and providing supplemental realtime and new baked lighting solutions. I'm not certain on the specifics of Unreal's UI system, but that may actually be one of its weaker areas if I recall correct.

Thursday, August 13, 2015

Zeth wrote : A function library sounds like a shared codebase. And no, they wouldn't have any instance variables if they were simply static functions/methods. Interface blueprints sound interesting, but I would hope they would be usable on more than just a 1 to 1 relationship.

Interfaces themselves are a separate file with just the Function calls, but not the functions themselves(Those are handled by the Blueprints they're communicating with), and all they do is send the messages between the Blueprints so they can communicate a little more efficiently and tell each other which functions they need to execute. You can have half a dozen different Blueprints files all using the same interface, and if need-be, call them all up to execute a specific function at the same time using For Each Loop node by grabbing them all with a Get All Actors With Interface node, so... Yes to that I think...?

Unity 4.6 added the new UI handling. Unity 5 was mainly about making pro features free and providing supplemental realtime and new baked lighting solutions. I'm not certain on the specifics of Unreal's UI system, but that may actually be one of its weaker areas if I recall correct.

The UI is a bit of a weaker area, as there's plenty of issues with configuring and setting it up properly in a timely fashion, particularly with setting up any form of saving and loading system, which can become a massive web of nodes quite rapidly the more variables there are that you need to save. There's a "Advanced Save" plugin someone's selling on the marketplace though, so it might help alleviate that issue, but otherwise natively, saving a conglomeration of variables that an individual character can have can become a very messy process very quickly.



Then again... I can probably simplify my own saving systems in Spritehaven (Which currently are atrociously more complicated than they really should be...) with some singular "all-inclusive" variable Struct Blueprints with a series of Enumerators, Integers, Bools, and Floats to represent each individual variable, and then just save the Struct data by itself instead of grabbing and setting each individual variable separately which is what my current setup entails, since I'd be saving a set of variables from a few nodes, rather than over two-three dozen individual variables being spaghetti-webbed across my Blueprint Graph... In which case... Saving might not be as much of a hassle as I thought, I've just been doing it the wrong and inefficient way, and probably wouldn't have thought about the "right" way to do it (assuming it actually would work, I need to test it first...) without this topic having come up, so thanks I guess.

Thursday, August 13, 2015

Well, this IS coding it yourself. You shouldn't be against a visual form of it. These kinds of systems are inevitably the future since they can enable you to waste less time, offer more re-usability, and manage code better at a glance. Are they at this point of functionality yet? That is yet to be determined.

As far as I understand, this is only parts of code, general ideas, being linked to make a fragile but well enough structured code. I prefer controlling everything, writing all of it myself to avoid confusion or any other kind of problems.

What reasons are those?

Ambiguous, only general ideas put together, no precisions, real coders and the domain of coding are lacking in identifiable function in projects of the kind of ZEQ2-Lite. It is easy to read, and better for the eyes, but I wouldn't recommend this kind of systems for more than one individual. As you said, it is to be determined how functional and useful they are actually.

As I mentioned, these are actually flattening down to raw C++ code so there should be no performance cost.

I wasn't talking about performance, but how usable and efficient this system is. It seems quite fragile at the moment, maybe in few years we will be able to do things this way. Games conception will then look like roblox and the fact everyone can make games so easily will maybe have an effect on the market..

Unity 4.6 added the new UI handling. Unity 5 was mainly about making pro features free and providing supplemental realtime and new baked lighting solutions. I'm not certain on the specifics of Unreal's UI system, but that may actually be one of its weaker areas if I recall correct.

Yep, I know they ported it on the 4.6, but still think the new UI handling is the biggest addition of the update. If I recall, it was saying something like "Unity 5 introduce the new UI system [...] it is also available on the 4.6 version of the editor", I'm not sure about it.

Thursday, August 13, 2015

Wh1t34Gl3(SAS) wrote :
I wasn't talking about performance, but how usable and efficient this system is. It seems quite fragile at the moment, maybe in few years we will be able to do things this way. Games conception will then look like roblox and the fact everyone can make games so easily will maybe have an effect on the market..

Firstly, it's actually very usable and if built right, can be pretty efficient. There's been plenty of examples of full games being built purely with Blueprints already, and if you follow Epic's Unreal Engine channel on Youtube, they do a showcase every now and then on some of them, and also show off some of the better entries to their monthly Game Jams, some of which are rather impressive.

Secondly, Unity, Flash, UDK, and UE4, and any other cheap/free/accessible game engine are already having an impact on the market.

Take for example Nintendo's WiiU, it's actually been getting a good number of games made for it by indie teams, many of them using Unity. The XBOX One and PlayStation 4, I'm sure(I don't have either of them yet...) also have a bunch of indie titles being made for them as well.

Then factor in Steam Greenlight, and iOS and Android developers, tack on top of that the additional funding resources from the many available crowd funding websites, and you can see just from that how much the market has changed in the last ten or so years alone. Being an indie developer once upon a time use to be impractical unless you already had a lot of money, but now it's actually a feasible side-job for some, and a full time career for other.

Thursday, August 13, 2015

Zeth wrote : That's just a node-based state machine. They've been around long before Unreal. Even Unity has more than a half dozen different ones to choose from in the asset store.







The problem largely with (most of) these is that, while they help a non-coder develop flow of logic and build basic systems, they largely still rely on single-instance flow from what I've heard. That is to say, they are hierarchial -based rather than component-based.

I assume you can inherit one blueprint from another, but how easily can Unreal's blueprints communicate with one another? Can I have a Walk blueprint and a Jump blueprint and bridge them with 3rd communication/controller blueprint? Good component-oriented design is all about standalone systems that don't have a direct reliance on other systems. Your Walk action should not have a single line of code concerning Jump or Jump checks -- but at the same time it needs to not be able to activate while you are Jumping; this is where the bridge/controller comes into play.

Having one massive class (or blueprint/state machine) for something is an archaic design pattern that VERY quickly can spiral out of control on even a moderately ambitious project. As the class grows from new features, debugging becomes more heavy-handed and redundancies starts to appear. Webs of inheritance/polymorphic chains inevitably have their own sets of shortcomings as practices of OOP can only go so far once there are enough unique systems that demand reuse of code.

yes you can have all of those things, you don't have to make everything in one blueprint you could always open a separate event, or just divide them using a simple comment box or create totally separate blueprints and have them call each other, many possibilities

everyone has a preference I just like the way things are done within ue4, but anyway this is a terrible thread haha

Thursday, August 13, 2015

Yep, I know they ported it on the 4.6, but still think the new UI handling is the biggest addition of the update. If I recall, it was saying something like "Unity 5 introduce the new UI system [...] it is also available on the 4.6 version of the editor", I'm not sure about it.

5.0 brought zero new UI features. Even the press releases don't highlight/mention it. It'd been out for more than half a year already prior to 5.0 releasing. It's a fairly decent upgrade, yes, but it was most certainly not a feature of the newer version.

You are most certainly thinking of 4.6.

I wasn't talking about performance, but how usable and efficient this system is. It seems quite fragile at the moment, maybe in few years we will be able to do things this way. Games conception will then look like roblox and the fact everyone can make games so easily will maybe have an effect on the market..

You're speaking like this is some kind of idea that's in its infancy. These kinds of systems have been around (and in use) for well over a decade. This is just one of the first times it's been put natively in a triple-A 3D game engine (without being an addon/plugin).

I'd hardly call it fragile nor suggest that it needs a grand set of revisions to "mature". The only shortcomings and issues of the system (as with most systems) would fall to the user's domain.

Ambiguous, only general ideas put together, no precisions, real coders and the domain of coding are lacking in identifiable function in projects of the kind of ZEQ2-Lite. It is easy to read, and better for the eyes, but I wouldn't recommend this kind of systems for more than one individual. As you said, it is to be determined how functional and useful they are actually.

Yes, it's most beneficial for prototyping; however, that doesn't mean it can't be precise or do more complex things. Even hand-written code can get out of hand on a large project if you don't have establish coding standards. Whether it's for an individual or a group is irrelevant if the design is poorly planned.

As far as I understand, this is only parts of code, general ideas, being linked to make a fragile but well enough structured code. I prefer controlling everything, writing all of it myself to avoid confusion or any other kind of problems.

You can build entire games/applications with visual flow charts. Think of it more as an "alternative skin" to a programming language you already know. You still have the same power since you are still using the same principles of classes, variables, methods, loops, etc. You are just doing so using more streamlined interfaces.

There's very little loss of fundamental control in a proper visually scripted environment.

yes you can have all of those things, you don't have to make everything in one blueprint you could always open a separate event, or just divide them using a simple comment box or create totally separate blueprints and have them call each other, many possibilities Wink

Options are always good, but I do wonder how many individuals are actually practicing GOOD design practices. I fear a lot of early developers will think that "just achieving something that works" is the same thing as making results not only perform well, but be manageable and maintainable in the long run as part of larger systems. DESIGN is everything.

everyone has a preference I just like the way things
are done within ue4, but anyway this is a terrible thread haha

What an asinine remark given that this is one of the few intelligent threads that even exist on these boards. Considering the objectively historic and scientific tone of the discussion, this hardly is something to bring subjective matters like "preference" into.

Information-packed discussions and debates are the extrinsic purpose to any forum and one of the main reasons the internet was BIRTHED to begin with.

Thursday, August 13, 2015

Bored are we Zeth? Haha I still believe it comes down to personal preference but what do I know

Friday, August 14, 2015

Bored are we Zeth? Haha I still believe it comes down to personal preference but what do I know Smile

Preference means nothing in this case. It's not quantifiable or useful in a technical breakdown thread. We're talking pure measurable data/attributes here. If you don't have objective input, please do not post.

Postscript : Please do not quote unless you are responding to a particular sentence, comment, or paragraph.