Is game engine making hard?

Pages: 12
I've been told that I need to know OpenGL or some graphics thing besides just the OS API to make games, but now I apparently need to know about "game engine" development....Can some body tell me exactly what that is and how/why it's made and how I could have an idea on how to do it?
Also, if using Windows OS, do you have to use the API with graphics extensions to make games or no? might help you out.

3d games, the popular API's are directX and opengl - those are not engines just code bases to get your code to talk to your graphics cards, keyboard, network, e.t.c hardware. They are very complicated and they are very complicated. you use them to write/code your own engine or edit other open source engines.

Thats about as much as i know.
You can start with SDL! Or SFML! <-- SDL

These let you get started with visual, audio, and control systems quite easily =)

If you want a sample, you can ask for some code. I'm going to write an article on some simple concepts in game creation soon. I haven't decided whether to just make a site or just post it here on the articles.
Um....Okay. I know what APIs are....I wanted to know how hard it is to make a game engine, say, a 2D one, from C++ code alone.

Also, the logic behind it would help me get started in writing one. I can use Windows API, OpenGL or the such with it, of course, right?

I know how to grab the device context from OpenGL and use it with Windows API, which, even though lame, has to apparently be done if you're using a Windows OS. >.<
Last edited on
@vlad61....The homepage of GameDev is doing what for me...? lol.

So far you people gave advice on 3D graphics APIs, graphics cards, offered a link to a home page site and gave links to download SDL tutorials?

Um....Not trying to be mean here....But I said GAME ENGINE not graphics APIs.... >.<
yay google.

The tutorials are essentially for the creation of your games without an engine.

If you would like to learn how to create a game engine, it's quite simple, and fun!
Last edited on
Alright, I'll bite.

For a game engine, you need the following things >>

first: You need graphics, control, and optionally audio, and networking. SDL will work for our example.

second: you need knowledge of classes and I would hope most of the other OO concepts.

third: you need to understand how the world works =)

With the knowledge and capability stated above, it's fairly simple to make a trivial game engine.

simply make objects that store images, positions, and perhaps velocity. Then depending on the input, move them about and switch the images inside your objects. This is all rather ambiguous, but I'll get more in depth if I make a full tutorial.

For an example object.

// the following things are defined by you.
typedef (whatever image type your lib uses) image;
image load_image(string path);
void apply_image(float x, float y, image img, image canvas);
// done with definitions

class object{
image *myImage;
float x, y, xvel, yvel;

void load(string path);
void load(image *theImage);
void apply();
void teleport(float tx, float ty);
void add_position(float cx, float cy);
float set_vel(float nvx, float nvy);
float add_vel(float cvx, float cvy);

Last edited on
the hardest part imo is getting world objects to interact with each other in a way which doesnt break the object oriented design of your engine.
interaction can be difficult, what have you had the biggest problem with?

What I've found the most difficult was the resolution of collisions, for my action game. However, I've solved it, and now everything has been super easy. I love game engine design, and game programming!
What specific part of a game engine do you want to know how to create? Asking "how do I create one" is like asking "How do I make a car?"

Game Engines can be massive pieces of software that consist of a dozen subsystems. Think of a Game Engine as a collection of subsystems that all work together to govern how a game performs; it's logic like collision detection, rendering of images, handling user input from the mouse and keyboard, and audio support for playing sound effects and music, among others, each represent a separate subsystem the determines the rules of the game. Your input handling subsystem for example will determine what actions the system must perform if you press the 'w' key or right click with the mouse.

As an example of how a subsystem might work: within any game you have your main game loop. Basically the way it works is each iteration of the game loop will, for example, accept user input, update the coordinates of graphics, etc... depending on the users interaction and the game/object states.

Since a Game Engine is really a massive collection of objects interacting with each other, the game engine monitors the states of each object and will execute tasks against them. For example you may have something as simple as this:

class Player

    short int hitPoints;
    short int magicPoints;
    int xCoordinate;
    int yCoordinate;

At any given time the game knows where player is in the world and can update it's x/y coordinates based on players interactions. Say for example you hit the 'w' key, then the input system may know to increase your coordinates and move your player up. Your rendering subsystem may then update the screen to show your player move. Ultimately the best way to learn how to create a game engine is to try programming each of the subsystems and have them interact with each other. Again, this is just to nudge you in the right direction. Game Engines can be more complicated than most systems out there.

To give you a broad idea of the types of systems and their interactions, take a look at the engine architecture diagram for the C4 Game Engine: I also recommend reading the book Game Engine Architecture It is an advanced book on engine architecture, but it's the best on the market and my Architecture Bible.
I've had a lot of practice at it now so I don't have so much trouble, with my world objects I used to find myself needing to downcast quite a lot in order to get to derived class functions from base class pointers, which is a clear sign of bad design.

With collisions I never had trouble, bounding boxes or bounding spheres are simple enough and if you sit down and think about it pixel to pixel collision isnt too hard for 2d games, Ive never made anything that precise for a 3d game though just bounding shapes.
The detection was never hard at all, gosh that's 4 lines of code! I really had a hard time with making flawless collision resolution.
Oh right gotcha, yeah if you've got a swarm of enemies and they get knocked back when hit then more than one can end up needing to occupy the same space, is that the kind of thing you mean? If so, I agree totally that's not simple.
the hardest part imo is getting world objects to interact with each other in a way which doesnt break the object oriented design of your engine.

Agreed - it's kinda hard to design interaction between objects without creating heavily coupled classes. I was thinking of something like creating a tree structure for the game objects (I am using OpenGL, and with OpenGL using trees to render stuff seems like the most natural approach to me, and since I want my objects to be able to draw themselves, I decided that putting them into a tree as well - or rather, let them form a tree- was the best approach), where each object has the ability to send messages to the tree (I would write seperate objects to send messages like button presses and stuff). I didn't try that out yet, but I think it could work.
You got it, however I was also having a problem with object collisions with a tile system. One of two problems that took me days to figure out:

first problem, if I was to go more than 32 px/frame in my old engine, I would fall through objects

second problem, in my new engine, the object in question would get stuck on a stack of objects, because of a horribly complex problem involving my method of resolving.

I fixed the first problem by not only checking collisions in a box around the player, but by expanding that box to the previous position, and with the fix of the second problem.

The second resolution problem was fixed by creating a collision queue in my object class, so every frame I can have a managerial class add objects to each other's queue's for resolution and really speed things up. That wasn't the only fix though, the second fix was the separation of the x and y axis.

Right now, with a single unstoppable/immovable object, the collision resolution works almost perfectly. With multiple movable objects, well I'm going to work on that later =), with a completely movable object it works really well also.

edit : oh with the unstoppable objects, I do have a problem, because of persistence of velocity in my engine, it's either too sticky, or your player immediately falls behind a quickly moving (horizontally) block if he jumps off of it.

My next problem is expanding my player class, so that I can have double jumps, then I want to improve my following camera, so that it will slowly pan to a teleportation spot rather than a quick jump, which makes me dizzy. Afterwards, I'm going to add saving and loading of separate layers, so I can keep a background layer and load extra layers in front that can all have separate collision handling sequences. It's super fun stuff! Of course I'm working on my graphic arts skills all the time, and I think I may be getting a little better, so look forward to an awesome sidescrolling RPG!
Last edited on
Ulti, when you want to make a side scrolling game, you might want to consider making the collision line based. Though of course that would mean you would have to define additional meta data for your tiles, it would be worth considering if you want to have stuff like slopes and don't want to have a huge pain implementing it.
was he totally trollin? I Feel like it. If you weren't I apologize for not giving you specific instructions to making a game engine.
It's spoon licker, it wouldn't be his first time.

Well I think that's a good idea. I'm not sure on the details, if you have a second, could you expound?
Pages: 12