The best book I've read on the subject of game engines is 'Game Engine Architecture' by Jason Gregory. It gives a bigger picture view and covers a broad range of game engine systems. And the book doesn't give much implementation details (only where necessary to explain a specific concept).
Covering such a broad range makes it impossible to go into depth on any one subject, so the gameplay part (which it seems like you're mainly interested in) is only covered in one chapter, but still; if you want a good overview of the systems in a game engine and their interactions then this book is on the top of my list of recommended books to read.
The book requires a certain amount of previous coding experience, but not game specific experience. So I wouldn't recommend it to someone who just read a 'Learn C++ in 21 days'-book and wants to create a game engine, but from your question i get the feeling you won't have any problem with it.. ;)
There are various ways to support scripting in games; it's a sliding scale.
On the one extreme, you can have practically everything running using the scripting language, so you define all of your data, logic and so on using the scripts and just have some core engine functionality in C/C++. In this scheme, nearly everything on the C/C++* side is just on that side of the divide to make it efficient enough, or because it's already been written in that language and would be costly to reimplement.
On the other extreme, you can have most of your game code & data defined in C/C++ and implement bindings and or callbacks to allow some customisation via scripts. Bindings (e.g. LuaBind) allow your scripts to get and set values / call functions that aren't defined in the script code, but on the C/C++ side. Callbacks allow scripts to listen in for game events being triggered; .e.g you may have a script that is invoked when an entity is about to take damage. You can then customise / extend your game logic via scripting.
The book Game Engine Architecture does a good job of explaining the possiblities, though it doesn't include sample code or anything like that.
The how of scripting is very much dependant on what your implementation style is and which core & scripting languages you choose. If you want something more concrete, try homing in on some language choices (e.g. C++ & Lua) and then track down some tutorials like this one.
The why depends on the approach taken, but it's generally to split gameplay functionality / behaviour / data from the guts of your game engine. This makes it easier to change since you can reload scripts at runtime without rebuilding the rest of the project. A nicely implemented scripting system also makes it easier for people to get involved or to mod/extend the game without bothering a programmer.
A concrete example:
You might want to build a piece of functionality that tells a player how much damage they dealt over the course of a round.
If you do this on the C++/core side, it means getting a programmer to put in a load of very specific code to serve a very specific function, rebuilding the whole project and deploying a new version. They then check with a designer that everything is grand. If it's not, they have to recode and rebuild, sapping lots of time.
With a well designed scripting system, it's just a case of dropping a round_damage.lua script into a scripts folder. The script is automatically hoovered up and activated when the game starts, and each time a player takes damage, the "OnDamageReceived" handler is triggered. When the round ends, the OnRoundEnded callback is triggered and the script displays a message.
Providing a rich set of hooks is exposed, a scripter can do all of this without a programmer's help. If they make a mistake or want to try something else, the scripter can immediately reload the script without shutting down the game.
*Note, I say C/C++ for the core engine stuff because that's the common choice, but it could be any language that's fast enough for your purposes.
Before I developed a serious rendering engine, I'd read Advanced Animation & Rendering Techniques by Watt & Watt [1], cover to cover, a dozen times. It's pretty dated now, but at the time I first acquired it (90s) it was the most comprehensive overview of rendering I knew of. I'd also read Real Time Rendering, and Math for 3D by Lengyel, which are both on this list. For really proper collision, Real-Time Collision Detection (on the list) was absolutely invaluable, but I didn't get to that until a few years later. Around that time, I also read the excellent architecture book Game Engine Architecture [2] which I don't see here. It's well written, does things in the right order, and it's very comprehensive.
A game engine is a development framework for developing games. Unity and UDK are game engines. OpenGL and DirectX are rendering engine. A game engine may have its own rendering engine.
The 'open asset import library' has a model viewer where you can preview the models with all aclaimed supported formats (including animations). I would suggest exporting your animations, to a variety of formats and see if any of them give you wrong results (i.e. render artifacts) and conclude your own awnser. Personally, I had the most success with Collada (.dae) although I used 3ds Max.
To support the animation itself (presumable skeletal): interpolate the animation data (aiNodeAnim) between the key-frames; you need to calculate the bone matrices from the interpolated animation data (create a matrix out of position/rotation etc); calculate the 'animated' vertices by transforming the 'vertices' (aiMesh/aiBone) with the bone matrices that influence them; weight all of the 'animated vertices' and sum them together; render the newly vertices. And this a basic high level overview of animations.
The best book I've read on the subject of game engines is 'Game Engine Architecture' by Jason Gregory. It gives a bigger picture view and covers a broad range of game engine systems. And the book doesn't give much implementation details (only where necessary to explain a specific concept).
Covering such a broad range makes it impossible to go into depth on any one subject, so the gameplay part (which it seems like you're mainly interested in) is only covered in one chapter, but still; if you want a good overview of the systems in a game engine and their interactions then this book is on the top of my list of recommended books to read.
The book requires a certain amount of previous coding experience, but not game specific experience. So I wouldn't recommend it to someone who just read a 'Learn C++ in 21 days'-book and wants to create a game engine, but from your question i get the feeling you won't have any problem with it.. ;)
http://www.gameenginebook.com/
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135
There are various ways to support scripting in games; it's a sliding scale.
On the one extreme, you can have practically everything running using the scripting language, so you define all of your data, logic and so on using the scripts and just have some core engine functionality in C/C++. In this scheme, nearly everything on the C/C++* side is just on that side of the divide to make it efficient enough, or because it's already been written in that language and would be costly to reimplement.
On the other extreme, you can have most of your game code & data defined in C/C++ and implement bindings and or callbacks to allow some customisation via scripts. Bindings (e.g. LuaBind) allow your scripts to get and set values / call functions that aren't defined in the script code, but on the C/C++ side. Callbacks allow scripts to listen in for game events being triggered; .e.g you may have a script that is invoked when an entity is about to take damage. You can then customise / extend your game logic via scripting.
The book Game Engine Architecture does a good job of explaining the possiblities, though it doesn't include sample code or anything like that.
The how of scripting is very much dependant on what your implementation style is and which core & scripting languages you choose. If you want something more concrete, try homing in on some language choices (e.g. C++ & Lua) and then track down some tutorials like this one.
The why depends on the approach taken, but it's generally to split gameplay functionality / behaviour / data from the guts of your game engine. This makes it easier to change since you can reload scripts at runtime without rebuilding the rest of the project. A nicely implemented scripting system also makes it easier for people to get involved or to mod/extend the game without bothering a programmer.
A concrete example:
You might want to build a piece of functionality that tells a player how much damage they dealt over the course of a round.
If you do this on the C++/core side, it means getting a programmer to put in a load of very specific code to serve a very specific function, rebuilding the whole project and deploying a new version. They then check with a designer that everything is grand. If it's not, they have to recode and rebuild, sapping lots of time.
With a well designed scripting system, it's just a case of dropping a round_damage.lua script into a scripts folder. The script is automatically hoovered up and activated when the game starts, and each time a player takes damage, the "OnDamageReceived" handler is triggered. When the round ends, the OnRoundEnded callback is triggered and the script displays a message.
Providing a rich set of hooks is exposed, a scripter can do all of this without a programmer's help. If they make a mistake or want to try something else, the scripter can immediately reload the script without shutting down the game.
*Note, I say C/C++ for the core engine stuff because that's the common choice, but it could be any language that's fast enough for your purposes.
[1] https://www.amazon.com/Advanced-Animation-Rendering-Techniqu...
[2] https://www.amazon.com/Game-Engine-Architecture-Jason-Gregor...
Take a look at: Game Engine Architecture ISBN-13: 978-1568814131
A game engine is a development framework for developing games. Unity and UDK are game engines. OpenGL and DirectX are rendering engine. A game engine may have its own rendering engine.
Game Engine Architecture by Jason Gregory is a nice book
The 'open asset import library' has a model viewer where you can preview the models with all aclaimed supported formats (including animations). I would suggest exporting your animations, to a variety of formats and see if any of them give you wrong results (i.e. render artifacts) and conclude your own awnser. Personally, I had the most success with Collada (.dae) although I used 3ds Max.
To support the animation itself (presumable skeletal): interpolate the animation data (aiNodeAnim) between the key-frames; you need to calculate the bone matrices from the interpolated animation data (create a matrix out of position/rotation etc); calculate the 'animated' vertices by transforming the 'vertices' (aiMesh/aiBone) with the bone matrices that influence them; weight all of the 'animated vertices' and sum them together; render the newly vertices. And this a basic high level overview of animations.
There are tutorials and books that can go deeper into the subject. For example ogldev's tutorial 38, Jason Gregory's Game Engine Architechture has dedicated animation chapter. You can take a look at the source code of assimps model viewer.