I've already made small applications with SFML to just render a sprite on screen, handle basic WASD movement (not pretty Lol) and such smaller things.

Now build it up. Eg:

- Draw a box on the screen. Make it move. Add another box (enemy). Check for collision.

- Next show that the boxes have collided somehow on the screen (eg a new box is drawn on the screen).

- Add some logic. Add sound. Add game states (main menu, levels).

Congrats you just made you first game.

(I would seriously put a time limit like 24/48 hours to finish it, even less. That way I hope your design paralysis wouldnt get in the way of doing stuff.)

It can be something like a 2D shooter with one level where you shoot at a incoming wave of enemies. It can be pong. Whatever it is, it needs to have sound, game states (main menu, one level), rendering, input, (hopefully collision), AI. Then make something else, then again.

That is the only way to see/experiance/understand game design. You will see how all the different aspects are connected together to make a game. As you make more small games you will start to understand why more advanced paradigms are needed and what problems they solve. As you experience increases you will be able to actually make better designs as you will start to forsee upcoming problems using your past projects as a starting point.

It's all Logic after all. It must be logically possible to dechipher this pattern/philosophy/methodology one bit at a time until I got a certain whole :3

The pattern is loading data from files so less parts are hard coded. However without understanding the need for it, its pretty useless. The understanding part comes from experience.

I can understand this way of developing and that is also what I aim to do (Currently). I just can't really get my head around the actual implementation in code. That's all.

Because its like trying to force a solution for an unknown problem. Hint: It doesnt work like that.

I have already been programming for 2 or 3 years. Mainly in Java. Learned C# and have been using it for about a years time. I am a computer science student and finish my profession bachelor in January. I am not trying to use the expressions losely :/. And yes you learn by doing. But with everything you do you'd most likely want to make less mistakes and get more actual results, right? Yes, you learn from making mistakes. But making less mistakes in favour of better results is beneficial right? That's at least why I read up on how to program in the first place so that I could understand what I was doing and then I also had an easier time solving my problems.

Maybe this is the reason for your Design Paralisys. Some of my friends have the same problem coming from academia. They spend soo much time on design, wanting to build their first game. It will be perfect they say, telling me how these systems will fix all the problems. Guess what? When they actually start implementing them, they realise how worthless the designs are. What looks great on paper doesnt look so good when you start implementing it. On top, their systems are soo complicated, it actually makes things worse. Most of the time they cant even implement them hehe. So those friends start small/simple, increasing the complexity with each new game.

Dont worry so much about making mistakes, think about them as learning experiences. As I said End result is king here.

Like everybody is saying stop thinking and start doing hehe.

Edit: Read this: http://www.gamedev.net/page/resources/_/business/production-and-management/completion-vs-perfection-r3260

I am tryitng to show the importance of finishing projects.

Finishing projects makes a person better designer, not spending large time upfront on design with no project made beforehand.

Thats why I am trying to push you soo much to make a smal game like Josh did. Then to make another. With each new project, not only will the code become better, you will also start to realise why ECS, DDD, OOP...ect is used when developing games. How they help improve the code base and make it more re-usable code.

In a sense its like driving a car. Its possible to imagine what it will be like beforehand. However when you actually start driving, new problems occur. Things were not as they seemed they woud be. Imagination can only take you so far.

Hehe, you have a very interesting idea for simple.

With that analogy, I was trying to say that, imagination(theory) can only take you soo far. Practice is more important as it shows how stuff really is...Too much time spend on theory is not good (like in this case) as people generally learn by doing. Sorry, I am really bad at explaining things .

The other things you said about how to do the small projects and advance, I can get behind that. Just how to do it bothers me.

When you have developed something, don't you get a feeling like: I could have done X differently. Maybe by using Y it would have been a better idea. If I do Z next time not W, things could work out better. Listen to your gut feelings and try new ideas for your next project/s. Experiment.

Unfortunately there will not be always somebody to help along this all the time.

GameDev.net practicies a bit of tough love. Hehe. I am sure we are all just trying to help

I am quite positive that if you try to make the engine now. For one it will take you very very long time. As you said, you are not sure yet how systems will fit together. It will be such a massive project. There will be a lot of new things to learn. Learning new things generally takes alot more time. It may be soo hard, that I am quite sure that you would give up. There will be massive revisions as well. As you learn more concepts and implement more stuff, the want to revisit and improve old parts will be quite high too...

If you actually finish the engine and try to use it, you would probably realise that its over engineered and not useful at all.

(I actually wished you realised this yourself, rather than spelling it out so plainly:)

Now imagine that you spend the same amount of time by making games. The goal is still the same: 2D tile generic engine.

You just made you first game. Took you a day or two. Yes, its not the prettiest code. However you made it. Now you have some idea how to handle game state, collision, rendering, input. How they all connect together to make a complete experience.

case MainMenu:
  PlayButton.Update()
  PlayButton.Draw()
  ExitButton.Update()
  ExitButton.Draw()
break;
case GamePlay:
 Player.Update()
 Enemy.Update()
 CheckCollisions(Player, Enemy) 
 Player.Draw()
 Enemy.Draw()

Yes, the above is stupid simple, However every game has a gameloop, render, input, physics, ai.

Now you are starting your second game. You realise that the above code is not very reusable. What if you wanted to have more enemies? We have an actual problem to solve. You may search online/ask teatchers and get some advices. Then you actually try them out. See what works for the game you are making. There is no right/wrong here. If it works great.

Maybe by your third game your entity hierarchy is a monster like this:

Basic
 - Rendable
 - Movable
 - Collidable
 - Flying
 - Boss
 - MegaBoss
 - SuperDupperMegaBoss 

On your next project, you realise that the cool MegaBoss cant really be adapted to your new project. As the game was developed, you realised that maybe the entities or the code will not be very reusable next time. Hell it was a bit hard to work on it as it was, such a large hierarchy. You have heard of ECS which can actually fix this problem.

This in turn helps you appreciate what ECS is about. So you make a smaller game/project or convert an existing one to use components. Small = less things to worry about

Now the next project uses the ECS developed beforehand.

Given the experience of using your own system, you realise that some parts can be improved. So you go and do that before starting next project.

Maybe next time, scripting will be added.

On the next game, even more parts are stored in file. eg the game name, window measurements,

Because each new concept is tackled seperately, rather than simultaniously, it would be much more fun(motivating) to program and much less frustrating.

Not only will you have finished products to show (which will feel great and motivtional). With each game your base framework will improve more and more until its the 2D generic tile engine you wish to make.

I really hope this actually explains it finally.