Design Practices

Design Practices
• Some standard design practice in game development
• Memory and its types
• Optimizing memory access
• Memory alignment
• Virtual memory
• Memory-mapped file
• Naked and smart pointer
• Game scripting languages
 Some standard design practice in game
development
1. Class hierarchy and inheritance
2. Inheritance Vs. Containment
3. Virtual functions
4. Interface classes
5. Multi-tier architecture
 1. Class hierarchy and inheritance
• A good practice is to make minimum use of inheritance in classes not overdo the generalization in
designing the class architecture. Developers tend to go into generalization frenzy and end up with
class hierarchies which are 8-10 levels deep.
• This makes it very easy for mistakes to occur when someone makes a seemingly easy change in
the base class. Due to the deep levels of inheritance, a small error in one of the base classes can
trigger many things to break throughout the project.
2. Inheritance Vs. Containment
 3. Virtual functions
• Virtual functions are methods defined in the base class which can be overridden in the derived classes to
suit their own needs. Hence, each derived class can have its own implementation of the virtual function.
• In addition to this, virtual functions always remain virtual - which means that a class (D2) which inherits
from a derived class (D1) can also override the implementation of the virtual function present in the
original base class (B).
• The virtual function is a very powerful C++ concept and hence is easily abused by developers while writing
code. Many times, long chains of overloaded virtual functions are created which makes it very difficult to
maintain the base class.
• Similar to having multiple levels of inheritance, a small bug in the virtual function of the base class can
cause larger bugs in the derived classes which become difficult to identify.
• A recommended practice while changing the nature of a particular virtual function in the base class is to
rename it. This will cause the compiler to break the build and point out each and every instance where
the virtual function was overridden.
• The developer can then skip to all these implementations and compare them with the original to see how
the original function was put to use.
 4. Interface classes
• Interface classes are abstract classes which contain pure virtual functions and no implementation
logic. All deriving classes must compulsorily implement all the virtual functions in the base class.
• Languages like Java and C# have mechanisms for doing this, but C++ does not have such features
and hence these interfaces must be emulated using existing language mechanisms.
• Interface classes if used effectively, can help enforce design standards in a particular project.
Especially during the development of game engines, it becomes important for the developer to
define interfaces so that other developers writing components use these interfaces and can be
confident that their components will work correctly with the engine code.
 5. Multi-tier architecture
• A highly recommended practice in game development is to use a multitier architecture to keep
the user interface code separate from the game logic. What this means is that the code required
to generate graphics and other user interface elements on the screen is separated from the code
which is used to control the AI players, save data on the server, etc.
• This separation can be achieved by using proxy classes which call exposed API methods in
different layers to pass data and commands around.
• The benefits of doing this separation are manifold. One of the key benefits is that when the game
is to be deployed on a completely different platform, the game logic can be ported easily and a
new framework for the game-user interface can be written for the new platform, encouraging
code reuse.
• In some instances, the separated AI bots logic can be easily swapped for human players and vice
versa.
 Memory and its types
• Memory comes in various sizes, shapes and expenses. Different types of memory modules have
different uses and their own pros and cons.
• Hence, it is very important for the game developer to be familiar with the different types of
memory that he/she has access to and also to know their limitations.
• Besides the hard disk and CD-ROM/DVD-ROM, game developers need to deal with two different
types of memory systems - the system RAM and the video RAM.
• Games need to copy data from hard disks and optical drives and load it up into the system RAM
and video RAM to access them during gameplay. These are the fastest amongst the memory
systems that the developer has access to.
• There is of course the L1 and L2 cache which are the fastest in terms of access speeds. However,
since they are closer to the CPU and controlled by it.
 System RAM
• The system RAM consists of a series of memory sticks that are installed on the main board of the
system. The data in the RAM is persistent when the machine is running, and get erased every
time the computer is shut down.
• Depending upon the operating system, all applications that are started, get an addressable range
on this memory module to use. The operating system will itself keep a particular range for its own
use and allocate the remaining memory to applications as and when they demand it. The memory
that is utilized by the application can be divided into three segments:
• 1. Code segment: The code segment memory is assigned to the application when it starts by the
operating system. The size of this memory is limited and it never changes. The following are
stored in the global memory segment by the application:
• The compiled application code;
• text strings and
• virtual function tables.
• 2. Stack: The stack memory is primarily used when function and method calls are made to store
parameters and results of function calls. The stack grows as deeper and deeper function calls are
made and shrinks when functions finish execution and return values. Data in the stack memory
are stored in the "last in first out" (LIFO) manner.
• 3. Heap: Heap-based memory allocation is also known as dynamic memory allocation. This
memory segment grows and shrinks with memory allocation by applications dynamically and is
used to store persistent objects and dynamic data structures.
• Dynamically allocated memory will exist in the system until it is explicitly released by the
programmer or is freed by the garbage collector. The garbage collector helps in freeing
unreferenced objects, and also helps in reducing heap fragmentation. The differences between
stack and heap memories are summarized in Table 8.1.
 Video RAM
• The video RAM (VRAM) is a term generally used in computers to describe some form of writable
memory which stores information required by a graphics card to drive a display device. The VRAM
is really a buffer between the CPU and the display, and is often referred to as the frame buffer.
• When images are to be sent to the display, they are read by the CPU from some source (system
RAM, hard disk, etc.) and then sent to the video RAM to be converted to analog signals for the
display device. VRAM is located on the graphics card.
• Data cannot be directly written into the VRAM from the hard disk. It has to be loaded into the
System RAM first and then the processor will transfer this data to the VRAM. This is a slow
process and hence can halt your game for a second or more.
• Hence, it is recommended to load as many textures, images, etc., into the system RAM before the
program execution, so as to minimize in game loading of this information.
 Optimizing memory access
• Every time the system RAM is accessed by the CPU, the data is copied into the CPU cache. If the
data is already present in the cache, the access is instantaneous.
• If the required data is not present in the cache, the CPU then tries to locate it in the RAM and
finally the hard disk. This phenomenon is known as "cache miss" and can really degrade the
performance of a game.
• Hence, it becomes very important for the developers to design their data access in such a manner
that there is a minimum percentage of cache miss.
 Memory Alignment
• Memory alignment or data structure alignment is the way data is arranged and accessed in the
computer memory. The CPU will read and write data which is memory aligned much faster than
other data. An N-byte data type is memory aligned, if the starting address of that data is divisible
by N.
• For example, a 32-bit integer (4 bytes) is memory aligned if its starting address is 0x2000 or
0x2004 because these addresses are divisible by 4 bytes. However, if this integer was present at
the address 0x2001, it would not be memory aligned as that address is not evenly divisible by 4
bytes.
• On many Intel processors, memory is aligned automatically. However, if possible, the developer
should optimize the code so that the alignment is not dependent on the processor. Many times, if
the processor cannot memory align a particular data type, it will still access the data type, but
there will be significant performance penalties.
 Virtual Memory
• Simply put, virtual memory is memory created by using the hard disk to simulate additional RAM. This
can be a great boon if used correctly or an equally potent curse if used incorrectly.
• Basically, what virtual memory does is take blocks of memory from the RAM which have not been used
in a while and copy them to the hard disk. When the application requests that data again, the memory
block is copied back from the hard disk into the RAM.
• This is a boon because it allows developers to play with a large addressable memory. Games can need
gigabytes of memory space but they would not need it all at the same time, and hence virtual memory
comes handy in such cases. When players move to different levels or different sections of the map, a
temporary loading screen can be shown, and the data can be loaded from the virtual memory to the
RAM.
• However, anything to do with hard disk access takes a lot of time and can greatly hamper performance.
• Therefore, if code is written incorrectly to access virtual memory, and there is incorrect caching, the
game could be stalled for many moments while the processor loads up memory blocks from the hard
disk to the RAM; thus causing a very bad gameplay experience. Hence, virtual memory access should be
performed after a lot of thought and planning.
 Memory-mapped file
• A memory mapped file is a segment of virtualized memory stored on a local file or a file type
resource whose data is a byte-for-byte copy of the virtualized memory segment. This file can be
present on disk or a shared memory device which the operating system can access. The entire
contents of the file can be very easily read from and written to as if it were present in memory.
Both Windows and Unix based operating systems support the use of memory mapped files.
• Using memory mapped files is much faster than performing system-based reading and writing
operations on a file. Memory mapped files are perfect for loading resources or data into the
game. However, it is recommended to use this process for larger data sets which are at least the
size of the system's default virtual memory page. Anything smaller than that, and the process will
not be as efficient. This means that if the system's default virtual memory page size is 1 MB, the
memory-mapped files should be at least 1 MB in size or in chunks thereof.
• It is not recommended to memory-mapped files that exist on CD-ROMs, because if the CD is
ejected while the data is being read, the game will crash.