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.