How are video games created? Creating video games, of course, involves lots of programming. 'Programming', if you didn't already know, is the process of how a person assembles the instructions and commands that tell a computer how to accomplish a specific task. Programming consists of 2 main components: variables and code. Variables are the entities within which information is stored. Code, on the other hand, consists of the instructions that act upon the variables. What did creating Arena of Doom involve? Arena of Doom involved a special type of programming called object-oriented programming ("OOP"). What sets apart object-oriented programming from average, everyday, standard programming? OOP is far superior to the regular programming approach. OOP, however, does not discard the use of "structured" programming (the 'standard' means of programming just mentioned), but rather takes over where structured programming leaves off.
In what way is OOP superior to "structured" programming? OOP is superior to normal "structured" programming not in the sense that OOP code can perform tasks that structured programming can't, but is superior rather because of how it organizes its code and variables. The manner in which OOP code and variables is organized, you see, has a very direct, noticable effect upon how easy programs are to update, modify, and maintain. How, then, does OOP work? Understanding how OOP works means understanding the 3 fundamental concepts that make OOP what it is. These concepts are referred to by the terms encapsulation, inheritance, and polymorphism. All 3 of these programming techniques are made use of, as one will find, in the downloadable Arena of Doom program source code.
Writing code that acts upon variables is a normal part of the programming process. When modifying and updating programs written in the traditional manner, however, a problem can arise: when one attempts to modify or update such a program, changing any given module of code within the program can greatly affect modules of code in other parts of the program. Changing a single module of code, therefore, can result in a chain-reaction of unintended programming difficulty - creating a monotonous, tangled web of programming confusion. Yet this could have been avoided if one made use of encapsulation: one first divides the program into distinct aggregates by identifying the active entities that exist within the program. Afterward, one decides upon the variables and code that best express each active entity. In doing so, the variables associated with these entities are grouped along with the code that refers to those variables. As a result of this grouping, the code will never refer to any variable beyond the variables to which the code is assigned - solving the problems discussed above. This organization of a program into such active programming entities is the practice that lies at the very heart of object-oriented programming. Encapsulation not only makes programs much easier to update and modify, but also makes the program much easier to understand: because the programmer knows precisely what variables it is that the designated code refers to, he can, possessing that knowledge, more easily assign meaning to the code. This grouping of code and variables makes possible the writing of programs that are both potent and powerful - programs in which the programmer need not closely examine parts of the program to understand their basic purpose. Furthermore, and finally, grouping variables with the code that acts upon it makes it much easier for the programmer to "debug" - work through the errors of - the program he is writing.
Grouping code and variables in this manner makes possible a degree of efficiency and performance not possible with the traditional manner of programming. Once the program has been arranged into the groups representing the active entities within the program (as mentioned above), the code and variables they contain can become code and variables that can be reused in other programs that "inherit", so to speak, the active entities presented in the original program. Furthermore, new, additional code can be added onto the code of the original active programming entity, and extra variables can be added as needed. In fact, it is possible that multiple programs can reuse the same code. Being able to reuse code in this manner brings into being yet another aspect of object-oriented programming, to be discussed next.
Reusing code can in fact be a very powerful tool. At times, however, when the code of an active programming entity is reused in other programs, there sometimes arises the need to use the reused code in a way that is unique to each program. In this situation, the programmer specifies the way in which the reused code is different in each program from the code of the original programming entity. When one of the programs reusing the code is executed, the computer uses its knowledge of which program is running to determine which version of the reused code is to be used. This ability to give multiple meanings to code obtained from a single programming entity without doubt provides a high degree of performance, allowing programs to be written in a flexible, generic fashion.
C++ is an object-oriented programming language, and is the object-oriented programming language in which Arena of Doom is written. In fact, most video games are written using object-oriented programming, because the manner in which video games are required to be assembled happens to be highly compatible with the interface that object-oriented programming provides.
Arena of Doom was compiled using Microsoft Visual C++ 1.52. Later versions of Microsoft Visual C++, however, may not be capable of compiling the downloadable source code. C++ compilers made by other companies, in turn, may not be able to compile the source code either. However, this is not an issue, because a compiled copy of the game is made available. It must be realized, then, that the purpose of offering the downloadable source code is not so that it can be recompiled, but rather so that those who view it can learn of the details behind how the game works, obtain a greater knowledge of C++, and perhaps use that knowledge for their own programming purposes.
The 2 main files the Arena of Doom source code consists of are ARENA.CPP and ARENA.H. ARENA.CPP, first of all, is the file that contains a copy of the main C++ game source code. ARENA.H, in turn, is the file that contains information vital to the assembling-together of ARENA.CPP. If you desire to obtain a quick summary of the program behind Arena of Doom, refer to ARENA.H. If you desire to learn of the involved details of how the Arena of Doom program works (recommended for those who know C++), on the other hand, refer to ARENA.CPP.
To view either ARENA.CPP or ARENA.H using your Internet browser, simply click on the "view ARENA.CPP" or "view ARENA.H" link found near the bottom of this page. Press the "BACK" button of your browser when done examining the code.
Is the source code meaningful to you? If so, you may desire to download a copy of ARENA.CPP and ARENA.H to your hard drive. To do so, go through the following steps:
To view one of the files at a later time:
| ARENA.CPP is the file that contains a copy of the main C++ game source code. | ARENA.H is the file that contains information vital to the assembling-together of ARENA.CPP. |
| view ARENA.CPP | view ARENA.H |
| file size: 158K | file size: 34K |
If it was your wish, you should now have a viewable copy of ARENA.CPP and ARENA.H on your hard drive.
Click arrow to return to Arena of Doom main page.| Comments, questions, feedback: jsfsite@yahoo.com |