NVIDIA released the release candidate of the FX composer not too long ago. I downloaded and gave it a “breezy” try, but I don’t see GLSL support! Maybe I missed it. Why is there no GLSL support? Nothing is mentioned on the site as well. This is what the site says about API Support, “HLSL, COLLADA FX Cg, CgFX shading languages”.
I don’t have a latest card to test all profiles, but the product seems good, though it crashed on me once on an older gen card! Some dll problem. Ran ok with 6200 and 6600 cards. I am eagerly awaiting the gold release. Comes at an opportune time too since I will be finishing up with the current project and moving on to the next. Maybe I can seriously think of including this in the pipeline for the next version of the O2 Engine.
Apparently Microsoft’s answer to Adoble system’s Flash player. Or so they say. A significant development if you are a Flash game developer. I don’t see myself developing Flash games in the near future, but you never can tell.
Microsoft® Silverlight™ is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Silverlight offers a flexible programming model that supports AJAX, VB, C#, Python, and Ruby, and integrates with existing Web applications. Silverlight supports fast, cost-effective delivery of high-quality video to all major browsers running on the Mac OS or Windows.
Hmm, cross-platform, cross-browser! So are we going to see Microsoft officially support Linux and other *NIX platforms, and browsers like FireFox? Usually in Microsoft’s dictionary cross-platform means platforms including Windows ME, Windows XP, Windows 2000, NT, Vista and cross-browser means Internet Explorer 5, 6 and 7 .
Intel released a library designed to get the most out of multi-core processors under a modified GPLv2. This could be an interesting development. Parallel processing and parallelism is another contentious issue. Especially when it comes to implementing it. Many people have said that true parallelism is only possible while programming with a Functional approach. While that remains debatable, it is aptly clear that the next gen games will have to leverage most out of multi-core processors.
I am just a little bit worried about the licensing policy. They have released it under GPLv2 with a “runtime exception“. I am no legal eagle, but it sounds like Intel intends to make make some money with the library after all. I am also not sure how things will work out with AMD processors. In any case, it is one of the “must look into” things.
Surprise surprise! Nintendo announced the availability of its platforms for small and independent developers. It’s some kind of service named WiiWare which will allow developers to sell their games and players to download them off this service. WiiWare titles are supposed to be launched next year.
We are currently working out gameplay issues in the Doofus game and I am working on some serious tweaks to the A* algorithm used in the game. One of the feedback from beta testers was the movement of the enemies was somewhat robotic with very sharp turns. Fortunately all the enemies in the game are robots (smart move there), so the robotic nature of movement is kinda OK, still A* algorithm gives very sharp turns. I am working on some way to smoothen out these turns. (I hope it works out.)
Anyways, what the beta tester said, really got to me. He is right, you do get an uncanny feeling. So I decided to do some googling around to find out how other games were solving the same problem and why we got this sort of “uncanny feeling“. Before long I landed in the “Uncanny Valley”. The Uncanny valley is a hypothesis that was suggested by a Japanese roboticist Masahiro Mori . The hypothesis states; As robots became more and more humanlike, people were attracted to them, but up to a certain point. As soon as a robot or an android passed a certain threshold and became too realistic, people were repelled or disgusted. So what does this have to do with game characters? As it turns out the very same thing can affect game characters too.
Another article on the Slate gives more details on the effects of the Uncanny valley on game characters. I had noticed this effect before, where game characters don’t seem lifelike and their faces seem a bit odd. I couldn’t quite nail what it was that seemed strange, but reading the article makes things more clear. I was playing Elder Scrolls IV: Oblivion a few weeks back and there too the characters speaking to you looked odd. Their mouths, speech and gestures did not coordinate correctly. I remember in Quake 4 the character of Voss seems to be very robot like when he spoke to you.
I nearly shrieked out loud at one point. And whenever other characters speak to you—particularly during cut-scenes, those supposedly “cinematic” narrative moments—they’re even more ghastly. Mouths and eyes don’t move in synch. It’s as if all the characters have been shot up with some ungodly amount of Botox and are no longer able to make Earthlike expressions. — Slate
According to me, the Slate article is a bit too harsh and a little bit old. Yes, it may be true that games do suffer from uncanny valley effects, but I am not so sure they are here to stay. In fact after reading the article I fired up Half-Life 2 to re look at the animation effects from the cut scenes and guess what, the Source engine designers have nailed it! I mean the characters may not be totally lifelike but I found the animation system to have, lets say, less of the valley effect. Besides, if you look at the recent animation technologies like the ones in Shrek, Happy Feet, Chicken Little you see no visible signs of the Valley effect, at least I couldn’t. The gaming industry has some of the most intelligent and talented people in the world. With hardware evolving at law defying speeds and demands for realism going up all the time, I am sure these technologies will find their way into games sooner rather than later. To make claims like “though, gaming’s Uncanny Valley could be here to stay”, doesn’t do justice to the industry which is well known for its innovations and breakthroughs.
Do you feel your eyes getting stressed out after staring at the computer screen for too long? If you answered “Yes” to the question, then this is for you.
No, it is not another eye exercise, it is a nifty tweak for your Windows XP system that I happened to run across. It will take about 2 minutes of your time. Linux users need not worry, your systems probably already has this technology. Just in case it doesn’t, you can install it. It’s called FreeType. This is for Windows XP, Vista already has the new ClearType engine installed.
Recently I read an article about the new ClearType and OpenType technologies. The article caught my attention because it said that it made “reading enjoyable and less stressful for the eyes”. Being a computer programmer, I stare at the computer screen all day so any help to the eyes is a big plus. Microsoft has made the technology available for Vista by default, but what about the older Windows versions? After googling around a bit I found out that you could do the same for your XP systems.
First download the ClearType engine itself. It can be found at http://www.microsoft.com/typography/ClearTypePowerToy.mspx
The instructions on how to install and run the application are on that very same page.
After running and enabling the ClearType engine you will notice your fonts look a little bit different. Watch closely, they seem to have increased in contrast and look more pleasing.
There, you have successfully installed the engine. Now comes the time to take full advantage of it. Well as it goes, Microsoft has released 6 new fonts specifically designed to better the viewing experience with the ClearType engine. They are Constantia, Corbel, Calibri, Cambria, Candara and Consolas. Each is designed for a specific purpose and usage. Refer to the above mentioned article for details.
So where do you get these fonts? Well if you have a friend who has Vista, ask him to copy them for you. Each font is a set of .ttf files in the fonts directory. Or, I found a place you can download them. Its here. Scroll down and click on the “download” link . Unzip the zip file and copy all the font files .ttf to your WINDOWS/Fonts directory. That”s it.
I am using Consolas with my Visual Studio IDE for the past 4 months and I love it. I have also set the same font for my Notepad and other apps that use Monospaced fonts. One thing I would like to mention tough, the above mentioned Vista fonts look hopelessly bad if the ClearType engine is not installed.
The new fonts are a big hit with me, hope you find this information equally helpful.
Ah yes, so you want to make your new program/software cross-platform. Sure you can, just make sure you understand properly what it takes to write robust cross-platform software. If you haven’t written any cross-platform software thus far, then chances are you have no clue what is exactly needed. Writing truly scalable, robust and error-free cross-platform software with consistent behavior across platforms is difficult — and I have put an underline on that to emphasize just that. Go out and search for software that satisfies all the above points. I bet you won’t find more than a few. FireFox browser is one such project that comes to mind. It is a very good example of how cross-platform software should be created. Here I won’t go into the details on how cross-platform development is to be done, you can find plenty of that all over the net. Here I intend to point out (rant) about cross-platform development and it’s pitfalls.
Cross-platform development can be really easy or really difficult. There are several factors that come into play and everything really depends on the type of design, the quality of code and the tools/languages you choose. Cross-porting could add as little as 2% overhead to the entire development life-cycle, or things can be as bad having nearly 40-60% of your time trying to get things working the way you want them. Having said that, cross-platform compatibility does add overhead to any project and usually with experienced teams, it is about 10 to 20% of the entire development time (for non trivial projects). So the lesson is, if you don’t have to, don’t aim for cross-platform compatibility. If your project is never going to be executed on a platform, or if you are the one making decisions and are pretty sure there is no market for a particular platform, don’t get overzealous and try to port your design or code. Remember porting adds cost; and costs in everything from building to maintenance. ( Note: Design can be important while implementing cross platform compatibility, understand and use design patterns like Adapter and Facade).
So you still do want your project to be cross-platform? Fine! The first thing you have got to do is choose the right development language. Yes, you can write cross-platform C++ code. However different C++ compilers out there can be a nightmare to work with. You could save yourself a whole lot of trouble by choosing GCC for all platforms, but that can’t always be possible. In any case C++ programs can be tough to maintain for cross platform compatibility (, though I repeat, it is very much possible to do so). Another thing that can be a real pain in the a** to work with are build systems. Not all platforms will give you a cick and compile IDE for C++. In the worst case you will have to delve into the misty underworld of Makefiles. C++ is not a particularly good choice for cross platform development. Java or Python would be an ideal choice for a language. Both scale across platforms pretty well, but that doesn’t mean you have all the features of the language on all platforms. Read the docs carefully before implementing obscure functionality.
A good GUI can make all the difference between for an application. Making a correct choice for a cross-platform GUI is an equally daunting task. There are a lot of GUIs and a lot of libraries that claim to be cross-platform. Don’t be fooled, take them for a test ride and check the functionality yourself by making prototypes. Or save yourself the trouble by choosing a solution that is time tested. While choosing the GUI for cross platform development I have found that there is no easy answer. I worked on Qt some time back but wasn’t impressed with the moc-compiler thing. Also Qt uses obscure and redundant C++ coding practices to maintain compiler compatibility. Qt is a commercially available library and their support is, well I will put it at “OK”. wxWidgets has a huge community, but it builds on top of natively available widget libraries. It’s design mirrors MFC design, so it is a popular framework with MFC developers. I have developed using wxWidgets also and I would put it at good. I have found forum help (not kidding) to be better than Qt. My current favorite GUI is wxWidgets bindings for Python called wxPython. It is very easy to use and supports a ton of functionality (, and yes it is Python).
Another promising project is the Mono project. “Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix.” — The mono project. However some of the parts of the projects like the GUI are still in beta versions. Also one thing I have seen is Mono consistently lags behind Microsoft’s .NET framework. That is to be expected, since Microsoft will lead in .NET implementation and try and keep its version ahead of the competition. But nevertheless, Mono seems a serious contender for any cross-platform development. I haven’t give it a try though, maybe one of these days, when the game is shipped.
For our entire game project the 3D modeling and animation package we have used is Blender. It was pretty much used to make the main character and all the mesh assets in the game excepting the world. We are using another software package for world creation and scene composition, but more on that later. I selected blender for variety of reasons. The most important is of course, it is free, but that was not the only reason for its selection. Don’t let the free thing fool you, blender is a mature piece software with features that can rival even the best 3D modelers out there. In fact some of the features like multires mesh modeling, UV unwrapping, multi UV unwrap and powerful animation system are are cutting edge and the very best.
The second most important reason why I selected blender is its amazing flexibility! OK, so if you have used blender then you might disagree with me. I said might, a veteran blender user might actually agree with me, but for some reason blender has got this nasty reputation of not having a very user friendly GUI. I tend to disagree with that view because it is biased. Yes blender has an unconventional interface that takes a little getting used to, but to say outright that it is bad just because of that, is judging a book by it’s cover. Anyways, that is an argument for other day.
As I said, I selected blender for its flexibility. Blender offers an amazing plug-in support. It supports a full Python plug-in system which is very easy to use. The plug-in system allows blender to be extended very very easily. In fact blender is fully written in Python and is open-source. That is an added bonus, it allows you to have a peek at the source if you want to or if you are stuck somewhere. I personally found blender to be very easy to extend via plug-ins. Python is one of my favorite languages because of its simplicity. No doubt my previous experience with Python also helped.
Since programming plug-ins for blender is easy, you can easily export blender assets into your custom formats. Blender already comes bundled with a lot of exporters and you can open the python code for one and have a look at it and maybe, modify one to suite your needs. However, to dabble with the code, you must have solid 3D graphics and 3D programming concepts. Blender offers very little help or documentation on its design, so you have to understand why certain things are the way they are.
The other thing that helps a lot is the huge blender community support. Help is always at hand, people are willing to help out. That is not to say that blender documentation is bad, it is really good, though I must say the plug-in system docs are a little bit cryptic. But on the whole using blender to create game assets has been a win-win situation for me thus far. I have included some screens of art assets created in blender and then used in the game.
For any blender noob (, that is not to say I consider myself a pro,) the best way to get started is the blender video tutorials. They guide you through properly and allow you get you hands set on the blender interface. After doing that it’s just a matter of following the blender documentation. That is all you actually need to get started with the software. Yes, it will take a great deal more to master it, but this should be enough to get any newbie started.
A few months back I ran into a friend on mine who was on and on about Oblivion. For those who are blissfully ignorant, The Elder Scrolls IV: Oblivion is an action oriented role playing game by Bethesda Softworks. He was so persuasive, that I finally got hold of the game and decided to have a go at it first thing when I was a little free. So about three months after first getting it, I finally had some time yesterday evening and decided to install and see what the game was all about.
The first thing you notice (or should I say hear) when you start the game, in this amazing title soundtrack. The only thing I can say is, Wow! Awesome music, it captivates you instantly. The story and cut-scenes following the initial game introduction are equally breathtaking. The next thing you do is choose your character. You can actually design your character the way you want him(/her, not sure if a female character is allowed) to look. Nice piece of technology, but kinda unimpressive. OK so you can change the look and feel of the character, big deal!
When the game begins, you immediately have a couple of characters talk to you. One thing I noticed is the facial animation system. Oblivion uses the famous Gamebryo engine, so I was more than eager to see what the guys had put in on top of that. The facial morph animation system looks good, but still not as good as the Source Engine’s facial animation system in Half-Life 2. I must say, not bad.
As the game progress, you are taken through tunnels and dungeons. The pace of the game is good, but I am not too impressed with hand to hand combat. Another thing that ticked me off is an extremely difficult weapon selection window/dashboard. The designers have crammed an insane amount of things in that small dashboard including spells and what not. You have to be pretty quick on the keyboard while selecting a weapon or spell, else you can get mutilated really quickly. This can get real annoying at times when there are too many enemies around. Playing the game, you end up spending nearly 40% of your time on the dashboard selecting and sifting through things. I mean, come on, selection via dashboard, didn’t the designers find any better way to do that?
Another thing that impressed me are the terrain and the atmospheric effects. I must say they are good and add good cohesion to the game play. The game features some interesting effects like moving-grass, thunderstorm, rain and fog. It is commendable that the game manages to keep a playable FPS with all these effects ON, but the results of level of detail calculations are painfully obvious on my dirt cheap 6200 card. I also liked the effects for the Oblivion gate, ooh! you have got to see that.
The gameplay is designed to allow the player to explore and lure him into a sense of a limitless world. This can get confusing at times resulting in the player losing focus of his goal. Sometimes the goal is not clear, sometimes you tend to wander off, or take a wrong turn and get lost, sometimes you can go around in circles. The game, I think, allows you to explore more than what is needed. You can enter any inn, house, castle and anything else and explore. Apparently, you tend to gain very little by exploring and in fact get yourself in trouble if you talk to a wrong person. You can directly approach your goal without exploring anything and it makes little difference to the game, maybe it does, but nothing is made clear.
The game features impressive enemies, but their role is not immediately apparent. Some enemies can pop-up in strangest of places, some just wander the terrain. Some just hit you for no reason and others don’t even seem like enemies till they throw a lightening bot at you. Why? Maybe things will get clearer as I progress. There seems to be one more thing, enemies get harder to kill as you progress. I am currently inside the Oblivion gate and I can tell you killing anything here is pretty damm hard! Thus far the game seems OK, not the best I have played, but good enough to continue playing, which could be a while since I am like extremely busy on the game release.
Ah! Finally found some time to update the web-site. The main index page was rather drab and unattractive with very little on it except some techie nerdy stuff. Well it still does, what did you expect from a techi nerd, but added some spice by installing a random image display component. Looks kinda neat, if I can say so myself.
Along with that the major thing that was added were two articles from my previous blog to the article section on the site. The article on python called “Python: A maiden in a serpent’s disguise” is renamed to Python: Taming the serpent. I also added the game genres article named What are game Genres? Both these articles are from the previous blog on fastnet that went down. There are a lot more things to be added but I could not find time to salvage the entire blog. Maybe in coming week or, whenever; I am bad at deadlines!
“Hee haw haw ha! Be careful, its Friday the thirteenth!”
So what is the old superstition surrounding this morbid date in the calender? Well I decided to do some quick googling around to find out. It seems that Friday the 13th is among the oldest superstitions around. Or at least in the western world it is. “A Friday occurring on the 13th day of any month is considered to be a day of bad luck in English, German, Polish and Portuguese-speaking cultures around the globe. ” — Wikipedia. So much so they have a scientific name for it. It’s called, ok get ready for tongue twisters, paraskevidekatriaphobia or friggatriskaidekaphobia. Shush! Don’t say the words out loud, according to an urban legend, if you do so on this very date, something bad might happen to you.
Apart from this superstitious belief, there is no explanation either rational or irrational that anything bad happens on this date. People have given all sorts of wired explanations why 13th and in fact Friday the 13th is bad. Everything from prehistoric man only being able to count till 12 to a boy being drowned and then reincarnated to do unspeakable evil, which apparently forms the plot of the Friday the 13th movie series.
As far as I am concerned I have never observed anything, or nothing has ever happened to me that would suggest that Friday the 13th was bad. In fact I remember one incident a few years back when I was doing engineering and I had a lucky break on a difficult math exam on this date. I managed to pass the exam because of that. So in fact Friday the 13th has been lucky for me once. I am kinda weired, 13 has always been lucky for me, go figure! But then that’s just me. Remember,
“Even spooks don’t go out on Friday the thirteenth!”
Last weekend I finally decided to look into a long standing issue. Integrating a scripting system into the engine. There is no denying scripting systems add immense flexibility to a game engine and I intend to provide one to the O2 Engine as well. A little bit of history into scripting system for the O2 Engine; we had decided to integrate a script system for the Doofus game very early on, in the design spec itself, but dropped it later when it was found that a lot more was needed than was initially planned. A simple scripting system is very easy to integrate into the engine, but such an effort would have offered limited functionality. Though it was initially planned to have a very basic system for the engine, it was quickly realized during implementation that such an endeavor would be a folly. The O2 engine is an Object-Oriented monster and to have a superficial scripting system would not provide any substancial value addition to any future game creation process using the engine.
The main aim of any scripting engine should be to allow rapid development and in some cases rapid prototyping of game and game design ideas. This is where the problem lies. Any game created with the engine needs not only to interface with the engine code but also interface with the engine design. Game engines often have modules that interact with one another in specific and predetermined ways. This is where an engine is different from a framework or a library. An engine offers a higher degree of design abstraction than even a framework would. Not only are most of the design decisions already made, some of the implementation decisions are also made for you. This not to say that an engine can’t be flexible, in fact it has to be. You will never be able to create a game with it if that were the case. Engines allow for explicit flexibility, meaning flexibility has to be designed into an engine. Parts that need flexibility need to be designed to provide such and parts that don’t have to be abstracted away or totally hidden. A scripting system must be able to expose not only flexible elements of the engine but also expose the design of the modules and the interaction between them. Ideally it should extend the engine.
The one engine that does this with amazing effect is the Unreal engine. It has its own scripting language called Unrealscript. There is little doubt that the Unreal engine is probably the best game authoring system out there and this is partly due to the fact that it has an amazing scripting language. Tim Sweeny has a nice article on how the scripting language was designed, and he addresses some of the issues I have pointed out here. It is a must read if you plan to make a scripting language one day. It is probably beyond me currently to create and maintain a dedicated scripting language like Unrealscript for the O2 engine (maybe in the future), but that is probably the best solution to the problem. My best bet is probably picking up an existing scripting language and integrating it with the engine. There are quite a few of them to choose from, each having their merits and demerits. The ones that I am interested in are Python, Lua, AngleScript, Squirrel, GameMonkey. I plan to evaluate each one before deciding on the language to be integrated.
Last weekend I tried to integrate (my favorite scripting language) Python. Unlike the other languages, Python was never designed to be an embeddable language. It is more of a heavy weight application development language and probably will have the largest memory footprint among the others. I have also heard that it is slower than Lua and Squirrel. (I have no data to actually prove that yet, this is just hear say I got from Googling around.) It is however extremely popular and very powerful language. To be honest, I have a long history with Python and it was almost 5 years ago when I first picked it up, I have been Python fan ever since. Anyways, integrating Python using SWIG was easy. I have thus far only tried as small example, but everything went smoothly. O2 Engine however is totally another ball game. The engine has heavily templatized classes, which I am sure are going to be a pain to integrate. I also tried Boost.Python and it seemed even simpler, but needed a little more glue code.
This weekend (or whenever I get time) I will continue the integration exercise with Python. Then maybe move on to Lua and others. More information about that in Part 2.
UPDATE: The O2 Engine has come a long way after this post. It is now is directly tied into content pipelines with modelers like Blender and is capable of achieving far better lighting than what is presented here. This post talks about lighting in a fixed function pipeline which is pretty old technology. The Doofus game is released and can be found at www.doofuslongears.com.
Some preview of the lighting technology used in the game. This is not an in-depth explanation of it, but is just a preview so don’t expect technical details here. Maybe sometime later, (I will fill in the details) or you can just ask and I will be glad to explain it.
The lighting in Doofus works on several levels, ie passes. The passes are then composited to give a final image. This technology is not revolutionary and I certainly haven’t invented anything new, but I have used in a clever way so that it can run even on old h/w without much difficulty. It also gives the scene a nice cartoon effect.
First the scene is rendered normally with the basic lighting of OpenGL or DirectX. The O2 engine abstracts over both APIs and can use any one. The results of basic lighting can be seen in this image. (Click on the images to see a larger version of that image.)
This type of lighting is pretty basic. The scene seems pretty bland and devoid of any real excitement. This lighting shown here is the default vertex based lighting given by the rendering APIs.
The real excitement comes to the scene when shadows get added to the scene. In case of the O2 engine and the Doofus game I am using Stencil Shadows. Stencil shadows give hard crisp edges. That goes nicely with the cartoon theme of the game. In the next image you can see the shadows added to the scene. Along with shadows I have added a extra brightening pass i.e. Portions not in shadows are brightened up. That gives an illusion of soft sunlight (, the kinda sunlight you have very early in the morning).
Shadows add cohesion and drama to the scene. You can see a stark contrast between the two images, the one above without and the one on the right with shadow. The “drabness” of the scene is gone.
Things don’t end here. To have actual sunlit environments you have to have a super-bright component to the sunlight. Meaning, if you watch actual sunlight you will see that it is extremely bright with a halo like effect created at each shadow’s edge. For this, the engine does on more pass and applies a bloom filter to the scene to emulate sunlight.
The resulting scene looks actually sunlit, with the sunlight shining off bright surfaces. Watch the shadows boundaries closely, you will see what I mean. Now the scene looks correctly lit by sunlight.
Finally I want to show how the engine displays the sun. Observe the image on your right. You can see the sunlight bleeding through the edges of the roof just like an actual sun would when viewed across occluding geometry and notice the sun rays filtering through. The engine uses a similar variation of the multi render pass system explained earlier to achieve this effect. Just comes off looking great!
All images are actual game images captured while running the game in real-time. You can find more images of the game in the gallery section on my site.