Starting my own game engine - please don't laugh.

- What is the current popular gl library? glut? or should I limit myself to direct3D?

For creating a window, setting up an OpenGL context, texture loading, font rendering, event management, and audio, consider SFML.

It provides the basics, and though it wraps things up for use as a basic 2D API (i.e. sf::Sprite and such), you don't need to use those features.

Thanks servant, these looks well documented, gonnay give it a try now. :)

What is the current popular gl library? glut? or should I limit myself to direct3D?

OpenGL and DirectX are just APIs you use to do your rendering. Their current versions provide similar functionality so I would start with one of these build a simple render system on top of it and experiment with it. Later on when you feel comfortable with the one you can move to the other. Whichever you pick there are plenty of tutorials. Usually games in Windows use DirectX for their rendering.

If you're doing windows programming I would suggest to go with wgl instead of glut or some similar library. This way you create the window yourself and you use the windows gl related functions to create the context etc.

Also if you're playing around with OpenGL you might want to create a "modern" OpenGL context. This would require you to create a dummy context, check the system if it supports openGL 3+ and then create a context. This will allow you to use the modern capabilities of OpenGL.

http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/

http://www.swiftless.com/tutorials/opengl4/1-opengl-window.html

A good, updated book on general engine programming? (Not physics or math, but more of a windows api implementation and stuff).

My favorite book is "Jason Gregory's - Game Engine Architecture". This is a great book covering all the major game engine parts and will really help you understand how professional game engines are done.

However, I would start with "Mike McShaffry - Game Coding Complete" since it provides it's own simple game engine framework (if I remember right) and many code samples that will get you started. I would go the "Game engine architecture" later.

Btw, you'll also need a good book on 3D game maths... "Mathematics for 3D Game Programming and Computer Graphics - Eric Lengyel" is pretty good.

Have you guys tried doing this? What tips can you give me in technical terms?
- Is there a super basic game engine I can start with? I've tried cocos but it's too complex for what I want to achieve.

I first started writing a simple DX10 framwork for my uni projects. It was bad. Then I wrote a second framework again on DX10 which was slightly better and I've added some more game engine parts (input, maths library, scene manager, simple resource manager). Then I started learning OpenGL but without actually making a proper engine. Now I've started building a little engine again using my personal & professional experience I've found Gregory's book & Ogre3D rendering engine source code to be of great help.

I see a lot of

Write games, not engines.

around here usually. A line that is both completely right and completely wrong at the same time.

If you want to learn about the bare metal of a game engine, writing a game is certainly a decent way to do it. If you think about it, having to implement a game from bare metal yourself means you'll have to face and tackle each obstacle as you go, that both makes you research each part and gives you experience.

The other part that most people don't seem to mention is that making games takes -a long time-. If anything making even a half-assed game takes quite a lot of effort, you'll end up teetering into design and art and mechanics and audio more than just focusing on code. You'll end up dinking around with data and planning things and trying to make an actual game at the expense of a LOT of your free time. Often if you want to work on a side project you have to be rather choosy about what it is, since coding is such a long term effort.

Basically I'm just throwing out there a little advice: it's awesome you want to make your own engine, but remember to take small steps! Don't try and write some convuluted resource manager or something when your engine doesn't even have an identity. I would pick a simple goal to work on, something like.. "make a simple 3d shooter where you're in a room with a paintball gun and have to fire at pop up targets," something like that. The same applies to a 2d engine really.

I'd suggest developing the engine around a game, and not the other way around, so to help prevent bloated, over-engineered APIs. It will give you an obvious and immediate "roadmap" at any given time. Major engine milestones / dev cycles (versions?) can be considered in terms of what it means to the game. A completed game then signifies an important evolution in the development of the engine.

I suggest this also because I've found even if you write unit tests that mimic the game for the engine during the development cycle of a feature, you'll never be able to anticipate everything. Game states are a wonderfully complex beast. Sometimes the issues are simple things like mere API usage, other times obscure bugs that only happen when in the context of a particular hierarchy of parts working together. In other words: engine tests represent theory, whereas a game represents practice.

Allocate time. Lots of it. It becomes an enemy that you can only win through accepting that you only have so much of it. Use it wisely.

These are a few of the many lessons I've been learning as I've delved into game development non-professionally in the past ~2 years, anyhow. Above all else, remember to have fun and often take deep breaths! :-)

Great feedback everyone, no wonder why this is favorite forum :) .

Sorry for not to answer earlier, I decided to use visual studio 2012 for an IDE after like 1 year not using it and took me a while to properly recompile SFML to use it there, but so far it looks great.

My favorite book is "Jason Gregory's - Game Engine Architecture". This is a great book covering all the major game engine parts and will really help you understand how professional game engines are done.

However, I would start with "Mike McShaffry - Game Coding Complete" since it provides it's own simple game engine framework (if I remember right) and many code samples that will get you started. I would go the "Game engine architecture" later.

Btw, you'll also need a good book on 3D game maths... "Mathematics for 3D Game Programming and Computer Graphics - Eric Lengyel" is pretty good.

I'll check the Game coding one first then. Already read a bit of Lengyel's book when I entered college, although at that time even the depth buffer seemed alien to me, so I'll give it another try.

Basically I'm just throwing out there a little advice: it's awesome you want to make your own engine, but remember to take small steps! Don't try and write some convuluted resource manager or something when your engine doesn't even have an identity. I would pick a simple goal to work on, something like.. "make a simple 3d shooter where you're in a room with a paintball gun and have to fire at pop up targets," something like that. The same applies to a 2d engine really.

Thanks for the advice Satharis!, that's exactly my plan :) I want to focus mainly on graphics, starting with basic transformations and build up from that. The main learning focus I want to have are:

Phase 1:

Graphics(Render, Transformations)
Basic input detection (arrow keys)
Object Instantiation


Phase 2:
Shaders (This might look optional but I'm incredibly interested to learn these)
Basic Physics (Gravity)

Phase 3:
Collision Detection (Might consider putting this on phase 2, not sure yet)

I want to leave it at there for now to avoid getting overwhelmed, but other things I want to implement (That are way off the current scope, but would be nice to learn):

Network (Maybe just a chat n' stuff)
Scripting Implementation (Taking a compilers class on college, if it is good enough I might consider implementing this in 6 months)
Mobile Porting (I'm incredibly certain this is harder than all of the above together, but I might be wrong).

Fbx or Obj import. (Would be nice to import my maya models)
Basic IA and super basic procedural generation.
Oculus implementation.


The Game I have in mind to test this engine is sort of a mario 64 style platformer, nothing too fancy.

These are a few of the many lessons I've been learning as I've delved into game development non-professionally in the past ~2 years, anyhow. Above all else, remember to have fun and often take deep breaths! :-)

Fun is a big factor! I love to enter my "code obsessed" state, and the fact that I'm going to fight a shit ton of math looks incredibly rewarding (My 3d math classes were given by an incredibly boring professor and my 3d graphics professor had the marvelous idea of giving us WebGL instead of OpenGL, which might have been good if he had some idea of what he was doing.)

I'll keep you updated if I can on the design as a whole :) .

Sorry for not to answer earlier, I decided to use visual studio 2012 for an IDE

Just FYI, 2013 is free (in fact, more free than any previous version of VS) as has fairly significant updates and changes over 2012.

I've been developing a game engine for most of my professional career, so I can tell you about my experiences. First, let me mention that my book Mathematics for 3D Game Programming & Computer Graphics has a lot of useful engine development information in it. Don't let the first few chapters put you off. They are pretty dry and purely mathematical, but after that, the book gets into a lot of stuff that's specifically needed to make a decent game engine, like visibility determination, collision detection, basic physics, shading, curves, and fluid/cloth simulation. There is also the Game Engine Gems series, but they are collections of shorter chapters that discuss intermediate to advanced techniques. These books would probably be interesting after you've got an engine up and running and you're looking for some cool effect to implement, but there are a few chapters are would be generally useful to anyone (like a chapter in GEG2 about bit hacks for games).

Satharis made a couple comments above that I wholeheartedly agree with. Developing a game engine does take a long time, especially by yourself. I have been working on the C4 Engine for over 15 years now (although not continuously for the first five years), and there is still a lot of new stuff that can be added. It's important to start small and work your way up. Don't lose touch with reality and think that you're going to build a complete engine of high quality in a few months time, or even a few years. Choose very specific features to work on and implement them one at a time as best you can. After finishing some components of your engine, you should find yourself looking back and thinking to yourself that you now know a much better way of implementing the same thing. This ought to happen a lot in the first several years, and it's part of the learning process. Iteration is key to really discovering better ways of developing software and becoming a good engineer. Don't be afraid to completely throw away some system you spent a lot of time working on and start over. If you're not under any kind of time pressure, it will be worth it in the long run.

Way back in early 1999, the C4 Engine could barely render a handful of primitive geometry types (plane, cylinder, sphere, etc.), some particle systems, and some basic shading effects. After many years of hard work and meticulous refinement, it can do all of this today. It has been very rewarding, but also very difficult at times.

Btw, if you're going to write some kind of import component, I recommend using the Open Game Engine Exchange format (OpenGEX). The OBJ format doesn't support enough features (not even close), and FBX will have you tearing your hair out. OpenGEX supports Maya, and there's a free C++ import template that you can start with when building your own importer.

Just FYI, 2013 is free (in fact, more free than any previous version of VS) as has fairly significant updates and changes over 2012.

Ah, silly me, I honestly had no idea, at least setting up 2013 will be easier thing to do. Thanks :).

Way back in early 1999, the C4 Engine could barely render a handful of primitive geometry types (plane, cylinder, sphere, etc.), some particle systems, and some basic shading effects. After many years of hard work and meticulous refinement, it can do all of this today. It has been very rewarding, but also very difficult at times.

Btw, if you're going to write some kind of import component, I recommend using the Open Game Engine Exchange format (OpenGEX). The OBJ format doesn't support enough features (not even close), and FBX will have you tearing your hair out. OpenGEX supports Maya, and there's a free C++ import template that you can start with when building your own importer.

Well this is 1997 for me then, since I'm at 0's right now haha. Also I'm very thankful for the OpenGEX tip Lengyel, and as I said I read your book a while ago but will check it out again. I have a very deep sense of reality and don't really plan on doing something too complex that exceeds my current abilities. But I don't want to do something too simple either. Either way, main purpose is to learn the basics of gamedev pipeline and to improve my C++.

If you want to develop a custom renderer that can either use Direct3D or OpenGL, model it after Direct3D (Learn Direct3D first, then learn OpenGL later). It's much more strict than OpenGL, and it'll be trivial to convert the engine over to OpenGL.

You should also stick to OpenGL 3.3+ and Direct3D11 (There is literally no reason to learn Direct3D10 anymore). Learning anything that includes the fixed function pipeline is a huge waste of time, pretty much all your knowledge will be irrelevant by the time you make anything useful.

Wow, Eric Lengyel's advice was really inspirational for me! Thank you for sharing it. :-)

Don't be afraid to completely throw away some system you spent a lot of time working on and start over. If you're not under any kind of time pressure, it will be worth it in the long run.

I just wanted to try augmenting his advice here, saying just how important this cruel, but vital this can be for the success of the engine. No body enjoys throwing away code that they've poured blood and tears into, but you gotta do what you gotta do at the end of the day when the long haul is what matters. It reminds me of my difficult decision resulting in throwing away ~10k lines (in other words, ~3..4mo) of in-house GUI code in favor of an external library. Ultimately saved me a ton of time, I think -- ~3..4mo is nothing but a drop in the bucket in the long haul. After all, throwing away code is somewhat misleading, as you still retain all that you learned during the course of development.

However, I would start with "Mike McShaffry - Game Coding Complete" since it provides it's own simple game engine framework (if I remember right) and many code samples that will get you started. I would go the "Game engine architecture" later.

I second this, this is a great book ideal.for newbies and the experienced alike... I have the second edition and am well due an update.

I would suggest you check out Marek's site at Marek knows dot com. He has a great, huge video tutorials for an OpenGL game engine.

For books I would suggest also Coding Complete, along with 3D Game Engine Design and 3D Game Engine Architecture by David H. Eberly.

Eric's comments are really spot on - if you accept any of the advice in this thread, re-read his post! While not as extensive as C4, I have a similar feeling and background with Hieroglyph 3. It started out as a learning project, and has over time been upgraded, piece by piece, into what it is today. The only additional caveat that I would add is that instead of throwing away an entire component, be sure to take away whatever you can from it. Even if it is learning what not to do, there is always information available from a given implementation!

Good luck, and gamedev.net is your friend :)

Sorry for not to answer earlier, I decided to use visual studio 2012 for an IDE

Just FYI, 2013 is free (in fact, more free than any previous version of VS) as has fairly significant updates and changes over 2012.

That's true, assuming he isn't working for a company that is larger than the allowed size...

- Have you guys tried doing this? What tips can you give me in technical terms?

I myself have never programmed a game engine, much less the game I'm working on in Visual Studio. I can, however, point you to Blue Shogun. I believe he is currently making an engine, and he's even posted it on GitHub. You could ask him for the link and re-use his code if you want, or you could use it as a reference. Perhaps if you ask nicely, Blue will help you?

Hey guys! I deeply apology for not answering but I got on vacation and it's quite hard to answer on the phone, I'll keep working on my engine. And I'll probably change to vs 2013 or other ide. One of the reasons I might think it twice is because older version usually have more complete documentation.

Personally, I think there is more benefit to writing a software renderer from scratch than trying to make an engine. I'm of the "make games, not engines" camp. If you just make a game, then make another, and another, you'll find stuff you keep repeating. You put that stuff in a library and make it easy to use. Engine. It is just as easy to learn someone else's engine when you understand what is going on under the hood.

If you want to do everything yourself like "Hand Made Hero" you'll spend a lot of time fighting with the OS and their way of doing stuff, or fighting with OpenGL, DirectX, OpenAL, XInput, etc.

If you want to understand libraries, spend some time doing it yourself to understand the reason for the library. Try writing a sound API or writing Box2D from scratch. Learn the math. Discover the limitations.

As far as books, I recommend:

Game Engine Architecture, Second Edition

by Jason Gregory

Link: http://amzn.com/1466560010

The Black Art of Multiplatform Game Programming

by Jazon Yamamoto

Link: http://amzn.com/1305110382

*edit*

I have benefited from writing a software renderer from scratch that did shaded, textured polygons. In my programming life, I have never learned more or done anything more productive. I learned:

* software rendering from scratch

* debugging rendering code by hand

* speeding it up rendering code

* trying out different algorithms

* implementing algorithms from papers only to find they didn't work

hi,

for developing a game engine, you need a memory manager, witch i recommend automatic pointers,

for sound, i recommend OpenAl,

actually SFML and SDL have all of these, and boath have the mouse and keyboard inputs

if you want to implement 3D graphics in your engine, ogre3d is the best, irrlicht in my idea is good two

for scripting, lua is the best scripting language, witch you can implement it in to your engine

if you want to create a compiler for your engine, (please note i'm saying game engine, not game framework), you can use LLVM, and create your compiler, but you have to read about compilers and how they're created