Game Engine from scratch using C++ and python - Where do I start?

Started by
27 comments, last by Telastyn 11 years, 6 months ago

Where do I start?


Try my Python 3 video tutorial series.

@Pointer2APointer

Player should not inherit from GameEngine ...

+---------------------------------------------------------------------+

| Game Dev video tutorials -> http://www.youtube.com/goranmilovano | +---------------------------------------------------------------------+
Advertisement
@Pointer2APointer:

That's not a game engine or even the base for a game engine, that's a class for drawing an image, there's much more to a game engine than drawing images even for very simple engines.
I also don't see why the Player class inherits from the GameEngine class, that's a serious violation of the single responsibility principle (and the liskov substition principle, but let's not get nitpicky here)

How do you handle state? How do you handle systems besides drawing? Why does a draw function take a filename as input (does it actually reload the file every draw call?)? etc.

I gets all your texture budgets!

If I was in your shoes this would be the path of least frustration:
In the OP it says that you would like to use python + c++. Then Start learning Python. Eg follow Goran Milovanovic's tutorials or/and read a book about the language and make the samples as you go through it.
Just start coding and learning.

As you learn more and more, try experimenting and making small examples with what you have learned. eg when learning if else do:

[source lang="cpp"]if(statement)
do something
else if(statement)
do something
else if(statement)
do this[/source]

In the same time start a small and as simple as possible project. And Complete it!!! Something great happens when a project is complete smile.png
Eg: As I was learning I made a couple of progressively more complex text rpgs. My last one had a small combat loop where I could cast spells and buy gear in shops.
As you gain knowledge , hopefully you would start to see how complex games really are. Also that making games and playing them is not the same.

When you feel you are trully ready, move to graphics view. Eg using PyGame. Start making small games with it. To improve your knowledge and solidify your understanding of how games work. Then maybe if you feel ready move to C++. Pick OpenGL or Direct3D and so on.....

Radikalizm and the other "naysayers" just want to open your eyes to what it is that you want to make. Rather than trying to make a game engine try to make a game. In the OP you said you wanted to make your dream game. So go and learn the knowledge needed to make it! An engine can be used to make different types of games. But to make a good engine, you need to know what a game needs.

As you are learning and understanding more, start building your dream game. Step by step build it up. There will be lots of mistakes and rewrites. But that’s good as you will get better and better at coding and will be moving forward to making and finishing your dream game.


// This is using SDL and C++ as an example.
#include <SDL/SDL.h>
typedef SDL_Surface * LOAD;
class GameEngine
{
public:
GameEngine() // Put whatever here for the constructor params.
{
// Here, too, for whatever you want it to initialize.
}
}
class Player : public GameEngine
{
public:
Draw_Image(short xpos, short ypos, short xheight, short yheight, const char *FILE_NAME)
{
// Render the image here, optimizations, etc.
}
private:
short x, y;
short height, width;
}



You should probably avoid posting code on forums at all possible costs. If you make a mistake, every programmer who sees it is going to go in for the attack

[quote name='Pointer2APointer' timestamp='1349206468' post='4986164']

// This is using SDL and C++ as an example.
#include <SDL/SDL.h>
typedef SDL_Surface * LOAD;
class GameEngine
{
public:
GameEngine() // Put whatever here for the constructor params.
{
// Here, too, for whatever you want it to initialize.
}
}
class Player : public GameEngine
{
public:
Draw_Image(short xpos, short ypos, short xheight, short yheight, const char *FILE_NAME)
{
// Render the image here, optimizations, etc.
}
private:
short x, y;
short height, width;
}



You should probably avoid posting code on forums at all possible costs. If you make a mistake, every programmer who sees it is going to go in for the attack
[/quote]

Having your code attacked by more experienced programmers is a good way to learn. (posting bad code as a recommended solution isn't the best idea but posting bad code to get help and feedback is)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
I'll try to give you a more technical answer. As I understand you'd like to mix Python with C++ and that is really great. As I see it, you'll probably wanna build the entire engine in C++ and use Python as a scripting language for AI and perhaps simple events handlers?

I'm not sure about how well you know programming but it'd be wise to get familiar with the Object Oriented Programming concept (if you don't know it yet). Learn about inheritance, interfaces and virtual functions. Basically most of the game engines are a huge set of interfaces and virtual functions - this way it's fairly easy to implement new things or to make changes to the existing objects, without the need to modify each of them. You should also get familiar with the proper use of pointers - you could probably get away with naked pointers for a very simple game, however all professional engines use smart pointers. This way you don't need to worry about memory leaks, which may at some point make your game a real mess.

After getting the basics done, you can eventually move towards proper memory management. How to cache game files efficiently in the RAM and load them before they're needed (if it's a simple game, then I guess you can load everything at once). After that, you can learn some basics about creating your own Process Manager and Events Manager for the engine - it'll be incredibly useful when you later add AI. Of course, you should also get familiar with DirectX or OpenGL (or SDL if you want to make 2D games only). Having this knowledge, you should be able to create a simple engine - keep in mind, that there's more such as Networking or Multithreading etc - however the things I mentioned above is the minimum if you want to make a nice and flexible framework for simple projects.

As for the literature, I'd recommend this book to learn C++ http://www.amazon.co...49271707&sr=8-3

This one for game engine development: http://www.amazon.co...49271663&sr=8-1 (by the way, this book has been recommended to me by one of the users at this forum - I'm currently reading it and it's great!)

You may also need this one for Python: http://www.amazon.co...49271811&sr=1-3

Good luck!
An engine is 3 parts. See http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

You have the model, which keeps track of the state of the game that you're making. This is going to be where you would manage things like your physics and AI.
You have the view, which is the component that takes what information is stored and generated in the model and displays it for the user. This would be things like your renderer and sound system.
You have the controller, which is where you're going to be taking inputs from the player, and deciding how you're going to manipulate the model based on those inputs, or how the view describes the model.

Generally, you have a main loop. This loop repeats until the game is ended. What happens in the loop is you capture inputs from keys, you perform any ongoing calculations based on the state of the game and the inputs recieved, and you update the view to reflect the current state of the game.

An map of it might look like this

Main Loop:
HandleKeypress Function
DoPhysics (affected objects fall based on time elapsed since last call)
MoveCharacter (based on keypresses recorded maybe? Check for collisions? Whatever.)
RenderScene
Repeat

The tricky part honestly comes down to doing those things efficiently. If you want to run at even just 30 frames per second, you have to spend no more than 33ms on calculations between frames. When you want to work with voxels, you have a large amount of data, so you need to find ways to work on that efficiently, when you want to work physics into it, then you have a large amount of points interacting with a large amount of points, which gets even harder.

If you want to start, find out how to make a 3d scene that accepts inputs. Use OpenGL or DirectX. Just getting stuff on the screen is a challenge if you've never done it before. Then come up with a way to represent your data, put that data on the screen, come up with a way to handle user input, use that input to change the data or move the camera. Finally, find a way to do it quickly enough to be acceptable, and eventually write it to (and read it from) permanent storage if you want to be able to save games.
I have a Java/C++ background but I've recently started programming in Python for the very first time. I suggest starting out with Python first as the language is more human than C++. The downside could be that when you switch to C++, it might look a bit foreign. But if you want a challenge and start out with C++, you will have very little problems switching to Python.

Any ways, trust those that say you are not ready to build the engine. So try and disregard that idea for now.

I'd recommend using Pygame to assist you in making a game in Python: http://www.pygame.org/news.html

It might not be the best game module out there, but it has a lot of resources to learn from. I personally learned a lot reading this guide: http://programarcadegames.com/index.php?lang=en

It is an excellent and easy to follow guide on not only how to make games but a great introductory to programming itself.

Good luck!
Totally agree with everybody who says games first and engine next.

I am currently set out to writing my own engine too. I am starting off by making a simple rendering engine. For now I have a Maya mesh exporter that I can use to construct mesh data in my own format that is going be used in my engine to load meshes. From there my first task would be able to render this mesh using OpenGL/D3D. From there I can go ahead and start building up features in my rendering engine.

I believe building an engine from scratch starts with small steps like these.
I see that I've already been attacked for my poorly written game engine code tag. sad.png

What I actually intended on getting at was that a member function within a class that draws and renders an image, and can return the position in a 2D plane/world can already be a simple game engine practice for beginners.

In fact, most games you'd write will have some form of an engine, or at least parts that can be transformed better to reusable code segments and sub-systems that handle game-specific data.

It was my mistake - you don't need to pass an argument to an image loading function containing the file name everytime it's invoked/called.

I was just aiming to simplify the idea, but I failed to elaborate more into the example, as I just wanted it to be simple. My bad.

If you really want better game engine examples, or from people who have more experience in game engine design (more than me at least), you can try a lot of the examples listed above, or for the sake of your topic's title, keep working on one yourself.

A game engine is a system that will act as a "wrapper" of some sort over a graphics library, like SDL, SFML, DirectX, OpenGL, and many others. It can dramatically change depending on the genre/target of the game.
For example, a platform game would contain codes that handle 2D Cartesian plane mapping, raster image formats in a window and coordinates (for 2D), sounds, AI for non-playable characters, positioning, objects/instances such as coins or items, an animation engine (to accurately load and animate images in memory), gravity and/or friction (if necessary), advanced collision detection systems help a bunch, and playable/game states and tile systems too(tile-based games often save more memory if programmed effectively).

As for 3D, well, it's a more difficult extension, as you have a third-dimensional axis awaiting you, along with several other aspects. ph34r.png
Yes, this is red text.

This topic is closed to new replies.

Advertisement