Category Archives: O2 Engine

Selecting a scripting engine – Part 2.

by

1

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.

Selecting a scripting engine – Part 1.

by

4

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.

by

0

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.