Is Unity helping or hurting programmers?

A language sporting a garbage collector allows you to write code that continuously allocates memory without care. Situations such as this allow a bad programmer to hide poorly designed code.

Better to catch these early on because they crash the program than to allow them to pile up and have to deal with them at an advanced coding stage.

 

Isn't this topic suppose to be about Unity helping/hurting programmers?

 

C++ let's you do the exact same... so I'm not sure how that helps your case? It's simply a performance issue that can exist in both low and high level code.

In production code with your example, C# means that:

A) Your code isn't crashing unnecessarily.
B) Your tests will easily pick this up if it's an issue, and you can easily address it in most cases.

If GC is causing issues, then go and optimise your allocations (or more importantly, deallocations and references). However do this in say the 2% of your code that exists maybe in every 10th application you write.

 

Managed languages allow developers to continue bad coding practices that an unmanaged language would simply crash under. Unity's languages being purely managed could be viewed as potentially hurting a programmer by concealing poorly designed code.

 

While managed languages often won't even let you compile with 'bad practices' that low level code supports.

Other than GC allocations... which as I noted above isn't a problem (I'd much rather my code run a bit slower than simply crash), what other examples do you have of high level languages 'concealing' bugs?

 

It isn't merely slower. It might be if the GC were running continuously, but the GC runs in intervals. So the result is spikes in performance. These spikes can become visible on mobile or other low end platforms. Even in the event that they are not visible, they are still wasting precious time that could be put to far better use.

 

Oh god, not the spikes!

Option A) You may get performance spikes... that your testing will hopefully pick up and can be resolved.
Option B) You simply crash. If your testing doesn't pick it up... your users can't use your app (which may cause significant mental and financial distress to both them and you).

Of course the flip side is that a good GC might in fact provide a more stable, faster less 'spiky' experience than whatever you conjure up to replace it.

 

Folks, i think you miss the most important point. A language is just a tool. I use my tools to achieve my goal. I don't set my goals to use a tool. That's why i use Unity to create a game. Because my goal is to write a game. Not to write code.

 

Which is perfectly fine but the thread was about whether Unity helps or hurts programmers. In most cases, it won't matter in the slightest. But it does potentially allow badly designed code to be hidden away with tools such as the GC.

 

Which is why Tiles is correct.

With Unity I have something like a dozen apps in the market, all of which are running perfectly fine and delivering value to the end users.

Not one has performance problems because of C#. All of which were much easier to develop (and possible) thanks to C#.

It's a tool that gets the job done.

 

This fact was stated in the original post and was never contested by my posts. The point was not about Unity getting the job done, it was about whether or not it could hurt a programmer's skills.

 

Okay, so it helps a programmer get the job done... you agree and accept this. But you contest that it could still hurt their skills. What skill/s is/are more important that delivering product?

 

A better skilled programmer is...

A) Less likely to introduce poor design decisions that may cause problems later and slow product delivery.

B) More capable of introducing additional program features, both basic and advanced, within given time constraints.

C) More capable of producing easily reusable code that can speed up future product delivery.

Anyone concerned with delivery a product within time constraints should be concerned with the design skills and code quality of a programmer.

 

All of those are simply ways to help deliver product. Given that Unity developers are delivering product, these skills are simply secondary considerations.

Back to what you appear to be claiming, how does using C# (or 'managed languages') reduce a developer's skills in these area's?

Does Unity and C# encourage good design decisions? Yes.
Does Unity and C# enable developers to add additional features within time constraints? Yes.
Does Unity and C# encourage and support reusable code? Yes.

 

But it is highly unproductive to use C++ and a selfmade engine to do the job in a month when you can do the same job with Unity and C# within a day. What tool to use depends of your goal.

So the best skilled programmer is the one who uses the tools wisely, dependand of the goal

 

I think you could be the best programmer and yet a miserable software developer. As others said before, you can only be as good as you know the API you plan to use. If you learned in these years to write c# code, then it's up to you how good you will do with c# on traditional desktop development (if you plan to use .Net or Mono). Then again if you think you need to do software development with c++ or another language then just sit down and learn the language. In the end of the day if you learned once to master a programming language you can adopt to other programming languages as well. This discussions about languages or development environments, what is better than the other one, leads to nothing as longs as people don't invest time to learn a language and the API, someone wants to use with it. But the best tip I can give is stop thinking "what if" and start thinking more "how to", people often make the mistake to think too much about these things and lose time they may have filled with valuable experience.

 

That's not the same thing as a bug, though. If it behaves as intended then it doesn't matter what else is going on. And a lot of the time crappy memory usage or poor performance aren't problems.

Yep. Programming is only one of many skills that are required to develop good software.

 

I will concede with Ryiah and say sure, Unity's managed language harms programmers.

Directly after this concession, I will propose the simple reality that unmanaged languages are less efficient at doing most tasks, raise the amount of time, work, frustration, stress, and thus MULTIPLIES the possibility of bugs or poor performance (due to the programmer being a human, as opposed to this theoretically perfect code-monkey who is always in a stress-free fully-focused state of nirvana).

Either that, or while conceding that managed languages are harmful for Unity, while pointing out that not using the best tool for the job harms your intelligence and efficiency which is significantly more harmful to programmers than the harm he speaks of.

I don't actually concede to his points, but it's irrelevant if he is right or not. There are factors significantly greater to make his point null. It is irrelevant if something harms you, if that harm is nothing compared to a greater harm one could propose.

 

I wouldn't say "secondary", I'd say "supporting". Each one of those things is a part of the core skill set that allows us to deliver and ship. Lacking any of them harms our ability to deliver and ship.

The thing is, I see them as being language agnostic skills.

 

To note though, it is the only skill that is absolutely required to make games.

Although one could argue that with some game engines and assets, it may be possibly to make super simple/easy crappy games without knowing programming.

Art isn't required (Text based games). Interfaces aren't required (Just look at the horror that is Dwarf Fortress), Design isn't even required (Look at all the good games with serious flaws). If you want to make something outside of pre-canned stuff like RPG Maker or a clone of a clone of a clone of an example, then programming is required.

For making games, and especially for complex games, programming is required. You don't even need design or an idea. Some successful games aren't really designed as much as they are cloned or accidentally awesome, so even the "game idea" is not a requirement.

 

Or, y'know, all the many games that exist that don't involve a computer at all. And even in the realms of electronic games your own post mentions a bunch of counter-examples.

I know someone who made a game in PowerPoint.

 

In general I agree. But I make the point they are *only* useful *if* they improve the ability to deliver. I'd hire someone who writes poorly documented, inextensible, 'one use only' code over someone who doesn't if at the end of the day he delivers more/better product/results. Of course, experience shows that this tends to be a contradiction in terms.

I'd disagree, in addition to the concerns raised by angrypenguin I'd suggest looking at the modding community. I'd suspect one can, with no code, reskin a game and reuse existing mechanics in such a different way to result in an entirely different game.

 

You can of course say that even this is some kind of programming ...

The trend goes away from the traditional written languages towards the non text approaches like Unreal's Blueprints.

 

Also, hand waving away art and interfaces and so on and so forth is a) trivialising anything that contradicts your point and b) counter-productive. In a text-based game the text is the art, Dwarf Fortress does have an interface, a design with a flaw is in fact still a design, so on and so forth.

 

I'm referring to approaches that don't program at all, not even through visual or other non-standard means.

In short, someone can go out today with an objective of making a game, say a sea based shooter and achieve that goal without writing a line of code, or implementing any 'logic' in any system simply by reskinning a game.

 

And some modding tools offers a way to "program" game logic, which what was what i was referring to.

But i get your point

 

Especially if we apply to programming the same logic Carter has seemingly applied to other fields, since that actually gives us a lot of scope in our "not programming". If simple art = not art, archaic interface = not an interface, flawed design = not a design... then surely tweaking stuff in a mod or bolting together third party scripts or simple event chaining = not programming?

 

Unity is definitely educational, so yes I think it helps programmers but I think it hurts games because its so easy so many people are putting rubbish out.

 

Sure, if you *only* use Unity scripting, you might not progress as a programmer. But what about practice?

Ultimately, your skill acquisition and education is up to you. It's not the tools fault, if you let your skills degrade.

It's the same as with sports. If you don't return to practicing your basics regularly, your higher-level skills will suffer, too.

So even if you're working mostly with Unity, if you don't want your coding skills to degrade, seek out challenging problems to work on. If you've never done so, hand-code a double-linked list, self-balancing trees, sorting algorithms or what have you.

Create a practice regimen and curriculum for yourself in the same way that an artist might do studies to squash her weaknesses and brush up on basics.

 

I don't understand why you might not progress as a programmer in Unity.
Good programming does not only happen at the algorithm level. Code design is even more important when it comes to bigger code bases and regarding that Unity is neither helping nor hurting programmers. It is necessary to solve design issues, not matter in which environment you are.
Regarding algorithms, there is also lots of potential where programmers can profit within Unity. There are tons of topics that are relevant for games that are anything but trivial to implement.

 

I've skimmed a lot of this thread as it's not particularly relevant.

But I believe if the original question is to refer to programmers as the diverse role to fit into any job position, Unity does not help. Though I don't think it hurts in every situation.

If you learn programming isolated in Unity (a bad idea in my opinion), there are certainly important concepts of programming that will be missed, which comes to the argument mentioned in many other threads that some form of formal learning (college, university), is indeed helpful to gain a robust programming skillset.

Anyone knowing everything they need to know to make a game in Unity looking to move into the games industry at a higher level, with no other knowledge, will absolutely struggle.
(Edit: by higher level, I mean the larger studio developers of the 'traditional' games industry, not developers that also use Unity)

Which is why programming learnt formally as a concept, then practically across both high and low-level languages provides a better base of knowledge than just 'getting stuck in' as is often the advice found in this forum.

The issue comes into play only when moving to something out of the 'Using Unity' comfort zone, which for many on this forum, is probably unlikely. Likely the complaints about languages or other engines, or software, being hard to use, stem from the fact that a lot of this self-taught programming knowledge comes from Unity using a high-level language.

It's not Unitys fault, of course, though I do think it can hurt the self-taught in the long run (if they intend to ever not use Unity) if they are not open minded about the concepts of programming as a whole, or the more complex features of low-level languages.

If no-one ever intends to use anything other than C# (or I suppose, UnityScript), then there's no issue, of course.

 

What I mean by that is, that if you stay in your comfort zone, you might reach a point where you stop growing as a programmer. If that's not even your goal, who cares, but Carter asked if Unity is hurting programmers, and I'm just proposing a scenario where for some people that might be the case. But then again, it's not the tools fault, but the programmer's who chooses to stay in the comfort zone.

[edit] My proposed "solution" works inside the Unity environment.

 

Thanks for the clarification. I completely agree with you!

 

I think if you've been programming in C# for 3 years in Unity and tackling moderately difficult projects I think you would be surprised how well you could do outside of Unity. You should still be learning all the standard patterns and how to apply them to different situations. Learning a new GUI framework like WPF isn't difficult if you know C# and delegates already etc.

Working on solo projects you won't get experience on how to work in a dev team, but tool or language has nothing to do with that.

 

The problem with university etc... is that it teach you many fancy pattern.
When you read a cool pattern in a book, you just want to apply it... even if it's not the good place in your code to do it. And that's a pitfall every beginner fall in (including me..). Most pattern will be usefull one time in your life (and some never).
And sometime, you are even encourage to use fancy pattern by other programmer, because it make you look good...
Even if the result is that it's overcomplicate, and your are the only one understanding it. You are the only one understandint it, and it make you look smarter than other..
It's only when you are an old bastard like me, nothing to prove anymore, that you understand that you need to keep things simple. And you will understand that you are enough smart to invent most pattern. What I mean is that you don't need to read a book to discover the right pattern. Most of the time you just need to think about your problem and you will "create" the pattern naturaly. And that will be the proper moment you will have to use this pattern.

Unity don't hurt programming. But it teach you only patterns usefull for Video game Gameplay developpement.
So you will learn to be a "Gameplay programmer", not an engine programmer. Maybe an ok graphic programmer, if you put your hands deep in shaders. Maybe a network programmer etc..

But you won't learn to make a website...

 

I think it is even mentioned in Design Patterns, that the ideas as not that fancy, because when it comes to certain problems, the solutions are often obvious. The actual benefit is that those solutions got an actual name, which helps a lot when it comes to communication.
Sometimes, it is surprising how many different patterns I am actually using in Unity.

 

oh cmon, that's statistics
statistically i'll never die.. i lived n days, i have died 0 of these days.. probability of dying: 0

but to stay on topic.. i always work as high level as possible for a given task/problem.. why make it more timeConsuming than it has to be if you can achieve the same result? To show off my awesome low level skills? BS.. contrary to statistical analysis i know that i only live a finite number of days.. i don't like wasting them showing off how awesome i am but rather get the job done and let others tell me how awesome i am for my efficiency

 

Depends how you are using C++. First in which context C++ is a crap? Are you trying to do simple/event scripting with? Then yes, is a crap, C++ is not a language to prototype or do simple stuff (scripting languages anyone?). It's a system language that lets you manage memory at very low levels, designed with performance in mind. Hence the reason why game engines and other performance critical applications are written in C++. It will remain in the gaming industry for a long while. C# will never replace C++ and with it's new additions (C++11/14) it's becoming more and more elegant.


But like I said, there's no point in doing simple gameplay programming with C++ (no need to hate C++ for that), for such things use C# or any scripting language. Use the right tool for the job.
Peace.

 

Does it hurt programmers? I think the hardest thing to learn when switching to a new language/framework are the tools and framework itself, not the actual language or concepts (in most OO languages anyway). Generally, if you understand 1 language well enough, you can quickly learn others.

I don't think Unity is hurting programmers at all - Most programmers I know jump between multiple languages and actually started in a completely different language (eg: procedural vs OO).

Languages/technologies evolve - programmers have to evolve too. It's up to the individual whether or not they want to take the time to learn something new. The learning curve required to move to a new language/tool/framework is not specific to Unity.

 

Sample size: 1. Confidence: ~0. Your example doesn't support your argument.

 

So I started looking at unreal 4 for example and they really promoting the hell out of blueprint most of the examples in there marketplace are using blueprint. Personally I don't want to learn blueprint because it seems kind of soeficic, I wonder if playmaker is going to make a unreal version that would be neat you wouldn't a new language

I went to gameloft and they told there teams are huge, like 10 programmers 10 artists, it took them like a year to make a game like uno. Now if you were using unity for example you could make the same in fraction of the time with a way smaller team. At the interview I was talking to the guy and he said they made there own racing game and rather then using a preexisting physics engine they rolled there own, I did ask them why and the answer they gave wasn't very satisfying.

So what I think is at least in some cases these overbloated teams would lose there cushy overpaid jobs if they switched over to unity or something. They wouldn't need 4500 devs which is how many devs gameloft actually has
http://www.appannie.com/apps/ios/app/uno-tm/

 

The problem of induction, yes? I think an old Scotsman had something to say about it, long ago.

 

Um....wtf? O...k...

*slowly backs away*

I thought people here were intelligent enough to understand that when talking about "Games" in a Unity thread about creating video games...that we were talking excluslively about video games when referencing "games". I smell a troll. Unfortunately, mods tend not to crack down on subtle things like this, even though it's quite obvious the person isn't even trying to communicate with others.

It's amazing that you felt the need to strawman something that wasn't even the beginning of an argument.
I mean...seriously?

"OH MAN, HE DOMINATED THAT GUY! Pointed out that if someone uses UNITY Nothing to make a REAL LIFE BOARD GAME, then it didnt take any PRORAMMING! Oooooohhhhhhhhhhhhh!!!! In a Unity thread about video games too! SCHOOLED!!!!!!"

I am sorry, but I cannot stop laughing at this. Talk about stretching your argument to try to win. What are you trying to win anyway? Did I hurt your feelings in another thread, to the point that you gotta stretch things so far to somehow disagree? No one is going to argue that you should have at least a basic understanding of programming or scripting to make good video games in Unity.

As for modding a video game, that at least has its merits as a reply. At least someone could "mod" a unity asset to make a super duper lame probably crappy video game.

Unfortunately, modding a game or using a game to make a game within a game, is not developing your own video game. You could mod a game to the point of making your own video game, but I guarantee you that requires what? Requires programming. At least in some form or another. I'm sorry, but you'd be a hard sell to convince most people that you made a video game by stringing together tiles in Minecraft to play the Mario Theme Song or doing that in Dwarf Fortress to "make a computer". You could rely on stronger examples like DAY Z, or "Total Conversion" mods. However, you will still have a hard time convincing others that it makes you a game developer who used absolutely no programming skills.
Go ahead and try to claim to others you are a game developer by showing them work you did in modding minecraft. See how people react to you. (Warning: it won't be pretty. Prepare your self-esteem and protect that ego of yours.)

But at least this argument has some merit. At least it doesn't spout out about hike-and-seek or board games, as if those relate to Unity and video game development.

You know, when people use examples in their argument, most of them are not stupid enough to use things that counter their very points. Did you even attempt communication? Did you even TRY to understand what was being said? Why in the world...

This entire conversation seems to have devolved into people arguing for the sake of arguing. Sorry, but attacking strawmen so early in the conversation (before anyone even argues...lol...) is not the type of conversation I'd participate in. Not this time anyway.
I'd have a more rational conversation by arguing with myself than with people who think that pointing out hide-and-seek is a game, in a conversation about video games, is an intelligent rebuttal.

 

@angrypenguin

Even better, I can prove how little you are attempting communication and how hard you are trolling simply by pointing out my post and your reply. This is a valid reason why everyone on this forum should add you to ignore if they find themselves in an argument with you.

Here are the three main statements which make up the core of my post stating "You need programming to make games.":

Please read each one, followed by a repeat of your statement. It is quite clear you are nothing more than a troll, out to argue for the sake of arguing, and sow discord in these forums.


Remember to apply context for the statements below.

This is in a thread about Unity, which is a game engine designed to make video games. The conversation topic is about programming and programming video games.

@angrypenguin Or, y'know, all the many games that exist that don't involve a computer at all. And even in the realms of electronic games your own post mentions a bunch of counter-examples.

@angrypenguin Or, y'know, all the many games that exist that don't involve a computer at all. And even in the realms of electronic games your own post mentions a bunch of counter-examples.

@angrypenguin Or, y'know, all the many games that exist that don't involve a computer at all. And even in the realms of electronic games your own post mentions a bunch of counter-examples.


I wish the mods would send a message by saying "If you want to have a conversation, then please communicate with one another. Do not ignore one another. Soap box ranting (disagreement while not even reading or considering the other person's statements) is unacceptable here."

Let us see some proactive measures to promote communication and decrease discord.
Maybe then we can have real conversations here, and it can be a place unlike the rest of the internet.

 

Counter-Strike, Defense of the Ancients, Gunman Chronicles, Dear Esther, Natural Selection, Antichamber ...

 

edit: This guy didn't read anything I said, and cherrypicked that sentence.

I stated directly after that sentence:

 

You said "modding a game or using a game to make a game within a game, is not creating your own video game".

A game involves logic and algorithms. Therefore it's impossible to make a new game with new rules without using at least some kind of language to define those rules. So, I don't see the point of the question you bolded.

 

Just to keep things clear. No scripting != no programming. Blueprints is not scripting, but is programming.

 

And directly after that, I stated "You could mod a game to the point of making your own video game, but..."

Are you reading the conversation? The entire argument is about whether or not someone can make a video game with absolutely no programming skills.

Please keep up. Cherry picking sentences kind of derails the primary topic.

 

I am following the conversation. Why can't you answer without snarky remarks?

Like Tiles I make a differentiation between programming the core foundation and using scripts as actual game assets that get processed by that foundation.

But if you are this nitpicky, let's say the scripts can be replaced by a human game master that moderates the game *rolls eyes*