• Create Account

Banner advertising on our site currently available from just $5! # Game Engine or not? Old topic! Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic. 103 replies to this topic ### #1Joe P Members - Reputation: 166 Like 0Likes Like Posted 13 May 2011 - 08:25 AM Hey guys, So Ive been reading about game engines lately, and Im kind of confused about them. My approach to programming has always been to use the least amount of abstraction libraries as possible without sacraficing too much time for complexity (I wouldnt do a game in x86 assembly ) So what exactly does a typical game engine do for you?? Does it basically do common game tasks for you such as collision detection and AI? If so, how can someone learn how to truly program games by using one? Maybe I am thinking that they do way more for you than they really do.. I have been using C++/SDL lately and for me it is the perfect library because it gets rid of the really low level stuff, but allows me to really get into the code and learn about whate happening. There are no magic functions that solve problems for me. So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? I mean I know there are programs like Game Maker where pretty much anyone can make a game with, so where does the abstraction stop?? Where does a programmer put him/her self and say "this is the level I want to be developing my games at, this is how much help I want from the API"? I mean, if programs like Game Maker exist, whats stopping anyone from making some awesome game with almost no programming experience? Im really not familiar with these sort of programs but the wiki for Game Maker says it allows someone to make a game with no programming experience. If thats the case, there must be limitations on these sort of engines and prgrams right?? Never, ever stop learning. - Me Sponsor: ### #2donkey breath Members - Reputation: 206 Like 0Likes Like Posted 13 May 2011 - 08:37 AM GameMaker will get you so far but it is a general library. game engines are there to give a solid foundation to build your own game. There are many differences between the engines (cross platform, scripting, etc). Basically a game engine takes care of the fundamental (networking, inputs, etc) but you can build upon these or take them as they are. Major differences are some engines give you source code so you can get right into the code, others (like Unity) you get no source access so the scripting is the only control you have. If the scripting doesn't have access to an API that you need, tough. There will be posts to this that will expand, or correct what I have said, but the general issue is that to build a game from nothing on your own will take a lot of time as there are so many elements for you to learn and develop. Game engines simply give you a base to use the core functionality or build from it. ### #3Joe P Members - Reputation: 166 Like 0Likes Like Posted 13 May 2011 - 08:58 AM I looked at Unity, theres basically no true code at all.. only scripting like you said. There must be a downside to using a tool like this right?? I mean there are SO many kids who say "I wanna make an awesome MMORPG but I dont know programming". If things like this exist, what is the incentive for these kids to learn something so deep and complex as C++? I mean, I know I love programming in general, so using real languages and doing stuff from the bottom up is exciting for me. I enjoy learning whats happening on the lower level. So your saying that these sort of engines and programs exist because doing it on your own from scratch takes too long... if thats the case why isnt every developer using these tools? I mean, if your goal is simply to make a cool game and possibly get others to play it, and you dont really care about whats going on in the code, where is the incentive to sweat through learning opengl and sdl when you could drag and drop some stuff and script and basically make a game equivalent to someone who wrote a million lines of C++ code to achieve the same thing? I just watched a video on youtube for unity3d, and in the second tutorial in a series, this guy has a full on jungle environment that looks awesome, something that would take alot of work coding from scratch. Never, ever stop learning. - Me ### #4Radikalizm Crossbones+ - Reputation: 3098 Like 0Likes Like Posted 13 May 2011 - 08:59 AM I wouldn't confuse programs like gamemaker with actual engines, engines can be considered as libraries which contain a frequently used set of functions so you don't have to worry about these yourself while working on a game project (this can be at a very low level, or at a very high level, depending on what the engine was designed for) while gamemaker is more of a toy providing a drag & drop interface for creating rather generic games The philosophy behind engines is that it would be a waste of time to rewrite low-level stuff you already coded in a previous project when starting a new one, so why not bundle your reusable code together in a library? About the amount of abstraction engines provide, you have to keep in mind that not all engines are the same, there's almost a direct relationship between the amount of abstraction an engine provides and its flexibility, a general-purpose engine could support a wide range of genres resulting in leaving a lot genre-specific implementations up to the client, while a genre-specific engine could provide all functions needed so the client doesn't have to worry about anything else than the game implementation itself In the end, if you feel that you can maintain a good productivity by using SDL, then by all means keep on using it, you don't need an actual game engine to write games, nor should you worry about engines until you find yourself in a situation where you are doing more projects on a larger scale, when you reach that point it'll just be a matter of finding the right tool (since engines really just are tools) for the job, or rolling your own I gets all your texture budgets! ### #5Telastyn Crossbones+ - Reputation: 3754 Like 1Likes Like Posted 13 May 2011 - 09:01 AM My approach to programming has always been to use the least amount of abstraction libraries as possible without sacraficing too much time for complexity (I wouldnt do a game in x86 assembly ) Game engines mostly aren't abstractions, and where they are they're implementing the abstractions that you'll need to do to be productive anyways. So what exactly does a typical game engine do for you?? Does it basically do common game tasks for you such as collision detection and AI? If so, how can someone learn how to truly program games by using one? How can someone truly write games if they spend all their time reinventing the wheel? So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? No. Knowing what is happening is overrated. I mean I know there are programs like Game Maker where pretty much anyone can make a game with, so where does the abstraction stop?? Where does a programmer put him/her self and say "this is the level I want to be developing my games at, this is how much help I want from the API"? A good programmer wants all the help they can get from APIs. The less code you write, the less time it takes, the less debugging you need to do, the less maintenance. I mean, if programs like Game Maker exist, whats stopping anyone from making some awesome game with almost no programming experience? Im really not familiar with these sort of programs but the wiki for Game Maker says it allows someone to make a game with no programming experience. If thats the case, there must be limitations on these sort of engines and prgrams right?? Absolutely. Programs like these can never satisfy every scenario/requirement. Or satisfy them better than alternatives. Same with APIs. Sometimes the abstractions prevent you from doing cool tricks that are required to get what you want. But the approach isn't 'learn cool tricks, then use the API', it's 'use the API until you can't do what you need to do easily'. ### #6NEXUSKill Members - Reputation: 470 Like 1Likes Like Posted 13 May 2011 - 09:04 AM A game engine takes care (or is supposed to) of those things that all games would need in order to work, a rendering system, a resource pipeline, input handling, network communications framework, sound system, graphic user interfaces, and so on, strictly speaking programming a game consist more or less on implementing the flow that defines when and how this things are used, rather than the functionality itself. In this sense, programming a game presents its own sets of problems, challenges and tasks without even digging deep into the inner workings of the engine. Its always good to know how the lower levels work, but usually programming an engine without having programmed a game first is like trying to make a wheel without knowing what you're gonna use it for, people carried stuff around long before they realized the wheel makes that easier, in this way, the problem must come before the solution. Game making is godlike LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272 ### #7Joe P Members - Reputation: 166 Like 0Likes Like Posted 13 May 2011 - 09:11 AM So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? No. Knowing what is happening is overrated. This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing. So you would recommend that a new programmer whos never made games before to use the highest level engine possible to make a game, and not at all concern themselves with anything that they dont need to in order to finish the game? Never, ever stop learning. - Me ### #8TheTroll Members - Reputation: 883 Like 0Likes Like Posted 13 May 2011 - 09:33 AM A lot of it depends on your goal. Are you trying to learn or just trying to make a game? If you want to learn, then going low level is what ya want to do. You want to learn the hows and whys of doing things. If you just want to make a game you can often ignore much of the lower level stuff and use libraries that can help you. XNA and others do much of the work and let you worry more about game play and the likes then about translations and buffers. ### #9donkey breath Members - Reputation: 206 Like 1Likes Like Posted 13 May 2011 - 09:36 AM Game engines provide libraries that give a solid (in most cases) set of code. It is probable that this is tested and therefore you don't have to worry about the possibility of bugs 9or that is the theory). Scripting engines make it easy to get a game up and running using minimum effort. However you are stuck with thier code (unless you have source). People will use these engines because it gets them to where they want to go quickly. Others will build thier own engines as they want to have a clean pipeline that is built around thier needs (e.g. trying to get a FPS engine to make a RPG is not that efficient) and is efficient. one example would be an artist who wants to get a demo up and running, they would use a game engine, 99% of the time it would be Unity.... What you have to remember is it is easy to spot a game by the engine used as the rendering is the same, in my opinion. ### #10Telastyn Crossbones+ - Reputation: 3754 Like 2Likes Like Posted 13 May 2011 - 09:42 AM This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing. After spending many years playing around with low level details and not getting anything actually done, yeah. Knowing the gist of how things work is good enough for pretty much everything. I don't particularly care about the mechanics of buffering and decoding video if I just want to play one. I want an API that reduces all that headache to 1-2 lines of code so I can go back to making the game. So you would recommend that a new programmer whos never made games before to use the highest level engine possible to make a game, and not at all concern themselves with anything that they dont need to in order to finish the game? I recommend that a new programmer not make games. Learn to program first. If your short term goal is to make a game, use the most/best APIs/tools to accomplish that goal. If your short term goal is to learn to program, then some portion of that will involve mucking about in low level stuff to get used to debugging things there and get a better understanding about buffers, bit fiddling, pointers, implementing your own algorithms/data structures and the such. But all of that code should be throw away. It should be focused on gaining knowledge and experience, and once done a programmer should pretty much avoid doing any of it again. ### #11donkey breath Members - Reputation: 206 Like 0Likes Like Posted 13 May 2011 - 09:44 AM Essentially, use the right tools for the job ### #12Burnt_Fyr Members - Reputation: 1331 Like 3Likes Like Posted 13 May 2011 - 09:46 AM So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? No. Knowing what is happening is overrated. This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing. So you would recommend that a new programmer whos never made games before to use the highest level engine possible to make a game, and not at all concern themselves with anything that they dont need to in order to finish the game? Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating? Something I struggled with for a long time(and still do to some extent) is that 'why' is more important than 'how'. ### #13donkey breath Members - Reputation: 206 Like 1Likes Like Posted 13 May 2011 - 09:51 AM Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating? As a programmer, it is your job to know how it works. I am not a microwave technician or car mechanic but if I was and came to fix your microwave or car wouldn't you want me to know how it works? That way if it is a problem out of the ordinary I would have a much better chance to fix it. Would you drive a car fixed by someone why it needs fixed, but not how? You would quickly find yourself becoming an unemployed programmer/mechanic/engineer if you only knew why but not how. Nobody would hire you. Try using that analogy you gave in an interview and see how it goes, I suspect not very far. ### #14TheTroll Members - Reputation: 883 Like 0Likes Like Posted 13 May 2011 - 09:51 AM Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating? Something I struggled with for a long time(and still do to some extent) is that 'why' is more important than 'how'. Not really the best examples, because I know how all three work, and I have had to fix all of them. Without knowing how they work I could have never fixed them. But I guess the same might be said libraries, if it works and does what you need it to, you don't really have to understand HOW it works. When it doesn't work or you need more, then you need to start working on the how. ### #15Joe P Members - Reputation: 166 Like 1Likes Like Posted 13 May 2011 - 09:58 AM A lot of it depends on your goal. Are you trying to learn or just trying to make a game? If you want to learn, then going low level is what ya want to do. You want to learn the hows and whys of doing things. If you just want to make a game you can often ignore much of the lower level stuff and use libraries that can help you. XNA and others do much of the work and let you worry more about game play and the likes then about translations and buffers. Well Im a computer science major.. so naturally I just have a desire to know whats happening. After programming in assembly and C, I have a great appreciation for knowing whats happening underneath the abstraction. I dont plan to work in the game industry, I just want to do it independently and as a hobby. I just see so much talk about libraries like XNA and all that lately, I was under the impression that nobody does things with libraries like SDL and OpenGL anymore. I mean sure I want to make games, but I want to do it in a way that I learn whats happening and truly understand whats going on. Im not just concerned about "getting it done", I want to truly be knowledgeable and very good at it, Never, ever stop learning. - Me ### #16Joe P Members - Reputation: 166 Like 0Likes Like Posted 13 May 2011 - 10:01 AM Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating? As a programmer, it is your job to know how it works. I am not a microwave technician or car mechanic but if I was and came to fix your microwave or car wouldn't you want me to know how it works? That way if it is a problem out of the ordinary I would have a much better chance to fix it. Would you drive a car fixed by someone why it needs fixed, but not how? You would quickly find yourself becoming an unemployed programmer/mechanic/engineer if you only knew why but not how. Nobody would hire you. Try using that analogy you gave in an interview and see how it goes, I suspect not very far. Exactly.. Im a programmer. This is my life... why the hell would I just want to brush off the details? Im interested in this stuff, and seeing that it will be my career, I feel like I should really be an expert on it. saying that how stuff works doesn't matter just seems like a total cop out to me... Sure I dont know exactly how a microwave works, but Im not a microwave technician. I am a programmer though.. Never, ever stop learning. - Me ### #17Sunda Members - Reputation: 334 Like 0Likes Like Posted 13 May 2011 - 10:27 AM So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? No. Knowing what is happening is overrated. Imagine this. What about an artist who just wants to paint, but he doesn't know anything about painting, techniques, perspective, colors, etc. Then he starts to grab some others artists drawings and start to copy them without even complaining HOW they did it. Will he ever archive his goal?. Knowing the basics is not reinventing the wheel but if you know how and why a wheel was invented, you'll expand your horizon. You wrote that because you already know what's happening in the low level. ### #18Joe P Members - Reputation: 166 Like 1Likes Like Posted 13 May 2011 - 10:39 AM So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? No. Knowing what is happening is overrated. Imagine this. What about an artist who just wants to paint, but he doesn't know anything about painting, techniques, perspective, colors, etc. Then he starts to grab some others artists drawings and start to copy them without even complaining HOW they did it. Will he ever archive his goal?. Knowing the basics is not reinventing the wheel but if you know how and why a wheel was invented, you'll expand your horizon. You wrote that because you already know what's happening in the low level. Im glad that you and others are saying this. For second I thought just maybe I was crazy for having a desire to know how everything is working. I mean I guess I can understand if youre just a person who wants to make a game but isnt really concerned with being a true programmer you can sort of ignore a lot of things. But I cant imagine any programmer, especially the ones I know, who would brush off the low level details and not care to know whats going on. Most of the programmers I know are really into what they do, and are perfectionists... they want to understand the ins and outs of their craft. Never, ever stop learning. - Me ### #19JBourrie Members - Reputation: 1204 Like 1Likes Like Posted 13 May 2011 - 11:27 AM So your saying that these sort of engines and programs exist because doing it on your own from scratch takes too long... if thats the case why isnt every developer using these tools? I mean, if your goal is simply to make a cool game and possibly get others to play it, and you dont really care about whats going on in the code, where is the incentive to sweat through learning opengl and sdl when you could drag and drop some stuff and script and basically make a game equivalent to someone who wrote a million lines of C++ code to achieve the same thing? I just watched a video on youtube for unity3d, and in the second tutorial in a series, this guy has a full on jungle environment that looks awesome, something that would take alot of work coding from scratch. There's a number of reasons I can think of, and most of them are biased toward my belief that we should be using middleware for most games: - Because the business side often equates "owning our tech" with "owning our game". They think that for some reason if they don't build the whole thing from scratch, they are beholden to some other company. Save a few special cases, this is not actually the case. But I've had alot of trouble convincing "the suits" that paying$250k for an engine license is more valuable than putting that money (and then some) toward building an engine from scratch, debugging it, testing it, writing the tools, delaying development until it's finished... and in the end, most off-the-shelf engines have better tools anyway.

- Because programmers like to reinvent the wheel. They're often the type that say "well, I didn't create that wheel so I don't really know how it works. Therefore I don't trust it and I will create a new wheel that does the same thing... only my way". I thought this way myself for many years. Then I learned that what I really want to do is understand why the wheel works so I can make a better vehicle to use it. "Knowing what is happening is overrated" is a patently ridiculous response for a programmer, but "Knowing what is happening" is different than "Writing it myself". I find it equally ridiculous to go in and write the tech for a standard third-person shooter nowadays: between Unity, Unreal, Source, Torque, etc there is a solution at every price point.

- Because some programmers are fearful for their future employment. I hope nobody gets defensive about this answer: not every programmer is this way. But some are. They're afraid that if development and scripting is so easy a designer can do it, that programmers become obsolete. This is also ridiculous: if designers/artists can do the standard stuff, then programmers are free to do the groundbreaking, awesome stuff. Instead they spend so much time rewriting the same damn pathfinding algorithm or rendering pipeline that they don't have time to really experiment.

- Because sometimes a game is so unique, it would be harder to write it with existing tools than to just roll your own. This is rare (I actually wish it were more common), but in my opinion it is the only valid reason to not use middleware. Katamari Damacy, for example, needed to be able to do complex LoD and streaming not based on distance but instead based on the size of the character. It needed to be optimized to display hundreds of low-fi models instead of a few hi-fi ones. The physics required a dynamically re-shaping ball. It was a game that they were better off writing their own engine for, or at least heavily modifying pre-existing tech.

In short, if you want a first-person shooter in a jungle environment, and you write it from scratch, I would argue that you're not using the right tools. Middleware shouldn't be looked at as a way to replace programmers. It should be a way to empower them to innovate: a way to take away the drudgery of writing their 20th octree optimization and instead focus on coming up with new technologies that will make future games better.

Check out my new game Smash and Dash at:

### #20phantom  Moderators   -  Reputation: 8266

Like
1Likes
Like

Posted 13 May 2011 - 12:47 PM

Ugh... "true programmer"... a phrase which rings of elitest BS to me.

There is no such thing as a 'true programmer'; you just get programmers who care about different levels of abstraction based on their level of intrest.

Not every one who programs cares about even low level detail, they do what they want to get to their goals; someone who takes Unity and builds a game is no less a 'true programmer' than someone who decides to spend years trying to build one from the ground up. They both have different goals is all.

I agree that 'knowing what happens' is over rated. It can be a useful skill to have but I wouldn't say it was a hard and fast requirement. For example a large chunk of the programming team on the project I was on at work have practically no idea how the graphics system works and a large chunk probably have no idea how to do graphics at all. Does that stop them doing their job? No. They trust that those of us who need to know how these things work will do our job so they have the tools they want.

Take myself for example; my focus is graphics and high performance technologies which means I've spent alot of time figuring out how to optimally perform graphics tasks with the APIs, understanding how GPU hardware works, understanding how low level CPU hardware (cache, memory access, LHS, etc) affects runtime performance and how to program around it and, because it's a major feature of our work going forward, I have a very strong background in threading and task based systems. However, if I wanted to do say some networking I'd go dig out a library which is recommended by someone and not give a damn about what it does; if it works then I'm happy and that's all I care about. Same goes for audio coding; if I want audio in a game then I'll go and grab a library and be done with it, I don't care how it does what it does.

Frankly knowing everything is impossible, or at least knowing it and being useful in it. Most of my advanced knowledge in the various subject matters comes because I've been doing these various things for about 15 years now in various ways.

However, when I started off do you know what I started with? BASIC. STOS BASIC on the Atari ST infact which was a game specific version of the programming language. At that time (mid-90s) it would be the same as using Unity now and I know a few people who made games in it and even released them commerically. The only reason I didn't was because I was more intrested in the lower level side of things but that was just my intrest and didn't make me any more of a 'true programmer'.

I think, also, you underestimate the volume of people out there using the various engines which have been released and not giving a damn about what goes on under the hood. Unity and UDK have A LOT of users and various games have been cranked out by various people using them.

So, if you want to make a game the best thing you can do right now is grab an existing bit of tech and get on with it.
If you want to write tech well the great thing is no one is stopping you but don't think for one minute that you are any sort of elevated programmer for it; chances are while you are solving some problems with your tinkering those making games are solving problems which are just as hard, if not more so, while making their games.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS