Hi all,

I understand that there are already quite a few threads out there, but it seems that most of them are about the pros and cons of certain stuff in the game engine, or either that it's just a bunch of theories here and there. Perhaps I didn't look hard enough or either that I'm just really noob to not catch certain stuff mentioned.

So getting to the main point, my questions are what does a game engine really need? How to structure the engine in a industry-standard structure? (I'm still a student, but I'm going to graduate soon...) And last but not least, how do we make a game using this engine in question?

It depends on the situation, some might say, so I shall narrow down the question here. Let's say we're making a 2D RPG game engine that uses C++ and OpenGL as its programming languages.

From I have understood so far, a game engine is a program where a programmer does his magic on to create the game, and contains functions that instantly creates basic game mechanics that is needed in a game.

Can anyone change or add on to the sentence, and perhaps answer my the three questions as stated?

With regards,

Donald Leow

( P.S. Sorry if I sound weird or arrogant, as some have told me. I tend to sound like this when I try to ask questions...I apologize for my inability to ask questions in a normal way. )

Well this isn't really a super beginner answer but you should read a bit about how CPU's operate and the basics of how an OS processes messages.

For example a single core CPU can only process one instruction at a time, even though there are millions of transistors, it's still one instruction after the next. An OS has to be built to work with this principle, see,

http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows

http://en.wikipedia.org/wiki/Event_loop

http://en.wikipedia.org/wiki/Message_passing

http://en.wikipedia.org/wiki/Message_queue

You don't have to really know much of how the OS works, but these topics can help you understand a basic principle that it's one instruction after the next and this is the root idea if a game engine also.

The engine also runs in a loop, like a while loop, do loop or for loop, and every other calculation runs inside this loop.

Within the loop you are continually monitoring the user input(mouse/keyboard) and when the input changes the engine has to update the game state accordingly. That means the view you see or the sounds you hear have to be recalculated, there are hundreds of thousands of calculations/messages being processes every second. If you monitor is running at 60Hz that means it update the screen 1/60sec so that is the time the CPU/GPU have to calculate every graphical and physics, sound calculation, thankfully electrons travel extremely fast also.

This should help you understand that a game engine is split into components and is all based around the concept, check user input --->do loads of calculations-->update the screen-->check user input-->do loads of calculations-->update the screen.

The 'do loads of calculations' involves calculating new vertex positions, pixel colours, physics calculations, sound calculations, collisions detection. Loads of calculations but they are all broken down into individual parts and processed one after the other.

If you are serious about creating a game engine, you would learn the 'components' of a game engine, and build a thorough design document of your engine, decide on the classes and features you need to use and then code it.

You will find that the CPU/GPU, the OS and the Drivers do a huge amount of work for you.

Think I used the word calculation a few too many times..lol

Unless you really want to spent a lifetime creating a efficient engine You should just pick one of the dozens of amazing engines out there. Creating an engine requires you to already be a expert game developer. And if you where an excellent game developer you would not have posted this question here. So take my advice and just pick an engine to create your 2d rpg.

The question is:

Do you want to make games?

or

Do you want to make a game engine?

Also, "Game Engine" is a fairly abstract term. Technically any code you have that runs a game is a game engine. It may not be very flexible but it's still the games' engine. Then you have very generic code that helps you make your game defined as a "Game Engine". Most people probably look at Unity3D and say it's a game engine. However it's purpose wasn't to run any specific "game" (not including demos which are there to show you have the engine works), but it's still considered a game engine by most. I would say a more true def of a game engine would be something like UDK, CryEngine, & Source. These are engines that were built for specific games. The reason they exist is because the company wanted to make a specific game. Engines like Unity don't exist because they wanted to make a game. They want to aid you in making games (which they do well).

So you can see there are 2 approaches. Make a game and refine it over time until it becomes generic enough to be considered a game engine. Or, make a generic game engine and then make a game with it. When just starting out I'd go with making a game first by using higher level libraries for gfx, sound, physics, etc as this will help you see what the issues are when making a game and you'll have to figure out how to solve them. Then you can refactor it so that it's more generic.

Unless you really want to spent a lifetime creating a efficient engine You should just pick one of the dozens of amazing engines out there. Creating an engine requires you to already be a expert game developer. And if you where an excellent game developer you would not have posted this question here. So take my advice and just pick an engine to create your 2d rpg.

If you want to become an expert some day, you must go this way and reinvent something every time.

Yes, but if you say things like "From I have understood so far, a game engine is a program where a programmer does his magic on to create the game, and contains functions that instantly creates basic game mechanics that is needed in a game." then you should probably learn more about general programming instead of creating your own engine first...

Well for a start if it's for 2D games, I wouldn't use OpenGL directly. I'd rather something like SDL2 which will take care of all the OpenGL stuff for you as well as giving you lots of great features like input checking.

The question is:

Do you want to make games?

or

Do you want to make a game engine?

^This.

You used the example of a 2D RPG. The stuff that most people would think of as being done by the 'game engine' (graphics, rendering, collision detection) is the LEAST part of a good RPG. You've got to write a plot with quests, sidequests, and dialogs. You need music - background sounds, background music, battle music, character themes. You need to create the characters, their backstory's, their character arcs. And you build the world, with all it's lore, history, npc's, and then create the maps for every town, building, and outhouse in that world. Before you can code the mechanics like the combat system or character classes you have to create all those concepts and work them out on paper so the game will be reasonably balanced: you'll tweak it as you go, but the basic concepts have to be sound.

You can spend all your time working on the engine, or you can spend your time working on all (or even some) of that other stuff.

Try to do everything and you'll end up accomplishing nothing.

Yup, I agree, you have to decide what it is about making an RPG that you want to concentrate on making, and what stuff you don't find interesting. If you want to make an RPG with a unique engine/look, or whatever, and don't really have this giant urge to put the story in your head into a game, then perhaps an engine is the way to go.

Also, as an aside, just because you don't decide to make your own engine on your first project, doesn't mean you can't make your own engine later. One can get a pretty good understanding of what it takes to make a good engine after having used one. Or you get annoyed enough by the limitations of the one you're using, and decide to make one that avoids the problems =)