Path of progression?

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.

Technically, it was a colour monitor, even if it was only green or orange, instead of just plain white. I had a fancy monitor that changed between these colours with the flick of a switch. 🙂

taby said:

Technically, it was a colour monitor, even if it was only green or orange, instead of just plain white. I had a fancy monitor that changed between these colours with the flick of a switch. 🙂

Now you're just bragging. 🙂

john6 said:
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.

I think you're misinterpreting.

All the posts are telling you to keep it simple, and the progression comes from doing the simplest things, then doing something slightly bigger, then something slightly bigger.

Pong is frequently suggested because for most beginners it seems like an easy challenge, something they ought to be able to just churn out. But then in practice even though it is a very easy video game, it ends up presenting enormous obstacles they have no idea how to overcome. It is beyond their skill, but they won't know it because they refuse to try.

It isn't telling you to learn to use Photoshop by programming shader languages. It is more akin to asking if you've tried mashed bananas, mashed potatoes, mashed rice, and are ready for more complex cereals yet.

Simply: have you built any games yet? Tic tac toe? Guess the number? Hangman? Sudoku? Have you built relatively simple clone games like pong, breakout, snake, or frogger? If you haven't built any of them yet, why do you think you have developed the skills to make more complex games?

If you haven't built ANY games, or you've built simple games, it changes the approach. Right now we're getting that you've got no experience climbing hills but are looking to climb Everest, or you've got no experience with foods but are hoping to start with a juicy steak, or you're asking to participate in a marathon when you haven't even walked around the block before. You absolutely can get there, but you've not given any indication that your current skill set is up to where it needs to be.

If you had come back in your reply with that you've made several clone games then the response would be different. As it is, the replies come across more as ego. “You can't make me practice! I've been playing this instrument for two months and I can try to play Chopin if I want!” Of course you can work on the advanced stuff, but there are well traveled roads people can follow to help you get there more quickly. That is starting with the simplest games.

I think pong or scrabble are not the coolest games to start, I give the guy a point there.

I think a walking sim is ok, as long as it's literally a walking sim: 1 basic man model that slides on key press and a plane for floor.

Then you can add walking animation.

Then you can a sky

Then you can add a house with no doors (box)

Then another static character.

Then a dialogue system.

Then (optional) a terrain.

It's doable. I followed these steps ages ago with XNA, but right after XNA was gone, and I hadn't clearly set goals or a purpose for my game. Went crazy into graphics, animations and details, but there was no purpose. That's why we are all suggesting: make a small & defined game. So make a walking sim THAT ends when the player reaches XXX goal.

That's it. There you have the steps you asked for.

And now that we all are here, if anyone is kind enough, please visit my post (link below), and give me some suggestion if possible; it'll be greatly appreciated 🙂

https://gamedev.net/forums/topic/717251-tidy-multiplayer-design/

john6 said:
It's a walking simulator.

For a walking simulator, you'll want to look into the following:

• Assets importing workflow.
• Gaining familiarity with the character controller, including how it behaves over slopes, stairs, narrow passages, etc. and how to tune it.
• Depending on the setting, you'll want to look at the terrain tools, including painting height maps, painting textures, placing props, and adding grass/foliage to the scene.
• Walking near a prop and triggering something, like a description of the prop showing up on screen.
• Clicking on a prop, like a door, to make it do something, like open or close.
• Lighting: real time and baked.
• Post Processing. Extra credit if post processing changes dynamically based on player actions/moving between zones.
• Sound effects like footsteps, the door opening, sound of a lever being pulled, etc. For extra credit, you could get footsteps that sound different based on the surface you're walking on.
• Music. For extra credit you could make it fade between different tracks depending on your location.
• Pausing the game.
• UI, including a start screen, credits screen, and an options menu. Rebinding keys and letting the player adjust basic graphics settings (resolution, anti-aliasing, etc.).
• Serialization and saving/loading.
• At various points during development, go through the full export process and run a release build of your game.
• Depending on what all you want in the game, you'll probably also have to learn the shader graph and the Cascade particle tools in Unreal as well.

john6 said:
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.

Nobody - myself included - said you should put UE aside to learn C++ first.

john6 said:
I am getting frustrated because I don't understand why almost all the “advice” amounts to starting back at square zero.

Don't get annoyed or frustrated so quickly.

If you don't want general beginner advice, then don't present yourself as a beginner, asking a extremely general question on what you should learn.

john6 said:
I fully understand the concept of taking small steps. That's exactly what I'm doing here.

You don't. What you you do is: You skip over learning the basics of game development, taking the easiest route possible, then complaining about people mentioning there is a chance of failure but there might be an even easier route.

john6 said:
But I don't see the need to put my life's story in a post just to ask a fairly simple question.

john6 said:
I am building a small game. It's a walking simulator.

Notice: The emotional complaints and expression of annoyance took more words than simply telling what you try to achieve. (Which would have been helpful information for the opening post. Chances are you can make a walking sim without C++.)

john6 said:
Cloning the games I threw quarters at 40 years ago would not keep me motivated.

My first game was not really Pong either.
But again: You've spend more words on describing what you don't want, don't like, don't care about, than telling us what you want to make, what's your experience and skills, or what's your actual question.
So what advice did you expect?

john6 said:
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.

That's actually irrelevant. Photoshop and GPU shaders have nothing to do with each other.
But any video game is actually a computer program. And thus programming is relevant to game development.

In your case somebody else has already written the program, and you only add content, click checkboxes and tweak sliders. That's fine. But i would be worried about hitting a wall at some point, and then it might turn out: At an age of 50 it's eventually too late to learn from the book on your shelf.

However, for a walking sim you should be able to navigate around those walls. Good luck.

Just to clarify to OP, before he get's any wrong ideas: Blueprint is programming, just with a visual interface. It has everything that a programming language has: Classes/Objects, Variables, Functions, Enums, Structs, Loops, Events/Delegates, Inheritance, Interfaces, Virtual Functions… Both “Unreal C++” (which is what I call it due to the pre-compiler) and Blueprints have their ups and downs, but if you learn Blueprints, you actually learn how to program in Unreal. It uses the same classes, the same functionality/systems, and you can easily port and Blueprint-class to C++ or vice versa. So if you are liking Blueprints, then it is the right choice, and there is not a chance that he will hit a wall, because the only real limitation of Blueprint is it's absolute abysmal performance… but then again, as said, you can translate any slow blueprint code to C++, which will take way less time to learn as you already know how programming in UE works at that point, and only need to learn the syntax.

In terms of type of game, I can second the advice to start small, even though (or maybe cause) I didn't follow it myself. I started a large-scale 2d action rpg at age 14, and had to basically redo the whole game manys times because, while I got things working, they were not scalable or good to use at all. I initially used Rpg-Maker events (which are a like a poor mans version of blueprints), ported everything to their RGSS (which is a poor mans version of a textual programming language), and now ported to my own engine (which finally works very well due to all the experience I have), and aren't finished after 16 years. Perpaps if I made smaller games initially, I'd saved all the time re-doing everything. Pong in Unreal truthfully sounds a bit too basic for me too, as Unreal takes away 95% of what you need to do to get something like Pong running (back when this advice was originally formed), I'd aim for something a bit more complex. So really, a walking-simulator, if you plan for it with a limited scope, could work just fine.

Juliean said:
the only real limitation of Blueprint is it's absolute abysmal performance…

Makes me wonder - is there a way to click a button, and it translates your blueprints to C++?
Sounds easy to do, and maybe it would help with performance?
Although i assume they already do this under the hood, raising the question of why blueprint perf. is as bad as people say.

JoeJ said:
Although i assume they already do this under the hood, raising the question of why blueprint perf. is as bad as people say.

Yes, there is a “nativization” system that does exactly that (convert Blueprint to C++), but at runtime. From what I've heard, it doesn't work perfectly in all situations, but in a lot of cases where it does, it provides a good speedup. Not sure why there is no button to do that for your assets, maybe because of it not working perfectly. They also use runtime-optimized replacement-algorithms, like placeholder-variable names from what I've seen (int var1210231452123 and so on, similar to IL2CPP), so that would make editor-auto convert a require manual fixups - still don't see a reason why it couldn't be done.

For “why” performance is bad, I can only tell you the technical reasons. Nativize apparently is not fully realized and can't be used as a default everywher, so lots of blueprints have to run on their bytecode/interpreter. And that is pretty much just shit :D I had a look into it a bit, and they only have like 64 opcodes, and no JIT. So pretty much every “instruction” has the overhead of not only the interpreting, but also having to go through many dynamic dispatches. For comparison, my own IL/bytecode (for my own Blueprint based Visual Language) has about 200 opcodes, to support native types like int without function-call overhead, and the performance is already multiple times faster than Blueprint.
Adding to that, they also don't have a JIT, which is something that pretty much any bytecode-based language has. My own JIT, in its very basic form (just laying out the machine code for each bytecode-instruction after each other and folding constants) already provided multiple times speedups. My second variant of that JIT already produces near-native quality code, with speeds that are very close to C++.
So what I'm saying is - there is no reason performance has to be that bad, why is it then? Eigther Unreal doesn't care to optimize it; there might be historic reasons for it… we can never fully know. But big companies usually don't think their visual scripting systems through fully. I know somebody who has the pleasure to work with Frostbite, and he told me that their visual scripting requires a page of code for every node that has to be exposed… yikes :D At least Unreals Blueprints are easy to use and extend code-side.

Juliean said:
For comparison, my own IL/bytecode (for my own Blueprint based Visual Language) has about 200 opcodes, to support native types like int without function-call overhead, and the performance is already multiple times faster than Blueprint.

What do you think about the upcoming Windows on ARM invasion?
Ifaik, you currently generate native x86 instructions. But assuming we get many ARM devices, and maybe RISC-V in ten years or who knows what, i guess such native approach becomes more and more unpractical in the future.
So, assuming programming remains a thing and we're not all replaced by AI bots, how can we deal with increasing variety of CPU architectures?
I assume we could generate something like Clang LLVM byte code instead x86 instructions, then use Clang as a library to compile that to native?
Ofc. there won't be so many architectures, so we could do this offline and just ship 3 binaries.
But if we did this on client, with all software not just scripts, Chip designers could change their instruction sets with every generation, like currently happening with GPUs. Which might be very helpful to counteract the stagnation on shrinking transistors.