GAME ENGINES AND OTHERS: PART 3 OF 3

At last! The final part of the series ...

Where were we? ... On part 1 I had introduced some general concepts about game engines and other components and on part 2 I had presented some examples for each category. Well, now is time to reduce the spectrum to .NET world.

There may be a lot of well-known components that I'll forget to mention (as wll as new additions made to the market and upcoming ones), so I recommend you for the n-th time to pay a visit to "DevMaster.net" and check the "3D Engines Database" section.

Not too many components were built for .NET using C# from scratch, but I can remember two of them which did: Purple# and Haddd.

Purple# was one of the first engines to appear that were written using C# 1.1 and if I remember well -please correct me if I'm wrong- it'd be ported to version 2.0 of .NET. However, things have been quiet for a while since no news have been posted and the forum's activity has almost stopped. Also, last time I checked the "Downloads" section had no files to download (?).

Tip: you can always use the rate of new posts, both for news and forum's threads, as a proxy of the activity related to the component's site. I mean, whether a component is still updated or under development, whether it has been abandoned by the developers and or its users, etc.

Haddd was one the most (relatively) recent ones to appear and was pretty much impressive. Open source, its rendering process was designed for the use of shaders (mostly, model 2 ones), a physics middleware was successfully plugged in and some AI implementations were interesting. Unfortunately, Haddd project was suddenly stopped. Fear not! Fortunately, the source code for the latest review was distributed free to the community and now there's a new successor: Jadengine.

What about components ported to .NET and or targeted for .NET but built upon non-NET components? "Err ... what? Please rephrase ..."

I remember AXIOM3D. This engine was built upon OGRE and let me tell you it was quite good on the offered features and open source. One of the things I liked most about it was the BSP implementation.

Then it came Realmforge GDK. Built upon AXIOM3D -but from a different team, this component was meant to ease your game-creation experience by providing a handy GUI which one could use to set and edit your worlds properties and such.

Both components were discontinued. Fear not ..... again! Visual3D.Net is on its way.

But, what is it? Well, to sum up, the next phase of evolution that results from the cumulative experiences of the developers of Realmforge3D (the original developer of AXIOM3D joined the project a few months ago). Correct me if I'm wrong but it has been built from scratch using C# and MDX so it's not AXIOM nor OGRE dependant anymore.

For what it can be seen in the screenshots and read in the forums, Visual3D.net promises to be a very useful framework when released with support to .NET Framework v2.0 and XNA Framework. A Community Technology Preview ("CTP") of Visual3D.net is comming this October so if you're interested don't forget to visit its site and sign up to get the latest news about the CTP.

Its nemesis? Or at least, for what I understand, TorqueX ... Garagegames' future product which is a combination of its newest product ("Torque Game Builder") and some features of other products (like "Torque Game Engine" and "Torque Shader Engine") all ported to XNA Framework. This also promises to be very useful so as to reduce coding time.

Some videos have been released to the public showing TorqueX's features and a public beta has been announced (even though no release date has been confirmed yet), so again if you're interested, go and sign up to receive the newsletter on the product.

As already said, Visual3D.net and TorqueX will both support XNA framework, so this match is going to be interesting ...

"Wait! You have mentioned XNA for the third time now ... but what is XNA?"

According to XNA's FAQ it "is not acronymed". XNA Framework is a collection of classes and tools that can be used for the production of DirectX-enabled programs with VisualStudio 2005 that can be run in both, PC and XBox 360 platforms. One of its most important features is the content pipeline it offers (a handy way of "incrementally" deal with your assets for the game, like meshes, music and sounds).

Think of it like the successor of Managed DirectX 2.0, given that it has been recently announced that no further development shall be provided for MDX 2.0. Sooooo, when you choose a component for your project bear this information in mind in order to avoid ugly surprises.

"Ok, but what is XNA Game Studio Express?". XNA GSE is the ... you know what? Just read it here (I promise I'll post my comments about it in future posts but currently you can find some source code for it I've already posted in this blog).

I cannot bring the series to a proper end without mentioning some other components that supports .NET technologies through the provision of wrappers which are worth checking:

• 3Impact,
  
• Irrlitch,
  
• SDL.NET, and
  
• Truevision3D.

I could include "3DState" to that list since it has been around for a long time now, but last time I checked there were no news nor forum page. The website was revamped with some flash components but it seems that there is no sign of further activity (?).

Remember MAC developers to check "Unity3D": based on its features, users' comments, demos and examples, this framework seems to have nothing to envy to PC-platform's ones. And yes, for those of us who may consider buying a MAC, Unity3D can produce cross-platform executables.

To sum up, as you can guess for what you have read in the whole series of posts, there are a lot of engines, middleware and frameworks which will help you produce videogames from square one (as well as, in some cases, other multimedia applications). Thus, the whole process of selecting the one/s for your project demands a high amount of man/hour efforts so as not to fail by making a wrong choice. Therefore, before starting a project make sure you spend some time to develop a systematic method to evaluate the component candidates efficiently in order to seek and get optimal results.

Well folks, I hope you have enjoyed reading "Game Engines And Others" as well as found it useful.

'till next time. See ya!

GAME ENGINES AND OTHERS: PART 2 OF 3

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]

DO THE MATH

In one of my previous posts, I had included some links to interesting sites where figures on sales were published and discussed. Remember those?

Now, do you want to know more about what "indies" should and souldn't expect? Well, if your answer is "yes", an I'll bet your answer is "yes", just read Jeff Tunnell's article.

Browsing the web I happened to find this site which is really interesting and instructive. Ok, enough talking ... just go, read the article and do the math.

See ya ...