Do you think using Unreal Engine could cripple the basics of a begginner programmer?

Recommended Posts

I mean, I realize that it does so much for me, collisions and physics to mention the probably most obvious things, that even though I am a begginner, I don't really need to learn those now...and this might be a really bad thing.

On the other hand, it gets out of the way the majority of the stuff that would stump a begginner trying to create a very simple game, so that even a begginner has a chance to create a simple game and see/understand better how everything interact with each other, and that's is a very good learning opportunity to improve because it ease the learning curve of what goes into a game.

What's your opinion on this? :)

What "stance" do you think a begginner should have regarding this fancy engines? 

Also do you think that my fear of a "learning potential" being cripple by it is an actual thing? I mean, should I really worry about it?

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

I think it can be a very valuable learning experience to build at least a simple game for yourself using lower level APIs.

However, I don't think it's neccesarily something you need to do first, and I don't think it's harmful to use an engine first. I will however note that caveat that if you're using C# with Unity, or C++ with Unreal, or whatever other option, it can definitely be beneficial to learn at least the basics of your chosen programming language outside of the engine so you don't have to focus on both things at once: i.e. I would get a book or find some tutorials on C# before trying to use Unity.

Share this post


Link to post
Share on other sites

Do you think a car with an automatic transmission and a full tank of gas would permanently damage your ability to drive, or should everyone start by learning how to change the oil and filters, rotate the tires, service the fuel injectors and rebuild the clutch on a manual transmission?

Share this post


Link to post
Share on other sites

Beginners gotta start somewhere. Besides that, I see nothing wrong with using engines like Unreal or Unity. Even AAA studios have used them to make some great games. (Examples: Hearthstone, Bioshock Infinite)

Share this post


Link to post
Share on other sites

I think there is real value in lowering the barrier for entry to computer programming, personally. Game development is a perfect example of how many different disciplines a person must be competent in before they can start pumping out programs of real worth. Using an example from non-game dev experience I've had, I once did a project with a doctor, who had all sorts of doctor problems and wants he needed solved by a computer program, but who wasn't a computer programmer. He very intimately understood his industry and the type of problems he'd run into, but had no way to put it into a program. After several weeks of back and forth of him teaching me things he'd needed to communicate for me to build his program for him, it wound up that the programming aspect of the project was actually pretty simple. Most of the time was actually getting me, the developer, up to speed in his area of expertise.

I often think of the number of people who have life-altering ideas that they just cannot translate into a program. Every skill someone is required to pick up is a barrier to entry that'll turn away a percentage of the potential total developer population.

This is a bit at odds with my general advice that someone looking to strengthen their grasp of computer programming should start low, with old hardware, so that they can fully grasp the ins and outs of talking to a machine. Indeed, computer programming knowledge is very cumulative. But put it this way -- how many great authors would we have lost, if it was a prerequisite that one knows how to press and form their own paper by hand?

Share this post


Link to post
Share on other sites

This brings up the question....do you want to make an engine, or make a game?  If you just want to make games and that's all you care about right now, then go right ahead with a game engine.  The above suggestions still apply.  If you want to make an engine(not my recommendation unless you want to for learning), then you could still start by using an engine just to get a feel for the kinds of things you don't have to do when using an engine(which are things you would have to do if you made the engine yourself).

I don't see anything wrong either with making something simple in with vanilla OpenGL/D3D in C++(or whatever).  Knowing a bit about the undersides of game engines can make you better at using said engines....but I don't think it is necessary, rather something that can possibly help.

Share this post


Link to post
Share on other sites

Unreal can't cripple a developer's code skills, skills in general don't work that way.

Then there is the fact that to be crippled you would have to be less than average, the average developer uses an engine. So learning the inner workings of an engine gives you an advantage.

 

Unreal will reduce the volume of code you need to do yourself to make a game, it won't reduce the level of code you need.

Share this post


Link to post
Share on other sites

Thanks for all the feedback guys, many good points here,  I am sure this answers will be useful to other beginners as well :)

That said, I'm personally seeying faster progress on my side because I can focus on learning what I need at a given moment without being crushed by needing too much stuff all at once in order to achieve the most basics of things, so my current plan will be to keep going with Unreal&C++, taking every oppurtunity to refactor blueprint nodes inside C++ when I see one, and let's see where I'll eventually land :P

 

 

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

Basic reality is that not everyone works on that low level stuff anyway, and if they do it might only be small sections of it at a time. Contrary to what you might expect not everyone needs to know how to make all that low level stuff like game loops, input handling, physics, etc. Is it helpful to know? Sure! In reality someone with good programming knowledge that gets thrown into even a proprietary engine like frostbite or something will be working in a separate layer from all that stuff, it already exists.

Coincidentally, even if you want to work on that low level stuff, often someone new to industry won't be trusted with it anyway, so you would end up learning piecemeal by working around it, people can get quite good at developing software like that without ever having made their own version from scratch. But at any rate, it doesn't hurt to know.

Share this post


Link to post
Share on other sites

It really depends on the level-of-detail you want to master.

The same can be set for third-party and standard libraries of a programming languages: if you use them, will it limit your abilities? In the extreme, we can go even further: network protocols, OS, instruction set architectures, till we eventually reach the semiconductor level (and we can probably go even further).

Knowledge and experience with neither of these levels-of-detail will have a bad impact. On the other hand, nothing comes for free. Don't expect that sticking to one domain, will reveal all the secrets of other domains. Translated to your specific topic: don't expect that using Unreal makes you an expert in collision detection and physics.

Share this post


Link to post
Share on other sites

My stance is this:

If you're a "beginner programmer", I think you should write a simple game, like Pong or Breakout "from scratch".  Do it one time, and see how much it sucks to write.  Spoiler alert:  It will suck :-D The good news is: it's a simple enough game that you can finish it; or you can get far enough to realize that you don't want to finish it, because writing every-single-aspect-of-the-engine sucks:  The game loop; input/command handling; object/asset/resource management; sound/music; collision detection; physics; graphics/rendering; etc... 

Then, write the same game in Unreal Engine, and see how much faster you go. If you're a complete beginner, the development time might be longer than you think (time spent learning Unreal Engine/API).  But you'll quickly find that writing a game using Unreal goes WAY faster than writing the game and also the rest of the engine

Unless you WANT to write engines (like me:  I so happen to enjoy writing the engine bits).  Then, by all means, write the engine bits, and then write the game, using your own engine.  But that's not necesary to make games.  Indeed, some kits allow you to make entire games without writing any code at all.  Using those doesn't make you any less of a game developer (well, maybe less of a software developer, but no less a maker-of-games.. and the goal is to make games, right?)

Share this post


Link to post
Share on other sites

To answer your question in the context of "Do you think using Unreal Engine could cripple the basics of a begginner programmer?".

I don't believe it can cripple the basics of a beginner programmer because the word cripple in this context refers to disabling someones ability to program. I've known people that have used drag and drop game engines for years, and started pumping out iOS games after learning objective-C! Just because the engine handled a lot of tasks prior didn't prevent people I've known from programming those same functions from scratch once they learned the language, and understood the library.

To be honest, I started on GameMaker 3 back in 2001 when Mark Overmars was working on it still. I was able to make games, but felt very limited in what I wanted to do (If I wanted to make changes to the engine, I couldn't, I needed to wait for those changes), and always enjoyed re-inventing the wheel to a degree. I ended up jumping into Basic, C++, JAVA, C#, and many other languages throughout the years designing my own engines and editors using low level libraries. The many times I went back to such tools, and even tried some engines, I always went back to coding for some reason, I wanted more control, and to dive deeper. In the 2D world, I have no reason with my code base to even consider any game engine.

I haven't used Unreal yet, but intend to in the future as I have not developed, or intend to develop a 3D engine. However, I only want to work directly in code and avoid using Blueprints. Faster or not, I still enjoy the creative process with code and control. Unreal offers an outstanding deal for those wanting a AAA engine to make games with a very decent licensing package.

Everyone has different goals. Mine wasn't just to create games, but the engine and editors that built those games. I wanted to dive deeper, and be in control. Some people want to develop games with as little low level programming as possible, or even no coding. Others enjoy that process, and many have gained enough experience and knowledge that it's not a daunting task to code their game from the ground up. If someone is happy using RPG Maker, GameMaker, or a game engine, so be it! We're here because we love making games, however you do that isn't important.

Share this post


Link to post
Share on other sites

I don't believe using advanced engines to make games, and learning to program as a programmer have anything to do with each other.  If you think of each of these as skills in an RPG called "technology career simulator 2017" you would see that having a "designing games" gives a small bonus to checks of the "designing computer games" skill (full bonus for simple indie games, half bonus for FPS/Sports style games) ... and "basic programming and hacking" is a prerequisite for "advanced programming and design" and so is "computer science and programming theory", but the skill "game modding / level design" doesn't require any of those (it does get bonuses from programming and hacking though) ... and "3D game development (using engine)" gets full bonuses from any programming or hacking or modding or asset skills ... but doesn't require any of them.

So what I'm saying ... in a long winded way ... is that these are 2 separate parallel things, that don't form the foundation of each other at all ... but skills in either will somewhat help you in the other, only because they each kind of help you with different aspects of "the big picture" ... a required skill if you want to do things 20 years down the road like "game engine architect" or "lead game producer" (maybe)

If you wanted to do a career in music, learning to play guitar/drums/piano wouldn't be directly preferred skills before learning to use sequencing software, be a sound technician, or DJ.  nor the other way around.  BUT, if you had learned any of those, it would give you a starting point/frame of reference to make learning the other side less like starting from nothing (more of the terms and concepts would feel familiar than when you had done nothing in the field at all).

Share this post


Link to post
Share on other sites

In my opinion. Learning the basics outside the engine is a good thing. I'm talking about the very basics, nothing in depth. I think this will help you understand problems and how to solve them a bit faster later on. I'm not saying you can't learn programming while working in an engine, but it will probably be easier if you already know enough programming to understand how to read the API documentation.. It will likely also help you to break down and think about the problem you want to solve. (also useful while looking for help). Engines will hide some basic concepts from you that you won't even know you need at some point. 

As said, this will most likely only hurt you short term, as long as you're willing to learn. This can be applied to  different levels of programming languages as well.

SO, the short answer IMO is no, but learning programming languages and concepts outside an engine is a better approach, and should pay off quickly.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Forum Statistics

    • Total Topics
      628675
    • Total Posts
      2984169
  • Similar Content

    • By composerjones
      Hey guys, I just composed a new piece that is definitely inspired by scores of the Final Fantasy series and the Kingdom Hearts series. I hope you guys enjoy!
       
    • By sang_261198
      Hi everyone.
      My name is Sang and I am a student in primary school. I studied Java and  i am really like it.
      and now I want to learn make game a game use Java in Java Swing. Would you like give me some websites teach make game java for begginers, please?
      Thank you very much!
    • By Exoaria
      I have an inventory system that I am trying to make as part of my first programming venture.
      Creating the inventory doesn't seem to pose the challenge, but rather the control flow and code organisation that is needed. I have done some research, but I can't find the answers that I need. Instead, I have become confused, which you will see if you read my sheets I've been scribbling on trying to figure out how to work it.
      Most of the information that I think anyone would need to take part in this discussion can be found in that link. I am using flawed logic, but I don't know how it is flawed, since I am coming from the perspective of someone who is new to code and does not have a lot of experience with the optimal interactivity between functions and the logic that should be used in these situations.
      Essentially, I hope to gain some seeds of wisdom from someone else that may have been in my position or a nudge in the right direction from someone else who, in fact, can see where my logic is flawed and where it needs to be shifted.
    • By aejt
      I recently started getting into graphics programming (2nd try, first try was many years ago) and I'm working on a 3d rendering engine which I hope to be able to make a 3D game with sooner or later. I have plenty of C++ experience, but not a lot when it comes to graphics, and while it's definitely going much better this time, I'm having trouble figuring out how assets are usually handled by engines.
      I'm not having trouble with handling the GPU resources, but more so with how the resources should be defined and used in the system (materials, models, etc).
      This is my plan now, I've implemented most of it except for the XML parts and factories and those are the ones I'm not sure of at all:
      I have these classes:
      For GPU resources:
      Geometry: holds and manages everything needed to render a geometry: VAO, VBO, EBO. Texture: holds and manages a texture which is loaded into the GPU. Shader: holds and manages a shader which is loaded into the GPU. For assets relying on GPU resources:
      Material: holds a shader resource, multiple texture resources, as well as uniform settings. Mesh: holds a geometry and a material. Model: holds multiple meshes, possibly in a tree structure to more easily support skinning later on? For handling GPU resources:
      ResourceCache<T>: T can be any resource loaded into the GPU. It owns these resources and only hands out handles to them on request (currently string identifiers are used when requesting handles, but all resources are stored in a vector and each handle only contains resource's index in that vector) Resource<T>: The handles given out from ResourceCache. The handles are reference counted and to get the underlying resource you simply deference like with pointers (*handle).  
      And my plan is to define everything into these XML documents to abstract away files:
      Resources.xml for ref-counted GPU resources (geometry, shaders, textures) Resources are assigned names/ids and resource files, and possibly some attributes (what vertex attributes does this geometry have? what vertex attributes does this shader expect? what uniforms does this shader use? and so on) Are reference counted using ResourceCache<T> Assets.xml for assets using the GPU resources (materials, meshes, models) Assets are not reference counted, but they hold handles to ref-counted resources. References the resources defined in Resources.xml by names/ids. The XMLs are loaded into some structure in memory which is then used for loading the resources/assets using factory classes:
      Factory classes for resources:
      For example, a texture factory could contain the texture definitions from the XML containing data about textures in the game, as well as a cache containing all loaded textures. This means it has mappings from each name/id to a file and when asked to load a texture with a name/id, it can look up its path and use a "BinaryLoader" to either load the file and create the resource directly, or asynchronously load the file's data into a queue which then can be read from later to create the resources synchronously in the GL context. These factories only return handles.
      Factory classes for assets:
      Much like for resources, these classes contain the definitions for the assets they can load. For example, with the definition the MaterialFactory will know which shader, textures and possibly uniform a certain material has, and with the help of TextureFactory and ShaderFactory, it can retrieve handles to the resources it needs (Shader + Textures), setup itself from XML data (uniform values), and return a created instance of requested material. These factories return actual instances, not handles (but the instances contain handles).
       
       
      Is this a good or commonly used approach? Is this going to bite me in the ass later on? Are there other more preferable approaches? Is this outside of the scope of a 3d renderer and should be on the engine side? I'd love to receive and kind of advice or suggestions!
      Thanks!
    • By deltaKshatriya
      Hey all,
      As some of you may know, I do have a Computer Science background, but either by chance/design/fate/insert stupid excuse here, I didn't take any graphics courses in my undergraduate degree, but now I'd be very interested in at least learning the basics of graphics and potentially pursuing more in graphics. I'm interested in all sorts of graphics in general, so everything from real-time engines to rendering engines like Arnold, Octane, etc. Can anyone point me in the right directions for books/tutorials?
      Thanks in advance!
      EDIT: Apologies in advance if I missed the proper channels for this as well
  • Popular Now