Game Engine

There's a thread regarding C# game engines (started yesterday).
You must be seriously, seriously pro to plan build an engine. There's no chance to do something serious without getting more experience first. Of course, as there's no definition of what exactly an "engine" is, you could cut a lot of corners and claim to have an "engine": that's not how it is supposed to work.
Game engines, no matter what they tell you, are not fun.

If you have to ask how to build an engine you're definitely not ready to build one
Building an engine is absolutely not a beginner's job, so it'd be best to put that idea on the shelf for some time until you're ready for it

Thanks for the response but i have worked on two projects in my university course work where in i made games using directx 11 and directx 9 using our professor's game engine. Also, i have an idea how each module of a game engine works too but i don't know know how to start making it from the scratch.(or is it still to early for me to consider making a game engine)

Mostly in game engines there isn't a fixed point on where to begin, you could start off anywhere and build gradually on top of that. The easiest would of course be to lay out a design for your engine and start with the system that has the least, or preferrably no dependencies on other engine systems.
From then on it just comes down to implementing the systems you designed, you need to have a clear vision of what the engine is supposed to do, how it's supposed to do it, and for which goals it's going to be used. Writing an engine without having a clear usage goal in mind is substantially harder. This of course all has to happen within the limits of the system(s) you'll be targetting.

Building the systems themselves will be all up to you, and to build an efficient rendering system or audio system (for example) you'll be digging deep into the gritty details of how such systems work, and you'll need to be quite familiar with those details if you want to build something that actually works, and works well.

Let me give you one piece of advice: If it's games you want to build you should just pick an existing engine and build the games you want. The chance of your custom-built engine outperforming any of the available options will be quite minimal. If you're actually interested in building engines you should first of all consider whether you actually have the required skillset to start one. I'll have to disagree with Krohm here, because building engines can be fun IMO, but it's completely different from building games, and if you don't have a clue as to what it takes to build an engine you'll get frustrated quite easily, and the development process overall will not be a fun ride.

In the end nobody can stop you from building one, but don't expect there to be an abundance of tutorials or guides on the subject, it will all have to come from yourself

I'm sorry to say but two university assignments isn't be enough to make an engine. I made several games from scratch (without using engines) and several other applications (all outside the university) and I still don't think I would even consider making my own game engine. A game engine is not about games. It's about architecture, software engineering and all the stuff that is not really game related (or at least not only game related).

So head the others' advice and make games instead of an engine, or get pretty damn solid knowledge and experience in software engineering (probably several years of intensive programming)

Hey there - I'm in a similar position, and I'm going the game-engine building route for the following reasons:
a) Building up a knowledge of how game engines are structured is important to me. Building even a simple pac-man game engine myself would, for me, be enjoyable! Sure, it will be frustrating - having to write boiler plate code myself, but that's part of the experience for me. It's a richer learning experience in my view.
b) Using ready-made game engines, whilst yeilding much more immediate results, teaches you less about the princples - I think.

So basically as you've probably concluded, knocking out as many games as possible is not my objective. It all depends what you enjoy. It doesn't bother me that everything I'll do has been done before many times - that's not the point. The experience is of more importance than the tangible results for me.

In the future maybe I'll use ready-made game engines - who knows. Not yet though.

Hey there - I'm in a similar position, and I'm going the game-engine building route for the following reasons:
a) Building up a knowledge of how game engines are structured is important to me. Building even a simple pac-man game engine myself would, for me, be enjoyable! Sure, it will be frustrating - having to write boiler plate code myself, but that's part of the experience for me. It's a richer learning experience in my view.
b) Using ready-made game engines, whilst yeilding much more immediate results, teaches you less about the princples - I think.

So basically as you've probably concluded, knocking out as many games as possible is not my objective. It all depends what you enjoy. It doesn't bother me that everything I'll do has been done before many times - that's not the point. The experience is of more importance than the tangible results for me.

In the future maybe I'll use ready-made game engines - who knows. Not yet though.

And what principles would building a game engine teach you, you think? I don't think building an engine is a great learning excercise, because it requires you to already know all there is to it to actually get something up and running. If you start out with the idea "I'll learn everything while developing" you'll likely end up with a horrible mess of barely functional (or not even functional) code.
There is a common misconception (IMO) among beginning developers who think that building an engine will somehow give them much more experience than building games will, and that they'll learn so much more by throwing themselves onto an engine project from the start instead of actually gaining the skills required to build an engine.

But then again, nobody's stopping you from attempting to build one, but please do keep the advice given to you in mind

And what principles would building a game engine teach you, you think? I don't think building an engine is a great learning excercise, because it requires you to already know all there is to it to actually get something up and running. If you start out with the idea "I'll learn everything while developing" you'll likely end up with a horrible mess of barely functional (or not even functional) code.
There is a common misconception (IMO) among beginning developers who think that building an engine will somehow give them much more experience than building games will, and that they'll learn so much more by throwing themselves onto an engine project from the start instead of actually gaining the skills required to build an engine.

But then again, nobody's stopping you from attempting to build one, but please do keep the advice given to you in mind

I agree.
As many of the others have already said, you need to know the inter-workings of the engine before you really continue. Also, as Radikalizm stated, you'll need to know a great deal of code and understanding of what's required of you to build that engine. This would be different if you had been working with a certain engine for a few years and you had many quite a few games along the way and you felt ready to make an engine. You could also, check out Jad Engine an open source 3D game engine. Go look at the code and what's required of you. If there's a good amount of terms or keywords or even structures you're not sure of yet/haven't learned yet then it's probably not time.

But, if you do continue good luck.

Hey there - I'm in a similar position, and I'm going the game-engine building route for the following reasons:
a) Building up a knowledge of how game engines are structured is important to me. Building even a simple pac-man game engine myself would, for me, be enjoyable! Sure, it will be frustrating - having to write boiler plate code myself, but that's part of the experience for me. It's a richer learning experience in my view.
b) Using ready-made game engines, whilst yeilding much more immediate results, teaches you less about the princples - I think.

So basically as you've probably concluded, knocking out as many games as possible is not my objective. It all depends what you enjoy. It doesn't bother me that everything I'll do has been done before many times - that's not the point. The experience is of more importance than the tangible results for me.

In the future maybe I'll use ready-made game engines - who knows. Not yet though.

You confuse from-scratch coding with engines. Pac Man requires nothing like an engine. Even a fist person shooter doesn't require an engine. Engine is something for making more games than one. It's not only some reusable code, it's the whole toolchain required to make more games (okay, definitions may vary), and usually implemented in a way, that it's commercially releasable or at least usable by more developers (or a development team, ie "in house" engine) in a structured environment.

You are talking about from-scratch coding, with is fine, I did/do that too, but that's light-years form engine programming.
And another thing, using engines does teach you principles. If you haven't ever used an engine and finished/polished a game (or several), I'm sure you won't be able to make anything that resembles an engine (even if you make games from scratch)

Ah yes, thanks for the tip on terminology. I was equating a game-engine to a game-framework (i.e. like for a 2d platformer or shoot-em-up). That could definitely be confusing. Interesting post that.

Thanks a lot for each one of your responses and i have decided first to make a game of my own then a engine.

I've begun making my own game engine (actually this is now my second as I grew bored of the original one) after precisely 1 university course on it.

It's not as bad as people say. Start simply (boxes and spheres), solid colours instead of textures, etc. and move on from there.

I should add that I'm writing mine in c# using SlimDX, so things are a little easier for me (I don't have to worry about memory leaks as much or other more obscure errors), so I'd recommend getting started with something like c# and XNA. Most universities I know teach some measure of Java, and C# is barely a stone's throw from Java, syntax-wise.

There should be a sticky about this.
It's quite often that the OP confuses engines with the framework (there's a "how to make a game engine" thread every day), and it's quite often, that we don't understand that they are really asking about frameworks. Even higher rep members doesn't always get the intentions of the OP (me included, but I try to pay attention) and sometimes answer harshly, pointing out that making engines is a failure for a beginner, and blah blah same old. Which is truth, but off topic if we look behind the misused "engine" term.

The appropriate reply would be pointing out that the OP is misusing the term "engine".

It's often clear that the OP is talking about reusable stuff/libraries, which is still not an engine. In this case, the "make games, not a libraries" like comments are truth, but the OP should be told that it is NOT and engine anyway.

I think it's important to tell these to the OPs, as they will have a hard time to get useful info, as they desperately google with the keyword "engine" while they could find info if they used the right terms.


Note, it's very possible that I even misuse the term "framework". By framework I mean the whole structure of a particular/specific program without the details, the dressing (I'm so bad at expressing myself). Without the actual textures, gameplay details, texts blahblah.

Framework is the term used in the programming book I have been using: "C# Programming For Beginners", so I'd go along with that. The distinction between framework and game engine is an important one I agree.

I think I have to humbly admit that I was guilty of the same confusion between engine or framework though I don't consider myself a beginner (I knew assembler on my c64 and Amiga)

If I get it right a game engine is some package that allows non-programmers or beginning programmers to create a game with point and click interfaces while a framework is only there to hide the nitty-gritty i.e. individual DIP calls, renderstate changes, model management, etc.
I myself want to create a game from scratch without a framework then but definitely not a game engine. According to me the latter is work for a whole team of Computer Science Phd's

I think I have to humbly admit that I was guilty of the same confusion between engine or framework though I don't consider myself a beginner (I knew assembler on my c64 and Amiga)

I'd say you stand a good chance of creating your own game from scratch if you dabbled in assembler.

I think I have to humbly admit that I was guilty of the same confusion between engine or framework though I don't consider myself a beginner (I knew assembler on my c64 and Amiga)

If I get it right a game engine is some package that allows non-programmers or beginning programmers to create a game with point and click interfaces while a framework is only there to hide the nitty-gritty i.e. individual DIP calls, renderstate changes, model management, etc.
I myself want to create a game from scratch without a framework then but definitely not a game engine. According to me the latter is work for a whole team of Computer Science Phd's

An engine is not a point-and-click tool. There have been countless of discussions to define the term "engine" but it always ends up with lots of people disagreeing with eachother.
The best way to describe an engine would be to give examples. Have a look at the UDK, Cryengine 3, Unity, etc. Those are engines
They provide an entire toolset for building vastly complex games of varying genres, and that's what an engine's all about

I'd say you stand a good chance of creating your own game from scratch if you dabbled in assembler.[/background]

What would make you say that? I've programmed in IA32, AMD64, MIPS, MC68000 and ARM assembler, and those skills mean absolutely nothing when it comes to developing my engine or games for that matter

Maybe point & click was a bit radical but I couldn't find the exact way to express it.

On assembler, yeah I agree I know x86-64, ARM, 68K but it doesn't help understanding how to create a game, only how computers work under the hood.

What would make you say that? I've programmed in IA32, AMD64, MIPS, MC68000 and ARM assembler, and those skills mean absolutely nothing when it comes to developing my engine or games for that matter

I was referring to the expertise required to program in a low level language, which I see as admirable frankly. I see higher level languages as easier to master if you have mastery of low level languages. By implication, programming expertise in low and higher level languages is a huge advantage if you want to make a game, by virtue of the necessity of coding.

I would say that your expertise in assembler is a huge advantage, since it proves that you have the mathematical mind required for programming - giving you a solid foundation for coding any software you put your mind to - including games.

I was not intending to downplay the complexity of game design or anything else. It was a compliment to those who can cope with low level languages.