Excel Games and Versions of Excel

The first Excel games were made with since Excel 97 (8.0) became available, because it was the first version of Excel with VBA support. Now, probably a very small fraction of users works with Excel 97, but Excel 2000 is probably still quite popular, even though most people works with Excel 2002 (XP) or Excel 2003.

If you want to make a game with MS Excel, it is a good practice to assure it will work with different versions of Excel. You may easily find concise summaries of differences between Excel versions like that on John Walkenbach’s website.

The most important upgrades are the introduction of modeless Userforms in Excel 2000 and customizable protection of workbook elements since Excel 2002. Below, I will list some lesser known issues that may be important for Excel gaming. The fall into three categories: backward / forward compatibility, performance and localization.

1. Backward / Forward Compatibility

Generally, if something works in one version of Excel it should work with other versions, but not the reverse because of new features. In fact, this is not always the case. The practical issue, important for Excel gaming is working with unlocked cells. The following code:

Range("A1").Locked = False
ActiveSheet.Protect
With Range("A1")
 .Value = "X"
End With

Works both in Excel 2000 and Excel 2002, however:

Range("A1").Locked = False
ActiveSheet.Protect
With Range("A1")
 .Value= "X"
 .Interior.ColorIndex = 15
End With

Works neither in Excel 2000 nor 2002. What is quite peculiar, the code:

Range("A1").Locked = False
ActiveSheet.Protect
With Range("A1")
 .Value= "X"
 .Font.ColorIndex = 15
End With

Works in Excel 2000, but not Excel 2002 - there is no forward compatibility. And finally, the code:

Range("A1").Locked = False
ActiveSheet.Protect AllowFormattingCells:=True
With Range("A1")
 .Value= "X"
 .Interior.ColorIndex = 15
End With

Works in Excel 2002, but not 2000, since the extended option for protecting workbook elements (AllowFormattingCells) is available since Excel XP - the lack of backward compatibility.

Of course, there are several ways to copy with this problem. Instead of formatting unlocked cells, use only Range().Copy method to alter cells. Unprotect / Protect to perform the operations (it will slow down the code, though). You may also write a piece of custom code for different excel version, to make the third example above works both in Excel 2000 and 2002:

Range("A1").Locked = False
If Application.Version <> "9.0" Then
  ActiveSheet.Protect AllowFormattingCells:=True
 Else
  ActiveSheet.Protect
 End If
With Range("A1")
 .Value= "X"
 .Font.ColorIndex = 15
End With

Reading Excel version with Application.Version allows you to handle some compatibility issues. When you use it, remember that it returns a text string, not a number.

2. Performance Differences

When it comes to typical task like arithmetic calculations or copying a range, there is no difference in performance between Excel versions - new versions are neither faster nor slower than the older ones. With one exception...

Excel Games Developers may be tempted to use different shapes to show animation. Sometimes it may produces outstanding effects, like in Gijs ter Beek’s ShootemXL (available in my Library):

Each new Excel versions added new functionality to shapes, like transparency. However, this happened at the significant decrease in performance. For shapes with 3D effects and shaded background, the following code, which rotates a shape named "mystar":

For Xi = 1 To 500
 ActiveSheet.Shapes("MyStar").Rotation = (Xi*3) Mod 360
 DoEvents
Next Xi

May be about fifteen (!) times faster on Excel 2000 (you could get around 300 frames per second) than on Excel 2002, and it gets even more slower on Excel 2003. Simpler shapes are not affected that much, and they may still be animated very fast on latter Excel versions. Anyway, if you design a Shape animation on Excel 2000, make sure to test it also on Excel 2002 at above.

3. Regional Settings

Difference in Excel Version do not amount only to new vs older versions, but also to English vs Local Versions. When you develop an Excel application, keep in mind that it may be used by people who have version of Excel with different localization.

Many countries use coma as a decimal separator. Normally, it is not the problem, since Excel converts all numbers automatically to regional settings. However, if your code includes conversion of strings to numbers, you may encounter problems, as conversation function also use regional settings. The VBA code:

Xnum = CInt("10.0")

Works perfectly in English version, but will cause "type mismatch" error when run on German or Polish Version of Excel.

Whenever you add new objects like charts of shapes, give them an unique name using standard Latin alphabet (do not access objects via the default name like "Chart 3" and do not use signs outside the Latin alphabet for naming objects). Otherwise, there may be problem with accessing those objects with different localized version.

Finally, remember that if you try to access different functions of Excel with SendKeys, your code will most like fail on localized versions. The example from Excel VBA Object browser for SendKeys:

Application.SendKeys ("%fx")

Works only in English Version. In my Polish version Excel I would need:

Application.SendKeys ("%pk")

Generally, the use of SendKeys should be avoided as almost anything you could do with SendKeys can be done with other more reliable methods.