Why not try using an engine one time, sort of a test-drive, to find out how it works and what it does? Unreal is C++ based and Unity is C# based, so the latter would require you to learn a new language. Engines are mostly designed for 3D games.

In general, broadening the range of tools that you have worked with doesn't hurt. It makes you a better programmer in the sense that you have experienced the tools, and can make a better decision which tool is the best solution for the problem at hand.

As for your degree, many programmers aren't very good at math (read the math forum here). I would think that's where you can shine. Eg a race-car game is basically a graphical car simulator program, "environment destruction" in FPS also involves physics. I am sure you can find more examples if you start looking for them.

All right, I will give Unreal a shot then. I was a bit worried a might get myself into a breadth vs depth issue if I began exploring other tools but like you said I guess it really doesn't hurt to try other things to get to know them. Thanks a lot for the tip as well as the insight on my degree. I really do appreciate it.

Since eventually, everything is put onto the same von Neumann machine, most "depth" is universally applicable. classes and objects work in much the same way everywhere, with the same kind of design issues. Algorithms are language-independent, and all languages have the same kind of data structures. That makes "programming" pretty much transferable across different language without major efforts. (Well, until you go into more exotic languages, like Prolog, Lisp, or a functional language :))

"breath" is more hazardous however. Lots of things look the same at the surface (while loop and assignment look the same everywhere), but are in fact very different when you dig deeper, and work with the language or the tool. These differences make one tool or language more useful for a particular type of problems.

I find the differences enlightening. Most languages and tools tell you a certain practice without explaining why. By trying several different practices, you experience that other solutions work too, solutions that you can apply in other situations too.

If you are interested in 2d, I recommend you look at Gamemaker Studio.  What UE4 and Unity do for 3d, Gamemaker does for 2d.  It isn't as capable in general as other engines, but for 2d games of just about any type it is more than capable.  It is much better than what people make it out to be. The GML scripting language is quite similar to C++, so since you know some C++ you should feel right at home there(I did).  The idea is the same as other engines, do all the low level stuff for you and let you just script your specific game's stuff.  You won't have to do any sprite loading, game loop coding, and you won't see a main() anywhere.  The IDE and engine take care of that all for you.  So for the purpose specifically of developing a game in 2d, it is gonna be one of the fastest and easiest ways to go.

So @Alberth, based on what you have told me so far I gather that it would be best if I made a small project using an engine in order to get to know a different tool and spread my skills a bit but my main focus ought to be going more in depth with my core programming skills.

Thanks again for the help and for sharing with me your insights on the dangers of breadth! That is quite interesting indeed, I never really had given much thought to the possibility of tools and languages being so different in their implementations. 

@kburkhart84, you touched upon another one of my questions. Given that engines do all the low level work for you wouldn't using engines hinder my development as a programmer since I would be letting them do most of the work? Wouldn't it be better for my development to use libraries in order to focus on doing more low level work? Or is that an unnecessary investment of time and energy?

I do not know how much of an issue this would actually be since I have no idea how much programming or rather what aspects of it do programmers on teams generally work with. Do you happen to have any insights on that?

3 hours ago, Gabriel Gonzalez said:

So @Alberth, based on what you have told me so far I gather that it would be best if I made a small project using an engine in order to get to know a different tool and spread my skills a bit but my main focus ought to be going more in depth with my core programming skills.

Thanks again for the help and for sharing with me your insights on the dangers of breadth! That is quite interesting indeed, I never really had given much thought to the possibility of tools and languages being so different in their implementations. 

@kburkhart84, you touched upon another one of my questions. Given that engines do all the low level work for you wouldn't using engines hinder my development as a programmer since I would be letting them do most of the work? Wouldn't it be better for my development to use libraries in order to focus on doing more low level work? Or is that an unnecessary investment of time and energy?

I do not know how much of an issue this would actually be since I have no idea how much programming or rather what aspects of it do programmers on teams generally work with. Do you happen to have any insights on that?

I've come across many types of programmers, and game developers. Some want to make their desired game in the fastest way possible, while others enjoy creating the engines and tools for their games to run on, there is no wrong or right answer here.

I personally enjoy creating game engines and tool-sets, along side games so for me I would never use GameMaker because I have different goals in mind. For someone that wants to make their game in record time, but still be able to script (GML), then GameMaker is a good solution.

You have to ask yourself what you want to be able to do. If you have a goal that someday you want to be able to sit down with a library and just code your own game engine, then using GameMaker will not get you there. C++ with SFML as an example will get you to that point, or even just working with OpenGL/Direct3D directly. You also have to factor in your career path, if you want to make an impressive portfolio for C++, GameMaker will also be useless in this case. You would be better off making toolkits, engines, and games with C++ and SFML, then creating a showcase for when you apply for jobs. (This assumes you're wanting a job as a 'programmer', especially in physics programming).

Rutin has this spot on.  In fact, me and Rutin are kinda on opposite sides.  I learned my share of C++ and made a few things years ago with OpenGL(and DSound APIs) and C++.  I also messed with using a 3d engine(Irrlicht) using C++.  Over time I figured out I was more interested in tinkering with games themselves and less of the underlying code, which was good timing as Unity and Gamemaker have been really coming into their own these last several years, getting quite powerful and capable while still being easy and quick to use.

Other people(Rutin for example from what I've seen on the forums) are more along the lines of enjoying the raw coding side of things.  They take time to roll their own mini-engines which over time can grow(maybe not to compare to Unity/UE4).

There are advantages to both paths, depending on what you want.  In fact, I'd say it is fair to say you could realistically do some of both.  It would take longer time to get the same progress, but many of the concepts cross over.  C++ code is similar enough to the C# scripting Unity can use, and even Gamemaker's GML scripting language is similar enough to C/C++ that your C++ knowledge can apply there as well.

12 hours ago, Gabriel Gonzalez said:

Thanks again for the help and for sharing with me your insights on the dangers of breadth!

Danger is perhaps a bit overestimating, I see them mostly as enrichment.

If you are a carpenter, and you only know about hammers, then the entire world is a nail. By learning about saws and screw drivers, you expand your knowledge, you become a better carpenter.

Switching from hammer to saw is however quite daunting, you have to let go of all your hammer ideas, and use a saw as it was designed to be used from the ground up, ie using a saw in a hammer-like way won't give you very satisfactory results. Give each tool a fair chance to shine.

Once you understand how a saw is to be used as a saw, you can work on using a hammer and a saw together, picking the right tool at  each stage. At this point you can understand which tool to use for which job, and you know what you're going to be missing if you pick a different tool instead (which can happen for various reasons). A little further, maybe you can tweak one tool a bit in the direction of that missing tool, and simplify you problem a bit. Basically, use good stuff from one tool in context of another tool.

Your idea of also concentrating on depth is a good one, algorithms and data structures are useful everywhere.

@kburkhart84 and @Rutin, I definitely lean more towards the raw coding side of things although not completely. Even though it definitely seems fun, my goal is not necessarily to create my own engine or independently develop a game. Rather, I would love to work together with a team in the creation of a game where I focus more on the programming side of game development. Therefore, like @Rutin suggested, since I am more interested in finding a job as a programmer it seems that my best bet is to continue developing games using C++ and libraries such as SFML so that I can use them to showcase my skills when looking for jobs.

Also, thanks @Alberth for clarifying and sharing more of your views on depth and breadth, I do see the importance of spreading one's skillset a bit and will definitely keep all that in mind as I go along on my journey.

Thanks to all of you guys for taking the time to respond to my topic! Your responses really did help me clear up a lot of  questions I had regarding coding and engines and were also full of useful information :).