Creating own 2D game engine from scratch - howto

Started by
11 comments, last by Satharis 8 years, 4 months ago

I'm new to creating games - I've been into PHP/JS/HTML stuff for about 8 years, but I'd like to create a simple game engine in C++.

Basically - if it's about programming, I know Delphi, Object Pascal and (as above) PHP, but never created games in OpenGL or DX. What should I know? Where to look for tips?

Description of things I'd like to apply in my engine:

- simple sprites/animations (mainly just animated sprites and sprite movement in line (horizontal/vertical)

- mouse click responsiveness for sprites

- basic UI (buttons, labels, checkboxes, buttons with graphic labels)

What kind of games should I be able to create with that engine? I don't know how to name that kind of games, but they are about setting diamonds of different colors in lines and getting points through that.

Can someone tell me how to do that kind of stuff?

Advertisement
If you really want to make a 2d game engine from scratch you should check out handmadehero.org. Sorry can't link on mobile.

If you really want to make a 2d game engine from scratch you should check out handmadehero.org. Sorry can't link on mobile.

I'm new to creating games - I've been into PHP/JS/HTML stuff for about 8 years, but I'd like to create a simple game engine in C++.

Basically - if it's about programming, I know Delphi, Object Pascal and (as above) PHP, but never created games in OpenGL or DX. What should I know? Where to look for tips?

Description of things I'd like to apply in my engine:

- simple sprites/animations (mainly just animated sprites and sprite movement in line (horizontal/vertical)

- mouse click responsiveness for sprites

- basic UI (buttons, labels, checkboxes, buttons with graphic labels)

What kind of games should I be able to create with that engine? I don't know how to name that kind of games, but they are about setting diamonds of different colors in lines and getting points through that.

Can someone tell me how to do that kind of stuff?

Honestly there aren't many reasons to create a 2D engine. You can just use one of the many available on the internet. Even Unity is good for 2D.

What will you make?


Honestly there aren't many reasons to create a 2D engine.

I have to agree for the most part with this, but on the other hand, some reasons do exist, including (but probably not limited to!):

- As a learning experience -- either for the entire "make an engine" part, or for sub-parts where an engine would prevent you from doing so (e.g. if you want to learn graphics programming and OpenGL, Unity wouldn't be a good fit -- although other, smaller, frameworks might be suited in this case).

- Because what you're wanting to make is so highly specific that a huge engine wouldn't give you a lot of benefit, or in some cases even be a detriment.

- As a way to gain knowledge on how game engines are made (compared to on how games are made using engines).

- Because you find it interesting and/or fun.

Hello to all my stalkers.

I don't know how to name that kind of games, but they are about setting diamonds of different colors in lines and getting points through that.


This usually known as match four, match three etc.

Most simple mobile games seem to be match four games these days.

Thanks for the replies. I don't want to use any pre-made engine - one of the reasons was mentioned by Lactose! - I'd like to learn some C++ stuff by creating my own engine.

Do you have any more resources than only handmadehero?

The first thing you need is to get an understanding of what your engine should provide to its users, ie game programmers.

Your list is a nice starting point, but you need to flesh it out to the point of a concrete API that a programmer can use.

Second step is dual. At one side you need to realize the API, at the other side, you need to test your designed API for usability.

While theoretically, you could design the whole API first, and then implement it entirely, and then test it, it's probably much more useful if you take an incremental approach.

Take a part of the API that you want to realize; make an API, implement the API on top of a library, like SDL or SFML. Then invent a program (game) that mostly only needs the selected part, and build it on top of your API. Repeat, until a) all parts of the engine have been realized and b) you're happy with the result.

Are you wanting to write a game, or write the engine?

Do you plan to use your engine to make a game after its done?

If so my advice to you is to write games, not engines...


Honestly there aren't many reasons to create a 2D engine.

I have to agree for the most part with this, but on the other hand, some reasons do exist, including (but probably not limited to!):

- As a learning experience -- either for the entire "make an engine" part, or for sub-parts where an engine would prevent you from doing so (e.g. if you want to learn graphics programming and OpenGL, Unity wouldn't be a good fit -- although other, smaller, frameworks might be suited in this case).

- Because what you're wanting to make is so highly specific that a huge engine wouldn't give you a lot of benefit, or in some cases even be a detriment.

- As a way to gain knowledge on how game engines are made (compared to on how games are made using engines).

- Because you find it interesting and/or fun.

You could argue that points 1, 3 and 4 are all the same and that point two is an example of Not-Made-Here Syndrome.

Not that I disagree with you in the least, I just think your list could have been:

  • because you would find it fun or informative


You could argue that points 1, 3 and 4 are all the same and that point two is an example of Not-Made-Here Syndrome.

I agree that 1 and 3 have a lot of overlap.

I don't agree that 4 necessarily has a lot of overlap with the others -- I can find something fun/interesting without wanting to use it as a learning tool (although learning would happen as a by-product).

For 2 I definitely disagree. There are certainly cases where e.g. Unity is not the best option. Examples here would include games where other engines/frameworks are better suited (RPGMaker springs to mind), or cases which are outside the normal use case of Unity's target demographic -- high-end titles, benchmarking applications, etc.

That isn't to say that 2 doesn't lend itself to the kind of thinking you mentioned, I just don't think it disqualifies it from being valid in some cases.

It should be noted that for indies and smaller companies, point 2 might not be hugely relevant.

Hello to all my stalkers.

This topic is closed to new replies.

Advertisement