Monday you said? Yeah, right ... lazybones ...
Whatever ... On part 1 I had introduced some general concepts about game engines and other components, right? Well, today's post will concentrate on giving a few examples of some of the "helpers" that you may find in the industry, or at least, among "indies".
To do so, I'll will use the same categories of part 1, so If you don't remember the definitions and concepts, or you didn't read part 1 at all, you'd better go and read it first before we continue.
Ok, assuming you did. We shall continue ...
Ahhh, by the way, what you will see is how I see it, ... it's my blog, right? ... so feel free to re-arrange things up in your own list if you think that some component belongs to a different category.
(1.a) General-purpose engines.
If you had paid a visit to Devmaster.net as I suggested, you would have noticed the growing number of engines available in the market, like "Irrlicht", "3Impact", "C4 engine" and "Truevision 3D".
C# developers: although most of them are C++ original, some of them like "Irrlitch" provide a wrapper for .NET technology.
(1.b) Game-type-specific engines.
Our first classic match of the night: "Unreal Engines vs. Quake Engines". That is to say, "Epic Games vs. Id Software".
And lately, a new generation of engines that continue Quake III's legacy: "Doom III engine".
(1.c) Game-bound engines.
Well, to tell you the truth, you can include here any engine created for the sole purpose of developing one game and or sequels for that "title". In fact, the line between the previous category gets thinner when the engines starts to be modified in order to develop new "different" titles.
2. Game Frameworks.
From fully WYSIWYG frameworks like "GameMaker" and "Multimedia Fusion" -which you can get interesting results with, to full 3D-powerhouses like "A6 - GameStudio", "Quest3D" and "Torque Game Engine" -which let you target very ambitious projects, there are a whole range of frameworks to choose.
MAC developers: check out the cross-platform "Unity3D" engine.
C# developers: a new battle is coming: "TorqueX vs. Visual3D.Net". Buy your tickets ...
3. Game-Oriented Languages.
New GO languages are now entering the field but one of the classic battles of latest years is "Blitzbasic vs. Darkbasic".
Choose the contenders you prefer for each side, like Blitz3D vs. DB Pro, and enjoy the match.
OOP developers: both "line of products" above are non-OOP.
(4.a) Game-Oriented Middleware: Rendering.
I could mention too many components here like "Renderware" and "Gamebryo", but I will refer to OGRE (which stands for "Open Source Graphics Engine").
Contrary to what many of you may think, OGRE is not a game engine ... read the "Graphics" part of the "G" abbreviation ... ok, time to run away before the mob reaches me ...
Really. You can build your own engine by using its outstanding multiplatform-rendering capabilities, and you will likely find those who did, but OGRE only provides a set of C++ classes which will make your development life easier for rendering processes.
C# developers: yes, there's an OGRE.NET out there.
(4.b) Game-Oriented Middleware: Physics.
"Bring it on!". That's what companies that develop physics-prone components are saying one each other.
Havok, Newton, ODE, PhysX, Tokamak ... These guys have been around for so long now, and the battle still goes on.
Different type of licensing, different technologies, different features, different logic structure, different support, different approaches to the one domain they have in common: physics' mechanics.
C# developers: be aware that currently most of those companies neither offer nor support wrappers for .NET technology. You may find third-party wrappers, but no guarantees as usual ...
(4.c) Game-Oriented Middleware: Scripting.
Some AAA games have their own scripting language, like "Unreal Script". But there are general-purpose scripting languages that you can use, like "LUA" and "Phyton" (both well accepted in the industry).
Also, there are relatively new entries but yet powerful options, like "Gamemonkey Script".
And finally, I must mention one of the mostly used languages for internet-targeted games: "Actionscript" (built-in language for Adobe's Flash).
A tip for C# developers: with a bit of self-effort you can also use C# as your scripting language.
(4.d) Game-Oriented Middleware: AI.
Ok, you can either use scripting languages to modify the behavior of your game's "bots" or hard code your own implementations but there are some intereting components you may consider to use, like: "AI.Implant", "Renderware AI", "PathEngine", and "Memetic".
C# developers: see the tip in (4.c) above.
(4.e) Game-Oriented Middleware: Networking.
Last but not least, multiplayer stuff. Err ... getting a community of gamers together to play your game.
If you think that the other "areas" were tough, don't forget this one. Believe me. Point-to-point communication, client-server models, world updates, anticipation of each connected player's movements, etc. This requires a lot of patience and experience. Thus, not many games provide this feature.
Luckily, here come some components to the rescue, like Quazal's line of products, "Replica Net" and "Plane Shift".
Now, some final thoughts ... you may have heared about some of the above-mentioned "helpers" or even used them, but the fact is that in order to produce a game from scratch to completion you have to choose the right ones, that is, the ones that comply with all of the requirements for your project: budget, scope, technology, features, comfort, support, ... just to to mention a few.
But one thing is getting to know a bunch of components in order to pick the right one for you and your crew and other very different thing is to "wander" around them in a sort of "never-ending" testing, because you are either waiting for that long-awaited "saviour" component, you have played around so much that you don't know where the North is anymore, or you can't just make up your mind.
One of the huge mistakes that many "indies" usually make -I included- is playing around with some third-party components at the same time for a long time. You may say, "what's wrong with that? One should get to know a component before buying it, right?" I'll tell you what, the problem is that when you use, not one or two, but more components at the same time for a long time you face the risk of not getting to know none of them with the due depth of detail that you need in order to properly deal with your project.
In other words, don't play around with the components as if you were carring on the project it-self in a paralell manner through all of those components, like saying "the one that reaches the finish-line first wins the race" (if you compete with your-self in this one there will be no winner).
Just perform a set of small and accurate tests on the functionality that you need for your game in a sort of check-list verification: "Engine 1 ... checked, Communications ... checked, ... ". And then, having analyzed the pros and cons of the candidates, select one, get to know it deeply and start your project.
And please, don't look back until you finish it or otherwise you'll be only creating abbandonware, potentially speaking.
Just remember, there may exist no perfect components in absolute terms but relatively speaking, there is one (set of) perfect component(s) for your project if you manage to choose smartly. Or was it for soul-mates?
Anyway, part 2 is now finished. See you all next time ...
[... we will only focus on .NET based components]
