Creating a Game Engine

[ichigo_cool]

I'm just curious, what are the most important c++ concepts you need to know (as specific as you can be) to create one, and where does one begin?

[jwenting]

wrong assumption.
You need to know a lot about software design and engineering, mathematics, physics, etc. to create an engine.
Just starting to code at random will get you nowhere.

Once you have a proper design document, you can use that to figure out what programming tools/languages/libraries are appropriate to implement it.

[ichigo_cool]

Wrong Assumption? What assumption did I make in asking a question.. At any rate, I'm not randomly coding things. I've been learning and practicing for a while and messing around with c++. I'm wondering what, in c++, is most important to game engine coding.. As in what topics/subjects should I spend more time in...

[Sodabread]

OpenGL or DX development, 3D math, heavy OOP, memory management, scene management for a start.

[venomxxl]

In general:
C++ concepts: object oriented programming (OOP)
Other: OpenGL/DirectX, math, good programming skills (and habits)

What you need to know depends on what you want your engine to do. Is it going to be a 2D or a 3D engine? Do you want physics? Do you want to use audio libraries? How much abstraction will it provide? etc.

The fact that you want to write an engine in C++ doesn't mean you have to do heavy OOP. Get a pencil and a piece of paper. Write down what you want the engine to incorporate (3D rendering and physics aren't a wise choice for a beginner, you will find numerous obstacles). Then think about how you would want to use your engine. (some engines are made for only one type of games, like Quake engine) Write some pseudo code. Then try to design your engine around that. You could also get some ideas from analyzing existing engines (try sample code). You might want to learn about software designing (UML is sufficient).

A game engine is a rather long-term project and it tests your programming skills. Don't overestimate your skills and start with something simple.

[ichigo_cool]

Thanks for that lengthy reply venomxxl, the kind of game engine I'd like to create is mainly something along the lines of an engine to create pokemon game style maps and sprites. Something to that calibur would be sufficient for me. A great start would be something like a map editor that can save maps and the engine can load the maps and have a character move around in them. I just have absolutely no clue whatsoever on how to go about this.

[Sodabread]

What you're looking to do is called a tile engine. Research that a bit to get educated on the basics of how to start building one and go from there. Once you get the basic map structured and working, start working with a camera to move around your map, then expand step by step, adding characters, collision, objects, etc...

In addition to knowing that, you'll need to get familiar with one of the aforementioned graphics libs (DX/OGL) or GDI+ if you want the absolute basics.

[TheRealOrder]

A Tile Engine, well that is a great way to start. 2D graphics rather than 3D will greatly lower your learnign curve too. I would suggest Direct2D, DirectWrite and the Windows Imaging Component (WIC) as the three Library APIs to use that are designed to work together with the first Two being new APIs introduced last year; although there are many others very good APIs. When you build your game and all your hard work for doing a 2D engine could be used as the user interface of a Direct3D application in the future. Good luck, and do not go overboard on the OOP, everything does not have to have a wrapper in separate classes, especially when your learning and may not know the benefit of the extra work.

[ichigo_cool]

Isn't Direct2D and DirectWrite nonexistant anymore, or deprecated? Also, what exactly is a wrapped? I've looked it up multiple times but never seem to understand.

[TheRealOrder]

Your thinking of DirectX. There are now three, DXGI, Direct2D and Direct3D that are hardware accelerated. DXGI is just the device and swapchain removed from Direct3D that will let you go fullscreen with Direct2D without creating the Direct3D device. From msdn:

"Direct2D is a hardware-accelerated, immediate-mode 2-D graphics API that provides high performance and high-quality rendering for 2-D geometry, bitmaps, and text. The Direct2D API is designed to interoperate with existing code that uses GDI, GDI+, or Direct3D."

GDI+ is now legacy code in Windows 7. DirectWrite was introduced for Windows 7 also and is interoperable with Direct3D, Direct2D, and GDI+. It handles text and fonts. I mentioned the WIC, as Direct2D has functions to use its converters to load a bitmap from file into a Direct2D bitmap object.

Wrapping means taking the data and functions that operate on it and making a class out of it. OOP is having everything in a class so straight OOP designs requires you to WRAP up all your data into different classes. I think, as a beginner, you should keep it simple, some functions and global variables and some classes. A good book and some practice you will start to see the power in OOP and will make more classes.

[KazenoZ]

Well, I'm not even sure that we're following the same lead here, are you looking to PROGRAM maps and sprites in the _style_ of Pokemon, or are you looking to just deal with the graphical aspect?

Since for the former, your demands of the engine aren't quite enough, and for the latter, well, why program?

In more detail:
If your aim is to actually program a game, bringing Pokemon as an example, I would assume that you're after a 2D RPG style of a game. For that, just mapping and spriting won't really be enough, since then you'll just be standing on a map with sprites unable to do anything, you should have your engine contain basic functions that you want to use in the game.
Now the term game engine doesn't have to be as scary as it sounds, it doesn't necasserily mean that you need to be a pro-1337 dude that can totally get the hang of particle systems, mode7 and all other crap. You can just create a very simple engine that suits your own level and needs, and it doesn't need to be too complicated. Remember, an engine just means a set of reusable functions, they don't NEED to contain any physics or anything too complicated, and they can just focus on one aspect of your game, like the mapping assets in your example.

As per the original questions in the OP;
- I do not believe that there are any concepts that you need to know, other than using objects in your program, where applicable, and knowing the language and library that you are working with, just take any piece of code you've been using so far, and make them reusable, by generalizing them.
- There is not really a constant rule to where you should start, so, I would say, just start whereever you want, not just programming random stuff, like was said above, but do take a little time designing a UML of the engine, including all the functions and options you want it to contain, look it over, see the spot that you think the highest amount of other functions would need to rely on, that you think would be the easiest to do, that you want to finish first so it'll help you test the others. Any of these approaches could be practical, it just depends on your nature and preference.

And in case you did mean that you just want to make Pokemon maps... ignore the long-long post above, and just go on Google and search for Pokemon ROM hacking, there are communities devoted solely to editing the ROMs, making new maps, sprites, and even whole new games based on the various Pokemon engines in the various ROMs.

Good luck to you and all the best.