- Forum
- Lounge
- Game Engines
- Page 3
Game Engines
closed account (N36fSL3A)
Obviously I know how to program.
But I was taking it as you can write a game with no engine as in the engine is non existent in the game. I hope you can understand what I'm saying. I didn't take it as you can just use a pre-made.
But I was taking it as you can write a game with no engine as in the engine is non existent in the game. I hope you can understand what I'm saying. I didn't take it as you can just use a pre-made.
Right so your saying that the code you write to make a game inherently becomes the game engine? Even if none of it is reusable.
| Zereo wrote: |
|---|
| Sigh again... I guess I'm typing in gibberish lol |
Sorry, didn't realize you were still discussing form the stance of "Make a game not an engine". Thought you had changed to arguing if you even had to write an engine in regards to all the ones that are available to use for free out there.
closed account (3qX21hU5)
| But I was taking it as you can write a game with no engine as in the engine is non existent in the game. I hope you can understand what I'm saying. |
That is exactly what I said and meant.
| I didn't take it as you can just use a pre-made. |
And once again no that is not what I meant. Or even said.
You seriously need to look up what a Game Engine is. A game engine is not the specific parts that make up a game as you seem to think it is. It is a TOOL that can be used to make game development easier, but it doesn't have to be used. It is a separate program from the game they are not the same thing.
Last edited on
closed account (N36fSL3A)
oh. I though it was the logic handling and rendering and such as that. Thanks for clearing that up.
| Fredbill30 wrote: |
|---|
| oh. I though it was the logic handling and rendering and such as that. Thanks for clearing that up. |
Well thinking it out for a minute would make you realize that was wrong. If it was the logic handling and rendering (drawing or printing to the screen) then a calculator would have an engine as that describes basically every program you code that actually does anything significant.
No reason to feel dumb. The whole point of getting smarter and learning is to pay attention to those who have been doing this a long time. That and to understand what they are trying to tell you. You will learn a lot more and be corrected on a lot more as you get older.
| The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph. |
| Generally though, the concept of a game engine is fairly simple: it exists to abstract the (sometime platform-dependent) details of doing common game-related tasks, like rendering, physics, and input, so that developers (artists, designers, scripters and, yes, even other programmers) can focus on the details that make their games unique. |
@Zereo, BHXSpecter
No.
@Fredbill30
Don't feel dumb, you were right.
A game engine is not a thing. "Game engine" is just a term used to describe some of the components of a game---namely, everything aside from the game logic (see drew887's quote for specifics). You can write a game without an engine: it's called "poor design", it happens when you forget to properly separate the game's components. If you write a game with properly-separated components, and then you take out the one that makes fun happen (the core game logic), you have a game engine. If you put the "fun module" back, you have a game. That's it. That's the line of demarcation. A game and its engine don't run in parallel as separate programs as Zereo seems to be suggesting, although a game engine could be a program by itself, loading the game logic as a library, but the opposite (i.e. the game loads the engine as a library) is more common, and it's also common for them to be a single file with no explicit separation (this isn't necessarily poor design: the game engine code and game logic may still be separate, just not explicitly so). Nor is a game engine a tool. A map editor is a tool. A 3D modeller is a tool. A texturing program is a tool. A game engine is not a tool. I think Zereo is confused because prefab game engines usually come with tools that assist you in creating a game. In that context, "game engine" is a misnomer: that should be referred to as a game development kit (and in fact it properly is referred to as such: hence, Unreal Development Kit). Those aren't game engines; those include game engines as well as a series of tools for developing games using the included engine.
What kind of monkey logic is this? A calculator has an engine, just not a game engine because it's not a game. What is a calculator? It's a program that reads a mathematical expression from a user, parses and evaluates it, and then displays the result. We can split this into two components: a user-interface and a mathematical expression evaluator. I'd call it an evaluator but you can call it "calculator engine" if you want.
No.
@Fredbill30
Don't feel dumb, you were right.
A game engine is not a thing. "Game engine" is just a term used to describe some of the components of a game---namely, everything aside from the game logic (see drew887's quote for specifics). You can write a game without an engine: it's called "poor design", it happens when you forget to properly separate the game's components. If you write a game with properly-separated components, and then you take out the one that makes fun happen (the core game logic), you have a game engine. If you put the "fun module" back, you have a game. That's it. That's the line of demarcation. A game and its engine don't run in parallel as separate programs as Zereo seems to be suggesting, although a game engine could be a program by itself, loading the game logic as a library, but the opposite (i.e. the game loads the engine as a library) is more common, and it's also common for them to be a single file with no explicit separation (this isn't necessarily poor design: the game engine code and game logic may still be separate, just not explicitly so). Nor is a game engine a tool. A map editor is a tool. A 3D modeller is a tool. A texturing program is a tool. A game engine is not a tool. I think Zereo is confused because prefab game engines usually come with tools that assist you in creating a game. In that context, "game engine" is a misnomer: that should be referred to as a game development kit (and in fact it properly is referred to as such: hence, Unreal Development Kit). Those aren't game engines; those include game engines as well as a series of tools for developing games using the included engine.
| BHXSpecter wrote: |
|---|
| If it was the logic handling and rendering (drawing or printing to the screen) then a calculator would have an engine as that describes basically every program you code that actually does anything significant. |
What kind of monkey logic is this? A calculator has an engine, just not a game engine because it's not a game. What is a calculator? It's a program that reads a mathematical expression from a user, parses and evaluates it, and then displays the result. We can split this into two components: a user-interface and a mathematical expression evaluator. I'd call it an evaluator but you can call it "calculator engine" if you want.
@chrisname
I'm just saying what I had been told for a few years now. Probably why I have had so much trouble programming games, was thinking of it in the wrong terms.
I'm just saying what I had been told for a few years now. Probably why I have had so much trouble programming games, was thinking of it in the wrong terms.
Okay good, reading this post was making me think that everything I learned in school about game design was wrong xD
It all depends on what you call an "engine". I generally think of it as a fairly high level library of sorts that does much of the "dirty work" of a game, but is generic enough that many different kinds of games can be created using it. With that definition, games themselves wouldn't be considered engines. However, if you define an engine as something less inclusive, such as a "renderer", then almost every game could be considered to have an engine. You both are right in your own contexts, but wrong in each others' contexts.
@ModShop
That's what I call an engine too, but I don't think it has to be explicitly separate from the game logic (i.e. in separate modules (library and executable) or even just separate namespaces). A well designed game will most likely have a game engine by virtue of being designed well: there will be some amount of separation, be it at the class, namespace, file or directory level, or even as separate codebases. Zereo stated that a game engine was an entirely separate program from the game itself, when in reality they're usually a program and a library (or collection of libraries depending on how obsessed the designer is with "modularity") or even a single program. Having the game and game engine as separate programs would be exceedingly inefficient because you would have to use a lot of IPC. The fastest way would be to use shared memory which would likely be equivalent in performance to using a single process with multiple threads: better than using other forms of IPC, but still slower than having a single thread because of the synchronisation primitives you would need to use to prevent race conditions and other problems inherent to using shared mutable data in parallel execution.
That's what I call an engine too, but I don't think it has to be explicitly separate from the game logic (i.e. in separate modules (library and executable) or even just separate namespaces). A well designed game will most likely have a game engine by virtue of being designed well: there will be some amount of separation, be it at the class, namespace, file or directory level, or even as separate codebases. Zereo stated that a game engine was an entirely separate program from the game itself, when in reality they're usually a program and a library (or collection of libraries depending on how obsessed the designer is with "modularity") or even a single program. Having the game and game engine as separate programs would be exceedingly inefficient because you would have to use a lot of IPC. The fastest way would be to use shared memory which would likely be equivalent in performance to using a single process with multiple threads: better than using other forms of IPC, but still slower than having a single thread because of the synchronisation primitives you would need to use to prevent race conditions and other problems inherent to using shared mutable data in parallel execution.
Last edited on
Unless your game is entirely procedural, you will end up making an "engine".
I constitute an engine as a complete solution of various software tools defining an asset pipeline for content design, in conjunction with various libraries that trivialize basic game functionality (collision detection, object management, etc.). Things such as level editors, audio asset management tools (i.e. DirectX's XACT tool), behavior tree editors, debugging tools/libraries (not just step-through/break-points/stack frame), quest designers, and others, all come together with your game code to make a full engine.
What's been described here are frameworks. XNA is in that group. libpng, SFML, OpenAL, and other libraries come to make your framework. You can make a game without an engine and just through a framework. It's not going to be fun unless you're working entirely with procedural content generation. Once you start adding your own tools to speed up your development process, you're building an engine, regardless of how those tools are linked to each other.
If you're a programmer, you'll love just working with a framework and maybe a level editor. As soon as you throw other people into the mix, you'll want to get some sort of engine tied together. You're not going to successfully work with an artist if they want to try out their art and can't unless you manually implement it. If your game is even remotely complicated, they won't be able to just replace the file that the game accesses. Game objects will most likely have custom bounding shapes that must be updated to match the sprite on an individual basis. I worked on a team and tried just having artists ask me to implement sprites, and it worked, but none of them liked the pipeline and I got a lot of crap for it. Made a tool that allowed them to overload assets and their properties and everyone was happy.
Make a framework if you're on your own. Otherwise, you'll need an engine.
I constitute an engine as a complete solution of various software tools defining an asset pipeline for content design, in conjunction with various libraries that trivialize basic game functionality (collision detection, object management, etc.). Things such as level editors, audio asset management tools (i.e. DirectX's XACT tool), behavior tree editors, debugging tools/libraries (not just step-through/break-points/stack frame), quest designers, and others, all come together with your game code to make a full engine.
What's been described here are frameworks. XNA is in that group. libpng, SFML, OpenAL, and other libraries come to make your framework. You can make a game without an engine and just through a framework. It's not going to be fun unless you're working entirely with procedural content generation. Once you start adding your own tools to speed up your development process, you're building an engine, regardless of how those tools are linked to each other.
If you're a programmer, you'll love just working with a framework and maybe a level editor. As soon as you throw other people into the mix, you'll want to get some sort of engine tied together. You're not going to successfully work with an artist if they want to try out their art and can't unless you manually implement it. If your game is even remotely complicated, they won't be able to just replace the file that the game accesses. Game objects will most likely have custom bounding shapes that must be updated to match the sprite on an individual basis. I worked on a team and tried just having artists ask me to implement sprites, and it worked, but none of them liked the pipeline and I got a lot of crap for it. Made a tool that allowed them to overload assets and their properties and everyone was happy.
Make a framework if you're on your own. Otherwise, you'll need an engine.
Unless I'm misunderstanding you, you're saying that the tools that come with a game engine are part of the game engine itself? I disagree. I would call the game engine and all the tools and documentation and everything that comes with it a development kit. For example, UDK (Unreal Development Kit) is a development kit which includes the Unreal Engine as well as a variety of tools, documentation, etc. The whole package is not called Unreal Engine because it's not Unreal Engine, it's Unreal Development Kit, of which the Unreal Engine is a component. Another example would be the Valve Source SDK (Source Software Development Kit). You might bring up Unity3D because Unity is usually referred to as "Unity game engine", but the first sentence on their website is "Unity is a game development ecosystem". Not a game engine. A "game development ecosystem". In other virtually the same words, a game development kit. Calling a game development kit a game engine is like calling Windows a kernel. There is a Windows kernel, but Windows is an operating system of which the Windows kernel is a part (namely, the kernel). Besides, the tools can't be part of the game engine because they include the game engine as a library, thus the game engine is part of the tools. A set can't be a proper subset of a proper subset of itself, therefore the tools can't be part of the game engine if the game engine is part of the tools. The game engine is part of the tools (the tools use it as a library), therefore the tools can't be part of the game engine. Using Windows as an example again, to state the contrary would be analogous to saying Windows was part of the Windows kernel, when in fact the Windows kernel is part of Windows.
Last edited on