2011
06.29

It has been a long time since we haven’t updated our progress. So we start by publishing our session material presented at Tehran’s Game Expo 2011. Major topics that we talked about was Deferred shading continued , Terrain rendering, HDR Lighting, User Interface, Engine memory management and core design, Scene management, etc.

Download: EngineDesign_EXPO2011.ppt

Early terrain rendering test

Node-based terrain material editor

Test scene with and without HDR lighting

2010
12.28

We are hiring a talented C++ programmer who is interested in computer games and interactive real-time applications, for our Faith of steel game.

If you are interested, call us on 0912-3470953 or E-mail us at jobs@tochalco.com

2010
11.29

Here is the session material we presented at GDCIran 2010, covering topics such as our content/shader pipeline, exporter, deferred renderer and shadow system.

Some pictures from presentation and demo application …

sunlight, shadows, ambient occlusion

100 dynamic local lights rendered with deferred lighting

4-split PSSM shadows

2010
11.18

We are attending GDC Iran which will be held from 1st to 3rd of Azar in “Elmo Sannat” university.

Topics we are going to discuss is about graphics and content pipeline of Faith of Steel, including our art creation and export pipeline, shader system, deferred rendering and shadow system.

For more information about other attendants and  program schedule visit GDC’s official website.

2010
11.06

Here’s the IFA Truck model created by our artists. Rendered in Max viewport using the shaders from our generated shader repository.
Modeled in Maya 2011 and BodyPaint RC12. additional texture work done in Adobe Photoshop.

Maps: Diffuse + Normal

2010
10.30

Here’s the first Iranian soldier model created by our artists. Rendered in Max viewport using the shaders from our generated shader repository.

Modeled in 3dsmax 2011, Zbrush 4.0 and BodyPaint RC12. Rigged in Maya 2011. Additional Texture work were done in Adobe Photoshop.

Maps: Diffuse + Spec + Normal

2010
10.25

This post is mostly meant for Game development studios in Iran.

There are lot’s of debates over whether young Game development companies make their own game engine or use third-party engines (like UDK, Unity, Torque, etc.)

Third Parties, The Good, The Bad

There are some good sides and bad sides choosing each approach, using thirdparty engines surely have benefits of lower costs, less research and R&D, and much less coding and testing. They will produce noticeable results in much less time, actually you can make a playable demo in the early development time.

But, there are some ugly drawbacks using these thirdparty technologies, especially the one’s that are not widely used commercially :

  • You can not be as Creative as you want, technologically or gameplay wise: Many indie engines do not support specific technology or core features that will cripple game design in the middle of development. many game development studios sacrifice their game features/design in order to fit them into the capabilities of the engine, and that’s mostly what makes a game unoriginal and generic with no innovative game mechanics.
  • You don’t have the Source Code, so watch out for bugs: Many third party engines do not come with full source code, so if there is a need for some feature, or worse, a bug in engine, you can’t fix it, and this will be catastrophic for development, and even may cause the whole project to fail. Actually many game development houses in Iran was forced to trim down their base game design or even change the whole genre in the middle of the development due to this fact.
  • Your development is always dependent on and ruled by the thirdparty engine: most of Game development houses in Iran, start with a buggy, cheap engine (no source, limited support,…) and because they become bound to the engine due to the tools and development pipeline, they are forced to continue their successor games with the same crappy technology, which will cause a series of bad games.

In-House Engines, The Good , The Bad

Developing an In-house engine, simply costs a lot more, needs experienced programmers, lot’s of R&D time, and lot’s of coding/debugging. and there is a high risk of failing, due to the fact that in Iran, programmers are more inexperienced having less knowledge than their international counterparts.

But there are some great goods, of course  if an studio could manage to create it’s own in-house engine:

  • You can be as much as creative as you can: Programmers can modify features and pipeline easily to match the designers and artists needs in order to be creative in design, you are bound by your own level of creativity and experience not the third party stuff!
  • More Extensible: As hardware and software progress through years, your company needs to adapt itself to those technologies as fast as possible to make (or to be able to make) the best possible use of hardware platform and OS, which is not true at least with cheap engines at all. In-house engines and also be ported to other platforms if such thing is needed.
  • Easier Debugging: Debugging is much easier comparing to third-party open source engines (closed source engines can not even be debugged)
  • Good Start for future projects: developing an engine, increases the knowledge of the programmers in the studio, that leads to more creative and skillful people that can bring more exciting ideas to the future projects

UDK Fever

Another example is, nowadays, Many developers in Iran are going towards developing with UDK (Unreal Development Kit), and sadly they are so confident about it that they think they can build any game with it that compares to Commercial AAA games, because it’s “Unreal Engine”, from Assassin’s Creed and Call of Duty series of games to Puzzle and Adventure games! This is not true, actually UDK is not the “Unreal Engine”, There is no source code and proper developer support,  it’s just an Editor for making Unreal Mods and make standalone executables from them, even with it’s kick-ass graphics and features achieved by some mouse clicks, companies can not and won’t be able to create a competitive AAA title. Not even in distant future. it is meant for hobbyist and students to learn the engine and make mods in order to spread the popularity of the UDK among artists and game designers.

For example, the Game “bioshock” was one of the best games of 2007 which utilizes Unreal engine as it’s base, but if you look more deeply into what efforts they have done to tweak and modify it alot for the game, you’ll see that it uses Unreal Engine 2.5 (not even for this generation of hardware) as for their base, and merely developed their own engine on top of it. like integrating Havok physics, Multi-threading, advanced shaders, shadows, lighting etc. (http://en.wikipedia.org/wiki/Bioshock#Game_engine)

Another example is “Mirror’s Edge” which is a great game by DICE, and it is based on Unreal Engine 3.0, but integrated a new BEAST lighting system, and replaced the whole Unreal Lighting pipeline to suit their graphical needs and visual style, these are just some examples of what you can NOT do with the UDK.

Note that all companies who use Unreal, actually license the engine with it’s full source code and Epic’s technical support (NOT UDK). and have their own programmers to work on different gameplay/graphics features that are needed to be added.

What Commercial Studios do ?

We have gathered a list of released commercial game titles within 2007-2010 that were critically acclaimed by reviewers, they are all top games with an average score of more than 80 (out of 100), the titles and their scores are collected from the well known site metacritic.

We just listed the Engines they have in their games and found that over 75% of AAA titles use engines developed In-House by their studios, 25% of them used thirdparty engines (most of them were Unreal Engine, the licensed one).

Here is the excel file containing the list of evaluated games in case you are interested.

In Conclusion

We Personally think that any Game development studio, especially in Iran, should have strong reasons for using Third-Party engines, it is acceptable to use cheap third party engines for Indie and low-cost games, but for Commercial games that must compete with latest western AAA titles, in common genres like First Person Shooters, Third Person Action, Open World, Role Playing, etc. there will absolutely be no future in using cheap third parties.

There is also a PowerPoint presentation file, we presented in a private meeting between Iranian game developers, held by National Iranian Foundation of Games, which discusses the above issue in more detail.

Engines, yes or no (Persian)

2010
10.19

Managing Shaders is a hard and complicated task in any Modern Engine, in this post we are going to give a brief description on our material/shader pipeline which handles the both artist side (content creation) and programmer side (runtime graphics) of the development process.

There are several major problems in a game development pipeline when it comes to content creation and its usage in game:

  • In many engines, artists doesn’t have clear view of what object will like in the final Render of the Engine, due to different material/shading systems of Content creation tools like 3dsmax, maya, etc. and the Engine itself. So in many occasions they are forced to do models in their content creation tool, export it to the Engine/Editor, Setup materials and then preview it and see if there are any problems for Textures/Materials like Normal maps, Specular maps, etc. which makes iterative modeling very time consuming and complicated for development process.
  • Many Not-so-Famous engines and most indie Engines does not have a proper Material and Shader tools in order to streamline content creation process. They support limited subset of material properties, which concludes to broken materials and cumbersome work from artists, they also does not propose a unified material system like commercial engines. For Example they only export diffuse maps and leave the rest (Normal, Specular, Ambient Occlusion maps,…)  to be set and tested by artists later.

The ideal solution would be a unified material pipeline, in which the artists could see the final look of their work inside the modeling tool itself, they also need to be able to export their models easily to the engine without any extra processing phase. Our in-house engine uses Deferred Rendering pipeline, so our shaders inside the engine are a little different than casual forward shaders.

What we did was building a ShaderAuthor tool which creates our desired set of shaders from two Uber-Shaders, A special forward lighting model for 3dsmax viewport DirectX (.fx) materials, and another one for our Deferred lighting renderer. both of them have the exact same output. We keep these generated shaders in a Shader Repository that can be accessed by the engine and 3dsmax, Artists design their models and preview them using the shaders from repository in a WYSIWYG fashion. After modifications made, models will be exported to the engine using COLLADA format or our own Proprietary model format, but at runtime, the engine loads their corresponding deferred shaders from the repository which have the exact output.

Of course it took couple of months for us to figure out the process and overcome some of the problems listed below :

  • 3dsmax support for DirectX shaders is quite tricky and undocumented.
  • Many bugs where found in 3dsmax viewport regarding DirectX materials, even with their own default .fx materials.
  • Common exporters like FCollada have limited support for .fx materials, and even discontinued support for recent versions of 3dsmax.

Here is a diagram of our Shader Pipeline in Content creation process :

As a result, we could manage to make an efficient enough pipeline that gives much more freedom and speed for the artists in order to iteratively test and export their models in to the game. As you can see in the image below two model shots are taken from the Modeling app (which is 3dsmax), and the same model exported into our engine :

2010
10.19

Couple of months ago we had done some early tests, in order to Test our Content Creation pipeline and basic renderer.

These shots are taken from the test application and the Environments not related to the game itself.

Note that Graphics quality will be considerably improved in the final Renderer as this test has no Realtime Shadows, No HDR lighting and No Lighting system.