GAMEY LITTLE HACKER'S 'RPG ZERO'

On previous posts I commented that GLH had published some handy source code and tips for data-driven games, in particular, RPG ones.

Well, GLH is back with an awesome demo video of a starting RPG project:

From GLH's site: "When I started writing about game programming here last month, I really did want to practice a little altruism and share some stuff with the community. I'm afraid the vanity levels on this project however, make it wholly unsuitable to share as good practice. The sheer self indulgence in the code should warn people away. I really can't in good conscience recommend anyone learn anything from this... the scripting language is an own rolled, interpreted, prefix notated, reflection driven nightmare for pete's sake!

I would like to share though. So if anyone is interested in watching, I'll post the goings on in my RPG land."

So, what do you think? Should we be interested?

C'mon! Pay a visit to this site and let GLH know that you are interested ... I did ... ;)

ACCEPTABLE TEXTURE SIZES?

First things first: Sharky has released the latest build of Air Legends, so go, download and test it for stability.

Having said that, on the post that announces the build there's an interesting question (read Sharky's third comment) about the do's and dont's of chosing proper texture sizes for videogames.

It'd be nice to count on thoughts & suggestions -by more experienced user than me in the field- in order to answer it, accordingly.

So if you feel like sharing your experiences either from your technical background or "code-warrior" tales, just pay a visit to Sharky's blog, browse to the above-mentioned post and drop your comments.

Later.

MORE ON 'FIRST PERSON SHOOTER CAMERAS'

Continuing with this latest series of "reminders", a week ago or so Eli (etayrien) posted this handy tutorial about FPS cameras.

Well, if you found it useful -like I did, and you want to go deeper in the field you'd then better go and check Eli's recent comments on the use of "quaternions".

From Eli's comment: "... I would use a quaternion based camera in two situations:

a) if the camera needs to orient in an arbitrary direction: ie any combination of roll, pitch, and yaw. Otherwise you can get gimbal lock. You'll have to web search for more information on what that is; I don't have the math background to explain it properly :)

b) quaternions also have the handy ability to interpolate between different orientations.

http://msdn2.microsoft.com/en-gb/library/microsoft.xna.framework.quaternion.slerp.aspx

This can be very useful for third person cameras ..."

BTW, read between lines: "... but like you guessed, we've been really busy ..."

... something is being cooked ... something is being cooked ... ;)

NEED OBFUSCATOR FOR .NET?

Do you remember the second part of the series "Deploying Games To The 360 Without Sharing Source Code" -related to obfuscation of .NET assemblies?

Well, if you're not interested in the subject just skip this post. Otherwise, read on ...

I have searched the Internet for some obfuscators and this is what I've found so far:

• BitHelmet
• Eazfuscator.NET
• .NET Reactor
• {smartassembly}
• CliSecure
• CodeVeil
• dotNet Protector
• Dotfuscator for .NET
• Salamander .NET Obfuscator
• Skater .NET Obfuscator
• Spices.Obfuscator
• Xenocode

Some of the vendors' sites do include comparison charts but unfortunately I couldn't find "user-made" comparison charts. Thus, like usual we all end up in a "try the demo-before-you-buy" scenario to get the one that properly fills our needs for code protection.

BTW, the list above is meant to be as a "dynamic" reference, so if I happened to miss one obfuscator -sorry about that, just let me know and I add it to the list a.s.a.p.

Also, if you know well one/some of these apps -because you use or used it/them- and want to share your thoughts you're welcome to post your comments.

Hope this helps!

FIRST PERSON SHOOTER CAMERAS

There's a new tutorial at Cornflower Blue's blog which explains in detail how to create a FPS camera with XNA.

From etayrien's post: "... We've been busy lately, which should put smiles on all your faces. I like my job, so I can't give any specifics, but we've got some stuff coming up we think you'll be excited about. ".

Told ya!!! ... something is being really cooked by the XNA Team ... does anybody know anything else about that "some stuff coming up"? What could it be? Hummmm ....

... well, cannot wait ... ;)

TIP: DEPLOYING GAMES TO THE 360 WITHOUT SHARING SOURCE CODE - PART II

In line with what he had explained for the matter, Stephen Styrchak has added some important information regarding obfuscation in general, and for the 360 platform in particular.

From Microsoft's forums: "Whether you want to obfuscate or not is completely up to your own discretion. It seems like a lot of people share the false impression that being able to decompile/disassemble binaries is a new thing that is possible with managed assemblies. It is not. It is just as easy to run a decompiler/disassembler on native binaries, and that technology has been around for decades.

That being said, yes, it will certainly work for assemblies compiled for the Xbox 360. Obfuscation is a post-compilation step that takes an assembly as input, and generates a new (obfuscated) assembly as output. The obfuscated assembly is functionally equivalent, but the instructions and functions have been rearranged in a way that makes it harder for humans to understand.

An obfuscated assembly is no different than an unobfuscated assembly in that it makes no difference to the JIT compiler and runtime if an assembly is obfuscated or not (which is why it will work on the Xbox 360). Similarly, assemblies for the 360 are not special assemblies; they are produced by the same C# compiler as the Windows assemblies -- so no special obfuscator is required to use on them.

Note that obfuscation just makes it harder to read disassembled assemblies, not impossible to read. With a more sophisticated disassembler, I believe you could effectively undo most of the obfuscation. You'll have to check with your obfuscation tool vendor to understand just how "secret" they can make your code. From my understanding of obfuscation, the efficacity also depends on the complexity of the software you are trying to obfuscate. That is, an algorithm in a single function will probably remain almost completely unchanged. However, an algorithm that requires dozens or more functions would be very well hidden. The trick is in hiding what functions are being called an what data is being passed around. The instructions doing the work (loops, branches, etc) are otherwise the same.

--Stephen"

Cheers!

TIP: DEBUGGING XNA GRAPHICS PROBLEMS

Shawn Hargreaves has posted a technical article with relevant advice on how to debug and diagnose Direct3D-graphic calls both on Windows and XBox360.

From Shawn's post: "For debugging Xbox graphics you have to rely on less scientific techniques, such as tea leaves, entrails, or a visit to the local palm reader..."

Say no more, a must read ... ;)

TUTORIAL: A DATA DRIVEN SAMPLE ("SHOOTER ZERO")

Continuing with the "XNA Community Pimpage" tradition, I recommend reading this post on Gamey Little Hacker's Blog about data-driven game architecture and implementation.

Not only is the second part of the series on the matter but also you will find an interesting demo sample code which will bring some light for those of us who need tips and examples (and I say "of us" because I'm starting to deal with the concept of "Entity" within my engine so this example comes to me in the proper moment).

From GLH's blog: "Questions are welcome, and if there's enough interest I could write a few more posts that break out the details."

All in favor of more posts just raise your hands, or ... well, say, let GLH know that you're interested in more posts on this regard ... I am ...

TIP: DEPLOYING GAMES TO THE 360 WITHOUT SHARING SOURCE CODE

From Microsoft's forums (by Stephen Styrchak): "If you really want to share an Xbox 360 game without sharing the source, you can do it pretty easily. Just build your game into a DLL instead of an EXE (Game Library project). Then share a project with the source for the program entrypoint (main) that references your compiled assembly.

Basically, the project you have to share is the default Xbox 360 Game project with the Game1.cs file removed. The Game1 class should be defined in a separate DLL, which you can build from an Xbox 360 Game Library project. That way, the code in Program.cs will instantiate and invoke your game, which is implemented in another assembly.

You can develop the game using a multi-project solution and a project-to-project reference. But when it comes time to share it, just create a new Xbox 360 Game project and reference the already-compiled Game Library that holds all your game logic. Share that project (which is just a stub and contains no game logic), your compiled game assembly, and all the compiled assets.

This way, anyone with XNA Game Studio Express can use your shared project to build and deploy your game, without actually having the source for your game.
Although many people will encourage you to share your source as well, there are ways to show off your games and your creativity without giving everything away if you really, really don't want to.

Simpler methods are on the way. Just be patient.

--Stephen"

Some tip! But wait, if you can read between lines you may notice that something is cooking -even though no time frame has been revealed.

Please, tell me that an update pack for XNA is almost there ...

"... Just be patient ..."

Ok.

SOME HELPFUL ADVICE FOR THE 360 DEV.

Peter D. has published some tips that will help you avoid the "memory wall" you may find when developing games for the XBox 360.

From Microsoft's forums: "I mentioned in a previous thread, that developers need to be careful when creating their games as the 360 has only 512mb of ram available. I noticed recently that as more people start to use the XNA launcher, they are running into this memory wall.

So here are my top tips to help avoid the wall ..."

Want to know more, follow this link.

TUTORIAL: XNA COLLISION DETECTION FOR 3D MODELS (PARTS 2 & 3)

Sharky's has published parts 2 and 3 of his formerly 2-part tutorial series called "XNA Collision Detection for 3D models".


For those of you who didn't read part 1, please go and check it now!

Also there's some sample code you can download and read through the code.

Enjoy!

OOB INTERSECTION TEST USING XNA

As we wait for the second part of Sharky's tutorial "XNA Collision Detection for 3D models", there is an interesting source code to study, which was programmed and uploaded by Minh at Channel 9 site.

Too many links for one sentence, don't you think?

Anyway, just dowload the code, build the assembly and play around with the test demo to see how the test performs.

See ya!

SHARKY'S AIR LEGENDS BATTLES XNA COLLISION DETECTION ...

Sharky has published "XNA Collision Detection for 3D models - Part 1". The first article of a two part series where he tells from a "code warrior" experience the path he has being following so as to implement a precise yet robust collision detection system in his game: Air Legends.


This is an interesting read since it's a common problem developers face when dealing with collision as rotating AABB -in case you decide to go this way- could bring performance issues, possibly leading in the end to the use of other techniques like bounding spheres (i.e.: read the comments on this post).

I cannot wait for a new release of Air Legends (and the radar), one of the first games that were and are still in development using XNA ... and of course, fun to play too ... ;)

INFINITY: A SPACE-BASED MMOG

What an excellent way to publish my first post of this new year 2007 by talking about this amazing game that is being created: "Infinity". The guys behind this new production have posted great videos and images that really do a great job of showing off what the game is about.

Also, the "Journal of Ysaneya" is very interesting to follow -for us, developers- since it comments on the status of the game, the coding challenges they face to fix bugs, improve the gameplay, implement new features, etc.

Pay a visit to Infity's site, read the journal and don't forget to download the combat prototype and join the battle between the read & blue teams.

Cheers!

PROBLEMS WITH FULLSCREEN MODE IN XNA?

Some members of the XNA community (including me) have experienced problems with XNA games when running on fullscreen mode -in particular, I have a GeForce 6600 GT card.

The problem: when a XNA game tries to get/set the presentation parameters for accepted fullscreen modes, it takes the list of rates accepted by the gfx card and in some cases uses the higher one -for instance, like 240 Hz on 800x600. Phewww! So you will see nothing more than a black screen and your monitor trying to warn you that something is attempting to set an invalid refresh rate.

The workaround: if the user forgot to (or cannot) forbid any rate above the maximum accepted vertical retrace on the gfx card, just catch the "PreparingDeviceSettings" event and then set a common rate like 60 or 72 Hz. How? In the class that derives from "Microsoft.Xna.Framework.Game" class, add the following line (say, within the constructor):

graphics.PreparingDeviceSettings += new EventHandler<PreparingDeviceSettingsEventArgs>(MyMethod); // "graphics" is a reference previously instanced as "GraphicsDeviceManager(this)" usually in the same constructor

Then add the following method in the same class:

private void MyMethod (object sender, PreparingDeviceSettingsEventArgs args)
{
args.GraphicsDeviceInformation.PresentationParameters.FullScreenRefreshRateInHz = 60; // for instance, or 70, 72, 75, etc.
}

I've modified the code of games like Rocket Commander and Wildboarders and it all works great!

Let's hope Sharky modifies Air Legends soon so that I can finally play the game.

Enjoy!

RECOVERING VISUAL C# EXPRESS' PROJECT TEMPLATES

After installing XNA GSE v1 I happened to find that the project templates that come by default with the express version of VS C# - that is, Windows Application, Class Library, Console Application, etc. - had vanished from the IDE's templates browser ... :(

My first desperate move was uninstalling and reinstalling the whole thing (of course, after a very laoud scream of terror), but before jumping to a pool where maybe there was no water at all, I though (and look how clever I am): "Weeelllll! Maybe it's time to watch some TV ...", but adding almost instantly: "... but first let's do some search on MS's forums so as to get some answers, put the blame on someone else and common daily things like that ...".

For my surprise I found not one but two threads related to a similar issue which gave me a relevant hint on the workaround. And as we are approaching Christams Eve I'm going to share with all of you ...

The solution is simple, just execute the following line -either through the command shell (cmd.exe) or browsing your windows explorer to "start > run":

"%vs80comntools%\..\..\common7\ide\vcsexpress.exe" /installvstemplates

Of course you'll have replace "%vs80comntools%\..\..\common7\ide\vcsexpress.exe" with the correct path to "vcexpress.exe" in your local machine.

Although it all should work, it may occur a catch: the templates might still be missing according to the IDE's templates browser (this happened in my case, meaning, another scary scream). No sweat! If you open the folder where "vcexpress.exe" is located you will also find a folder named "VCSExpress", right?

If you don't, contact your local administrator, who will recommend you to (un/re)install everything.

If you did, open "ProjectTemplates" folder and then "1033" folder so as to find at least 4 zip files (usually 6) containing the missing templates. Copy these zip files to "ProjectTemplates", run again the above-mentioned command line and voilá! The IDE now recognizes all of the installed project templates.

It seems that XNA GSE installation process changes the "cache" file located in a folder named "ProjectTemplatesCache" in a way that all of the project templates installed within the "ProjectTemplatesCache\1033" folder are disregarded.

Thus, after applying the workaround commented in this article you will find the recovered templates duplicated in the "ProjectTemplatesCache" folder (that is, 6 inside and 6 outside the "1033" folder) until a MS's team fixes future installers of upcoming XNA GSE versions ... ;)

See ya!

SERIOUS THOUGHTS ABOUT XNA GSE - PART II

Where were we? Ah, yes ... "Will I succeed by using XNA GSE?".

Let's face it: like everything in life, time will tell. Time will prove you were right or wrong but, is it worth trying? Straight answer: yes, provided you are able and capable of facing and breaking through a tight membrane formed of strong competition.

Like you, everyone is competing to get community, market, publishers and or employers' attention. No matter how shared in common a colleague may behave along the road, it all summarizes to a simple fact: in the end, to some extent, everyone is thinking "that prize has to be mine!". C'mon let me hear "not me". Anyone? (don't panic, just continue reading, ok?)

So, what could make one stand out from the rest? That's the key point.

A combination of skills, dedication, commitment and perseverance (not to mention finance resources to live on day by day).

"How could XNA GSE help me achieve my goals?" Interesting question. Personally speaking, for the first time I feel someone is providing a well-designed framework for game development with great potential.

Many companies offer many solutions to developers but you always find a catch: you have to learn a new language (either for hard-coding and or scripting), the language lacks a professional GUI and or IDE or even it is not an object-oriented one, there is no way you can extend the given framework, it lacks the proper tools, it does not provide the features you need, it does not handle with key aspects of game creation as expected, plenty of bugs, poor support, and so on.

Now we have a framework that plugs into VS2005, and thus to be used with .NET languages (in the case of XNA GSE it plugs into C# Express) which offers a set of tools and features (please read part I) designed from scratch to facilitate the process of creating a game from an object-oriented perspective and last but not least, with strong support. What is more, new tools are being created on top of XNA as TorqueX or will support XNA as Visual3D.NET and I believe we will soon see more coming.

But there is one more factor that XNA GSE is trying to impose which opposses to the fact that we are all competing in the end: a community of developers that really collaborate by sharing experience and knowledge. It's like saying "Ok, we are all trying to cross the finish line first but unless we help each other it's likely that none of us will even get there!". So far, MS is achieving this goal: code snippets, solutions, implementations and complete games are being shared by and to the XNA's community and there is no indication that it will stop. A lot of people, including me, is excited about this whole thing and participates in good mood, what in turn is a lot to say (I can list a bunch of forums where members try to tear each others apart, and newbies, are fiercely bounced and discouraged).

To sum up, this time one cannot complain that "we" do not have the framework and or tools needed (ok, an implementation of one of the "big" physics libraries for .NET/XNA would be welcome, like Havok's or Ageia's) or that there is no support (either from the developer or the community), meaning, now it is really up to each of us -or our teams- to create a game that catches everyone's attention.

So let's go for it!

SERIOUS THOUGHTS ABOUT XNA GSE

As we are approaching to the release date for XNA Game Studio Express v1, the following first question may come to one's mind: how successful will it be?

First of all let us consider one simple fact: if you want to program games using DirectX and C# then bear in mind that XNA is the successor of MDX, so unless you decide to implement your own wrappers to DirectX dlls (what would be like re-inventing the wheel) or try native-proned languages (like C++), you will end up using it, anyway.

Ok, but what is it with GSE? It is a framework based on XNA and mounted as an add-on for C# Express which provides a set of tools and implementations that let you program your games with ease. GSE takes advantage of XNA's content pipeline, brings a basic implementation to manage the rendering process (i.e.: initializes and sets the devices for you, handles the calls to update and draw functions, among other tasks) and let you deploy your game to XBOX360!

You may ask: where's the catch? You want it, so here you are. According to the XNA FAQ:

• In order to develop, debug, deploy and play your games on XBOX360 you will have to join the "Creators Club" for a fee of USD 99 for a year or USD 49 for 4 months.
• You cannot produce a commercial game for XBOX360 with the express version.
• When you deploy the game to the XBOX360, and want to share it with other members of the club you will also share all your content and source code.

The good news is that all of the above does not apply when referring to the PC platform. Meaning? You can produce a commercial game for PC, without paying any royalties or fees, and without sharing your source code and or content.

So? Well, Microsoft has decided to catch a larger marketshare in the consoles industry by providing developers with handy, simple and inexpensive tools to build and deploy games for the 360. What is more, by doing so, contrary to what its main competitors do (that is, Sony's PS3 and Nintendo's Wii) MS is bringing to its equation a new relevant factor: "indies".

Being and "indie", go and try to produce a game -either commercial or not- for PS3 and or Wii and come back later for further talk. Just by calculating how much it would imply to do so would discourage you in the split of a second. It is hard to start an independent project and or small enterprise in the software industry, and it is harder in the game's one.

MS has noticed those facts as well as other two main things:

1. The number of indies has increased in later years at a growing rate.
2. Many of them use managed languages (like C#) to create their applications and games.

Moreover, some serious tools and frameworks are being developed and fine tunned to work along with XNA, either now or in the near future, like "TorqueX" and "Visual3D.Net".

Thus, will XNA GSE succeed? My guess is YES.

So the question becomes: will one succed by using XNA GSE? I will let that question unanswered until later posts ... ;)

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]