High-Level Languages in the Development Cycle

[ LiB ]

There are a number of advantages for using a high-level language in a development project. These advantages include

Automated garbage collection.
High-level features like built-in pattern matching and built-in types.
Simpler syntactical rules.
Coding is less time-consuming .
Lower costs than using an internally built language.
High-level languages are easily embedded, modular, and extensible.
Artists, level designers, and even employees with little computer science experience can easily grasp and understand high-level languages.

There are also a number of reasons to not use a high-level language for a development project. These include

They are slower.
Their byte-code can be easier to hack.
Their debuggers aren't as advanced.
Legal concerns could arise when using open -source code in for-profit development.

The key, then, is to know when to use the tools and when not to use the tools. Although Python, Lua, and Ruby can be used to write complete games , they usually aren't. In a typical shop they serve a specific function, where their strengths can be leveraged.

For instance, in a Python game, the main looping engine code may look something like the following:

 # Update any input from the User Input.GetInput()  # Process user Input Input.ProcessInput() # Use tick to up-date the graphics scene Graphics.Tick() #Redraw the graphics Graphics.Redraw()

There is nothing that says each of the calls must be Python, however. Python can be calling to modules written in other languages. The Graphics.Tick and Redraw methods could be ANSI C or even assembly. Python could be running the game loop and calling out to C only when needed for CPU- intensive operations.

In a project that mixes languages, you'll likely see two languages, as shown in Figure 12.1. One will be high-level, used for generic tasks, and administrative. The low-level language is used for specific time-saving tasks (see Table 12.1).

Figure 12.1. Typical roles of partnered languages

graphic/12fig01.gif

Table 12.1. Partnered Languages

Typical High-Level Language Tasks	Typical Low-Level Language Tasks
Call low-level language	CPU intensive tasks
Game code default	Graphics/rendering system
AI	Collision detection
User interface	Tasks with many quick iterations

Perhaps the biggest benefit to development is using a scripting language to drive data. Over the years , companies have discovered that it is not a good idea to bury game parameters like movement speed, character strength, and unit hit points for exampledeep down in executable code. If these attributes are buried, play testing becomes an extremely lengthy process because every little change must be made to complex, difficult-to-read-and-understand code, and then there must be a lengthy recompilation and re-building of the entire game. Rebuilding a game with a large code base from scratch can take hours, or even a whole day, and the act of recompiling actually risks introducing new bugs or issues.

If game parameters (like movement speed, character strength, and unit hit points) can instead be controlled with a scripting language, they can be changed almost on-the-fly . Play testers could change statistics and attributes until the balance of the game makes sense without having to go back to a development team.

Also, game play details can be really time-consuming to program in C or C++. If high-level scripting is running the AI, the player attributes, or the quest flow of the game, then the C coder will be freed up to focus on the engine code. Designers can easily fiddle with the settings of the higher-level code and try out parameters that they normally would have to delve deep into the engine to get to.

Even better, if the separation between the engine and the game code is severe enough, the base low-level engine can actually be used for multiple games and multiple releases. The C/C++ engine stays static while the high-level scripts define new parameters, new game objects, and new goals and missions for the new player characters . Since many companies claim that the biggest problem they face is resource management, you can see why many have adopted this release philosophy.

[ LiB ]