Hi, I have a question.

Whenever I try to develop a game, I end up with problems in software design which I am usually unable to fix. So I was wondering what could or couldn't help you until I stoped at "design patterns".

Are they crucial for a beginner in game development area or not? What would you recommend to read to learn about software design or OOP in this case??

Thank you for answer,

Tetriarch

Are they crucial for a beginner in game development area or not?

They aren't crucial at all, and in fact focusing your learning on them too early can misguide you.

Design patterns are useful as a way to establish a common language for speaking about problems and solutions. They're useful so that when I talk about a "factory-like" approach to a problem with other developers, those other developers know I mean some kind of solution that involves creating new objects (at runtime) from some kind of key (at runtime) and we don't have to rehash the basic fundamentals of the problem.

For fostering communication, design patterns are great. By they aren't specific solutions to specific problems you are having. If you fall into the trap of looking at them as ready-made implementations to apply to a problem, you fall into the same trap that involves every problem looking like a nail because you have a shiny new hammer. There isn't one way to solve a problem using a "factory;" it's just a pattern, not a drop-in silver bullet. Don't think of them as such or you will unnecessarily limit your ability to solve problems effectively by (potentially) trying to shoehorn in some preconceived implementation.

Thank you Josh.

So if I can remove design patterns of the list. Is there any source or article about OOP you would recommend? Probably considering C++ might be good.

Thank you.

Is there something specific you are trying to learn about?

My own general c++ book recommendation list is located here.

Be aware that there are many tutorials, guides, and books that have terrible errors and major flaws. Others cover the language well but are difficult to read or present the material poorly.

There are also many outdated books that no longer apply. The history of C++ goes back to around 1979 as a C compiler, the name changed to "C++" in 1983. If you pick up a book describing C++ as it existed in 1983 or 1989 or 1995 the code will probably not build on a modern c++ compiler.

As Josh mentioned, design patterns are just names for common things. Like "Peer to peer", or "shared blackboard", or "event driven system", or "factory method". They are common patterns encountered all the time in software that people give names to easier communication.

It is like a mechanic talking about "skew gears", "reduction gears", "miter gears", "worm gears", "rack and pinion gears", etc. You don't have to use all of them in projects, but they are useful to know so everyone can mean the same thing when they talk about it. They can say "Rack and pinion" and you know "a wheel on one side, a bar or track on the other".

The are things you will eventually learn, but it is not essential that you learn all the common patterns up front. You will learn about them, see them, and have them described to you often enough as you learn. Eventually you'll probably want to read some books to ensure you've got the basics covered, but it isn't necessary for the beginner.

While Josh is spot on, I would make one amendment:

Learn about patterns, not as a way to solve your problems, but as a way to expand your vocabulary of solutions. You probably won't find a pattern that fixes some arbitrary issue you're dealing with at Moment X, but you might find ideas that help you rearrange your software into new shapes. Those shapes can help you in turn to address or even outright avoid the original headache.

Usually (but not always!) when you find a problem you can't solve, it's because you've made some decisions a few steps back that conflict with the way the tools you're using work. Sometimes the answer is just to learn a different tool, but most often the answer is to go back and question your assumptions as vigorously as possible, and think about ways to rearrange your model of the program such that the problem doesn't manifest.

Okay guys, thanks a lot for help, I think that this pretty much solves my problem..

Whenever I try to develop a game, I end up with problems in software design which I am usually unable to fix. So I was wondering what could or couldn't help

What likely works is to start discussing your problem in a forum like this one, or to some other person.

Once we set our mind to some idea, it's hard to look outside those ideas even if they are totally nonsense (but being stuck in all the details, you tend to fail to see that). Don't worry, it happens to everybody This is how the human mind works.
Programming is a lot about all the little details, and it's easy to get totally lost in the big picture.

By talking to other people, you have to explain why you made certain decisions. Those explanations make you reconsider what you are trying to achieve (the teddybear programming effect). Also, other people come to the problem fresh, and often see other directions to solve it.

Nope. Design patterns in the beginning are not crucial nor necessary. You learn those with experience. But after you have several completed games or projects under your belt. Your first, primary, and singular goal is to finish making the game. Making sure it runs. And making sure it does what you expect it to do.

Designs patterns are merely a way of solving a pattern of issues.

There are some patterns that are most useful for game developments because of how it interacts with objects.

As a software developer I should say it is always important to know your patterns.

They are easy to use and can be very helpful for solving a problem.

However, don't take it too seriously, Designs patterns are good to have, but as any other tool for designing, you should carefuly inspect the pattern and why it fits as your solution.

Good luck!