28 replies to this topic

[OhGodWhy]

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

[Radikalizm]

I'm afraid game engine development is absolutely not a beginner's subject, so it's definitely not the way to go if you're completely new to programming.
Put that dream idea of yours on the shelf for a while and start with very very simple programming excercises and basic games so you get an understanding of what games are all about under the hood.
Then repeat that process over and over again for some years, writing more and more complex games with more advanced features.
When you've done that you'll probably have a nice codebase which you've kept over the course of your game development career which you can maybe build an engine off of.
Then you can take that idea of yours back off the shelf ;)

[GeneralQuery]

"How do I make a game engine" is one of those "If you need to ask, you're not ready" questions. It's like asking "how can i streamline my house building process" when you've never built a house. Ok, that's not the most accurate analogy but it conveys the whole "putting the horse before the cart" thing. To design and implement a game engine, you need to know before hand how to design and implement games. You get the experience necessary by writing games first. How can you anticipate the needs (down the the finest detail) of game construction without experience of constructing games? Well, you can't. Games first, then engines.

The other thing is to keep it simple. You'll learn far more by completing a project than you do by overreaching. That intangible quality called "experience" is just that: having a holistic understanding of a process that can only be achieved by completing said process numerous times, realistically. Some people are of the "sod it, just get stuck in and have a crack" camp but i disagree with this philosophy on a fundamental level because project completion gives you a holistic understanding that cannot be achieved by falling short and only managing to tackle a few areas in isolation. Sure, you'll learn something but not all learning exercises are equal. Whipping out Occam's Razor for a quick shave, if there's a path that is easier and quicker to learning and one that is harder, more arduous and less fulfilling, you take the path of least resistance, each and every time.

The game ideas you have are far too ambitious for an absolute beginner. You state you don't want to use a game engine so you must start at a more appropriate place, i.e. the beginning. Learn a language. Learn basic 2D/3D concepts. Write Pong. Write Breakout. Write Tetris. DO a rain check and see where you want to go from there.

[zalzane]

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.

[OhGodWhy]

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.

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

[Radikalizm]

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.

That's quite an oversimplified view of game engine programming you have there, and that's coming from someone who's actually developing an engine ;)

Re-usable code from previous game projects can form the base for your engine, but the systems designed for one game are not guaranteed to work for other games you might want to build. A good engine can be used for varying types of games, and designing and implementing systems and accompanying tools which allow an engine to do so can be an incredibly complex task, even if you're not a beginner developer anymore by definition.

Also, flat out calling everyone a naysayer is just rude, we have the best intentions for the OP and we're giving him advice based on experience

[Telastyn]

Where do I start?

Same place as everyone else. Make a program that prints 'Hello World' to the screen.

Edited by Telastyn, 02 October 2012 - 12:24 PM.

[Dunge]

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.

[Pointer2APointer]

First of all, you probably mean a VERY 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:

#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);
}

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.

[EpicWally]

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.

[Goran Milovanovic]

Where do I start?

Try my Python 3 video tutorial series.

@Pointer2APointer

Player should not inherit from GameEngine ...

[Radikalizm]

@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.

[ZeroBeat]

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 somethingelse if(statement) do somethingelse 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
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, 03 October 2012 - 06:02 AM.

[Shaquil]

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

[SimonForsman]

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

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)

[Vodahmin]

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!

Edited by Vodahmin, 03 October 2012 - 07:45 AM.

[zeidrich]

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.

[cYnbios]

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!

[SNce]

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.

[Pointer2APointer]

I see that I've already been attacked for my poorly written game engine code tag.

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.