• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Peter Mishustin

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

28 posts in this topic

Hello! Please brace for NEWBINESS-
I was finally sick of "Playing games" that make rules for me and I wanted to make my dream game!
So, after long hours of reading (very interesting) books on Python and C++, aswell as other languages, I decided to start!
So i bring to you this question;
Where do I start?
I dont want to use an engine, i want to MAKE one- Voxel based, full 100% destruction, lots of physics and math involved, 2D visuals using sprites and such.
How do I start?
Where do I start?
What am i missing?
How do I improve?
I'm hoping you can answer my question, since i've been getting pushed left and right and downvoted everywhere :(
1

Share this post


Link to post
Share on other sites
Everyone in this thread is a naysayer.

The first thing you do to create a game engine is to program several games. Take note what kinds of tools and algorithms you reuse in each game, and build a framework off those algorithms.

Needless to say, once you've programmed several games, you won't actually be a beginner anymore.
1

Share this post


Link to post
Share on other sites
[quote name='zalzane' timestamp='1349198824' post='4986107']
Everyone in this thread is a naysayer.

The first thing you do to create a game engine is to program several games. Take note what kinds of tools and algorithms you reuse in each game, and build a framework off those algorithms.

Needless to say, once you've programmed several games, you won't actually be a beginner anymore.
[/quote]

Thankyou SO so so very much. Your relatively small, but effective answer gets my upvote. I understand alot more now, and have grown better from it. I hope something good happens to you in return (karma).
0

Share this post


Link to post
Share on other sites
When I was 13yo (13 years ago) I had very basic knowledge of programming. I knew basic C and understood everything the wrong way. Still, I e-mailed a developer from a simple game I wanted to mimic (that was before I knew about GameDev), asking this exact same question (where do I begin) and his reply was : "Download the DirectX SDK". Judging from this forum, this is the worst answer possible, but at the time I loved that guy and it actually helped me to start trying things out, to find out by myself I was trying things too advanced for my level.
2

Share this post


Link to post
Share on other sites
First of all, you probably mean a [b]VERY[/b] simple game engine, like maybe one that dictates coordinates on a cartesian plane of bounded raster images in memory in a window, and maybe input synchronization.

You can implement a super-simple engine like this, pretty much:

[CODE]
#include <SDL/SDL.h>
void ShowBMP(char *file, SDL_Surface *screen, int x, int y)
{
SDL_Surface *image;
SDL_Rect dest;
/* Load the BMP file into a surface */
image = SDL_LoadBMP(file);
if ( image == NULL ) {
fprintf(stderr, "Couldn't load %s: %s\n", file, SDL_GetError());
return;
}
/* Blit onto the screen surface.
The surfaces should not be locked at this point.
*/
dest.x = x;
dest.y = y;
dest.w = image->w;
dest.h = image->h;
SDL_BlitSurface(image, NULL, screen, &dest);
/* Update the changed portion of the screen */
SDL_UpdateRects(screen, 1, &dest);
}
[/CODE]

This is basically a skeleton source code that can be brushed up to draw images into memory.

It is reusable, and fixed now for any future readers.
0

Share this post


Link to post
Share on other sites
I stole this from another post, but this article http://lazyfoo.net/articles/article04/index.php (and a number of the others on this site) have given me a pretty good idea on how to structure games.
0

Share this post


Link to post
Share on other sites
[quote name='OhGodWhy' timestamp='1349196306' post='4986095']
Where do I start?
[/quote]

Try [url="http://www.youtube.com/playlist?list=PLDFB7FFF90EE6F0C1"]my Python 3 video tutorial series[/url].

@Pointer2APointer

Player should not inherit from GameEngine ...
0

Share this post


Link to post
Share on other sites
@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.
0

Share this post


Link to post
Share on other sites
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 [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
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. Edited by ZeroBeat
0

Share this post


Link to post
Share on other sites
[quote name='Pointer2APointer' timestamp='1349206468' post='4986164']
[CODE]
// 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;
}
[/CODE]
[/quote]

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
-1

Share this post


Link to post
Share on other sites
[quote name='Shaquil' timestamp='1349264041' post='4986345']
[quote name='Pointer2APointer' timestamp='1349206468' post='4986164']
[CODE]
// 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;
}
[/CODE]
[/quote]

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)
2

Share this post


Link to post
Share on other sites
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++ [url="http://www.amazon.co.uk/Ivor-Hortons-Beginning-Visual-2012/dp/1118368088/ref=sr_1_3?ie=UTF8&qid=1349271707&sr=8-3"]http://www.amazon.co...49271707&sr=8-3[/url]

This one for game engine development: [url="http://www.amazon.co.uk/Game-Coding-Complete-Mike-McShaffry/dp/1133776574/ref=sr_1_1?ie=UTF8&qid=1349271663&sr=8-1"]http://www.amazon.co...49271663&sr=8-1[/url] (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: [url="http://www.amazon.co.uk/Programming-Python-Complete-Introduction-Developers/dp/0321680561/ref=sr_1_3?s=books&ie=UTF8&qid=1349271811&sr=1-3"]http://www.amazon.co...49271811&sr=1-3[/url]

Good luck! Edited by Vodahmin
2

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
I see that I've already been attacked for my poorly written game engine code tag. [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]

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. [img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img]
0

Share this post


Link to post
Share on other sites
[quote name='Pointer2APointer' timestamp='1349468993' post='4987241']
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.
[/quote]

... ?

No one is arguing that you didn't go into enough detail. We just pointed out some fundamental flaws in what you posted.

By the way: You should never, ever typedef a pointer. That's an unnecessary level of indirection, and it's something that has no place in your example, because you're not even using it anywhere.

[quote name='SimonForsman' timestamp='1349265283' post='4986350']
posting bad code as a recommended solution isn't the best idea
[/quote]

Well, yes, but on the other hand, you can't really blame people for not knowing any better.

They think they're posting code that is appropriate from one perspective or another, so they post it, because they want to help. I think that's fine, as long as there are other GameDev members who can point out the flaws, and keep everyone informed.
0

Share this post


Link to post
Share on other sites
[quote name='Goran Milovanovic' timestamp='1349505824' post='4987332']
By the way: You should never, ever typedef a pointer. That's an unnecessary level of indirection, and it's something that has no place in your example, because you're not even using it anywhere.
[/quote]
Actually, typedef'ing pointers is common in game industry, smart pointers that is.
1

Share this post


Link to post
Share on other sites
[quote name='Vodahmin' timestamp='1349506814' post='4987335']
Actually, typedef'ing pointers is common in game industry, smart pointers that is.
[/quote]

I would still argue against it: It's something that carries certain benefits, I'm sure, but it makes code more difficult to read, because now I have to look for what opaqueDataType actually represents.

If I just have SDL_Surface*, it's immediately clear.
1

Share this post


Link to post
Share on other sites
To end my misfortunate and bad example code of a game engine, I'll go back and edit to better suit a problem.

As for type defining an SDL_Surface *, I always do it because it's easier and faster to write out [CODE]LOAD SDL_LoadBMP("image.bmp")[/CODE] than it is to write [CODE]SDL_Surface* LOAD = SDL_LoadBMP("image.bmp")[/CODE].

I would hope others see the time-saving benefits of using a typedef at times, aside from other use.

Now I'll go and fix what I poorly wrote out.
0

Share this post


Link to post
Share on other sites
[quote name='Goran Milovanovic' timestamp='1349547716' post='4987464']
[quote name='Vodahmin' timestamp='1349506814' post='4987335']
Actually, typedef'ing pointers is common in game industry, smart pointers that is.
[/quote]

I would still argue against it: It's something that carries certain benefits, I'm sure, but it makes code more difficult to read, because now I have to look for what opaqueDataType actually represents.

If I just have SDL_Surface*, it's immediately clear.
[/quote]
I think it's only a matter of getting used to it. There is no apparent reason for typedefing SDL_Surface* but if your pointer declaration looks like "shared_ptr<SDL_Surface>" or something longer, then it can be a bit frustrating to rewrite it every time, so why not just typedefing it to "SDL_Surface"? Then, as a matter of good practice, you can add a "p" before the pointer declaration (for example "pSurface"), so there is really little room for mistake.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0