@chrisname: I agree with you; a lot, if not most, games will inherently contain "engines" of sorts from the way they are designed. While being somewhat tailored to the individual game's needs, the internal framework is still generic enough to be called an "engine". Ideally this said "engine" would not be heavily entwined with actual gameplay code (stuff specific to that game, what I generally call "game logic") and would be mostly separate, but still part of the codebase and all in the same executable.

A 'game engine' is nothing more than a large library consisting of multiple sub-systems of reusable code. Various aspects of a video game such as computer graphics and sound are built upon low level APIs to ensure ease and development time decrease when it is used repeatedly.

The term is very vague I think. I am currently using the Direct3D 10 API to render 2D and 3D polygons for both my small 2D game and desktop physics application. I wouldn't call the my code a 'rendering engine/library' yet, though if I plan future programs using similar sub routines and classes, then I will simply group those parts of the code I wish to reuse into separate .lib files to form a 'game engine'.

See the problem is that, like chrisname pointed out, too many sites refer to development suites (kits) as game engines. It is no wonder it is so confusing to quite a few programmers.

@chrisname
Also, I like my monkey logic :P. Worked for me for 32 years now ;).

I don't think anybody should use a widely used game engine for commercial apps. I believe this way mainly because if you create a game with a tool that's widely used it increases the chance of your game being compromised and resources stolen without your consent.

I think that if you want to make a game engine don't use those such as FrostBite or stuff like that, but use a small, private engine somebody else made.

If not, I'd personally go through the task of creating my own game engine from scratch.

Anyone can go and steal your games resources off the filesystem or cd regardless of what engine you use to load and display them. Engines with large user-bases are actually going to be more stable and safe than those with small user-bases or home-rolled engines.

Fredbill30 wrote:
I don't think anybody should use a widely used game engine for commercial apps. I believe this way mainly because if you create a game with a tool that's widely used it increases the chance of your game being compromised and resources stolen without your consent.

err... huh?!? The engine != game resources. have you not paid any attention to this entire thread... I guess not, trolls don't need to read other peoples posts.

Fredbill30 wrote:
If not, I'd personally go through the task of creating my own game engine from scratch.

Yes, and if you were a plumber; would you create your own supplies and tools? There is a reason why people don't do that, its an inefficient idiotic idea.

I would call the game engine and all the tools and documentation and everything that comes with it a development kit.

Very fair point. (Not ignoring everything else you've said, just don't need to quote all of it.) Will keep that in mind, and I still want to emphasize the importance of an asset creation pipeline and being able to make the tools that would come with a GDK. But that's not the point of discussion, just something that is (under most circumstances) as important or more important than the game engine.

Yes, and if you were a plumber; would you create your own supplies and tools? There is a reason why people don't do that, its an inefficient idiotic idea.

We're not talking about plumbing, we're talking about games. We're not talking about a wrench, we're talking about the LHC. Overexaggeration, but the point is that a plumber's tools are not something that come with their own little quirks, they're not something that are incredibly complicated to use. A race car driver will know their car inside and out. A scientist working at the LHC will generally know just about everything there is to know about the LHC, because they all have to know. You should know too. You won't find a screwdriver that's acting funny, and you may find an occlusion algorithm acting funny because of how the engine does its task scheduling. You might not think of that as a possibility if you didn't work with your own engine, and if you didn't find that it's best to not instantiate new threads but continually have worker threads. That may be the model the engine uses, and so the latency of your occlusion may be a result of some other process taking up too much of a worker's time on a dual-core machine. Wouldn't think about that without asking the developers directly, or without making your own engine and realizing that this can be the case.

@NGen:
We're not talking about tweaking an engine or building a library over the years made from reusable code and then turned into an engine. My reply was on making an engine from scratch by yourself... You don't do that, its a waste of time; unless you are a team of developer making a new engine to outdo the current AAA games. But still... said engine would be catered to a game already in the works and probably an update of a previously used engine.

NGen wrote:
A race car driver will know their car inside and out

Yes, but he is not the one who built the engine. The car manufacturer he is representing did. Not even his own local mechanics will do that. All they will do is tweak it.

for example, I used XNA for making games in the past. I know XNA inside out, however I would never waste years rebuilding the XNA framework.

Oria I know but things such as code bits and stuff like that can be easily stolen (copywritten material sometimes) because of exploit tools that people have made from having access to big named game engines.

I don't know why people hate writing things from scratch anymore but I think it's pretty cool. Most likely because most days I have plenty of free time.

Oria I don't know why you're calling me a troll for stating my opinion, am I not subjected to that?

Notice how I used "I think" in my posts because I was almost certain my reply was only something I'd do.

Engines with large user-bases are actually going to be more stable and safe than those with small user-bases or home-rolled engines.

Obviously never used cryengine or crysis 1 multiplayer. Was a mess, plain editable text (was meant to make the game easily modifiable for modders) but ended up letting anyone mod the original game and there happened to be a network exploit as well. Could change a property somewhere and make any gun freeze players upon hitting them (or something like that...).

I believe this way mainly because if you create a game with a tool that's widely used it increases the chance of your game being compromised and resources stolen without your consent.

Maybe on PC but on console it is a different story, there are checksums and such to make sure content isn't modified. Most console games also don't have tools released with them. What happens is people read the assembly and reverse engineer the content structure. All you can do is make it harder for someone to do so. Doesn't really matter who's engine you use, if someone wants to get the data and knows how, there isn't really any stopping them.

I mean for PC. I'd just not feel comfortable making my copywritten contents exposed to the entire world. Lol.

We're not talking about tweaking an engine or building a library over the years made from reusable code and then turned into an engine.

That's not what I was talking about either.

Yes, but he is not the one who built the engine. The car manufacturer he is representing did. Not even his own local mechanics will do that. All they will do is tweak it. for example, I used XNA for making games in the past. I know XNA inside out, however I would never waste years rebuilding the XNA framework.

Alright, that's your call. There are still things to be learned by building it yourself, and thus there are benefits. Practically speaking there are few areas where a custom-made engine would be beneficial, I agree there. If we're talking about personal projects, then I see no reason to not make some projects while developing your own engine and also making some projects with a different one.

^ You spoke my mind.

^ and you just spoke mine

There are still things to be learned by building it yourself, and thus there are benefits. Practically speaking there are few areas where a custom-made engine would be beneficial, I agree there. If we're talking about personal projects, then I see no reason to not make some projects while developing your own engine and also making some projects with a different one.

Definitely there is a lot of things you can learn from building your own Engines yourself and they can be a great learning experience, but only if you are ready for that learning experience.

I just wanna stress it again that yes building a engine will be a beneficial experience but you need to have some experience before you do so. You don't want to start building a game engine without knowing what goes into one, or else it will turn out badly.

Using the race car analogy, would you go out and build yourself a race car without having any experience with standard cars first? Probably not. It is just the same with Game Engines (At least my definition of them).

In order to build a Engine that is useful to more then one game or useful even for one game you should know what goes into a game first. You should have experience building a game first or else you are going in blind.

In order to build a Engine that is useful to more then one game or useful even for one game you should know what goes into a game first. You should have experience building a game first or else you are going in blind.

Definitely agree. I'm planning on taking a chunk out of this summer to get a better look around the game engines/GDKs that are available specifically for this purpose.

I would just like to reiterate that I never did mention building a game engine, I was just asking about building a game with an engine, I wanted to know about experiences using them to build games.

In order to build a Engine that is useful to more then one game or useful even for one game you should know what goes into a game first. You should have experience building a game first or else you are going in blind.

I also agree on that, though you should also know your game's specific needs, otherwise you will turn out with a collection of jumbled subroutines which don't seem to fit together. I believe you should not try to built a full on multipurpose engine for the sake of it, that is the mistake of a lot of beginners.
Only focus on your games needs for the time being.

Planning the engine's architecture takes time as well, what I do is write out the whole structure on a piece of paper, figuring out how the rendering pipeline will be structured (vertex buffers, pixel buffers, shaders ect.), and other subsystems such as sound, physics and AI.

If you are planning on building an engine from scratch, build it alongside a game!!!

One other advantage of building a game engine other than using another one is if you find a bug in the engine, it is easier to iron out the bug with your own than one you do not know the ins and outs of.

I have used the Irrlicht game engine before, and it is nice and stable, suited my purpose. Unless you are making an engine for something like learning experience, if there is already an engine out their that fulfils your needs, use that...it saves a bunch of time and you can actually focus on writing the game.

Montario79 wrote:
I also agree on that, though you should also know your game's specific needs, otherwise you will turn out with a collection of jumbled subroutines which don't seem to fit together. I believe you should not try to built a full on multipurpose engine for the sake of it, that is the mistake of a lot of beginners.

I know exactly what you mean, I did the same thing when I wanted to make a RPG as a FIRST game. (Lol fail, right?) I made lots of failed attempts at projects. (Not really fails... I guess I over written code, it got buggy so I lost interest trying to fix it. Either that or I gotten a better game idea and started all over again... :P) Slowly over time I've written tile maps, enemy systems, doors, a simple command parser that read from text files, (It was messy basically a buch of if statements) and a simple server in winsock.

Now I am making an all new RPG (That most likely will be dropped) that takes new approaches to problems. I'm also working on making my code more powerful and efficient.

Now I've learned better ways to handle things. For example now my game loads maps from map files dynamically with a vector. (I'm starting to really LOVE dynamic memory now :D.... Arrays are inferior to vectors IMO.) I've also written down ideas on sheets of paper, carefully planning them out.
Next I'm thinking of (Almost certainly) creating a resource manager to handle sprites, fonts, text file analyzing, etc.

I personally prefer custom engines I hand write. I just love programming them. Writing game engines are like drugs. I can't stop them. (Just finding new ways to tackle problems excite me.

Fredbill30 wrote:
(I'm starting to really LOVE dynamic memory now :D.... Arrays are inferior to vectors IMO.)

using vector != using dynamic memory

What the vector actually uses is dependent on the allocator class passed to it.

In any case using dynamic memory in a game can make it slow, it really depends on what you are doing with it though, ie using it to load a map won't really have that big of an impact.