General introduction to RPG.XLS Engine (Chapter Three)

This chapter presents Performance Optimization & Managing RPG Stats

Previous chapter deals with Basic Object Model & Conversation Engine

Some examples in Performance Optimization

Both VBA interpreter and Excel as gaming platform are pretty slow, and for the complex game it could be quite challenging to optimize the code to assure its proper speed. While RPG.XLS has generally "turn-based" design, and there is no need to control much action in real time (as in arcade game) there are still many issues involved in assuring the satisfactory performance, as there are a lot of computations and manipulations with Excel objects executed with player’s each action.

There is a tremendous difference in speed between accessing VBA objects (like writing to VBA arrays) and accessing native Excel objects like cells or shapes, the latter being much slower. If there is a tradeoff possible, one should always try to increase internal computations and decrease the number of manipulations with Excel objects.

The element which consumes the most resources in Excel games is, of course, graphics. RPG.XLS uses cell based graphics, with the main screen comprising of 19 x 19 tiles, that is, 361 cells. Excel could generate around 400 to 500 tiles per second, thus, drawing the screen cell-by-cell each time would be very inefficient, as it would take around 800 milliseconds.

Another option is to draw entire map once and then just copy its fragment with one copy-range operation. Due to Excel economies of scale, this would require only several milliseconds. However, the entire stage map for the game will consist of 209 x 209 tiles, that is, 43,631 cells. Drawing entire map would thus require almost two minutes, forcing the player to wait quite a long time when switching stages.

The actual engine was optimized the following way: at the beginning, only a small fraction of map, 27 x 27 cells is generates, which takes less than two seconds. Then, with every movement, a small additional faction of the map is drawn, usually 27 tiles, which requires less than 100 milliseconds, and thus it does not interfere with even the fast protagonist’s movement. The schema below shows how this area is determined.

Note that the game keeps track whether the given cell of a map was already generated. If the cell was drawn, it will be skipped when generating algorithm targets its area second time. This helps further to optimize performance and free resources for other elements of the engine. The player neither has to wait too long when switching between stages, not does he suffers from any observable slowdowns during the explorations.

Area Map - the map of the stage showing only explored area - constitutes a very important addition to any RPG game. It becomes very useful when player has to explore difficult and dangerous areas like dungeons. Many careful players would like to look at the area map quite frequently, like once per minute or two. Thus, the map should be convenient to use and does not require much time to load.

In RPG.XLS, Area Maps consist of colored cells zoomed out, with one-to-one relations between cells and area tiles, thus, the area map of the large stage will be as large as 209 x 209 cells. Even though changing the interior of a cell is relatively fast (compared to other operations), drawing entire map cell-by-cell would be rather slow, taking more than 5 seconds.

5 to 6 seconds interval is not a lot of time, but still it could be inconvenient if players frequently look at the map. The first very simple optimization was to represent open areas by blank space, that is not drawn during map generation. The second one was to merge horizontally areas represented by the same color, and color the interior of such ranges rather than single cells, as illustrated below.

The optimizations allowed to reduce the time needed to draw entire Area Map by almost three times, to below two seconds. This is a good example how some additional VBA calculations (merging same-color areas into ranges) could easily help to optimize operations on Excel objects.

Managing RPG Stats

Both in pen'n'paper and computer role playing games, there are frequent random checks associated with player character’s skills and attributes, like rolling a dice to determine whether you hit the monster and then rolling it again and adding to Strength attribute to determine the damage you deal.

While the number of attributes and skills in RPG.XLS is rather modest, there are lot of interactions and modifiers affecting the random rolls. For example – you want to determine the Strength rating of the player character to calculate whether he is able to break through the locked door. The base value of his strength attribute stored in one variable is 7, but he is also very hungry (it lowers this attribute by 1) and drunk Strength boosting potion that rises this attribute by 2, so his actual (net) strength is 7 - 1 + 2 = 8.

I would like to create the role playing game that pays much attention to details. The example below (from 0.75a version of RPG.XLS engine) shows how drinking a strong spirit makes the character drunk and it affects his agility, perception and charisma. There will be a lot of such micro-management effects in the game:

Tracking all this modifiers every time would be almost impossible and would lead to very inefficient code. To solve the problem a Class Module was created in version 0.75a of the engine to simplify the handling of characters' statistics.

Now, to get the actual rating of Perception attribute of player character it is enough to use XCRST.GetPer in my code. To get the base value (without any modifiers) of Perception of certain creature one has to use XCRST.GetPer(1234, 0) – where 1234 is character's ID, and 0 denotes that base not actual attribute should be returned.

Of course, the detailed skill and attribute system is not an exercise in complexity in itself. The game will frequently perform different checks based on characters’ statistics. Even such trivial thing like the distance at which you could read the road sigh depends on characters' Perception attribute:

Using the Class Module is not necessary, yet very convenient way to handling a complex database of inter-related and frequently changing statistics. It simplifies the code, makes is more transparent, and allows to easily make amendments in stats-calculation methodology.

This section will be expanded in the future, on the basis of new versions of game engine. Should you have any question or comments regarding RPG.XLS, please email me. Your feedback is much appreciated:

Excel is a registered trademark of the Microsoft Corporation®
All contents Copyright © 2006-2008 Bartlomiej Dzik