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.

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?

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 :).