Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Microsoft Excel: Revolutionary 3D Game Engine?
View All     RSS
September 21, 2021
arrowPress Releases
September 21, 2021
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Microsoft Excel: Revolutionary 3D Game Engine?

March 6, 2008 Article Start Previous Page 4 of 5 Next

Office-level Graphics Abstraction Layer

If there is no need for ECG's advanced features, like resizable pixels and variable aspect ratio then Excel's other rendering subsystem -- the Office-level Graphics Abstraction Layer -- is a possible choice.

OGAL provides additional functions (polygon drawing, filling, etc), higher performance and compatibility with other applications of the MS Office package. This compatibility can be extremely useful if the 3D application has to be ported to (e.g.) Word.

A curiosity of the rendering process is that rendering is performed on a separate layer in front of the worksheet, so the subsystem can work without modifying the existing content of the worksheet.

This feature makes it possible to run OGAL and ECG side by side, or show the background calculations and their results on the same screen -- which helps the debug process. A screenshot of the running OGAL subsystem can be seen below (Figure 8).

The separate rendering layer in front of the worksheet is easily observable on the picture: while the rotating cube is rendered on this layer, the 3D calculations performed by the engine can be seen in the background.

Figure 8: Engine in action (with Office-level Graphics Abstraction Layer)

A typical example of the OGAL subsystem's refinement is the available polygons: whereas the current 3D engines operate with triangles, the OGAL supports other polygons (like quadrangles, pentagons, etc.) as well.

There is no need for a separate background buffer because it is handled by OGAL. Colors can be set by the usual 24 bits and the subsystem provides an additional alpha channel for the transparency as well. Again, the demonstration file is available in our example Excel engine files - for those who shun real-time, here's a video of it in action:

Warning: Only for very-very determined experts!

Paradigm shift

Sequentiality essentially influences our actual programming paradigm. It can be found in every corner of the programming vocation: day by day thousands of programmers code their algorithms row-by-row, create the executables step-by-step (as defined in the makefiles), debug the executables command-by-command.

Thousands of different programs and billions of source code lines were created with this sequential approach. Sequentiality pervades our current programming paradigm so much that programmers don't question its reason for existence and take its limitations for granted.

Note: Please don't underestimate the power of habit! Probably you have a QWERTY keyboard in front of you which has intentionally the most uncomfortable button layout!

It's not a joke: the QWERTY layout was originally created for the typewriters in the 1860s when the jam was a difficult technological problem. The QWERTY layout ensures that successive keystrokes alternate between sides of the keyboard. This layout helps to solve the typewriters' jam problem but it causes the greatest possible demands on your fingers and joints. The wind of change has blown away the typewriters and their 150 year-old technological problems but we still use the most uncomfortable keyboard layout these days!

It is the power of habit.

(For further information visit

Excel breaks with this habit and exceeds sequentiality. Its revolutionary approach can be observed in the following fields:

  • Non-traditional source code
  • Non-sequential debugging
  • Instant feedback (without a sequential make process)

Non-traditional source code

It is commonly accepted among developers that source code (and the algoritms encoded in source code) handled by the current development tools require a sequential top-down reading and interpretation. Figure 9 illustrates this sequential top-down interpretation.

Figure 9: Traditional, top-down interpreted source code

We accepted this sequential, top-down mentality so much that interpretation of an unusually formatted (but syntactically correct) source code can be immensely hard. If you would like to test your thinking then you can find some challenging examples at These examples are suitable only for the very determined readers, as they contain unusual line-breaks and tabulators as well.

Article Start Previous Page 4 of 5 Next

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Development Director

Loading Comments

loader image