Not exactly the first thing a new developer to UE4 does, especially when transferring from Unity. Hate on BPs == premature optimization.
[=bleeds187;408560]
Not exactly the first thing a new developer to UE4 does, especially when transferring from Unity. Hate on BPs == premature optimization.
[/]
Yep; I had 3 years experience on Unity and other half a dozen engines, from objective-C to C# and C++ plugins and tools Iâve built, some used by known studiosâŚ
Yet I invested more than 4 months exclusively to Blueprints never touching any code at all just to see till where it could take me. I then knew for sure that if you donât need engine customizations, you pretty much donât need C++.
You even have a in your sig. 
Canât compile a blueprint to a as far as Iâm aware. We need to add a side case where we understand that plugins are like packaged engine customizations. I certainly canât talk to DLLs using blueprints. All the stuff does works way better as C++ modules.
Thanks guys.
My problem with BP is not the performance (although I have plenty of prototypes on hold because of performance issues, and BP isnât exactly performant), but the problem is, I think writing code is a really nice way to program. I donât like visual programming at all. I canât even stand the material nodes in most 3D packages and surely donât want something similar to create logic.
Also, I donât consider my C# knowledge âbasicâ. I once opened an âadvancedâ book on C#, and perhaps that book was just not very advanced, but I knew 90% of what was there, like Threads, Generics, Events, Lambdas, Delegates, etc. Iâve programmed in C a lot in the past too (AVR microcontrollers), and I did try some technologies like Allegro and SDL on the old days before I started using Blitz Research products.
I really appreciate having an âeasyâ language for stuff that doesnât actually need performance, but visual stuff just scares me away.
Another point is that I just canât seem to find docs when I need. For example, procedural generation is a thing for most of my games, recently Iâve been using a modular approach since the ROI is better imho, but Iâm very interested in Mesh generation. For Unity itâs simple to find, I type âUnity Meshâ on Google/Duckngo/Official_Docs and I end up exactly where I want, all info I need on my fingertips. In case of UE4 Iâm yet to find the equivalent docs (in a concise and exemplified way if possible), and Iâm sporadically searching for that for months, no kidding. Iâve seen the pages on âUMeshComponentâ, âUProceduralMeshComponentâ, âUStaticMeshâ, etc. but nothing conclusive. Perhaps thatâs just me being real dumb but the docs are failing miserably for me. The API also seems too much complicated for a newbie. UObject has 2000 derivates. Iâm not saying thatâs bad per se, but definitely itâs not noob friendly.
Also, on a less important note, header files annoy the **** out of me.
C++ is not like C#, especially with the UE4 macros, conventions and added complexity; its not for the feint of heart (not saying you are, but until you do a big project with UE4 C++ you should want to do nothing more than a Hello World and work up the chain).
As for perf concerns that just loom these threadsâŚthere arent any; in a single folder of a UE4 project I am currently on we have over 1000 Blueprints (one thousand, yes) that weigh in at over 300mbs in file size. I have personally made a procedural placement system capable of randomly generating large interior spaces with props, AI, etc. all controlled by 3 Blueprints and 3 interfaces (you are not limited here).
Considering perf before you are even out of the project wizard is, to put it mildly, putting the cart before the horse. Code is slow, the Editor takes upwards of 20 minutes to compile with Incredibuild and 200GHz of power via helpers; you also would need to compile your client and server targets. At best iterating a single code file and relying on hot reload takes several minutes with incremental linking; changing a BP and hitting playâŚseconds.
Regardless of BPs or code you should not consider optimization until you are much further along and/or are having problems; at that point you are a Ctrl + Shift + , (frame profiler shortcut) from having 90% of your perf answers.
[=;408581]
You even have a in your sig.
Canât compile a blueprint to a as far as Iâm aware. We need to add a side case where we understand that plugins are like packaged engine customizations. I certainly canât talk to DLLs using blueprints. All the stuff does works way better as C++ modules.
[/]
Code required to convert any BP project to a âC++â project and be eligible for compiling plugins:
// MyGame.h
#pragma once
#include "Engine.h"
// MyGame.cpp
#include "MyGame.h"
IMPLEMENT_PRIMARY_GAME_MODULE(FDefaultGameModuleImpl, MyGame, "MyGame");
// MyGame.Build.cs
using UnrealBuildTool;
class MyGame : ModuleRules
{
MyGame(TargetInfo Target)
{
}
}
If that much code is your excuse for not using BPâŚsigh
[=;408649]
Thanks guys.
My problem with BP is not the performance (although I have plenty of prototypes on hold because of performance issues, and BP isnât exactly performant), but the problem is, I think writing code is a really nice way to program. I donât like visual programming at all. I canât even stand the material nodes in most 3D packages and surely donât want something similar to create logic.
[/]
I always wonder how people with absolutely no affinity for visual stuff can even end up developing games. What I understand even less though, with your programming background you should be absolutely ecstatic you can use something as expressive as C++ and have access to the engine code. Even if you donât understand a thing (hell I donât understand 99% of it either, but I sure find it exciting). Anyway, you seem to have made up your mind that blueprints are too visual and C++ is too codey or something, so have you checked out the following intermediary solutions?
https://mono-ueâŚio
Granted, the Mono effort seems to have stopped, but Skookum looks great for someone like you. Itâs been in development for a long time though, and theyâve gone rather quiet, but a release canât be far away now. Maybe you can get on the beta. Just be aware that by avoiding blueprints completely youâll be missing out big time. They are just too integral to ignore. Even if you went with C++ you very much want to use blueprints in tandem. Both are meant to work together.
Even if you donât understand a thing (hell I donât understand 99% of it either, but I sure find it exciting).
[/]
If only had that attitude!
Unreal4 C++ is like C++ on training wheels, donât be afraid of it, get a good book, look at the unreal templateâs codem, figure it out, if you already know C# then it will just be annoying but not hard to master.
This is been said before, the choice of C++ is because is the game industry standard, if you wanna become someone in this industry you have to learn C++, i wouldnât even consider using Unreal if it wasnât for it, as it would be a big waste of time, hence the reason i do most stuff in C++ including game jams.
[=;408537]
I hear people saying that all the time, but so far I didnât actually find anything (guide/tutorial or docs) that doesnât make me feel Iâm going backwards in terms of technology.
[/]
Not sure what you mean there.
The idea is that you should use technology youâre the most comfortable/productive with, not the ânewest/shiniest/most popularâ one.
After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
- because it is garbage collected, you canât actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
- However, unity does not garbage collect scene objects.
- But because it is technically garbage collected you canât apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
- No multiple inheritance.
- No protected inheritance. Interfaces are inheritance.
- No const parameters in functions. No const references.
- No const functions. I wanna ensure that this function canât change my class instance, dammit.
- Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if youâre not using it.
- I believe thereâs trouble if youâll try to pass out parameter to another function with âoutâ parameter. Youâll need to create temporary.
- Type deduction for generics is inferior.
- No type aliases or typedefs. Having to type âTMap<String, TList<MyStructureStorageType>>â every time is great.
- âvarâ does not work in class declaration. âTMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();â! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
- No macros means you canât collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
- Youâll have to use Unity serializer, but it does not support generic types. At all. Youâll need to inherit class from generic type container, then mark it as [System.Serializable].
- Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its .h/.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
- Defining object equivalence by implementing Equals() is âFUNâ. Thereâs no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.
Thatâs just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the serializer out of the box (youâll need to download unmainatained third party script or buy it for $20 from asset store).
The ONLY good feature C# has is reflection (Youâll hear âdonât use reflection, it is slow!â all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And thatâs it. Those two advantages are outweighted by huge number of issues.
So, Iâd rather not see Epic team waste their time impelmenting C# binding. Youâre free to implement them yourself, just keep in mind that according to EULA youâll have to release those language bindings for free.
As it was mentioned, epic team put some effort into making your life easier by implementing some helper facilities. So you shouldnât have much trouble if you already have experience with C#.
[=;408554]
If youâre comfortable limiting yourself to last-gen stuff then Unity is fine for your needs.
[/]
Err, no. Unity has number of superior technologies, except that many of them are buggy.
C# is not one of those better technologies.
For example, realtime precomputed global illumination is still experimental in unreal 4, but it is implemented in unity. You bake scene in specfic way and youâll be able to change light color/intensity on runtime, and changes will propagate across scene, with light bounces. However, on highly modular setup every object might receive random tint (it is significantly worse than lightmass seams) and those realtime baked lights wonât be casting any dynamic shadows.
Also, mecanim can retarget root motion properly, which is not the case with Persona animation retargeting at the moment.
C++ is not like C#, especially with the UE4 macros, conventions and added complexity; its not for the feint of heart (not saying you are, but until you do a big project with UE4 C++ you should want to do nothing more than a Hello World and work up the chain).
[/]
Yeah, perhaps Iâm skipping the âHello Worldâ part. :).
I always wonder how people with absolutely no affinity for visual stuff can even end up developing games. What I understand even less though, with your programming background you should be absolutely ecstatic you can use something as expressive as C++ and have access to the engine code. Even if you donât understand a thing (hell I donât understand 99% of it either, but I sure find it exciting). Anyway, you seem to have made up your mind that blueprints are too visual and C++ is too codey or something, so have you checked out the following intermediary solutions?
https://mono-ueâŚio
Granted, the Mono effort seems to have stopped, but Skookum looks great for someone like you. Itâs been in development for a long time though, and theyâve gone rather quiet, but a release canât be far away now. Maybe you can get on the beta. Just be aware that by avoiding blueprints completely youâll be missing out big time. They are just too integral to ignore. Even if you went with C++ you very much want to use blueprints in tandem. Both are meant to work together.
[/]
Visuals are too much overrated imho. I donât know why everything has to be âvisualâ nowadays.
Also, I donât think most former C++ developers who went C# want to go back to C++, so I donât understand why youâre surprised at all.
BTW, Skookum seems good enough. Thanks for the recommendation. There are things to consider though, specially because Iâve learned my personal quota of âobscure stuff that serves nothing nowadaysâ, Iâm not saying that Skookum is going to fail or something, but I surely have to think twice before investing time learning something that so far doesnât seem very widely adopted, I mean, is that knowledge valuable if I end up not using it at all?
Unreal4 C++ is like C++ on training wheels, donât be afraid of it, get a good book, look at the unreal templateâs codem, figure it out, if you already know C# then it will just be annoying but not hard to master.
This is been said before, the choice of C++ is because is the game industry standard, if you wanna become someone in this industry you have to learn C++, i wouldnât even consider using Unreal if it wasnât for it, as it would be a big waste of time, hence the reason i do most stuff in C++ including game jams.
[/]
Not in the game industry knows C++, thatâs for sure. Perhaps most programmers in AAA industry, but surely not . I donât want to be a âprogrammerâ, so, being able to read and understand C++ properly is more than enough for me imho.
Not sure what you mean there.
The idea is that you should use technology youâre the most comfortable/productive with, not the ânewest/shiniest/most popularâ one.
After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
-
because it is garbage collected, you canât actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
-
However, unity does not garbage collect scene objects.
-
But because it is technically garbage collected you canât apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
-
No multiple inheritance.
-
No protected inheritance. Interfaces are inheritance.
-
No const parameters in functions. No const references.
-
No const functions. I wanna ensure that this function canât change my class instance, dammit.
-
Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if youâre not using it.
-
I believe thereâs trouble if youâll try to pass out parameter to another function with âoutâ parameter. Youâll need to create temporary.
-
Type deduction for generics is inferior.
-
No type aliases or typedefs. Having to type âTMap<String, TList<MyStructureStorageType>>â every time is great.
-
âvarâ does not work in class declaration. âTMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();â! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
-
No macros means you canât collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
-
Youâll have to use Unity serializer, but it does not support generic types. At all. Youâll need to inherit class from generic type container, then mark it as [System.Serializable].
-
Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its .h/.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
-
Defining object equivalence by implementing Equals() is âFUNâ. Thereâs no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.
Thatâs just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the serializer out of the box (youâll need to download unmainatained third party script or buy it for $20 from asset store).
The ONLY good feature C# has is reflection (Youâll hear âdonât use reflection, it is slow!â all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And thatâs it. Those two advantages are outweighted by huge number of issues.
So, Iâd rather not see Epic team waste their time impelmenting C# binding. Youâre free to implement them yourself, just keep in mind that according to EULA youâll have to release those language bindings for free.
As it was mentioned, epic team put some effort into making your life easier by implementing some helper facilities. So you shouldnât have much trouble if you already have experience with C#.
Err, no. Unity has number of superior technologies, except that many of them are buggy.
C# is not one of those better technologies.
For example, realtime precomputed global illumination is still experimental in unreal 4, but it is implemented in unity. You bake scene in specfic way and youâll be able to change light color/intensity on runtime, and changes will propagate across scene, with light bounces. However, on highly modular setup every object might receive random tint (it is significantly worse than lightmass seams) and those realtime baked lights wonât be casting any dynamic shadows.
Also, mecanim can retarget root motion properly, which is not the case with Persona animation retargeting at the moment.
[/]
I agree with much of what you said. However Iâm pretty sure that âlistâ will end up way bigger in the opposite situation :P. Here are some points:
GC - yeah, sucks terribly, I agree, but itâs still much better than not having it imho.
Lack of multiple inheritance really sucks. Workarounds are cheap and crappy.
ref is certain trouble. Sure.
Equals() is sure nonsensical⌠Iâm not sure if thereâs no standard though.
Iâve either never experienced/needed the other stuff, or they work great for me, for example /out/ always was great, and lack of type aliases/typedefs i never really needed but i see how they could be useful⌠autocompletion helps immensely here though, but I agree that it could get too verbose.
Something important you mentioned is the asset store. Everything nowadays ends up in the asset store. Itâs the solution to all your problems, thereâs no problem in that per se, except when most of these solutions clearly should be built-in.
Iâm not a fan of reflection. Sendmessage for example, which is widely used, I find that extremely ugly, or passing a string in GetComponent, it feels to me like bad code that will break soon :P. Most people seems to be OK with that though.
[=;409033]
I agree with much of what you said. However Iâm pretty sure that âlistâ will end up way bigger in the opposite situation :P.
[/]
Donât think so. Iâve spent plenty of time with C#/Unity.
[=;409033]
Something important you mentioned is the asset store. Everything nowadays ends up in the asset store. Itâs the solution to all your problems,
[/]
Err, no. Definitely, no. Usually, every asset you find in asset store has some hidden fun problem you wonât ever discover until you actually buy it.
Buying anything coding-related is definitely not recommended. Thereâs maybe 3 good assets total. The rest is people trying to rip you off.
Asset store is decent (not good, just decent) when you need art assets. Models, or textures. Even in this case, It is highly possible that after forking out $50 youâll discover that the dude who made your pack didnât know how to make proper normals (so every box-shaped object is smooth-shaded, so youâll have to fix them manually), or created ao/normal maps by running diffuse texture (which was taken straight from cgtextures.com) through filter (which will result in a big mess), or that animation pack is pretty much useless because everything is stiff despite allegedly being mocap.
You may want to cut the chase and tell whatâs your point is. If you like unity workflow and C#, unity is still available, last time I checked.
[=;409033]
Yeah, perhaps Iâm skipping the âHello Worldâ part. :).
Visuals are too much overrated imho. I donât know why everything has to be âvisualâ nowadays.
Also, I donât think most former C++ developers who went C# want to go back to C++, so I donât understand why youâre surprised at all.
BTW, Skookum seems good enough. Thanks for the recommendation. There are things to consider though, specially because Iâve learned my personal quota of âobscure stuff that serves nothing nowadaysâ, Iâm not saying that Skookum is going to fail or something, but I surely have to think twice before investing time learning something that so far doesnât seem very widely adopted, I mean, is that knowledge valuable if I end up not using it at all?
[/]
I wasnât talking about high end visuals. Even the most ugly programmer art is visual in nature. Games are a visual medium. Even if you made a game for blind people youâd have to think visually, just that youâd use sound and dialog instead of graphics to paint images in the mind of a blind person.
Skookum is a very specialized game scripting language. The chances of you ever using it outside of UE4 are slim to none. But it has very easy syntax and nothing you learn is ever useless. Itâs also meant to work with both blueprints and C++, not as a replacement though. So thereâs that again.
If youâre thinking about the value of learning a language it sounds to me like you do want to be a programmer, which you refuted a few lines down. So, what exactly do you wanna do in games? Thereâs not a whole lot of room in between visuals and programming really, if you want to do neither. The fields in between are usually hybrids of both sides, like technical artists.
You can plead and hope for C# in UE4 all day long but itâs a waste of time. The chances of an officially endorsed by Epic C# are practically none existent. Too much work for very little benefit. Too narrow a space to cover in between the very scripty blueprints and the very powerful C++. And whatâs so incredibly visual about blueprints anyway? Surely as a programmer youâve made some class or flow diagrams before. Do you consider that too visual as well? Blueprints are essentially just diagrams, what could possibly be so unmanageable about that.
[=NegInfinity;409079]
Usually, every asset you find in asset store has some hidden fun problem you wonât ever discover until you actually buy it.
[/]
Exact. When you Google how to do something, a lot of the times you end up in the Unity answers and most answers are about buying stuff on the asset store, whatâs a subpar solution for most cases, and specially when the problem youâre having should be provided natively by Unity.
[=Gigantoad;409087]
I wasnât talking about high end visuals. Even the most ugly programmer art is visual in nature. Games are a visual medium. Even if you made a game for blind people youâd have to think visually, just that youâd use sound and dialog instead of graphics to paint images in the mind of a blind person.
Skookum is a very specialized game scripting language. The chances of you ever using it outside of UE4 are slim to none. But it has very easy syntax and nothing you learn is ever useless. Itâs also meant to work with both blueprints and C++, not as a replacement though. So thereâs that again.
If youâre thinking about the value of learning a language it sounds to me like you do want to be a programmer, which you refuted a few lines down. So, what exactly do you wanna do in games? Thereâs not a whole lot of room in between visuals and programming really, if you want to do neither. The fields in between are usually hybrids of both sides, like technical artists.
You can plead and hope for C# in UE4 all day long but itâs a waste of time. The chances of an officially endorsed by Epic C# are practically none existent. Too much work for very little benefit. Too narrow a space to cover in between the very scripty blueprints and the very powerful C++. And whatâs so incredibly visual about blueprints anyway? Surely as a programmer youâve made some class or flow diagrams before. Do you consider that too visual as well? Blueprints are essentially just diagrams, what could possibly be so unmanageable about that.
[/]
Afaik, âvisualâ has nothing to do with âstructureâ, but itâs about using your eyes to figure stuff, for example, when youâre coding, a function call is an âimaginary linkâ (sorry the terrible term), when using BP, thereâs no such a thing, the âlinkâ is a visible line on screen.
Also, that statement ânothing you learn is ever uselessâ, unless youâre talking about the little bit of experience you can use on other stuff, is very flawed. Iâm the living proof. I know a truckload of things Iâve never used in practice and surely will never use. It was a huge waste of time learning them.
I donât agree thereâs nothing else in game development than graphics artists and programmers too.
The blueprint âprogramsâ Iâve seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.
[=;409126]
Exact. When you Google how to do something, a lot of the times you end up in the Unity answers and most answers are about buying stuff on the asset store, whatâs a subpar solution for most cases, and specially when the problem youâre having should be provided natively by Unity.
Afaik, âvisualâ has nothing to do with âstructureâ, but itâs about using your eyes to figure stuff, for example, when youâre coding, a function call is an âimaginary linkâ (sorry the terrible term), when using BP, thereâs no such a thing, the âlinkâ is a visible line on screen.
Also, that statement ânothing you learn is ever uselessâ, unless youâre talking about the little bit of experience you can use on other stuff, is very flawed. Iâm the living proof. I know a truckload of things Iâve never used in practice and surely will never use. It was a huge waste of time learning them.
I donât agree thereâs nothing else in game development than graphics artists and programmers too.
The blueprint âprogramsâ Iâve seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.
[/]
in Unreal4 you have the best of the best, Blueprints as an awesome replacement for scripting that doesnât require a learning curve, itâs just intiutive (canât said that about LUA or other crappy scripting language) and then you have C++ which unless you try it in depth youâll love as a programmer, itâs not like people is forced to use it, a lot of developer use it because itâs great, and the fact that 99% of game engines are programmed in C++ proves that. Also if you notice thereâs lots and lots of Unity freelancers, why? because the ones who knows C++ are working on AAA games 
Also i doubt anyone who has done some serious C++ and switched to C# for some reason (by job requirements most likely) donât want to go back to it, it seems to me that this is a âthe right tool for the right jobâ. Said that C++ is the right tool for game dev
If you canât appreciate Unreal 4 that way, then is not for you.
[=;409126]
Also, that statement ânothing you learn is ever uselessâ, unless youâre talking about the little bit of experience you can use on other stuff, is very flawed. Iâm the living proof. I know a truckload of things Iâve never used in practice and surely will never use. It was a huge waste of time learning them.
[/]
My point about learning was that it is knowledge and that never hurts. You can read in many programming books that you should learn several languages. Some go as far and say learn a new one every year. While I certainly wouldnât want to do that, they sure have a point that each language will add a little more know-how. Skookum is the only language actually completely made for game scripting. If you look here
youâll see what makes it special.
[=;409126]
I donât agree thereâs nothing else in game development than graphics artists and programmers too.
[/]
Uh, well what else is there? Music, sound effects, marketing, business stuff of course⌠from what you wrote so far about wanting C# it doesnât seem like youâre interested in those either.
[=;409126]
The blueprint âprogramsâ Iâve seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.
[/]
Blueprints can get messy, no doubt about it. Because of their visual nature they tend to promote bad code habits in general. But with a little care you can keep them fairly clean. You can combine nodes in functions and macros, you have both global (per BP) variables and local ones in functions. You have classes, inheritance, interfaces. Components arenât much different than prefabs in Unity. Itâs just a bunch of stuff that belongs together. There are even blueprint components. Say you want to make a piece of code that makes an actor move up down a bit, like a floating animation of sorts. Make that as a separate component and now you can add it to any actor you want with a few clicks and they will float.
[=Gigantoad;409169]
My point about learning was that it is knowledge and that never hurts. You can read in many programming books that you should learn several languages. Some go as far and say learn a new one every year. While I certainly wouldnât want to do that, they sure have a point that each language will add a little more know-how. Skookum is the only language actually completely made for game scripting. If you look here
youâll see what makes it special.
Uh, well what else is there? Music, sound effects, marketing, business stuff of course⌠from what you wrote so far about wanting C# it doesnât seem like youâre interested in those either.
Blueprints can get messy, no doubt about it. Because of their visual nature they tend to promote bad code habits in general. But with a little care you can keep them fairly clean. You can combine nodes in functions and macros, you have both global (per BP) variables and local ones in functions. You have classes, inheritance, interfaces. Components arenât much different than prefabs in Unity. Itâs just a bunch of stuff that belongs together. There are even blueprint components. Say you want to make a piece of code that makes an actor move up down a bit, like a floating animation of sorts. Make that as a separate component and now you can add it to any actor you want with a few clicks and they will float.
[/]
To tell the truth, Iâve checked Skookum back when I played Sleeping Dogs :P. I always check those techs in games splash/credits. It seems good indeed. The problem is comparing it to C++, I think Iâd rather get some C++ experience than learn Skookum, not that itâs bad or something, itâs just a matter of where Iâm gonna place my bets.
I was thinking game design :P.
I totally didnât understand that part about Unity prefabs.
A language is just the interface to express your logic, if you can express what you need to in Blueprints, then more power to anyone who can. C++ is a bit lower level than C#, and with the UE framework, a lot of the guess work is already removed. As for people going to and from C++/C#, it depends on what your doing, you use the language that makes the most sense for the job, going âbackâ to C++ from C# is no different than going from âPythonâ to âPHPâ, one job required one thing, a different one required another one. Depending upon how adventurous you are, finding something that would bind your c# library to a c++ library is something you may want to look for.
[=Alezrik;409563]
A language is just the interface to express your logic, if you can express what you need to in Blueprints, then more power to anyone who can. C++ is a bit lower level than C#, and with the UE framework, a lot of the guess work is already removed. As for people going to and from C++/C#, it depends on what your doing, you use the language that makes the most sense for the job, going âbackâ to C++ from C# is no different than going from âPythonâ to âPHPâ, one job required one thing, a different one required another one. Depending upon how adventurous you are, finding something that would bind your c# library to a c++ library is something you may want to look for.
[/]
I agree!
That example is a little bit excessive though, Iâm sure that going from C# to C++ isnât as bad as going from Python to PHP. The latter case is much more traumatic and nonsensical, unless of course you need to use PHP systems, otherwise I see absolutely no reason not to use Python, unless you want to get bald. Youâre comparing the best and worst languages Iâve ever used.
Also, I sure agree that there may be reasons to use C++ over C#, no doubt in that, however, I donât see why one wouldnât consider C# completely usable for game development, itâs not like itâs not the right tool for the job, of course there are some âconsâ, but itâs totally suitable imho.
Thatâs not being adventurous, thatâs being sadistic and suicidal :D.
I found some good unofficial tutorials, Iâm gonna give C++ a 89102th try. Another thing to consider is the better âobfuscationâ of your IP, on C# you basically ship your source (open any compiled project with ilspy and youâll get pretty much the exact source), C++ is much better, although of course not perfect, itâs surely not worthy to âdecompileâ a C++ game, itâs much easier to re-code everything, while Unity stuff you can pretty much copypasta code from ilspy and with minor modifications you can use it.
Talking about IP, does BP have some kinda obfuscation?
I have been lurking in this thread for a very long timeâŚitâs about time i posted
The idea is that you should use technology youâre the most comfortable/productive with, not the ânewest/shiniest/most popularâ one.
[/]
I agree with this.
However this
After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
- because it is garbage collected, you canât actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
- However, unity does not garbage collect scene objects.
- But because it is technically garbage collected you canât apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
- No multiple inheritance.
- No protected inheritance. Interfaces are inheritance.
- No const parameters in functions. No const references.
- No const functions. I wanna ensure that this function canât change my class instance, dammit.
- Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if youâre not using it.
- I believe thereâs trouble if youâll try to pass out parameter to another function with âoutâ parameter. Youâll need to create temporary.
- Type deduction for generics is inferior.
- No type aliases or typedefs. Having to type âTMap<String, TList<MyStructureStorageType>>â every time is great.
- âvarâ does not work in class declaration. âTMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();â! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
- No macros means you canât collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
- Youâll have to use Unity serializer, but it does not support generic types. At all. Youâll need to inherit class from generic type container, then mark it as [System.Serializable].
- Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its .h/.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
- Defining object equivalence by implementing Equals() is âFUNâ. Thereâs no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.
[/]
I completely disagree, C# and C++ are two different beasts. How can C# be so unpleasant to work with after using C++ ? Why ? because of what you posted ? Well i could make a fairly good argument to use C# and not C++, because of those reasons, it would take awhile and im at work so Iâm not going to waste my time, but just because those things seem limiting, in actuality they arenât as limiting as you think. I use both in my day job, and both have their place, C++ isnât inherently better than C#, and neither is C# inherently better than C++. Itâs a completely different beast is all. Most of your complaints are things that the creators literally choose by design. You canât complain about the design of a language just because it doesnât make sense for you. C# wasnât even really meant for consumption it was made specifically to be economical towards memory and processing power for a specific company, and was never meant to even directly or indirectly compete with C. I mean the creator of C# himself said that the CLR was driven by the flaws of major languages like C++, java, smalltalk. Which in turn drove the design of C# itself.
If you were to base a comparison of C# and C++ purely on modern features. C# wins.
I donât hear you complaining about C++'s archaic compilation model, all the inherited legacy C garbage, classes vs structs, new keyword, exceptions or the ghastly multiple inheritance implementation, complexity added when operator overloading, template syntax, complicated atomics, c++ never protecting you from yourselfâŚI mean there are allot of problems which make C++ problematic.
Thatâs just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the serializer out of the box (youâll need to download unmainatained third party script or buy it for $20 from asset store).
[/]
A Serializer isnât necessary for game dev, you have to realize what youâre using, a game engine. There are going to be allot of things you donât have. Thatâs why things like an asset store exist. Also, on the same note, in response to you saying you can never really know if a product from the asset store has a bug, well thatâs the same for any program, is it not ? I mean UE4 has bugs. Your games, my games have bugs. yes all software has bugs. you paid for the assets in its current state, you did not pay for something claiming to be 100% bug free.
The ONLY good feature C# has is reflection (Youâll hear âdonât use reflection, it is slow!â all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And thatâs it. Those two advantages are outweighted by huge number of issues.
[/]
To say the only good feature that C# has is reflection is a bold statement to say. Many many people will disagree with that.