The big pit in the Silverlight development game

Originally doing "Gold X" using Silverlight is because of looking at the dark blue right-hand Silverlight game development tutorial, here like a bit, the tutorial is written very well! The basic idea of playing games is covered, which can give the novice of game development a lot of guidance in thinking mode.

However, in my personal development, release Gold X process, has found some of the Silverlight pits, here to share, to prevent everyone to make repeated mistakes.

1. DateTime Data Structure processing

In the game, if you want to use datetime data results to save time, be sure to use the DateTime.ToString and DateTime.Parse method carefully. Under different Windows machines, it is likely that the results are not as expected. The reason is that the time format for each Windows machine is configurable, and the time format used by the ToString and parse methods by default is related to the operating system settings. And some disgusting so-called operating system optimizer, the operating system time format from the standard YYYY-MM-DD HH:MM:SS changed to such as "Week X".

The problem is that after the call to DateTime.ToString (), the turn out will be the day of the month and minute information is discarded, and only the "Week X" data, and then call the parse this string when it is finished. The resulting client phenomenon is direct white screen, and the entire Silverlight application collapses.

Therefore, when using datetime, it is important to specify the time format. Use DateTime.ToString ("{Time format}") and the DateTime.ParseExact method.

2. Istabstop properties of buttons and other controls

If you use various Silverlight native controls in your game, then there is a bunch of interfaces that use visibility to hide and show. It is recommended to kill all the default Istabstop properties of the control, otherwise the problem is that an interface is hidden, when the player presses a space or enter the key, it will trigger the button's Click event or other control's various response events, there is unnecessary logic.

3, font, font library

Don't assume that using the default font will do everything.

The default Silverlight font will use Lucida Sans Unicode, and in many pirated or castrated windows, this font has been deleted, causing the problem is the direct white screen, the application crashes. The default font currently used by my application is Simhei, which is a bit less of a problem with missing fonts. If the size of the application package is not sensitive, you can still bring the font to the XAP package by default.

4, about Dispatcher.begininvoke

Novices are addicted, because they can solve the problem of non-UI threading UI. So novices don't care about 3,721, all the places need to involve manipulating UI controls.

Actually need to understand the principle of this function, in fact, I understand it is to put a piece of code into the next frame rendering callback to run, so there will be a frame of delay. Then in your game logic, the possible phenomenon is that the screen flashes, or causes unnecessary errors in the game logic.

For example, you write the logic of the inventory, when the user clicks on an item, hides the inventory and uses the item. If you put the logic of the hidden inventory in the BeginInvoke, then the error that can result is that the user clicks the item wildly before the end of the frame, and then triggers many times to use the item ... Such errors, all need attention.

You should use this function only when a non-UI thread is manipulating the UI.

5. Code Security

Do not make any secure xap packages that are completely nude presented to the player, and for security reasons you need to do code obfuscation.

A handy tool is smartassembly (out of Reflector's company), but it can have a fatal problem: The encrypted XAP package will access errors under some Windows machines! The client sees the phenomenon is inexplicably said smartassembly encryption expired. (It may be my cracked version, but pay, it is not a particularly good channel ah, and it seems not cheap.) ）

6. Resource File Security

Do not think that the resource files are encapsulated in the DLL (resource way) is safe, with reflector still sweeping. You need to write your own encryption!

7. Archive File Security

In IsolatedStorage, both the files you create and the applicationsettings are not encrypted. The risk of tampering is great, and you need to make your own verification mechanism.

And now the biggest problem for Silverlight users is that the 360 cleanup cache defaults to the Silverlight application space, and now most users prefer to direct the default cleanup cache. Will cause your istolatedstorage to clean up all the things you need to be sure to your users to understand this, so that they will 360 in the setting to remove.