The same here. I have been reading for an hour now.

I have some ideas for some games, but they are too advanced for me to create at this point.

Still, I want to create the engine myself, for the knowledge.

Where can I possibly learn this?

I have also heard that to make games with C++ you need DirectX or OpenGL.

What are these, and why do you need them with C++, and not Java?

Also, thank you for the links! I will read them!

Actually, depending on what kind of game you are making, you won't necessarily need either Direct X or Open GL. Have a look at NetHack, for instance. That is a full game where all you need is the console. Also, if you are making a Othello, Chess, Mine Sweeper kind of game, you can just use a normal canvas type of GUI object for your operating system.

Of course, Direct X and Open GL are graphics libraries that are closer to the hardware itself, and are much faster than any canvas any GUI component can give you, at least it were so in the past. It is also specialised in processing graphical data, wether it is 3D or 2D, so it beats anything you would do in pure software. Nowadays you can even offload computations formerly done on the CPU to the processor on the graphics card. It is also much more complex (but not necessarily so much more complex than to write graphics application in pure software, which is slow), so it really depends on which aspect of game creation you are looking into at the moment. You don't explicitly need C or C++ to use Open GL, I believe you can nicely make Open GL applications in Java. Here is one project aimed to enable that, that I know nothing about: http://jogamp.org/jogl/www/

If you start small, you will slowly master the art of making games. It is much more fun to make a Mine Sweeper clone than you think. There are some hidden things that are not apparent right from the start, for instance, what if you click a large area that has no surrounding mines? There you would stumble across making a recursive search to find all the adjacent safe slots on the map. Recursion is not really hard once you have learnt it, but it may be hard entry point, just like the concept of pointers, for instance (which Java doesn't have, just references).

Good luck! You are into a lot of fun learning. :)

Still, if I am going to make a pong game, I need in one way or another to load sprites etc.

Wouldn't that be a very primitive engine if the code does all the basic stuff?

When it comes to engines like Unity, I have no idea how they are made.

(Could anybody explain how?)

Either way, I guess I will start out simple with some Tic Tac Toe, Tetris and Pong.

'Engines' are siren songs to new programmers lured by the idea, but they just lead to you crashing on rocks.

Games don't require 'engines'. What even is an 'engine'? Some mythical concept you once heard somewhere that sounds appealing and impressive?

Games are made out of code.

After making several games, you start to realize that that you are re-writing a few of the same portions of code (how to load an image, how to open a window, how to play a song, and so on).

You then realize that these pieces of code that you've rewritten several times could be written in a way that they can be reused by multiple games, instead of being recreated over and over. So you start collecting these reusable pieces together in a 'library'.

As that library grows, and you reorganize it multiple times, you start to realize that some of the reusable components actually describe common game logic at a higher level. Things like movement and collision and cameras and scripting and AI. You also start to realize that some common architectures (higher-level code structures) are taking shape.

So this game logic and architecture is organized to form an 'engine' that is specific to certain types of games.

• Games don't require engines (especially smaller games). Games are made out of code.
• When you start to build up your own library of reusable code functions and classes, they help speed up development (allowing you to use the extra time to make bigger games).
• When the code library starts to gain game logic and higher-level architecture, then it should be reorganized into an 'engine'.
• An 'engine' is a fancy term to mean pre-boxed game architecture and logic.
• Different games require different architecture and logic, so it is possible that for some game projects choosing the wrong engine will leave you fighting against the engine to make the game.
• Some pre-boxed architectures are more generic (like Unity or GameMaker), and some pre-boxed architectures are more genre-specific (like RPG Maker).
• You don't set out to build an engine, you set out to build a game. After several games, you can refactor out common components.
• Engines aren't built from scratch apart from games, unless you've already built so many games (and by extension, game-specific engines) that you're really experienced at it. Otherwise, people tend to have the habit to put in all the things they think they need, or write architecture the way they think it should go, without the experience (from dozens of completed game projects) of knowing what they actually need or what actually works.

Some people build engines for fun, instead of building games for fun. That's fine! If that's what you enjoy (the architecture side of things), go for it!

But if you think you need to build an engine to make your game, you probably aren't seeing the forest because all the trees are in the way.

If you want to learn how to make good engines, then write (and finish) lots of games and then observe what features and architectural structures you find are common between their codebases.

Thank you!

I guess I will wait with creating an engine then.

However, I was thinking:

I have started on a Tetris clone.

However, I have the problem of collision detection.

I have made the graphics for the blocks myself.

The blocks shaped like this:

XXXX XX

XX

Is fine with collision detection. However, with these:

X XX

XXX XX

Where you have these transparent spots, gets a little more nasty for me.

Is the best way to do collision detection here to check first if there is a sprite-sprite collision, then check if the part

the sprite is colliding is transparent?

Thank you!
I guess I will wait with creating an engine then.

However, I was thinking:
I have started on a Tetris clone.
However, I have the problem of collision detection.

I have made the graphics for the blocks myself.
The blocks shaped like this:

XXXX XX
XX

Is fine with collision detection. However, with these:

X XX
XXX XX

Where you have these transparent spots, gets a little more nasty for me.
Is the best way to do collision detection here to check first if there is a sprite-sprite collision, then check if the part
the sprite is colliding is transparent?

Clever.

Thank you!

Even if you want to write your own engine, learning how to use an existing one would be a good start, then you'll know what sort of features to put in yours.