Some Thoughts and Questions on Engine Design
You say C++ and OpenGL, as well as something that could "possibly" go to 3d.
A few years back I bought the Torque Game Engine, and I think for the money it was one of the wisest investments of my life. The developers of this engine are former industry professionals, as well as the engine had seen life in a successful game (Tribes). I learned a great deal about the flow of data, etc from this experience.
What you could do, if you're interested in one particular view is simply fix the 3d camera so that it maintains that perspective. They provide the tools necessary to take a model from 3D Studio Max to their proprietary file format which is drawn in the game.
I was humble in the knowledge that I could not produce such an engine for so little money as what they have available.
So, I would highly suggest looking into it.
I know you say you want to try something home grown, but you really must think about what you want.
The Torque engine might be too much for you at the moment, too much to take in. I would suggest going through the basic OpenGL tutorials at a website like NeHe (http://nehe.gamedev.net/)
Doing so would answer any questions like "should I use a main loop".
A few years back I bought the Torque Game Engine, and I think for the money it was one of the wisest investments of my life. The developers of this engine are former industry professionals, as well as the engine had seen life in a successful game (Tribes). I learned a great deal about the flow of data, etc from this experience.
What you could do, if you're interested in one particular view is simply fix the 3d camera so that it maintains that perspective. They provide the tools necessary to take a model from 3D Studio Max to their proprietary file format which is drawn in the game.
I was humble in the knowledge that I could not produce such an engine for so little money as what they have available.
So, I would highly suggest looking into it.
I know you say you want to try something home grown, but you really must think about what you want.
The Torque engine might be too much for you at the moment, too much to take in. I would suggest going through the basic OpenGL tutorials at a website like NeHe (http://nehe.gamedev.net/)
Doing so would answer any questions like "should I use a main loop".
Author
I don't want to go for an already existing engine for the good reason that I already played aound with some of them and got good results. However I would like to learn how to design such a thing and thats why I want to do this!
I know openGL, I'm not a totaly newb (although not extremely good either).
BTW: for the main loop I mean is it better to have that in engine or in app?
I know openGL, I'm not a totaly newb (although not extremely good either).
BTW: for the main loop I mean is it better to have that in engine or in app?
1) MAIN LOOP:
Remember that you can have multiple "main loops" via multithreading. It sounds hard, but if you think through it (which you HAVE to do if you are making a game engine), it is quite possible.
2) MAKING YOUR OWN ENGINE:
This will greatly help you understand game programming. It is an awesome idea for a hobby project, don't let the pessimists deter you.
Creating a game/graphics/physics engine from-scratch is also a HORRIBLE idea if you actually want to be productive in making a solid game or if you want to collaborate/share code. Don't let the "real programmers" tell you you have to do it this way!
3) I am currently working on my own 3D engine, nothing amazing, just enough to render rough 3D polygons to a 2D SDL surface. Trust me though, you will learn a lot of math (esp. trig) and create very little game in this manner relatively speaking.
Remember that you can have multiple "main loops" via multithreading. It sounds hard, but if you think through it (which you HAVE to do if you are making a game engine), it is quite possible.
2) MAKING YOUR OWN ENGINE:
This will greatly help you understand game programming. It is an awesome idea for a hobby project, don't let the pessimists deter you.
Creating a game/graphics/physics engine from-scratch is also a HORRIBLE idea if you actually want to be productive in making a solid game or if you want to collaborate/share code. Don't let the "real programmers" tell you you have to do it this way!
3) I am currently working on my own 3D engine, nothing amazing, just enough to render rough 3D polygons to a 2D SDL surface. Trust me though, you will learn a lot of math (esp. trig) and create very little game in this manner relatively speaking.
Author
Hehe thanks ;)
Frankly, I don't care being productive, I'm at uni studying something which has absolutely nothing to do with computers (History and Politics :D ) and just want to do this as a hobby and implement a few ideas I have on my mind..not try and get rich :p
Do you have any ideas on how to structure this thing in a simple way?
Are you using a memory manager? Is it essential?
Frankly, I don't care being productive, I'm at uni studying something which has absolutely nothing to do with computers (History and Politics :D ) and just want to do this as a hobby and implement a few ideas I have on my mind..not try and get rich :p
Do you have any ideas on how to structure this thing in a simple way?
Are you using a memory manager? Is it essential?
I've been working on a home brew 2D game engine for some time (about a year) and I can say I've learned a whole lot (much thanks to the people on this forum).
However, after learning I've had to scrap and restart the engine twice now and while I'm learning and it's a lot of fun... I haven't gotten anything done as far as an actual game is concerned. Still, I think it's worth the time, but I agree with those who say it's not the route to take if you're itching to make a game right now. :-)
(Of course, there will always be that rewarding day when I can use my engine (codenamed "Mocha") to finally make a little game.)
However, after learning I've had to scrap and restart the engine twice now and while I'm learning and it's a lot of fun... I haven't gotten anything done as far as an actual game is concerned. Still, I think it's worth the time, but I agree with those who say it's not the route to take if you're itching to make a game right now. :-)
(Of course, there will always be that rewarding day when I can use my engine (codenamed "Mocha") to finally make a little game.)
Ok, first things first, what platform?
C++ is the language, which compiler? (I can help you with MSVC8, MinGW, or gcc/g++.) And what graphics libraries do you want to use? (I would highly recommend SDL for 2D graphics).
To get your engine off the ground, just make a main loop with some drawing code, and a screen flip. Later you can add more sophistication (objects, sprite animation, modular code)
Here, this should get you off the ground, compiling with the SDL library and works on MSVC8 and gcc last time I checked.
C++ is the language, which compiler? (I can help you with MSVC8, MinGW, or gcc/g++.) And what graphics libraries do you want to use? (I would highly recommend SDL for 2D graphics).
To get your engine off the ground, just make a main loop with some drawing code, and a screen flip. Later you can add more sophistication (objects, sprite animation, modular code)
Here, this should get you off the ground, compiling with the SDL library and works on MSVC8 and gcc last time I checked.
#include <string.h>#include <stdarg.h>#include <stdio.h>#include <stdlib.h>#include <math.h>#include <time.h>#include <SDL.h>#define FONT_HEIGHT 8#define FONT_WIDTH 8//define edges of screen#define XMAX 200#define YMAX 200//put some graphics functions here:void setpixel(SDL_Surface *screen, int x, int y, Uint8 r, Uint8 g, Uint8 b);//you could also use SDL_image for sprites, SDL_ttf for text, and SDL_gfx for shapesint main(int argc, char* argv[]){ /* Declare Variables */ SDL_Surface *screen; SDL_Event event; /* Initialize SDL, exit if there is an error. */ if( SDL_Init(SDL_INIT_VIDEO) < 0 ) { fprintf(stderr, "Could not initialize SDL: %s\n", SDL_GetError()); return -1; } /* When the program is through executing, call SDL_Quit */ atexit(SDL_Quit); /* Grab a surface on the screen */ screen = SDL_SetVideoMode(XMAX, YMAX, 32, SDL_SWSURFACE|SDL_ANYFORMAT); if( !screen ) { fprintf(stderr, "Couldn't create a surface: %s\n", SDL_GetError()); return -1; } /* START OF MAIN PROGRAM LOOP */ do { //PUT GAME AND ENGINE CODE HERE //Use SDL functions to draw to screen //deal with events SDL_PumpEvents(); SDL_GetMouseState(&mx, &my); SDL_PollEvent(&event); //SDL_WaitEvent(&event); switch (event.type) { //***HANDLE EVENTS HERE**** } //make the changes to the screen visible SDL_Flip(screen); //clear screen (on the working page) SDL_FillRect( screen, NULL, SDL_MapRGB(screen->format,255,255,255) ); } while (true); //end of main loop return 0;}
What is it with people and "engines" these days?
Key question: Do you want to make an engine, or do you want to make a game?
An "engine" isn't required to make a functional "game." And in fact, if you set out to build an "engine" in isolation, without having had previous experience with multiple games, you won't produce much of note. You'll simply flail about designing things that are "generic" or "extensible" to support requirements that doen't actually exist. You'll introduce the creep of half-implemented features. You'll, in short, make a big mess, and it won't be impressive at all.
Engine development is not the domain of the neophyte.
Focus your design and development efforts on making a game. Make more than one game. As you make more, you will see commonalities that you can refactor into a core codebase of reusable components, and this puts you well on the way to getting what might eventually be able to be called an "engine" up and running. You'll learn a lot more, get a lot more experience, and end up with a much more satisfying product in the end.
If you spend your time trying to yeild an engine, you'll end up with some DLLs or .lib files, some shoddy looking hacked-up demo applications, and no guarantee that your engine is actually as usable (let alone reusable) as you think.
By not designing it. The knowledge for what is needed by such a thing comes from experience, and you can't be taught that.
Case in point. You won't get very far with GLUT at all. It's very, very limiting.
There is no answer to that. It depends.
Forget about it. Instead, think about the game you'd like to make with it. Write that instead. You don't need to use existing engines like Ogre if you don't want, but you should be focusing on the result, not on the "features." Features aren't playable, they aren't fun, and they aren't impressive.
Now, to the comments:
It is a terrible idea, unless you have some kind of signifigant experience making actual games. Consider the very obvious car analogy: "I don't know anything about how cars use their engines or anything, but I'm going to build me an engine by golly!" Does this sound intelligent to you?
No, an engine is not simple.
No, a memory manager is not essential. It depends.
No, it depends what you need from it. And what you need is determined largely by the needs of the game. If you have no game(s), you have no needs, and thus, no reason to write an engine.
Now, having typed all that out I'm going to qualify what I mean by "engine" and note how it may be different. An "engine" is a set of robust, reusable components and tools. A piddling little bit of event handling code and some skeleton D3D initialization to clear the screen does not the beginning of an engine make. It's the beginning of the D3D application, perhaps, but certainly not an engine.
You can certain make yourself a little sandbox application to toy around with, without trying to construct an actual complete game. You still have, in this case, a goal product in mind: a sandbox or demo of a particular technique you were exploring. The key is to realize that you're implementing the technique, and reusing and refactoring your previous code, producing (eventually) an iteratively refined collection of "base code," that might someday become an engine.
Essentially: Setting out to design yourself a "set of useful tools" is an impossible goal when you have no clue what the context of the tools will be.
Eh, I generally feel that "restarting" a project is not educational, rather you should refactor your "broken" code to fix the issue because it forces you identify the issues and thus learn about them, rather than potentially ignoring them and repeating the same mistakes over and over. This "restarting" phenomenon happens a lot with "engines." Not nearly as frequently for games. Regardless of the definitions used, its the term that seems to afford the appropriate mindsets, strangely enough.
Key question: Do you want to make an engine, or do you want to make a game?
An "engine" isn't required to make a functional "game." And in fact, if you set out to build an "engine" in isolation, without having had previous experience with multiple games, you won't produce much of note. You'll simply flail about designing things that are "generic" or "extensible" to support requirements that doen't actually exist. You'll introduce the creep of half-implemented features. You'll, in short, make a big mess, and it won't be impressive at all.
Engine development is not the domain of the neophyte.
Focus your design and development efforts on making a game. Make more than one game. As you make more, you will see commonalities that you can refactor into a core codebase of reusable components, and this puts you well on the way to getting what might eventually be able to be called an "engine" up and running. You'll learn a lot more, get a lot more experience, and end up with a much more satisfying product in the end.
If you spend your time trying to yeild an engine, you'll end up with some DLLs or .lib files, some shoddy looking hacked-up demo applications, and no guarantee that your engine is actually as usable (let alone reusable) as you think.
Quote:
I would like to learn how to design such a thing
By not designing it. The knowledge for what is needed by such a thing comes from experience, and you can't be taught that.
Quote:
(I will be using OpenGL with GLUT)
Case in point. You won't get very far with GLUT at all. It's very, very limiting.
Quote:
for the main loop I mean is it better to have that in engine or in app?
There is no answer to that. It depends.
Quote:
Is that fine? I am really quite lost on how to design this thing...if you have any design suggestions
Forget about it. Instead, think about the game you'd like to make with it. Write that instead. You don't need to use existing engines like Ogre if you don't want, but you should be focusing on the result, not on the "features." Features aren't playable, they aren't fun, and they aren't impressive.
Now, to the comments:
Quote:
It is an awesome idea for a hobby project, don't let the pessimists deter you.
It is a terrible idea, unless you have some kind of signifigant experience making actual games. Consider the very obvious car analogy: "I don't know anything about how cars use their engines or anything, but I'm going to build me an engine by golly!" Does this sound intelligent to you?
Quote:
Do you have any ideas on how to structure this thing in a simple way?
Are you using a memory manager? Is it essential?
Would you have any suggestions on doing the design of such an engine?
No, an engine is not simple.
No, a memory manager is not essential. It depends.
No, it depends what you need from it. And what you need is determined largely by the needs of the game. If you have no game(s), you have no needs, and thus, no reason to write an engine.
Now, having typed all that out I'm going to qualify what I mean by "engine" and note how it may be different. An "engine" is a set of robust, reusable components and tools. A piddling little bit of event handling code and some skeleton D3D initialization to clear the screen does not the beginning of an engine make. It's the beginning of the D3D application, perhaps, but certainly not an engine.
You can certain make yourself a little sandbox application to toy around with, without trying to construct an actual complete game. You still have, in this case, a goal product in mind: a sandbox or demo of a particular technique you were exploring. The key is to realize that you're implementing the technique, and reusing and refactoring your previous code, producing (eventually) an iteratively refined collection of "base code," that might someday become an engine.
Essentially: Setting out to design yourself a "set of useful tools" is an impossible goal when you have no clue what the context of the tools will be.
Quote:
However, after learning I've had to scrap and restart the engine twice now and while I'm learning and it's a lot of fun... I haven't gotten anything done as far as an actual game is concerned. Still, I think it's worth the time, but I agree with those who say it's not the route to take if you're itching to make a game right now. :-)
Eh, I generally feel that "restarting" a project is not educational, rather you should refactor your "broken" code to fix the issue because it forces you identify the issues and thus learn about them, rather than potentially ignoring them and repeating the same mistakes over and over. This "restarting" phenomenon happens a lot with "engines." Not nearly as frequently for games. Regardless of the definitions used, its the term that seems to afford the appropriate mindsets, strangely enough.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
