Keep in mind that game development is sort of a two layer process.

If you're a programmer then it's like learning to paint, whether you go to school or teach yourself you are essentially teaching yourselves about the process of painting, you have to learn the way the paint functions, what tools and different brushes you have, how you might remove spilled paint or what have you. That's what they teach you in school if you go for a degree, you end up with useful knowledge about how the thing works on a fundamental level and also get practice in being forced to paint in different ways you might be uncomfortable with.

Game development on the other hand is a job, it's like taking that painting knowledge and now going out and painting murals for schools or a church or making art to hang on a wall, it could even be something like painting a house. All that knowledge about using the tools will come in handy but you also now need to learn specifics about your profession, tips and tricks and what the standard way of doing things might be in your field.

Arguably learning with a library can teach you more about the low level of how the things work but it makes it very difficult to learn higher level techniques used in modern development without you advancing to the point where you are making very difficult projects that require you to look up and teach yourself the relevant techniques. On the other hand a game engine like unreal or something tends to shove these techniques on you more upfront because they are built into it. It's much easier to learn what materials are and what their uses are from unreal or unity than it is to learn by making things from scratch in opengl or direct3d, even if the latter will give you a better understanding of how the thing is actually implemented in code. That applies to other things too: 3d animation, level building, AI path finding and scripting, event triggers. You get a more "industry standard" look at some of the tools people use.

Boiling all that into a few words, I personally found that it helped a lot to learn both things. Try a few languages, try a few libraries, try a few game engines, you'll learn different things from each of them, even just experimenting a bit.

I think your analogy really makes clear to me the difference between the two approaches. It definitely seems like in order to develop a more well rounded skillset I will have to spend time learning both low level programming and high level engine techniques. Given however that I want to go more on the programming side of game development I figure I ought to prioritize and give more time to learning the low level techniques using libraries. Correct?

4 hours ago, Gabriel Gonzalez said:

I think your analogy really makes clear to me the difference between the two approaches. It definitely seems like in order to develop a more well rounded skillset I will have to spend time learning both low level programming and high level engine techniques. Given however that I want to go more on the programming side of game development I figure I ought to prioritize and give more time to learning the low level techniques using libraries. Correct?

I don't really agree that if you're learning low level programming techniques that it makes it very difficult to learn higher level techniques, the opposite would be true. (Unless Satharis is confusing low level and high level here)

Let me give you a few examples.

Low level: You're goal is to program a 2D game engine, and your library only handles basic graphics, input, and audio. Now you have to program a game loop from scratch (fixed time step with free rendering). Now you need to program your own texture manager (while managing memory), collision system, physics system, game state manager, audio manager, event manager, logic state, draw state with double/tripple buffering, ect... Assuming your engine is now completed, it's just a matter of using the objects and functions you've made, correct? and programming your actual game while using the engine features? (which can now be looked at as high level in a complete state)

High level: Now you're using a pre-made engine that already handles everything above. All you need to do is reference their manual to find out what needs to be called for texture management, collision checks, ect... The time loop would already be setup, and you might have a toggle for setting the Ticks per Second. Besides this, again you're just coding your game while using the already present features. The draw back when using other engines is you will have to usually conform to their way of handling certain tasks, and dealing with their limitations, that's where the learning curve comes from. It's much easier to just pick up Unity and start working on your game right away, as opposed to having to program every engine feature first.

The misconception in game programming is this false idea spread by some people that you can only skin a cat one way. There are many many ways to accomplish a task, and yes there are industry standards in game programming.

On a current project I'm working on, I just programmed a custom full featured in game chat box from scratch (low level). If I was using an engine that already had this feature, it would be a matter of calling a method, setting the position, size, style, and filters. Which would be much easier at a high level.

The same applies with programming languages. Many people who learn low level languages transition into high level languages very fast. It's a matter of understanding what is now being handled for you, and what you no longer need to code from scratch. Aside from learning syntax changes, and differences in language features, it's not a daunting task. It's much harder to go from something like Python to C than C to Python.

When you're talking about low level to high level it comes down to this: low level is for those that want to program and understand all the moving parts of the engine itself. High level is for those that just want to spend more time on the game itself, and less time programming engine features.

In your case, you should go down the low level route. Program a cool physics engine and that will make your portfolio shine more than using a pre-made engine and showing how you can rotate some cubes, and simulate gravity with falling objects, ect...

6 hours ago, Rutin said:

When you're talking about low level to high level it comes down to this: low level is for those that want to program and understand all the moving parts of the engine itself. High level is for those that just want to spend more time on the game itself, and less time programming engine features.

In your case, you should go down the low level route. Program a cool physics engine and that will make your portfolio shine more than using a pre-made engine and showing how you can rotate some cubes, and simulate gravity with falling objects, ect...

Interesting. Ideally I would say I picture myself working somewhere in the middle between high and low level work. I do love the challenge of developing features from scratch and also find it super interesting to understand how everything works underneath the surface. On the other hand, I am also interested in working closely with the design aspects of game development and would also love to be involved in the implementation of the actual gameplay. 

Based on what little I know on the subject it seems to me that engine and tools programmers are not as involved in the implementation of the final gameplay itself whereas gameplay programmers seem to be the ones that sort of hit a happy medium between high level and low level. Am I correct or is that totally off? 

If my assumptions are correct then based on what everybody has already shared with me on this topic it seems that my best bet is either to focus on making games the low level route or develop a physics engine and make the most out of my physics background. Complementing either choice would be the occasional exploration of other tools in order to familiarize myself with them and spread my skillset a bit. 

Does anybody have any advice as to which option could possibly make me a much stronger candidate when looking for jobs in the future? In the end I am willing to do whatever gives me a better chance of actually joining a team. Unless of course it all doesn't really matter as long as I focus and stick to something.

49 minutes ago, Gabriel Gonzalez said:

Based on what little I know on the subject it seems to me that engine and tools programmers are not as involved in the implementation of the final gameplay itself whereas gameplay programmers seem to be the ones that sort of hit a happy medium between high level and low level. Am I correct or is that totally off? 

This entirely depends on the studio, and team size. If you're talking about a big company like Blizzard, then you're going to have programmers that work on tools, server backend, and the engine, apart from those working directly on the game itself.

I've personally had to do engine programming, build tool kits, and work on the actual game because of the team size. On bigger teams you will find that roles are more split and defined, and one person may be the only one creating tools, another two or three are working on low level engine programming, and the rest are working on using the engine to program the game. Even the roles within the game can be split, from AI programmers, to people that only handle physics programming, to network programming, ect...

This is why you will usually find more people attracted to engines like Unity, as opposed to going out and programming their own engine from scratch. You really either have to have a need, desire, or good reason to force yourself to do low level tasks, considering the amount of high level options out there. A lot of people just want to go out and code their games, and not worry about anything else.

Yes, building your own physics engine to load in 3D objects and preform various events would be very impressive in a portfolio, so would a game, it just depends on what role you want. Get the best of both worlds, make a game that depends on physics as a game play component.  

19 hours ago, Rutin said:

Low level: You're goal is to program a 2D game engine, and your library only handles basic graphics, input, and audio. Now you have to program a game loop from scratch (fixed time step with free rendering). Now you need to program your own texture manager (while managing memory), collision system, physics system, game state manager, audio manager, event manager, logic state, draw state with double/tripple buffering, ect... Assuming your engine is now completed, it's just a matter of using the objects and functions you've made, correct? and programming your actual game while using the engine features? (which can now be looked at as high level in a complete state)

Here's where the disconnect from reality occurs, you make it sound like the preferred way to do anything is to learn it low level first, then you know exactly how it works and understanding a higher level use of it in a game engine, thus allowing you to pick it up easier, unless I'm misunderstanding.

While that fact is true, how long is it really going to take someone to learn how to make those things from scratch? Especially if they've never even used an engine and know what tasks the system is expected to handle. How many people without experience do you know that you could ask to throw together a basic game with a game loop and they would know how to do it? I've had to explain to experienced programmers even how a simple game loop functions because they are only used to event based programming. You can learn, yes, but it's going to take a very long time. Creating a physics engine from scratch is hardly trivial, implementing one that actually functions correctly and without mind boggling-level bad performance is liable to require lots of reading up on algorithms and understanding what kind of physics bodies a game actually uses, and tradeoffs between them.

Therein lies the important part, game engines not only are useful in that they let you skip a lot of the work, but even just using them to play around with can give you insight into how a game engine generally functions. Animation is probably one of my favorite examples, try explaining how to code 3d animation into a game engine to someone, it is difficult. Assuming they already know all the steps to rendering and how models and things are actually represented in 3d space, then you start going into topics like inverse kinematics, animation blending, skeletal animation. Really, most topics in game development are pretty deep, you could write an encyclopedia just brushing over the various engine and game level systems in your average 3d FPS.

Maybe he already knows all about physics in games. If so then that's good! He'll have a much easier time creating a physics engine from scratch, but he'll probably still have to do lots of research and experimentation, to me the biggest asset in game development, is experience. Nothing beats having done something before, it gives you a much better understanding of the thing even if you are reading a book about implementing it. If he doesn't know all those things, I daresay he would learn a lot from messing around with a game engine, even just as a learning exercise. Using more than one engine is even better, then you get to see what commonalities they share and how each chose to tackle different problems.

47 minutes ago, Satharis said:

Here's where the disconnect from reality occurs, you make it sound like the preferred way to do anything is to learn it low level first, then you know exactly how it works and understanding a higher level use of it in a game engine, thus allowing you to pick it up easier, unless I'm misunderstanding.

Gabriel Gonzalez is looking to showcase his physics ability, and by creating an engine from the ground up will accomplish this far better than using an already made engine that handles the task for him; From a resume and portfolio standpoint. This doesn't not mean he cannot simulate various events in an already made engine to show his ability. I usually take the more hardcore approach because these jobs are not a dime a dozen (depending on location), and there is a high amount of competition in game programming as it is.

My opposition to your post was about this: "makes it very difficult to learn".

Quote

Satharis: Arguably learning with a library can teach you more about the low level of how the things work but it makes it very difficult to learn higher level techniques used in modern development without you advancing to the point where you are making very difficult projects that require you to look up and teach yourself the relevant techniques.

You will find there is a big reason why new people generally are told to "Make Games, not Engines". It doesn't refer to the exclusive use of high level engines. It means if you focus on making your game using a library, you will end up programming engine related functions as you go, and as they're needed. This lets you avoid blueprinting the engine when you have zero idea of what you might need.

As for the game loop argument, well it's simple, you read a book, look up the many articles online about it, or come to the forums here for help. The same would apply to how to use (x) feature in an engine, you have to pull from a source if you don't know. There is no magic bullet here, and everyone new to programming who starts at low level or high level is still in the dark on day 1. Yes, it takes more thinking to break down a game loop from scratch, but that's why it falls into low level.

I will agree that using an engine that handles a certain function can give you an idea for when you move into low level, but that's not the only way to get an understanding of what you require.

Time is also not a factor if programming is something he wants to do his entire life. I'm already at the 18 year mark programming, and I couldn't make engines in the first couple of years, but I was making games which required me to program engine features in order to complete the projects. Again, this is why people recommend make games, not engines because it's extremely hard to blueprint a game engine if you have no idea what components are needed. Does this make it impossible? No, that is why people write books on engine development. We live in an age of information, there is no excuse for someone to not be able to go online and find all the general concepts of what makes an engine tick. If he wants to do this the fastest way possible, then high level is the way to go. You open more doors for yourself when you're able to transition from low to high level.

At the end of the day, I can only speak from experience. I learned engine programming from making games in a low level environment from scratch for many years. I have never learned concepts that I took from high to low level when referring to engine and tool programming. I've also jumped into a high level environment using C# in the past with ZERO difficulty, so I don't know how it becomes very difficult to move into a low level environment to high level. I would spend my initial time reading the documentation for the engine which allowed me to find out what kind of work flow I would be working in. You still have to program game level code on-top of any given engine, either your own, or something like Unreal. Unreal doesn't make the game for you upon opening, you just don't have to deal with the massive task of creating all those engine features.

Getting back to the main post, if Gabriel Gonzalez's goal is to get into the industry as a game play programmer then learning low level programming isn't a must, and is not required. Just being able to use Unreal and adapt his skills with physics is still extremely valuable. If he wants to work strictly as an engine programmer working on the physics side, then he requires to know low level programming. Different studios require different skill sets, so the more you can do, the higher chance you have in landing that position.

I can only post my opinion, just like anyone else here. It's up to Gabriel Gonzalez to decide the best path. The more you know, and the more you can do, the more valuable you become in the market place.

4 hours ago, Rutin said:

Time is also not a factor if programming is something he wants to do his entire life. I'm already at the 18 year mark programming, and I couldn't make engines in the first couple of years, but I was making games which required me to program engine features in order to complete the projects. Again, this is why people recommend make games, not engines because it's extremely hard to blueprint a game engine if you have no idea what components are needed. Does this make it impossible? No, that is why people write books on engine development. We live in an age of information, there is no excuse for someone to not be able to go online and find all the general concepts of what makes an engine tick. If he wants to do this the fastest way possible, then high level is the way to go. You open more doors for yourself when you're able to transition from low to high level.

Almost all of my early projects were made from scratch, I too am speaking from experience. Reality is that it is hard to find information on how to implement a lot of low level game functionality because, surprise, people don't often do it. I should know, I've done it. You can look up how to write a game loop and you'll get many articles about the subject, many of them are flat out wrong, or simplistic, or don't even underline the core important parts of how to do it. Can you learn? Of course you can, through many hours if trial and error, my advice simply offered a way to make that trial and error less error and more trial.

Also the "Make games, not engines" line is generally around here because people often try to  jump into just making an engine without having a clue about what it is an engine even needs to do, which was exactly my point. Making a game organically forces you to look up things you might need, but in many cases you'll end up in a scenario where techniques or things might exist to solve your problem but you don't even know what they are,  in order to look them up. Breadth is helpful in that situation, not depth.

Honestly i rather disagree how you essentially sum up your reasons for taking the less optimal route as it's what I did, so it works fine, or anyone can do it this way if they try hard enough. That's a terrible basis for an argument. Time is a factor, people have limited time and need to make decisions on what projects they want to make. Can he start from nothing and just throw together a physics engine? Sure. Would it be worth jumping into it blind? Probably not. In fact it is violating the entire idea of "make games, not engines" to jump into making a physics engine without even understanding what a physics engine needs. I'm emphasizing that he has many options on what to do and that many of them will teach him more about game development, you seem to be stuck on the fact he should stick his head in the sand and stay there until he pops out with a 3d physics engine demo.

My advice is pick a project you want to work on, and work on it, getting anything done and gaining experience makes you a much better candidate, it's not all about not-invented here syndrome. Someone hiring you cares more about your passion and showing them some cool stuff you have made than focusing too much on making one fancy thing.

I understand where you're coming from, but we can agree to disagree.  What works for one person may not work for another, which is fine.

Thank you for sharing your view points.