• Advertisement

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
Advertisement
2 minutes ago, MarcusAseth said:

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

Yes. Forever.

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


  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By LifeArtist
      Good Evening,
      I want to make a 2D game which involves displaying some debug information. Especially for collision, enemy sights and so on ...
      First of I was thinking about all those shapes which I need will need for debugging purposes: circles, rectangles, lines, polygons.
      I am really stucked right now because of the fundamental question:
      Where do I store my vertices positions for each line (object)? Currently I am not using a model matrix because I am using orthographic projection and set the final position within the VBO. That means that if I add a new line I would have to expand the "points" array and re-upload (recall glBufferData) it every time. The other method would be to use a model matrix and a fixed vbo for a line but it would be also messy to exactly create a line from (0,0) to (100,20) calculating the rotation and scale to make it fit.
      If I proceed with option 1 "updating the array each frame" I was thinking of having 4 draw calls every frame for the lines vao, polygons vao and so on. 
      In addition to that I am planning to use some sort of ECS based architecture. So the other question would be:
      Should I treat those debug objects as entities/components?
      For me it would make sense to treat them as entities but that's creates a new issue with the previous array approach because it would have for example a transform and render component. A special render component for debug objects (no texture etc) ... For me the transform component is also just a matrix but how would I then define a line?
      Treating them as components would'nt be a good idea in my eyes because then I would always need an entity. Well entity is just an id !? So maybe its a component?
      Regards,
      LifeArtist
    • By kane david
      I want to start learning Level Design, so what are the main topics I have to learn about  specifically? since I learn on my own, so I don't want to drop something that could be important, and if there are some suggested books or courses to start from.
    • By Pooria1987
      Greetings to you all,
      I intend to build a 3D engine in C++ (I'm experienced with C++) targeting PC (OpenGL for sure and maybe Direct3D too), mostly as a hobby and to learn how it works at a low level. I've done some research and come up with these two books:
      3d math primer for Graphics and Game Development (2nd edition) Game Engine Architecture (2nd edition), By Jason Gregory Also at first I want to use an existing physics engine like physx or bullet and then maybe go for developing my own one later after I put the rest of my engine together. Now since for sure there are a lot of experienced people here I want to ask you which other books/resources do you recommend I study to help me implement my engine.
    • By GameDevCoder
      I am looking to learn C++ in Unreal so have commenced the tutorial '3rd Person Battery Collector Power Up Game'.
      It is on the 3rd video of the series that I have come across an issue. In the screenshot I have attached labelled 'picture 1', this is the tutors class which is correct. My screenshot 'picture 2' is where I see some issues.
      - my #include is in a grey colour font. It should be red right?
      - I also do not have a #include "BatteryCollector.h" in my class also. In the tutors example this line of code is present.
      Can anyone help me with why I have these issues. I am using Visual Studio 2015 as well. I thought would using VS'17 help so I installed this today. I have yet to try this out with that though but then I thought. Shouldn't it work fine on VS'15 anyway, would using VS'17 make much difference at all.
      I am very keen to work through this tutorial today so if the forum might be able to help me I would be so so grateful.
      Thank you.


    • By Andre Zunino
      Hello.
      First, a bit of context. I'm having my first contact with the entity-component-system architectural pattern in the simple shoot'em up game I'm writing. I appreciate the flexibility and decoupling the pattern promotes. So far, I believe I have the basics down. I have already defined a handful of components and systems which operate based on them.
      I'm now looking to add a cannon to the player's spaceship. I defined a Cannon component and attached it to the player entity (IOW, I "tagged" the player entity as having that capability). That component has a single member which indicates the cannon's rate of fire. Then I defined a PlayerWeapon system that is responsible for actually firing. At the moment, all it's doing is write a message to the console. Because no actual rate control is implemented yet, each press of the assigned fire button causes multiple messages to be output in quick succession. I would like to implement a sort of debouncing mechanism to have the fire rate respect what the cannon component dictates, e.g. fire once every 500ms.
      Now for the actual question on ECS modeling. Suppose I'd use a simple elapsed time accumulator to decide when the next shot should be allowed to fire. Where would that information be stored? Should the system be responsible for managing that type of information? Or should systems be considered completely stateless? In that case, the accumulator would be stored in the cannon component, along with the existing fire rate. Would you kindly share some advice on how to handle a situation like the above? As stated, I'm new to ECS and would like to make sure I implement the concepts as properly as possible.
      Thank you.
  • Advertisement