Selecting a scripting engine – Part 2.

My quest for a scripting system for the O2 Engine continues. This blog is a continuation of the “Selecting a scripting engine” series. You can check out the first part here. I tried a couple of different approaches to try and attack the problem. I am currently in prototyping phase, and things and decisions can and do change drastically. Also I have to test a lot of different techniques and scripting languages before deciding upon a final solution.

Python

I continued my experiments with Python with trying to integrate Python into a moderately sized project. Something that I had worked on before beginning with the O2 Engine. It has similar structure to the O2 Engine but is comparatively far smaller. Python is easy to bind (, than what I initially thought) but the party ends there. I must say I am a bit disappointed, extending the classes is turning out to be far more difficult that I had anticipated. As I mentioned in my earlier post, to build a game successfully with the engine you not only have to work with the engine classes but also engine design. Exporting the design was not very intuitive while working with python bindings . I am not ready to give up just yet, I have decided to look into how others are approaching the problem. Maybe look into how bindings for wxWidgets are written (wxPython).

New scripting language

I have no experience in scripting language creation but recently after a long conversation with an old friend of mine I was forced to look into ANTLR. ANTLR is a parser generator which could be used to create a brand new scripting language. Before I proceed I must warn you though that I am no expert in Lexers or Parsers and have no clue how to make a scripting language. My knowledge in this area is limited and I am just about getting my feet wet in this arena. Treat my comments in this area with a pinch of salt.

OK, coming back to the main topic. Some people I chatted with recently were of the view that it would be better off in the long run to implement a new scripting language from scratch. Let me say, this remains an issue of debate between us, and I have not reached a conclusion yet. Having said that, a scripting language specific to the engine will be excellent for scalability. Grammar to tackle game development specific issues could be built into the scripting language itself. This would avoid archaic constructs that often arise out of bindings for languages like Python or Lua. With off-the-shelf languages you do have to make design compromises to get all of your functionality in into the scripting language. Again, I am not making tall claims. As is said, I am still working with this whole concept of bindings and scripting languages.

Tried my hand at ANTLR and could not make too much out of what needs to be done. But I am very much a newbie at this, and besides, I didn’t spend a lot of time with it. Just a couple of hours on a Sunday afternoon aren’t really enough to make conclusive claims. I did a lot of googling around and I can see people have good things to say about it.  So, lets see how this turns out after some more experimentation. ATM I have very little time to devote to this.

A couple of interesting events.

  • FX composer RC1

    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.

  • Silverlight

    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® Threading Building Blocks 2.0 (TBB)

    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.

  • Nintendo “for” the garage developers

    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.

    Read more about this here and here.

Are we falling into the “Uncanny valley”?

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 [1]. 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.

Blender Bender.

BlenderFor 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.

blender1.jpg

Gem asset in Blender

Blender screenshot

Power-up asset in Blender

Game using the same assets.

Assets 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.

Selecting a scripting engine – Part 1.

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.

O2 Engine: Technology preview of lighting used in the Doofus game.

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.

Basic lighting.

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.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.

Lighting shadows plus a bloom filter.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.

Sun rendererFinally 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.