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??
Game Engine or not?
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.
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.
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.
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.
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
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
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?
[/quote]
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?
[/quote]
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"?
[/quote]
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??
[/quote]
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'.
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.
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.
[color=#1C2837][size=2][color=#2B3730][size=2]Quote
[size=2][size=2]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. "
[color=#1C2837][size=2]
[color=#1C2837][size=2]
[color=#1C2837][size=2]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.
[size=2][size=2]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. "
[color=#1C2837][size=2]
[color=#1C2837][size=2]
[color=#1C2837][size=2]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.
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
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.
[/quote][/quote]
[color="#1C2837"]
[color="#1C2837"]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.
[color="#1C2837"][color="#1C2837"]
[color="#1C2837"][color="#1C2837"]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?
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement