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

Started by
27 comments, last by Telastyn 11 years, 6 months ago
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 :(
Advertisement
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 ;)

I gets all your texture budgets!

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

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

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

I gets all your texture budgets!


Where do I start?
[/quote]

Same place as everyone else. Make a program that prints 'Hello World' to the screen.
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.
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.
Yes, this is red text.
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.

This topic is closed to new replies.

Advertisement