14
\$\begingroup\$

I want to start writing my game engine from scratch for learning purpose, what is the prerequisites and how to do that, what programming languages and things you recommend me? Also if you have good articles and books on that it will be great. Thanks in advance!

My Programming languages and tools are:

  • C/C++ is it good to use only C?
  • Python
  • OpenGL
  • Git
  • GDB

What I want to learn from it:

  • Core Game Engine
  • Rendering / Graphics
  • Game Play/Rules
  • Input (keyboard/mouse/controllers, etc)

In Rendering/Graphics:

  • 3D
  • Shading
  • Lighting
  • Texturing
\$\endgroup\$
7
  • \$\begingroup\$ Two points: this question, as it is, is too broad. What features do you want, what platform(s) do you want to support, what paradigms do you want to explore, how much responsibility you want to put in a scripting language (if any), and a whole host of other things I'm not going to bother continue listing out. \$\endgroup\$
    – Tetrad
    Apr 30, 2011 at 20:50
  • 8
    \$\begingroup\$ Two: There's a common prevailing wisdom that other people will spout that you shouldn't focus on making an engine without a game. An engine without a game means you can't prove your engine is useful. Good engines require people to eat their own dog food, as it were. A commonly-linked-to blog going into more of this argument is here: scientificninja.com/blog/write-games-not-engines \$\endgroup\$
    – Tetrad
    Apr 30, 2011 at 20:52
  • 2
    \$\begingroup\$ ^ Not only that, but writing an engine without a game to motivate feature requirements results in feature creep and bad API design. Until you know what you need, hinted at by game requirements, you may not put useful things into your engine. By the same token, if you haven't had to use the engine to program with, you might find some of your decisions to be really clunky. \$\endgroup\$
    – ChrisE
    Apr 30, 2011 at 21:12
  • 1
    \$\begingroup\$ I don't see the point in your listings. The fact you know C/C++ and Python help us, but why list that you can use version control and a debugger? \$\endgroup\$
    – PrettyPrincessKitty FS
    May 3, 2011 at 16:42
  • 2
    \$\begingroup\$ @TheCommunistDuck: Hey, that's better than some developers. :) \$\endgroup\$
    – ChrisE
    May 3, 2011 at 20:11

3 Answers 3

Reset to default
10
\$\begingroup\$

You can write a game engine in practically any language using practically any methods of rendering. You could write a game engine in bash using console output for example.

So, I think it would be best to define what exactly you want to learn in writing your own engine. There are a lot of "fields" in game development.

  • Core Game Engine

  • Rendering / Graphics

  • AI

  • Networking

  • Game Play/Rules

  • Sound

  • Input (keyboard/mouse/controllers, etc)

etc.. From there you can even have sub topics. In Rendering/Graphics

  • 2d or 3d ?

  • Modeling

  • Shading

  • Lighting

  • Texturing

  • GUIs/Huds/Interfaces.

  • etc, etc

Just one of those sub-sub-topics could eat up many hours (or years!) of study!

So, first define what you want to learn. Start simple.

Use whatever language you are comfortable with - though some are better suited for certain tasks. For example, the core engine and rendering is probably best done with a "lower" level language like C/C++ (if you need performance that is); but something like AI or Game Rules might be better done in a higher level language. Nothing says you can't mix and match. You could write your engine in C++, your rendering in C (since it works well with OpenGL) and then use LUA for scripting your Game Rules, etc.

As far as example, there is a game engine called Slick2D. It's written in Java and is open source. It's an example of a simple 2d engine written and designed really well. You can learn basic concepts from that, like game loops, managing game states, etc.

If your comfortable with C/C++; I would suggest taking a look at SDL/OpenGL. It handles some of the housekeeping like input, sound, creating windows, etc and can focus on other stuff.

\$\endgroup\$
2
  • 4
    \$\begingroup\$ Ahh the days when I was learning C++ and console games were awesome fun... [creates new console project...] \$\endgroup\$
    – Nick Bedford
    May 4, 2011 at 22:59
  • \$\begingroup\$ I updated my question, hope to give me a lot of awesome resources :) \$\endgroup\$
    – Wazery
    May 6, 2011 at 17:54
4
\$\begingroup\$

SDL + OpenGL is an excellent choice to start up a custom game engine.

I personally use a C-ish version of C++ because I found out that works the best for me. By that I mean I don't use any exceptions. There are two reasons for that: first and foremost exceptions require exception safe code all the way down which with OpenGL and SDL is not exactly easy to achieve. More importantly however this way it's very easy to expose C++ objects over the C ABI which is incredible helpful if you try to bring a scripting language into the mix.

I'm in a similar boat than you are and I wrote down some of my adventures with SDL and OpenGL in a blog (immersedcode.org) in case someone else is interested.

For the general architecture I have two suggestions: if you want a 3D engine check out the book "Game Engine Architecture" by Jason Lander. If all you want is 2D, keep the design as simple as possible and let yourself inspire by XNA or other projects.

Lastly: do not call OpenGL all over the place. Do yourself a favor and isolate it into a couple of places so that you have the ability to switch between desktop OpenGL/OpenGL ES or even DirectX at a later point if you want to.

\$\endgroup\$
0
\$\begingroup\$

Don't use C unless an implementation detail holds you to it at gunpoint. Otherwise, use C++, because it's flat out a vastly more capable language, and you can always choose not to use those capabilities later. I personally have nothing for/against Python, I've never used it.

I wouldn't recommend OpenGL against DirectX because DX has a modern object-orientated approach, which is far cleaner and more understandable/less error prone. The interface offered by OpenGL is extremely poor in comparison.

The last thing I've got is that I've heard from many people I trust that GDB utterly, utterly sucks and the Visual Studio debugger is by far and away the best. This is not my personal experience so take it with a little salt.

\$\endgroup\$
11
  • 4
    \$\begingroup\$ "OpenGL vs. DX". The fact that DirectX is more OO isn't really important. As far as being more understandable... OpenGL (prior to 3) exposes a fairly straightforward interface, and one which is easy to scan as it is all in a C-style imperative methodology. "Set the projection matrix to this. Start triangles. Here is a vert. Here is a vert. Here is a vert. End triangles." The 1.x series of OpenGL APIs is good for getting your feet wet in graphics programming, and combined with SDL (or even GLUT... urg) lets you get an app up in like 30-50 lines of code. \$\endgroup\$
    – ChrisE
    Apr 30, 2011 at 21:23
  • 2
    \$\begingroup\$ @ChrisE: Sure thing. There's something called extern "C", and it's appropriate use makes writing a C interface rather trivial- especially for Python, where a converter exists within Boost that makes binding to it easy. How about C++ language features? They're great. More use of C++'s language features increases the reliability of a project and ease of coding massively for a more than acceptable very minor performance trade-off. C's language features are pathetic in comparison. For example, correct use of a modern C++ compiler can guarantee no memory leaks. Do that in C. \$\endgroup\$
    – DeadMG
    Apr 30, 2011 at 22:01
  • 1
    \$\begingroup\$ @DeadMG: If OOP was really a big deal, also, the answer here is Java or C#, and not C++. The thing I disagree with is that the use of C++ features doesn't magically make your code better, faster, or even more reliable; you have to know how to use those features, and is learning a language in addition to architecting an engine really a good use of one's time? No. Not for somebody doing this for the first time. You can learn all of C in a day or two, comfortably, and never wonder what the language is doing. OpenGL, the useful basic call set at any rate, offers the same transparency. \$\endgroup\$
    – ChrisE
    May 1, 2011 at 1:26
  • 2
    \$\begingroup\$ OOP is not that big of a deal, not in high performance game engines. Sure it is useful, but it is often the wrong abstraction. Having good data flow, locality and memory layout of is usually better. While a lot of teams are using C++, they don't use most of C++ features. No exceptions, as few virtuals as possible, no RTTI, no STL/Boost. Why? Predicable and fast execution and small code on multiple platforms. I code in C and there are only two areas in which I would rather use C++: scoped locks and generic arrays. Not worth the hassle IMHO. \$\endgroup\$
    – void
    May 3, 2011 at 6:30
  • 4
    \$\begingroup\$ On GL vs. D3D: There is no matrix stack in GL3/4 core, and no attrib stack. Both GL and D3D maps to the same hardware architecture, but a lot of time GL feels thinner. Sure the GL state machine is a bit of a hassle, but so is actual hardware ;) Learning any of them is fine, and as long as you understand what is actually happening you can easily switch to the other (or a console API). \$\endgroup\$
    – void
    May 3, 2011 at 6:35

Not the answer you're looking for? Browse other questions tagged .