Is Unity helping or hurting programmers?

I love Unity, I really do. It's a tool that can let any user come in and create anything really fast. But, I am wondering is it hurting programmers who use it? Having used Unity for 3 years I can say I can do just about anything inside of the program, but transferring that knowledge to proper software development is difficult. I haven't done proper software development in years. I have been using Unity like I said for years, but it feels like if I wanted to go into software development I would be at a disadvantage because I have gotten so use to Unity's workflow development. What are your thoughts on Unity's workflow vs a more traditional work flow and is it helping or hurting?

 

No, the fact that you haven't done software development for years is.

 

Unity just has a scripting API. And you've learned to use that API, and get used to it.

It's like with any other API out there. If you want to expand your horizons again just start using something else.

 

Its like riding a bike... I can not touch a language for years and completely forget everything about it including the basics, but after a day or two (maybe a week) of playing in it, I remember most of the applicable stuff...

You're never gonna learn/use modern methodologies in Unity, but IMO it doesnt overly matter. If youre a competent coder, it wont take long to get up to speed, not that it will help you in a technical job interview.

 

Yep, this.

Is Unity hurting my graphic design skills? No, the fact that I don't practice them is. I don't suck at Photoshop because of Unity, I suck at it because I haven't invested time into learning it.

I've never understood why everyone reasonably easily accepts that graphic design, modelling, music creation, etc. etc. are all distinct skills from "Using your engine or editor of choice", but the same isn't true of programming. Programming and/or software engineering is as much a distinct skill just like graphic design and music composition are, and just like those things is deserving - and needing - of deliberate practice and development in its own right.

Also, as I've said many times: "Game programming isn't a subset of programming, it's a specialisation." That is to say, if you jump straight to game programming without also learning general programming fundamentals then you're not saving time - you're missing out. There are really good reasons that programming courses don't start by getting students to make games. That's not to say that you can't learn programming while you learn to make games if that's what interests you, just that you should also spend time learning the programming parts of programming.

 

Edit: Ugh, really didn't like how that sounded, so I'm trying again.

In regards to how it effects coders skill levels, I don't think it matters too much. Ignoring what a "more traditional work flow" might actually be, as you get more skilled in programming you'll be more able to switch between workflows anyway. And you've got to get your practice somewhere, so as long as you're doing what I mentioned in the last post (re: learning general programming and not just programming for a particular tool) I see nothing against getting it in Unity as opposed to getting it elsewhere. It's the new APIs, environments, etc. that you'll have to learn as you move around, not the fundamental coding and software design skills.

I guess I would suggest, though, learning a bit about how game engines work so that you understand the context in which your code is running inside Unity. (So that you understand stuff like the framework in which Update() is being called.)

 

Unity's empowered people with no chance to literally make over a thousand released titles, particularly mobile and so on...

It's not Unity's fault if you won't actually go ahead and make a game.

 

Every time I open Unity I get this stabbing pain in my side.

 

Don't open it then.

 

I've owned and operated a car for years, I used to dabble with engines but it's been a long while and I don't remember much, but I'm proficient at driving my car. I think if I did a little research and started looking into engines again, it would come back to me.

Everything is within the realms of your own ability and willingness to learn.

(I went full Graham Dunnett)

 

Are there actual, legitimate game studios and companies (registered, profitable, and with offices) that hire Unity3d developers? I always thought gaming studios only want to hire C/C++ programmers that have the ability to make an engine like Unity3d.

 

Hearthstone is made by Blizzard and it was made in Unity. Gamasutra's job listings also have a lot of listings where Unity knowledge is required, including some by 2K Games and WB Games.

 

Experience mostly or exclusively with Unity3d? As opposed to them wanting 5-10 years game development experience prior to Unity3d, 3 to 5 AAA titles under the belt, plus Unity3d experience?

 

Thanks for the comments everyone. I just have felt Unity has gotten me spoiled over the years. When I want to make something it literally takes no time at all to get a working prototype up and running. When I started working with a more traditional C++ style engine it all came crashing down onto me that I had it made in the shade. In order to get something working I have to do so many extra steps, compile the code, fix the compiling errors, mess with the linker and libraries, run the code, open the editor and then see what I was doing didn't work. Also the C++ intellesense is HORRIBLE! Unity has been a great tool in my programming career but now that I am not using it as my main engine I can see that someone who learns Unity first can be at a disadvantage. When I was using Unity I never really had to inherit from anything, I never had to include files, never had to override anything, didn't use a pointer, never could use breakpoints(until UnityVS came out at least), unit testing wasn't really beneficial, no source control unless we used Unity's version system and I never saw the need to use a double lol(that one is more of a joke).

Anyways, Unity is a great tool and I wish more companies would use it instead of feeling the need to write their own engine that is far less useful and 10x more complicated.

 

Code (CSharp):

1. When I started working with a more traditional C++ style engine it all came crashing down onto me that I had it made in the shade.

I think that's the false assumption you're making. Things didn't come crashing down. It just felt frustrating because you started learning a new skill again. All of a sudden you were a beginner again, making baby steps, and you compared it to your sprinting and running you can now do in Unity. Cut yourself some slack and try to view it from a perspective of "practice".

[edit] And the things you're mentioning that you're learning now, many of them can come in handy in your next Unity project.

 

Yeah I definitely wasn't use to it, I enjoy it though. Doing something new and being a beginner again feels nice. The biggest issue I have so far is not knowing how to word my Google searches lol.

 

There is quite bit in japan, for all game studio focusing on smartphone game stuff.
They mostly looking for specialised unity developer with already year of experience with it

 

Yes; I work for a studio that hire's Unity3D programmers. Development is a lot quicker with Unity; so they had no desire to build their own engine or anything. Unity FTW, Although I do know other languages like C++

 

Am developing software with Unity right now.

 

Computers have hurt my handwriting. I virtually never "write" anything so over the years my hand-writing has degraded to almost illegible.

 

This is good to know.

If actual game companies are indeed hiring Unity3d developers (as opposed to only hiring mid-level/senior game developers with dozens of years of C/C++ who just happened to pick up Unity3d) then it should mean that making games mostly or exclusively with Unity3d isn't going to hurt a developer.

 

Yes, at least in part. We hire experienced engineers, Unity experience is a plus, but not a requirement. A good engineer can adapt. Unless they are top in field in a very specific area, someone who defines themselves specifically as a "Unity" or "C++" or "Actionscript" developer may not be very experienced.

 

EA, Ubisoft, and Microsoft Studios all either use Unity or have studios underneath them that they publish for which use Unity. I've been seeing more and more job requests for data analysis and game design/feedback that require knowledge of MySQL, C#, and Unity.

 

What is "proper" software development? You might as well say C++ is not proper development because you are not writing assembler or machine code.

Learning Unity is a skill like any other. It would help you get a job as a Unity developer!

The games I make in Unity usually consist of 75% of the time writing the C# code which include events, game rules, physics, all sorts. In fact to make a full game on Unity and have it work on multiple platforms is totally "proper" software development IMO!

The alternative would be to write a game with "proper" software development in Java for Android, Obect C for IOS, C++ for Windows, etc. etc. Why would you want to do that?

 

I have to disagree, Unity does indeed spoil you. There are way more things a person need to take care of and understand when developing his own solution.

 

Well if you are making a game, if you feel spoiled, why not write your own game engine, write your own 3D model importer, your own physics engine, your own render pipeline, your own joystick input handler, etc.

As for me I'm happy being spoiled and not having to do all those things! And most game companies would not redo those things anyway since they would most likely use a game engine like Unity (or dare I say Unreal!)

 

Yes, and keyboards make punch-cards redundant too.

Your difficulty is not a deficit in programming skill but retained API knowledge, two very different things.

The purpose of programming is to automate and solve problems. If the net result of years of programming isn't a quicker and simpler workflow for doing things then we're doing it wrong.

 

I think it would difficult to define (or agree on a definition for) what "proper" software development is. But your point is a good one. Like any tool, it can be used well or poorly.

A "developer" can download/buy a handful of packages, ask a bunch questions and hack together a "game" without having a clue what they are doing. On the other end a game can built in from the ground up and executed in a more traditional way. Our game is much like that, entirely built in code, the editor used primarily for testing and asset packaging. I'm not saying that is proper or better way to do it, just that there is a wide range of approaches. It's less about the tool, and more about how it used.

 

I wrote a custom engine once, and let's just say there are reasons I'm back here with Unity. I enjoy being spoiled. I get to use others work to make cool stuff and then take most of the credit. What could beat that?

 

Well I know some excellent developers at a triple-A video game studio (that uses a proprietary engine) who tell me they can't get their head around Unity, so I think there is a skill to using other people's tech that some hardcore program-your-own engine people haven't honed (although they may just be stubborn). As far as it actually hurting someone's skills as a from-scratch developer, I'd think a valid analogy would be C++ making people crappier assembly developers. It seems to me faster ways of doing things can only help everyone.

 

C++ is a crap, dead language (not really dead but it should be). Boxing you into having to use that rather dangerous language is a terrible, utterly imcomprehensible and retarded move by that platform. As soon as they support a better safer language (such as C# or Java), they'll get TONS more people migrating from Unity. My 2 cents.

C++ isn't nearly as readable as a lot of other languages too. Sure it's a tad faster but compilers are so great these days that sometimes compiled C# may run faster than C++. No reason to learn or use C++ anymore at all.

 

If you are learning programming by starting with Unity, yes it is hurting you.

This is a very unpopular opinion, but for me it was true. It was not until I programmed a game from scratch, that I actually learned what I needed to know. Resorting to "Scripting" and learning with Unity actually slowed me down and prevented me from learning what I needed to know.

To be fair, if I hadn't returned to Unity, the 3 months I spent in the past learning Unity would have been a total waste.

Jerotas is right tough, C++ is an archaic language. In 2014, it is actually hurting a lot of people who are either stuck in the mindset that it is still amazing, or are too amateur to know better. It is not a horrible language to learn from, but it is quite a nasty one to use these days.

A lot of old timers will proclaim "heresy!" but I'd advise against using C++ anytime you can use a newer language.

I mean, there is a reason Apple isn't using C++ with its latest release. There is a reason many new game engines use newer languages.

Most importantly... there is a reason languages were created after C++. And it isn't because C++ is awesome.

 

It isn't about stubbornness. After learning what I didn't know before (duh...what else did I learn? lol), I will give great consideration into using others' game engines or assets. I will also take heavy consideration wen giving advise to others or suggesting game engines or assets to other developers.

When you roll your own, not only are you in full control over the engine or asset, but you know it inside and out. This has an enormous advantage. Using someone else's engine, asset, or code, is just hell sometimes.

The "stubborn" people are probably just "experienced" people. They know the benefits of rolling their own, or at worst heavily dislike using others' work. With just reason I might add.

It is more work, but once you catch up to where Unity is (wit your own engine), you are far ahead and know exactly wat to do, in the way you like, in the style you appreciate.

There is a massive difference between using one language over another, and using one engine over another. This is like comparing apples to oranges. An engine is significantly more than just code. It is an entire....well...engine.

You don't do things with Unity the way you want. You do things wit Unity the way UNITY wants. Otherwise, you are either doing it wrong or in for a headache.

 

It is indeed overwhelming, but if you are overwhelmed by crating an ngin from scratc, you will b qually ovrwlmd wit crating most gamsinUnity.g

(rg,
my
kyboard
is
dad
damn
you
condnsation)

 

This was priceless
please don't edit this once your keyboard is fixed(or new keyboard)

 

Okay, lol. Luckily I have 4 spare cheapo keyboards from my attempt a few months ago to split my single computer into a x4 gaming system.

I'm back! Unfortunately, that damn condensation dripped on the wrong area of my keyboard, lol. First my "H" and "BACKSPACE" were gone ,but I did still have "DEL" and copy pasted the "h" each time. Then my "e" went out. Copy/Paste E+H. Then the whole keyboard began to die, one key at a time (o, then a, and then I surrendered when my spacebar went out, but god-save the Enter key! lol)

 

I have a laptop that has numerous keys not working correctly, and every time I try to use that thing I have to stop myself from testing if all laptops can be bent into tablet mode.

 

Oh my smartphone has made it worse. I just talk to my phone all the time and it sends texts for me. You can't imagine the horror I feel when I see a soft keyboard, man!

 

We're getting lazy because of the ease of use.
Not Unity fault, I'm impressed by it actually.

It's like you put the blame on the car when you gain weight.
Well, it's us who should walk more instead of using a car to get here and there.

 

To the OP, that is the same for any domain in software engineering, the basic functional code stays the same but the architecture tends to lean more towards the technology you are using, e.g. Java's J2EE, Microsofts .Net.

So should your question be is the Unity API a good example of a modern development Framework, that contains best practice, modular features and design patterns?

Now that would be an interesting topic I could learn from.

 

But from what I understand, virtually the entire professional gaming industry uses C++. Same in finance, robotics, embedded, etc.

Even Unity won't eat their own dog food, as it seems they only hire C++ developers for actual game engine development.

 

Well, it's about having the right tool for the right job. I've seen a lot of discussion about moving low-level game dev away from C++, but none of the alternatives are offer enough improvement to be worth the massive cost of moving away from C++'s existing legacy. It's cheaper to fix individual problems by improving C++ (or avoiding parts of it) than it is to throw it away and start again. Unfortunately it's one of those things where plenty of people accept that there are issues, but no one solution is clear and ubiquitous enough to get everyone moving in the same direction at once. And even if it was, the costs would still be huge because of the sheer number of people who'd have to change - even people who develop custom in-house engines often rely on a wide range of middleware. It's really hard to change an ingrained standard.

Regarding Unity eating their own dog food, it's more or less standard for game engines to be written in a comparatively low level systems language (e.g.: C++) for performance while including a higher-level "scripting" language (LUA, Mono, JavaScript, a custom language, etc.) for rapid development iteration. Even in large studios with custom engines it's common for an engine team to implement some kind of high-level language which the gameplay team(s) use to more quickly make stuff with the engine.

 

I concur with the basic concept that modern game engines use scripting languages. However they tend to use them more for tweaking of the gameplay/game mechanics layer. This differs from Unity as with Unity all of the game play /mechanics layers are running in script. And unless you have a source code license you do not have the luxury of moving commonly used or performance critical code out of the scripting language and into the game engines native code base.

Note that Unity 5's IL2CP mono to C++, build process will help offset performance problems.

 

Based on... what? Of the engines I've used and/or seen (Unity, Torque, Unreal, some custom in-house stuff) the scripting layer can typically do far more than "tweak" gameplay. Often the point and purpose of the scripting system is to allow the majority of application development to be done without low-level engine access.

You're right that Unity is a tad different in that it's scripting system is essentially a fully fledged application development environment in its own right - being nearly a full .NET implementation.

 

OK take Doom 3's architecture



Notice how that between the GameX86 and Doom3.exe contain similar features to Unity. But Doom3 also had a scripting language that ran on a virtual machine that was used for game behaviours (idLib Parser/Lexer). In Unity if you want to write an FPS like Doom your FPS specific code is written in an interpreted language that is running under mono. The FPS specific code in doom is written into the games engine.

The benefit of a scripting language is it's flexibility and usability, it allows game developers to write the core game mechanics and level designers, gameplay programmers to work on the content.

Ideally the scripting language will not take up so much of the game that it can have an impact on performance.

Don't take my word for it, take John Carmacks...

 

Sure, I'll take John Carmack's word about how the Doom 3 engine works, considering that he wrote it and all. But that's one engine, and one that's fairly purpose-specific and not really designed for resale/reuse as a generic game development tool.

The multiple that I cited, on the other hand...

 

My point is that as long as the engine provides the flexibility to move code from scripting into a native core then you can have the benefits of flexibility and performance.

Note that Torque and Unreal 4 allow access to the source code that compiles to the game.

Unity does not have this option without a source code license. But this is only an issue if the game hits performance problems on it's target platform that can't be overcome with optimisation within Unity's mono code.

 

There isn't a good reason not to learn C++. At the very least it is worth learning to better understand low-level concepts as these can potentially help even with high-level languages. Or were you unaware that C# compiles down to native code as well?

 

There is a good reason: if you never need it. Besides, languages discussions are so silly. Once you understand one, you understand all. Especially from c++ to c# or vice versa The additional concepts in other languages are nothing really. Learn one, learn game Dev, and just make games. Programmers arguing over languages makes it seem harder than it really is to make games.