I'm just wondering what XNA is missing to be considered as a game engine? It does all the things a game engine should do (except the physics part); it also has support for every aspect defined on wikipedia's article on game engines.
It is designed as a framework - in fact, XNA is the Microsoft XNA Framework - so technically it's not an engine by name.
There is no 'engine' - if you notice, you derive your main class from XNA.Framework.Game and have to override the draw and update functions yourself. There is no central rendering system, or input system, or audio system ready out of the box. There is SpriteBatch and the vertex classes, there is KeyboardState, and there are some audio classes..but they are only abstractions over the low level drawing code.
EDIT: For the sake of usefulness, why does something matter if it's labelled as an engine, framework, library, or toolset?
To clear things up somewhat: I am developing an engine in XNA. Obviously I can't do that in something like Unreal, like Jonathan has mentioned. However, there are a few things I feel are important that XNA just doesn't have:
Plug-n-play: I want to be able to make some kind of template - have this HP, this mesh, this animation and BOOM! I have an NPC in my game.
Hidden low level - XNA does this already, but I don't want to fiddle around with GameServiceProviders. I just want to shove stuff together.
Game separated from engine - There may be a 'game' class, but I want to separate my logic and my code from the base system. I don't want
|show 4 more comments|
I’ve never used a ‘game engine’ but my understanding of this is more as a pre-defined set of tools bundled with a pre-defined skeletal game-structure for the development of a specific type of game. And surely that structure for the development of a specific type of game is the main defining factor in a games engine, it certainly seem to be what the aforementioned Wikipedia article is alluring to. To me the XNA framework is more akin to a third-party library set, like AJAX, in that it adds pre-built routines to the existing bare-boned programing language. It does not put any restrictions or guidelines on what you, as the programmer, can and cannot do with these library routines. In my mind that is not akin to an engine in any way. Then I come from a business software/web centric background, so maybe the view if this is slightly askew for a dyed-in-the-wool games dev.
I’ve built the framework for a game idea using XNA and it definitely feels like I’m using just another library over C#. I’m going to use the processes I’ve hacked out in the test program to produce two or three games for windows and possibly Xbox.
So, as I said, In my mind this is far away from what I understood to be a ‘Games Engine’ so when I came across this post I had no idea why someone would make that comparison. Am I wrong?
A framework provides a minimal architecture built for a specific type of application. It minimises assumptions about implementation details beyond the stated goals of the architecture. While a cross-platform game development framework might have the goal of providing "what is common to (nearly) all computer games, irrespective of platform", and might implement only such abstract factors as timing and entity management, the XNA Framework (implicitly) has a goal of providing "what is common to (nearly) all computer games written for execution on the XNA CLR". Given that this focus is so narrow, they have been able to included engine features with impunity. They bundle it all under the heading of "Framework", since this indicates a certain freedom of implementation which you as the game developer will enjoy.
Roughly speaking, a framework should be as unrestrictive as possible while still providing useful foundations. An engine, on the other hand, is typically more focused toward specific features, and in using it, you accept that there are certain limitations which you will be tied to.