next »

[Zack Bell]

Please remove this if has already been posted (I'm sure there was something similar on here  at some point).

I've only been programming for two or so years, but I absolutely love it. I would like to be pointed in the right direction when it comes to writing a game engine in C++.

(please no "make games, not engines"  )

This is more of a learning experience than anything else. My current game is being made in Game Maker, and will be finished in GM.

Hope somebody can help! I know that it is a huge task and that it takes a long time and a lot of knowledge, so the more info, the better!

 

EDIT: Holy shit, I guess this should have gone in the "request a tutorial" thread... It's such a large topic though, so I figure that this is ok.

[Serapth]

Not really sure exactly what you are asking?  The number one thing to do would be to download source code of existing engines and learn from them.  There are books on the subject, but they are all pretty dated now.  Also, use them.  Load up CryEngine, Unity and UDK and see how they tick.  Otherwise check out the code for Ogre, Irrlicht or Crystal Space and... get to it.


If you wan't a tutorial on creating a game engine in C++, that isn't going to be possible I imagine, as such a thing would be simply massive.

[Zack Bell]

Yeah, that's exactly what I was looking for. I assume that when you're smart enough to make one, you don't have to ask?  

[Liosan]

Write some basic 3D rendering (in either OpenGL or DirectX), a more-or-less-functional resource loader, some input handling and try to hack together some sort of mini-FPS. Then you can see what you did wrong You can also try adding per-pixel lighting to get a grip on shader programming.

Liosan

[Zack Bell]

I just got a book on OpenGL, actually. And have been looking at tutorials as well.

[Mikademus]

First, read (or at least leaf through)

• Gamma et al's Design Patterns
• Alexandrescu's Modern C++ Design
• the new additions to the C++11 standard

Then, do NOT take what you just read to extremes. There is this syndrome called "pattern happy", which is applying design principles too extremely and pervasively, and it is just as bad as ignoring patterns and existing solutions altogether.

Then, think about what the foci of your engine are (FPS, platformer games, RTS etc).

And then, look up existing engines and be inspired by what they do right and avoid their mistakes as you see them. (F.i. OGRE has a very over-engineered architecture, still you can learn about object composition in a 3D rendering engine from it).


Theory sidebar:
Remember, the word "engine" is very problematic and overloaded. Basically it means something that transforms input into output, and in a game programming context it means an system that restrict your freedom for creating something more organised to a purpose: ioquake is an engine that renderes FPS levels by the BSP algorithm. And game engines have engines in engines: input engines and network communication engines and rendering engines all are orchestrated together to create the game engine that has the utmost limited purpose: to make Sonic the Hedgehog, Wasteland, Kings Quest, or The Magic Carpet.

[dlan]

If you search for a recent book about game engine making, consider reading Game Engine Architecture by Jason Gregory.

Rather than an in depth view of a specific component, it offer a general view about every aspect of a game engine, with example from Ogre3D and Uncharted. The only topic it didn't cover much is audio and networking.

It also give some interesting informations about Memory management, profiling, 3D Math, etc.

Part of the book are freely viewable on amazon website, to give you an idea.

[kamac]

If you write such an engine, i can go as your tester 

[increpare]

Yeah, that's exactly what I was looking for. I assume that when you're smart enough to make one, you don't have to ask?  

A young man wrote to Mozart and said, "Herr Mozart, I am thinking of
writing symphonies. Can you give me any suggestions as to how to get
started?"
  Mozart responded, "A symphony is a very complex musical form, perhaps
you should begin with some simple lieder and work your way up to a symphony."
  "But Herr Mozart, you were writing symphonies when you were 8 years old."
  "But I never asked anybody how."

When Adam did flixel, he learned a lot of stuff as he went along, I think.  So long as you keep some use-cases in mind for the engine, you likely won't make too many horrible mistakes.  I think to a large extent the same was true of Chevy and flashpunk.  

[Zack Bell]

As I've been reading responses, I've come to realize that I really am more interested in making a game, not an engine. It's just that the word "engine" comes to mind when I think of programming without using a pre-made engine.

So I guess my question is more along the lines of how to write a game from scratch, in C++?

A 2D platformer, for example.

[harkme]

Because you want to write a 2D platformer in C++, I highly suggest you use SFML: http://www.sfml-dev.org/index.php

You won't be writing from scratch because it provides you with everything you need to start rendering images, playing sounds, getting input, etc., but you'll still need to handle how your game makes use of all those elements. As a bonus, SFML is cross-platform and so provided you do not use any additional platform specific APIs, your game should work on Windows, Mac, and Linux.

[Zack Bell]

Thank you! I'll have some spare time,  so I'll check out SFML soon.

[Mikademus]

I've only been programming for two or so years, but I absolutely love it. I would like to be pointed in the right direction when it comes to writing a game engine in C++.

(please no "make games, not engines"  )

As I've been reading responses, I've come to realize that I really am more interested in making a game, not an engine.

This deserves a big facepalm:

That said, have fun coding!

[Zack Bell]

Haha^

I guess I just think of an engine as a starting point. Not really an engine that I can hand out to help other people with their games. When I think engine, I think about programming audio, grapics, and input handling.

My bad 

[MattG]

1. Renderer
2. Controller/Keyboard Input Map
3. collison/physics
4. event trigger map
5. packer/player

[SpooderW]

LazyFoo's SDL Tutorials and The NeHe OpenGL tutorials

SDL for window management, image/font loading, player input, threading, an basic audio. OpenGL for rendering!

Assimp is a good model loader (albeit with weak documentation) if you don't want to write one.