Garshasp Development Blog

A very serious stage has started out recently in the development process and that is putting all the elements of the levels together and preparing for play testing. We are currently using the in house level editor, Iranvij, to setup the level physical representations, graphics, interactable environment objects and enemy NPCs. Switching to “In Game” mode in the editor is quite handy for the designers to play test right on the spot and make sure everything goes together well.

The in house scripting system has reached a level which has made it almost Turing Complete, since it supports sequence for commands, some kind of primitive selection constructs and a good support for repetition.

All enemy AI behavior, main player behaviors (Hierarchical Finite State Machines) and environment interaction and main game logic are being handled on this scripting layer which provides a flexible framework for the game designers to prototype and test ideas. The whole mechanism needs some testing and tweaking before it becomes fully re-usable as a game scripting framework.Performance tuning this interface layer would be the next stage, as we usually plan for performance issues and follow the big saying of Knuth which is :”Early optimization is the root of all evil!”

On another end, we are researching into some good techniques for crash reporting so that the development team can find the problems found while the design or testing team are working a bit easier. This crash handler is one in which we are investigating at the moment.

For months we saw ourselves come to the same major question whenever we wanted to plan for the level creation tasks. The question was basically, “Where should we start from?”.

There are always at least three main poles which need proper attention in order for a well balanced output, these are 1- Visuals (Graphics) 2- Game Play (Fun factor) 3 – Technical Feasibility (coding). If you want to create a level which looks great, is really fun to play and can be created considering the technical constraints or project constraints, then the three elements seem like they form a closed loop and it would be hard to decied where exactly the process should start from. Should we worry about the visuals first? Should we see what we can achieve technically and constrain the rest or should we consider the fun gameplay elements and then add the other layers?

There seems to be no strict answer to the above issue and after lots of discussions, we came up with a specific methodology to perform which we are following currently. Seeing a presentation from this years GDC from the Bioware team which was used for Mass Effect 2 strengthened our selected methodology.

What we are doing currently is to come up with the general visual concepts first, prepare the first phase for the level map which is 2D and then a 3D spatial map using boxes, fill it with the first stage of 3D models, play test the crude (un-textured) level in the game and implement the necessary code features and then re-iterate the loop by polishing the concepts, the 3D elements and gameplay testing and level design tweaking.  We have planned for four iterations. So far it seems to be a good choice although we need more time to really be able to tune the methodology and level development pipeline.

This task is very critical since it requires very close collaboration between members of different departments. Its quite fun also.