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?
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:
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?
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:
[/]
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.
[=;409854]
LOTS OF TRUTH
[/]
I agree 100% with every single word! That’s along the lines of what I wanted to say but I don’t have the talent nor vocabulary of fancy terms :).
There are however some very crappy stuff on the asset store. I mean some bugs here and there are acceptable, but there are really bad quality stuff there, plain broken stuff, you won’t even find bugs to fix because the whole shebang is a mess.
On a related note (sig)… why are most tutorials in video nowadays? I really don’t like video tutorials and I guess it takes more time/work to make them, so why are people making them so much? Do most people like them?
I know it’s totally off topic, but the reasons I don’t like them are:
1- They are too slow.
2- If you have to stop for some reason, it’s hard to catch up again, on text tutorial you just quickly take a look on the previous stuff and you’re good to continue.
3- If you need to go back to some specific part, it’s hard as hell and it takes a lot of time, this is not too bad if the tutorial is separated in various small videos though.
[=;409854]
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 ?
[/]
You’re arguing “apples are superior to oranges!” here.
Languages should complement programmer, and you need something that works well for your mindset.
In my case C++ is perfect fit, and C# is not. Argue all you want, but after working with C# for months I still hate its guts, still find it extremely limiting and unpleasant to work with, and still haven’t found enough of useful features in it. All the arguments in the world won’t change MY experience of the language.
[=;409854]
You can’t complain about the design of a language just because it doesn’t make sense for you.
[/]
Umm, yeah, I can, but not because it “doesn’t make sense”, but because it doesn’t give me enough power compared to alternative. See mindset statement.
[=;409854]
If you were to base a comparison of C# and C++ purely on modern features. C# wins.
[/]
“Newer and shinier doesn’t mean better”.
[=;409854]
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.
[/]
Every single of those tools has a reason to exist and practical application and I used every single one of them. As you said: “You can’t complain about the design of a language just because it doesn’t make sense for you.”. And now you’re doing just that.
[=;409854]
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.
[/]
It is one of the simplest markup languages to implement, it is available for free out of the box in python, and available for free as 3rd party lib in everything else. Selling that for $20 for unity is ridiculous. Ripping off people that can’t google doesn’t sound like the right thing to do for me.
[=;409854]
To say the only good feature that C# has is reflection is a bold statement to say. Many many people will disagree with that.
[/]
Why should that matter if someone disagrees with me? I used the language extensively and haven’t found anything else that I find useful or could classify as improvement.
People disagree on large number of things. Just because someone disagrees with you, doesn’t mean you’re wrong. If everybody has same opinion on some subject, doesn’t mean they’re right. See “appeal to the crowd”.