A bit of background:

I've been playing games since before computers had color monitors. I spent hours in arcades when they were at their peak of popularity. I am absolutely passionate about gaming. Which is why I find myself getting into gamedev now. I want to make games people can be passionate about, rather than trying to churn out the Next Big Thing, lowest-common-denominator kind of game trying to become a billionaire.

So, I installed UE5 to start tinkering. I quickly learned that making games can be more entertaining than playing them. You get all the juicy, OCD tingles of solving problems and drilling down into irrelevant minutia without having to deal with whatever gamification a dev thought would be fun.

And the crux of the issue:

Anyhow, my question is whether there's any sort of logical progression to learning the engine or gamedev in general. I've spent my first few days in UE5 obsessing over the camera, trying to get exactly the look I want as far as field of view, depth of field, removing head bob from the 3rd person pawn, etc. And I am perfectly content to proceed at a snail's pace learning the absolute fundamentals of the process. I have multiple game ideas that can be built in layers over time. But I'm looking at it from a player's perspective. So I don't really know what foundational things I may need to work on. Obviously, getting the character to move the way I want and figuring out other gameplay mechanics will be part of the process. But that seems maybe a layer or two above where I might want to focus right now. Or do I need to have some sort of rudimentary, playable “game” before I worry about learning how to optimize things or how to save/load data? I mean, I don't even know how to turn what I have in the engine into an external program which runs outside the engine.

TL;DR- What do I need to study other than gameplay mechanics and plopping textures on meshes?

john6 said:
TL;DR- What do I need to study other than gameplay mechanics and plopping textures on meshes?

Programming of coarse.

john6 said:
I've been playing games since before computers had color monitors.

This would have been the right time to get started with it. :P

Unreal has two primary ways for programming:
1. C++, which is not easy but can generate efficient programs. The Engine itself is written in C++.
2. Blue Scripts, Unreals visual scripting language. Easy and GUI driven, but results can be inefficient and there are limitations.

I would check some Blue Script tutorials, e.g. to implement a simple Pong game.

Btw, Unreal is not really easy for total beginners, people say.
An easy option would be GameMaker, Unity or Godot is already harder, then Unreal.
That's what i hear from other devs at least. So if you run into countless dead ends, try another engine eventually.

JoeJ said:

Btw, Unreal is not really easy for total beginners, people say.
An easy option would be GameMaker, Unity or Godot is already harder, then Unreal.
That's what i hear from other devs at least. So if you run into countless dead ends, try another engine eventually.

I'm actually finding it pretty easy. Blueprints are fairly simple to work with, even if it isn't always easy to find a node that does what you want. I never said I was looking for the easy option.

The problem with tutorials is that they are quickly outdated. Stuff from just a few months ago no longer works because nodes have changed. Plus, most of them are superficial and don't explain why they are doing things. They just tell you plug this here and that there. That isn't learning.

I get that “make Pong” is kind of the standard programming 101 thing. But I don't see how that would be helpful to me. Anything I would learn by making Pong I could also learn by working towards a real game. I don't need to knock something out in a day to feel accomplished.

john6 said:
I get that “make Pong” is kind of the standard programming 101 thing. But I don't see how that would be helpful to me. Anything I would learn by making Pong I could also learn by working towards a real game.

Pong is a real game. The reason people propose it to beginners is that it's very simple, so chances to make it work are higher than coding your own physics engine or GTA clone for example.

john6 said:
I get that “make Pong” is kind of the standard programming 101 thing. But I don't see how that would be helpful to me.

I assume you can't see it because you don't see a need for programming at all yet, since so far Blueprints are good enough.

If you are lucky, it remains enough to make the game you want. And if performance is fine as well, you don't need to learn programming.

If you are interested in how games actually work, or you need some functionality which is not some out of the box standard, programming is the answer to your question about what to study.

Time will tell, but i assume Blueprint is a good preparation to learn some real programming later if needed.

JoeJ said:

john6 said:
I get that “make Pong” is kind of the standard programming 101 thing. But I don't see how that would be helpful to me.

I assume you can't see it because you don't see a need for programming at all yet, since so far Blueprints are good enough.

If you are lucky, it remains enough to make the game you want. And if performance is fine as well, you don't need to learn programming.

If you are interested in how games actually work, or you need some functionality which is not some out of the box standard, programming is the answer to your question about what to study.

Time will tell, but i assume Blueprint is a good preparation to learn some real programming later if needed.

It's not that I don't see a need for programming. I use Powershell regularly, I'm familiar with BASH, and I've dabbled in everything from Lua to Haskell. There's a C++ book sitting on the stand next to me, several Rust books strewn about the house. The rig I'm on right now is one I built myself. And I have 11 IT certs in my pocket. You can't just assume that because somebody is in the “beginner” section that this is the first time they've ever turned on a computer. I don't need to learn C++ to make a playable game in UE5. I'm not trying to make GTA VII or my own physics engine. Learning C++ can come later, when I need it to get around some obstacle.

I think you're missing the point.

You started with this question:

john6 said:
What do I need to study other than gameplay mechanics and plopping textures on meshes?

And the response was basically: Make pong. It's an easy game and helps you recognize what skills you lack.

Instead of saying something like “I've made pong in 4 different tools, I'm comfortable with all the things I need for that level”, your response was:

john6 said:
I don't see how that would be helpful to me. Anything I would learn by making Pong I could also learn by working towards a real game. I don't need to knock something out in a day to feel accomplished.

And therein is the issue. Pong IS a real game. It's an easy game. Do you have the skills right now that you could make it, or not?

One common recommendation is a sequence like

• Guess the number
• Tic-Tac Toe, Hangman, etc.
• Pong clone.
• Clones of Breakout, Snake, and Tetris
• Assorted 1970s arcade games.

Every step teaches new skills and hones old ones.

Pong's got input, rendering and animation, physics collision detection and response, audio, scores as a very simple inventory, simple AI logic, basic UI with numbers up to 10 plus whatever you use for a splash screen and attract cycle, and much more. It's all there.

It's simple enough that with good tools an experienced programmer can crank out a pretty polished version in a few days, yet complex enough that you can hang all kinds of fancy elements on it if you want.

It is certainly easy to BELIEVE you have the skills that you could make a pong clone. It is quite another to actually DEMONSTRATE that you can do so. Lots of beginners never cross even this threshold, wanting to jump directly to their open world 3D masterpiece.

If you're working with an engine look for the official guides and walkthroughs that start with an empty project and go through to a finished, basic game. In Unreal they'll start with a basic empty level and slowly add a few actors, slowly starting with Blueprint-driven functionality and then gradually moving to code for Components and Actors. For Unity it's similar, starting with prebuilt assets and slowly adding your own MonoBehaviour and GameObject types.

In those it might not be Pong and Breakout, instead they'll be 3D variants of the same simple theme. The guides will be moving simple boxes around and using pre-built first-person or third-person characters that run around pre-built worlds, but they're still very basic. They're still push the block using built-in physics, touch the target with built-in response, draw some numbers on screen as a score as a basic UI.

Hello, there are a couple things I may put together from what I've read here, mixed with what I've been through (in no particular order):

-"Or do I need to have some sort of rudimentary, playable “game” before I worry about learning how to optimize things" - yes. It happens to me from time to time that I focus during several days on something that's not a priority (shaders, aesthetics, etc.) when I actually am at a 5% of the project. The difference is that now I do it consciously to relax my thoughts after getting stuck with something.
To be short: you need to see overall progress. You need to see your idea coming to life, because it's fun, because it will show you if your plan was good, or not so much.

-C++, Haskell, Cobol, C# or Fortran: Game engines will encapsulate a lot of painful work, and relieve you from it (manually building a window in C++ was a torture back in the day). I believe you can create games using game engines, with close to zero programming. But: coming to certain point you may be limited, and if you totally rely on game engines, you may get similar results to what other people do (like we could notice that Blood, Shadow Warrior and a couple more used the Build engine from Duke Nukem 3D, so they all looked and played similar). What you can do: use the engine as much as you can. If later on anything is not doable without code, then you can research on it. For example, nowadays game engines rely a lot on Events (onClick, onKeyPressed, these type of things. I don't know how that is handled on Unreal, but if it's with events, maybe that's something you can look into, in case you need to).

-Try to do something small, define your scope in a realistic way: Nowadays games are made by millions of people. You are one. This is something I need to tell myself as well, as I tend to dream a bit too much sometimes…

-When you have something, show it to someone. If it's not an IT person: better. They will judge it and tear it apart. That's not a bad thing, it helps us seeing things the way normal people do!

My experience lately, and a couple different areas:

-Engine: I started making a game in Unity. It was not difficult to learn, but the Game Editor was a disgrace. It was crashing all the time, it was terribly slow, it was giving false errors. Bad. Last year they made a very bad movement (legal / commercial) so I immediately changed to Godot. Had to learn it from zero. But discovered it's much more aligned to my way of thinking. I very much like it. Some things are more limited or more “humble”, but I still like it. If there is not enough info, or YouTube tutorials are outdated quickly, maybe you can parallelly install another engine and play with it just for fun (Godot doesn't even need installing and it's 154mb; a walk in the park).

-Single Player / Multiplayer: I decided to go multiplayer on my project. I won't say “don't take this route”. I will say: it's a pain. But if you like networking, then you may like it. I wouldn't advice to start there though.

-Graphics: choose 3D or 2D. With 3D you'll have to deal with modelling, 3D animations, transforms, etc. 2D is easier but of course, you have less freedom (1 dimension less will limit your camera, movements, visuals, etc.) 3D is a lot, a lot of work. Decisions, decisions…

Nowadays YouTube is probably one of the best tools to learn. None of us is born knowing it all, and we learn on the go!

john6 said:
You can't just assume that because somebody is in the “beginner” section that this is the first time they've ever turned on a computer.

I do not assume that people which use computers also have some programming background.
And it's 2024. I do no longer assume that somebody who posts here about starting to make games has programming background either, since there are now so many options to avoid it.

You did not mention your programming background or programming at all, while indicating gameplay mechanics or textured models would be the foundation of game dev. Which is not the case. Programmers wrote game programs for fun, and only after a while it made sense to analyze the games regarding common or different mechanics, and 3D models with textures came much later.

So, from given context i could not know you already have background.
But the impression you make in a first post is under your control, and so it's not my fault.

The joke about ‘starting with programming earlier might have been smart’ - that's my fault. (but you still did not clarify until now)
Now the discussion seemingly derails into kind of self defense. And i feel guilty and apologize. This was not my intent.

john6 said:
I don't need to learn C++ to make a playable game in UE5. I'm not trying to make GTA VII or my own physics engine. Learning C++ can come later, when I need it to get around some obstacle.

Yeah. That's fine.

But i want to strengthen my concern regarding engine choice anyway, just to point out why UE is usually less ideal for beginners, compared to Unity for example.

Let's say you run into issues where Blueprint is no longer enough, which is quite likely.
Then you do not only need to learn C++, but also how the engine works under the hood, the interfaces it exposes, etc. It's an engine made for larger AAA teams having expert devs, and i'm pretty sure it's far from easy.
Contrary, Unity is made for indies, and it's goal is to keep it simple. They use C# as the language to implement gameplay, which is easier than C++. Engine internals are only exposed for those who pay extra to get the C++ engine source code, which implies in the general case there should be no need to go down to this low level at all.

Personally i lack serious experience with both of those engines, but that's the overall impression i catch up. Unity is easy and beginner friendly, UE is advanced and requires expertise.

However - i don't want to convince you about using another engine!
Seems you do fine with UE so far and like it, so stick with it.

john6 said:
TL;DR- What do I need to study other than gameplay mechanics and plopping textures on meshes?

Well, beside programming, there's also content creation topics like level design, modeling, texturing, animation, etc. There are also more technical topics such as optimization, simulation, compression, audio, and much more.

It's infinite. But just move on and if you have concrete questions, people her can help. ; )

john6 said:
It's not that I don't see a need for programming. I use Powershell regularly, I'm familiar with BASH, and I've dabbled in everything from Lua to Haskell. There's a C++ book sitting on the stand next to me, several Rust books strewn about the house. The rig I'm on right now is one I built myself. And I have 11 IT certs in my pocket. You can't just assume that because somebody is in the “beginner” section that this is the first time they've ever turned on a computer. I don't need to learn C++ to make a playable game in UE5. I'm not trying to make GTA VII or my own physics engine. Learning C++ can come later, when I need it to get around some obstacle.

None of that matters here. What I care about is finished games. Until you've finished a game, I consider you more of a beginner than the 14 year old who made pacman in Roblox, finished it, and released it. John Romero worked on 27 games in the two years before Wolfenstein, and John Carmack worked on 18 in the same time. 18 small games is worth a thousand certifications, and a million books on C++ and Rust.

The primary reason you make a complete small game when you start out is because you need to learn the basics of game development. Games, like any large software project, are complex, interconnected machines where everything affects everything else, often in subtle ways you don't realize until the very end. If you start on a large project, the small, important details get lost in the noise. Working on smaller games makes those small, important details more apparent so you can learn about them easier. You're learning how to throw a straight punch and keep your head down before you move on to combinations. You may think “I've written software before, I know the basics”, but then you should know that the way these elements affect each other change when you change domains. I've seen it a dozen times. “I wouldn't get anything out of making a simple game” followed shortly by “I'm tearing it all down and starting over because past me was an idiot”. It's happened to me, I'll happen to you.

Okay, let me regroup here and try to clarify. I am getting frustrated because I don't understand why almost all the “advice” amounts to starting back at square zero. I fully understand the concept of taking small steps. That's exactly what I'm doing here. And the only way I could possibly convey that in my first post would be to give a complete dissertation on what I've done and what my goals are and how I intend to get there. But I don't see the need to put my life's story in a post just to ask a fairly simple question. And nobody would read the entire thing if I did. The major motivation behind using UE was precisely the fact that it allows you to do a great deal without typing the code. So being told right off the bat that the first thing I need to do is stop messing with UE and learn C++ was beyond annoying. Yes, it may be essential before I get busy making the ultimatest AAA game the world has ever seen. But you don't need C++ to move the silly mannequin around a completely procedural map. I have a long way to go, making interesting progress and learning about the actual design/implementation side of the field before I have to worry about writing actual code.

As for Pong being a real game, who cares? You don't have to be a good checkers player before you start to learn chess. I know you can learn things by building smaller games. My point is that I'm not trying to build AAA stuff over here. I am building a small game. It's a walking simulator. And UE gave me a head start by supplying all the models, the animations, the bits and pieces that interact with the screen, the OS, and the GPU. Basically all I've done for a week or so now is fiddle with camera settings and tweak blueprints to change the character's behavior. I'm going about as slow as is possible. And I'm perfectly content with that. At the moment, I'm struggling getting landscapes and skyboxes to work right. No big deal, I'm learning. I also have to figure out how to move the UE install since it cluttered up my OS drive. I'll sort that out. By then, I'll have a better handle on UE and I'll be able to tackle other details. The main thing is that every tiny thing I accomplish right now actually builds towards something I can see in the future. That is what keeps me motivated. Cloning the games I threw quarters at 40 years ago would not keep me motivated.

So, yeah, I'm riled up about people telling me I need to take it easy and learn the basics… that's exactly what I am doing already. And if somebody asks, “any tips for getting into graphic design with Photoshop?” you shouldn't jump in and tell them they need to learn GLSL first.