This article was published in The Journal of Advancing Technology, Volume Two, Summer 2005.
As a teenager, I was a huge fan of the TV show, MacGyver, starring Richard Dean Anderson. MacGyver was produced by Henry Winkler, John Rich and Paramount Pictures, and aired on ABC for seven seasons between 1985 and 1992.
The character MacGyver was a former Special Forces agent who worked for a think tank organization called the Phoenix Foundation. MacGyver was hired to solve problems that no one else was capable of solving, and he used his vast knowledge of science (mainly chemistry) to come up with novel solutions to the problems he faced, most of which were life threatening.
I developed a bit of a reputation as a problem solver among friends, relatives and fellow students. I came up with interesting ways to study for exams. For instance, rather than cramming the night before an exam, I would cram two nights before the exam, and then allow my mind to relax. I found that this method allowed me to bury the information more deeply in my mind and retain facts more effectively. This was like storing information rather than dumping raw data into my mind, as is the case with a typical €œexam cram,€ the goal of which is to pass a test rather than to learn something.
What is Lateral Thinking?
The phrase “lateral thinking” was coined by Edward de Bono, a Rhodes scholar and the author of more than 60 books, including the bestsellers Six Thinking Hats, The Six Value Medals and Lateral Thinking: Creativity Step by Step. According to de Bono, lateral thinking treats creativity as the behavior of information in a self-organizing information system, such as the neural networks in the brain. In other words, creativity is not a gift but a learnable skill that everyone can utilize when thinking creativity is a novel feature of the human mind.
The concept has deep roots in many disciplines and is most often illustrated by historical military scenarios wherein a military strategist is able to overcome a numerically superior enemy. How do you defeat someone who is much stronger than you? Obviously, if you cannot beat an opponent head on, you must come up with alternative strategies, and many such life-and-death situations throughout history have required lateral thinking.
According to Dr. de Bono(1), one practical way to solve a problem using lateral thinking is to break up a problem into elements€”or to itemize the factors in the problem and then recombine them in different ways. The recombination of elements in a problem is the part of the process that requires the most creativity, although random combinations often do reveal new solutions that one might not have otherwise considered. Edward de Bono describes this type of thinking as water thinking, as opposed to rock thinking.
What are water thinking and rock thinking? Water is a malleable substance a liquid that has the ability to fill any space. Thinking in this manner allows us to adjust our perceptions and perceive things in different ways. Rocky concepts, on the other hand, cannot be used to solve a myriad of problems because rocks are not malleable. Imagine that you have been encouraged to think a certain way throughout your life. Given that, even if you are a very creative person, are you truly able to think creatively?
According to de Bono, lateral thinking is a skill that can be learned. In fact, de Bono teaches that creativity is not a gift, but a skill, and that it can be learned through practice. Water thinking allows us to capitalize on the innate problem-solving capabilities of our brains, while rock thinking is limited to pre-packaged, if you will, problem-solving methods.
How can you learn to think laterally? You can start by changing your perceptions and assumptions when you approach a problem(2). This is called perception-based thinking using your brain’s innate skill at pattern recognition. In other words, if you allow your mind to perceive things without allowing your conscious effort at logical thought to get in the way, you may find powerful and elegant solutions to problems.
As you might imagine, even thinking about lateral thinking provides new boundaries for us. If you begin to see yourself as a rock thinker, and work toward expanding your boundaries, to become more of a water thinker, then your inner thought processes are changed. What happens when you being to think in a different way such as laterally? You are causing a physical change to take place in your brain. I don’t know about you, but I am absolutely fascinated by the prospect that, by thinking, I am capable of changing the neural connections in my brain. This gives the phrase “change of mind” a very tangible, literal meaning.
Applying Lateral Thinking to Game Programming
Game programming requires a whole new layer of thinking above and beyond the techniques taught by traditional computer science (CS) and computer information systems (CIS) curriculums. Unlike a database application or a word processor, a game is a dynamic, fast-paced, highly complex computer program that tickles three out of five of our senses (sight, hearing and touch, excluding taste and smell). Database programs simply do not need to render complex shapes, process user input and coordinate input with an object, check for collision with other objects on the screen, and so forth.
The query statements used to retrieve and manipulate data are the most complex aspects of a database application. In other words, a game programmer must write code that is entirely asynchronous and maintain a large amount of state-based information, while a traditional application is written to operate synchronously. In order to write a game, one must begin to think asynchronously in order to truly make a good game.
Not only must a game programmer exhibit vivacious creativity, he must learn to apply creative problem solving to the very logical process of writing source code to construct a complete program.
To understand the process that a game programmer must go through, imagine the work of a master architect such as Edward Larrabee Barnes(3), who is famous for having used the modular approach to architecture. Barnes preferred to use pre-formed concrete, stone and glass panels that not only reduced construction time, but also enforced modularity in his structures. Barnes was able to design complex and beautiful structures using simple building blocks, while also remaining flexible in his designs.
Game programmers, not to be confused with game designers (who are comparable to movie directors), must follow the same coding standards and guidelines, and use the same tools used by CS and CIS programmers (who produce commercial and business application software), but are also required to solve very difficult problems on-the-fly; that is, while producing a steady flow of useful code for a game. The ability to solve problems without pausing for any length of time to work out such problems is a developed skill. Game programmers must use creative problem solving “lateral thinking” not just to get the job done, but to remain actively employed.
If you approach a game programming problem head on and try to solve it with brute force methods, this is like attacking a numerically superior army and counting on the skill of your soldiers to overcome the odds. The problem with this approach is that a numerically superior army will always win an engagement if attacked head on, all other things being equal. Therefore, it is essentially a suicidal tactic.
The best approach for a game programmer, the only approach that the most successful game programmers have learned, is to solve programming problems laterally using a creative approach. For instance, suppose you are a 3D engine programmer who is working on the very core engine of the game upon which an entire project relies to succeed. To say that you are under pressure to produce high-quality code that is fast and efficient is an understatement–in fact, it is simply a given requirement of your job. You must produce an extremely fast 3D engine with a limited amount of time. Do you tackle the problem head on, with a limited amount of time (e.g., a limited number of solders) or do you find an alternative way to write the code?
What about the popular team technique called brainstorming to solve problems? Brainstorming is a technique invented by the advertising industry to come up with seemingly random approaches to build product awareness. This technique may be useful for the recombining process as I explain below, but not solely as a problem-solving tool. Brainstorming can, at best, give you a list of goals that you would like to achieve; brainstorming should not be used to come up with solutions.
One method to solving problems laterally is to divide a problem into elements and then recombine them in different ways in order to produce new and unexpected results. Your 3D engine must have the ability to load a 3ds max file containing a game level (i.e., “the world”), and it must render the level, containing mountains, rivers, lakes, trees, houses, rocks and many other natural objects and constructed buildings. You start by writing the code to draw textured faces (also known as “polygons”) on the screen. You take it to the next step by drawing simple 3D-textured shapes. Your third step is to load a 3ds max file describing an entire game level broken down into individual meshes (a collection a faces/polygons). From that point forward, the engine is refined and features are added, and the rendering code is optimized.
A Lateral Thinking Exercise
How might you use lateral thinking to produce the game engine as quickly and efficiently as possible? More importantly, how might you write the engine with capabilities that the designer and other programmers might not have foreseen? In other words, you want the engine to be flexible, customizable and extendable. First, break down the problem into a list of elements such as the following (this is just a simplistic list):
- Faces or polygons.
- Meshes or models.
- Textures or bitmaps.
- Rendering the scene.
- Game loop.
At this point, you want to come up with a list of unrelated words, perhaps at random, and this is where brainstorming may be helpful, but not in every instance. It is most helpful to write down a list of unrelated words or phrases such as the following (note that I include alternate versions of each word to help with the thought processes):
- Tree or forest.
- Freeway or road.
- Book or library.
- Phone or communication.
- Steel or metallurgy.
Now apply each of the items in List 1 with each of the items in List 2 and note any interesting possibilities that the combinations reveal to you. This is where a cultivated skill in creativity may help because associations are not always obvious:
- Faces/polygons AND tree/forest.
- Meshes/models AND tree/forest.
- Textures/bitmaps AND tree/forest.
- Rendering the scene AND tree/forest.
- Game loop AND tree/forest.
Examine these combinations: what associations can you come up with? Remember, this is an exercise in pattern recognition, not in logical step-by-step problem solving. You want to allow your mind to come up with these water associations without allowing your rocky assumptions to affect the result. While everyone€™s results will be different, a real benefit to this type of exercise arises when several members of a team are able to find some shared associations. Here is what I have come up with:
- Can new polygons be grafted onto existing polygons like leaves on a branch?
- What if the game engine will allow new models to grow or spring up without being loaded from a file, and what if we use #1 above to help facilitate this? Then might we have just one tree model, and the engine may create thousands of variations of that tree automatically?
- A forest is home to many animals as well as trees. What if the engine has the ability to construct a more compelling and realistic game world that is not entirely designed by using a large store of textures and models?
- Perhaps the rendering engine will have a main €œtrunk€ that does most of the work, and any special effects or features can be added on later using add-on modules, which are like branches.
- The game loop needs to be as fast as possible at rendering, but timing must be maintained for the animated objects in the game. What if each object in the game is spawned off as a separate thread, like a seed falling from a tree in the forest, and that thread is self contained with its own behaviors in the game?
As you can see, some of these associated results are interesting, and some are probably not useful at all, but the important thing is to follow this technique and do the associations with the other words and word phrases in the list. After coming up with associations for tree/forest, you would move on to the second item in List 2, (freeway or road) and see what associations you can make. This process need not have a finite list of words either. You might grab a random word out of a dictionary and produce a hundred or more interesting associations, any one of which may help you to solve an otherwise intractable problem.
As applied to game programming, you can see that even a trivial example produces some fascinating possibilities. And that, as far as lateral thinking goes, is the whole point of the exercise. MacGyver used intelligence, a vast knowledge of science, and lateral thinking to earn himself a reputation as the man to call when a difficult problem arises. Likewise, as a game programmer, if you learn to use your intelligence, your vast knowledge of computer systems and a heavy dose of lateral thinking, you may earn your own reputation and be surprised by the difficult problems you are able to overcome.
2. de Bono, E. (1992). I Am Right€”You Are Wrong: From This to The New Renaissance: From Rock Logic To Water Logic. London: Penguin Books.
3. de Bono, E. (1999). Six Thinking Hats. Boston, MA: Back Bay Books.
4. de Bono, E. (2005). The Six Value Medals. London: Vermilion.
5. de Bono, E. (1973). Lateral Thinking: Creativity Step by Step. London: Perennial.
6. The Great Buildings Collection. Great Architects. Edward Larabee Barnes, United States. http://www.greatbuildings.com/architects/Edward_Larrabee_Barnes.html
Winkler, H., & Rich J. (1985-1992).