How effective would it be for a non-gamedev to work on gamedev

These questions are a result of a little bit of thinking I've been doing recently, whilst I won't bother you with unnecessary details, I do wonder if any of you can answer this from your own personal experience (as employer or employee).

If we took two programmers, both graduated necessary formal education. First one studied C# and has 5 years of experience, second one studied C++ and also has 5 years of experience. Considering neither of them have ever worked in a video development framework (lets say Unity3D and Unreal Engine respectively). Considering their will to learn/adapt is that of an average Joe, how well would "vanilla" C#/C++ knowledge transfer towards game development?

And for the second part, lets say a team consists of 16 people, they all have same experience in either C#/C++, but only four of them have moderate (usable) knowledge of their respective game engine, could that potentially smooth things over?

As for the third part, game development of a AAA title takes multiple years and a rather massive team. I was wondering, if we shoved "ready" engine in front of these development teams, how much time could we cut? In other words, how much time is being "wasted" on things that aren't explicitly gameplay related? How much time does a Unity3D/Unreal Engine game developer spare compared to a company that develops its own engine from the ground up*?

I'm wondering on more details to the question: As a programmer, how necessary is your advanced knowledge of a game engine that you're working in? Assuming that you're not the lead developer or a "manager" of sorts.

* I know they don't develop them from the ground up, and they work/update it from previous generation, but you know what I mean.

Thank you for reading, and I'm eagerly awaiting your response.

 

Impossible to answer. Game development is incredibly difficult to predict time and effectiveness for experienced staff by an experienced project manager. There are endless variables associated with just the type of game and requirements of the game alone.

The questions you asked are simply impossible to answer, the context is unknown and the variables are too many.

Basically... “how long is a piece of string?”

 

About a piece long

 

Formal education means nothing in game dev.
It is important what you can do. For example if you have some form of por.
5 years of experience in what? Uni? Game industry? Or as clerk, doing coding monkey?

As @zombiegorilla stated, game dev is very complex topic.
While knowing programming is big benefit, but if you don't have any sense of artistic, or trouble to deal with technical challenges, or even struggling managing own work, that complexity increases tremendously.

This where larger games, divides into specific task and require multi disciplinary roles. From programming, via hardware, to visuals, to audio, to marketing, to ... just naming few, but required.

Not to mention you need someone taking responsibility as well for game designing.
Often coders receive task, they just focus on that.
But for small teams of few, well, you need have wide experience in various fields.

And foremost, interest in game making.

 

Look at a popular game you like -- say Clash Royale. It has, what, 3 or 4 screens, and fairly simple game-play. Could be programmed, roughly, in a week. Most of the work is the idea, spreadsheets, play-testing, tweaking, monetization tricks, visual effects; and the networking code (which the programers could work on).

The thing is, a programmer who wants to make games has probably programmed some games for fun. If you've written a text-based dungeon-crawler, about the same code works in Unity.

 

Like others have said, it's very hard to quantify all the variables in your question. What does an 'average' will to learn/adapt mean?

My experience of being a game programmer is that mostly it is using very core programming concepts (such as lists, loops, all that kind of stuff). The main difference compared to programming other sorts of applications is that you cannot look at everything as a complete abstraction, you must to some extent use a 'physically based' approach to conceptualize what is going on and design the architecture. Perhaps this is hard for a lot of hardcore programmers, it certainly made things easier and more pleasant for me though.

The only other thing is that Unity is a big tool. It's easy to approach, but hard to master. Or to put it more precisely, it's easy to get started, but there is a lot of potential locked away, especially in terms of adapting the engine to development of a particular game, that takes some time to become familiar with.

I have no experience with hiring people for programming games, but if I was to do it, beyond programming skills I would look for someone with:

1. Physics background (or at least a physics hobby).
2. User interface background (means they understand how easy it is to ruin someone's experience of an application).
3. A graphics design or some kind of visual arts hobby.

This things mean that they would be likely to adapt well to the specific programming environment of game development.

Other than that, all I can say is that someone with the drive of the 'average joe' will likely never make it as an indie. I would never hire someone onto a small team who is not very, very driven to learn and build things.

Depends on willingness to learn, and learn fast, in my opinion.

AAA companies build their own engines precisely to be able to work much faster than they would with a 'ready' (...for what?) engine. Like I said, if you engineer Unity to be an efficient pipeline for building your game (which you can to a large extent and it's the best thing about it) that's where the greatest potential is.

The problem for indies to build their own engines is that the cost is prohibitively high. If they could though, well anyone could work much faster with a game engine built from the ground up for their own purposes.

More valuable than any advanced knowledge is how fast someone can learn what they need to know. There will always be parts of Unity I don't know, because I've never needed to use them and never made a game that requires me to know it. But if I was to need to know it, the question is how fast can I learn?

I have to say though, for an environment like indie game development where every percent of efficiency matters, you would do very well to have someone with a thorough knowledge of Unity on your team, who can do the main optimizations necessary for the workflows that everyone else uses.

I think one of the most underrated and often unseen obstacles that indies face is that they are working with a brutally low efficiency due to only ever using a game engine in its most generic and un-adapted form. It's like driving a car everywhere in first gear, because it 'works' and you never really knew what those other gears were for.

 

^ This.
A phenomenal programer who has never done games is still going to have fair amount of ramp up. There are always various approaches to do things, and they will need to find the optimal approach and get familiar with the Unity API. Knowing C# doesn't mean you know anything about how a camera in Unity works. (or one of a thousand other things)

[edit: added]

Not just indies. At Disney/LucasFilm, we switched from an existing, robust in-house engine with dedicated staff to Unity because the upkeep was getting insane. Supporting IOS, Android and web, was starting to take all the team's time just to keep up with hardware/operating system updates. Abstraction of developing the game from target platforms is huge benefit.

 

You shoudl be able to get up to speed in 2 months with unity and more than 2 months in unreal. You'll keep discovering minor surprises and quirks for at least a year after, but you'll be able to produce games after that initial introduction phase.

C++ knowledge will not help you much in Unity (you can use C++ in plugins, but you can't drive gameplay with it), and usability of C# in unreal is dubious (there are pieces of framework written in C#, and C# plugin, but I see no point to stick with it). Unreal requires much more skilled C++ programmer to work through C++, and unity requires less C# knowledge to work with C#. Some common C# practice in unity would result in reduced performance (producing too much garbage is bad), so that would have some time to get used to. Basically, I believe that in unity you can make a game with a beginner or mediocre C# knowledge, while in unreal having an advanced knowledge is recommended.

In this case, I believe, your project will fail due to having zero artists, modelers, composers and sound engineers. Most parts of the game are art assets, and if you have only programmers, you have a problem. I'd expect that 8-12 people in your team would suddenly need to learn how to make media assets and models. Now, programming experience helps in learning new things, but that won't be efficient. They'll waste a year retraining. At least a year.

Rolling your own engine should be thought as a suicide for a new project, unless it is something basic. For a large team with infinite funding it will probably take at least a year to produce something workable, but once you have something rolling (and have infinite money), it turns into your own asset without licensing fees.

Using ready made engine in a project cuts off from 1 to 5 years of development time, depending on team size and engine comlexity. Industry engines are usually a result of a decade of development these days.

Making your own engine is not recommended. Regardless of team size it turns into liability and into a money sink.

Very necessary.

It goes like this. If you're looking for a cash grab, have zero programming knowledge, you can grab an asset store package, reskin it and pray to cthulhu that it doesn't have any hidden problems you weren't aware of (it probably does). If you hit those with little programming experience, you're screwed.

With decent knowledge of the engine, you don't really need kits from the store, and can make anything yourself. The sky is the limit. Well, the engine limitations are the limit, but the difference in what you can do is incomparable.

 

A willingness to listen and learn will get you a long way. That is all.