2009
Typical online games have a start screen, levels, storyline, transitions, high scores, chat, and other features that can take significant amount of time to develop. There are challenges when building online games, such as full screen support and scaling; speed optimization; animations; real-time calculations. Learn how to develop compelling Silverlight games faster, by using a base framework for the common game elements outlined above. / Easily Create Engaging Online Games
Contents
About the Author 4
About this Document 4
Goal 4
Scope 4
Target Audience 5
Getting Started 5
1. Introduction: Why Care About the “Details”? 5
2. Components of an Online Game 6
3. Screen Layout 6
Visual Layers that Make Up Your Game 6
Game Interface Layer 7
In-game Controls Layer 7
Sounds Layer 8
Start Screen Layer 8
Main Screen Popup Controls Layer 9
4. Silverlight Game Internals 10
The Game Loop 10
Some Classes That You’ll Likely Use in Every Game 13
The Game Class 13
Defaults Class 14
Globals Class 15
Enumeration Classes 16
Sounds Class 17
Other Classes 18
Keyboard and Mouse 18
Full Screen Support 19
Returning from Full Screen to Embedded Mode 20
Aspect Ratio 20
More Info 22
Transitions 22
Sound and Music 23
5. Networking 24
Score 25
Chat and Multiplayer 28
Network Speed Optimizations 28
6. Host Integration 30
7. Cheat Protection 32
8. Tips and Tricks 32
9. Summary 33
About the Author
Nikola Mihaylov is a Software Design Engineer in Test at Microsoft, working on the WPF/Silverlight tools for Visual Studio. Nikola’s first Silverlight game topped the http://silverlight.net charts for 2 weeks after its v1.00 release in 2008. Contact at or .
About this Document
Goal
This document will help you get started and quickly develop compelling Silverlight games.
It will provide you with a base framework for many repeatable game elements in order to save you significant development time, reduce coding mistakes, and increase traffic and desirability of your game.
As a running example, I will use the latest (at the time of this writing) release of a game called Shock: http://nokola.com/shock
You can download the first release of Shock’s source from here: http://nokola.com/sources/ShockSource.zip.
The source code is free for personal use only.
Scope
In the next few chapters, we’ll discuss the following:
Chapters 1 and 2: What makes up a Silverlight game?
Chapter 3 – Screen Layout: Laying out game elements to allow easy update to the UI, reduce XAML and code-behind clutter and have fewer bugs.
Chapter 4 – Game Internals: Discusses the typical classes that make up a game, how to make use of mouse and keyboard in code, how to support full screen, add transitions, and produce sound.
Chapter 5 – Networking: In this chapter you will learn how to setup a network connection to retrieve highscore list from a server, and some techniques to make your game load fast and look smooth. There is a short Chat and Multiplayer section that I intend to expand in the next release of this writing.
Chapter 6 – Host Integration discusses one important piece of an online game – interaction with the host browser.
Chapter 7 – Tips and Tricks describes some methods that you can use to increase traffic to your game, enhance game play, or just make your game look better.
Not in scope of this document:
· Game play and game idea
· Authoring graphics content
· Authoring sound content
Target Audience
I assume that you have good understanding of XAML, Silverlight and basic understanding of Web Services. You probably developed a Silverlight application in the past and are ready to take on bigger challenges. Or you are a game enthusiast who wants to develop a good online game.
Getting Started
If you accidentally bumped into this document, or you’re just beginning to work with Silverlight, I recommend going to http://silverlight.net/GetStarted. The resources there will help you get into the Silverlight development world quickly.
As you are reading through the document, check out this game: http://www.nokola.com/shock. I used screenshots from Shock to illustrate various methods for Silverlight game development.
You will also see references like this:
These references point into the first release of Shock’s source code, which is free for personal use and available here: http://www.nokola.com/sources/ShockSource.zip.
I intentionally removed a lot of the game’s functionality from the published source code in order to make it easier to read and understand. The live game on http://www.nokola.com/shock contains more functionality than the published source code.
1. Introduction: Why Care About the “Details”?
When I first started making games in high school I was mostly paying attention to the “game engine”, and completely overlooked other capabilities that I perceived as fit-and-finish back then.
I found out later that many hobbyist or even some advanced game developers are also not paying enough attention to “small” details – such as a good high score table, chat capabilities and other. The end result was: they never finished their project, or were lacking some taken-for-granted feature (e.g. scoring) in their game. They were making the same mistake as I did.
Having the right “fit-and-finish details”, can increase your web traffic tenfold. This document will help you easily implement the right capabilities to make your good game a great one!
As you read through we’ll be building a library of different components that you can reuse later.
Here are few examples of why should we care:
· Advanced high-score table: increases the time people play a game and they return more often. I increased the traffic to Shock more than twice using small tweaks in the high-score table.
· Terms of use, credits, login and other repetitive components are better done once and forgotten. It’s best to not reinvent them every time.
· Features perceived as “small” can take significant time to develop right.
2. Components of an Online Game
A compelling online game has some of these features:
· Startup screen
· Instructions screens
· Levels and transitions between levels
· Storyline
· Sign Up/Login
· Terms of use
· Credits
· Secret codes/Development (Staging) UI
· Send to Friend
· Embed link
· Feedback/Rating link
· Chat
· Community
This is a not all-inclusive list of items to think about when designing your game. You probably don’t need all and should think and decide which components are most appropriate for your game.
3. Screen Layout
There are many controls for various purposes in a game. Dealing with hundreds of different controls can get messy without a proper layout.
Having a good idea of what lays out where, will reduce complexity of your main Page.xaml file, and make your project easier to work on.
Visual Layers that Make Up Your Game
Your game’s Page.xaml will typically have these layers at minimum:
Game Interface Layer
The game interface layer is what the player sees as they are playing:
· Score
· Lives
· Elements that make up your game – e.g. a space ship for space battle game
· Health, energy, rank, time, and other indicators
Figure 1 – Shock’s Game Interface Layer
In-game Controls Layer
All UI that will appear on top of the game interface goes here.
For example: Item Shop, Level selection controls, or fly-in high scores. The “Choose Your Path” control (not included in the source code) below is defined in the in-game controls layer:
Figure 2 – Shock’s In-game Controls
Sounds Layer
The sounds layer can pretty much go anywhere. It contains a collection of MediaElement-s to play various effects and music throughout the game. The sounds layer is not visible on the screen.
Start Screen Layer
The start screen is what the user sees after going to your game’s web page.
Typically, you would put information that is good-to-know before the game starts here:
· Instructions
· Play/Restart buttons
· Terms of Service
· Login info
· Chat Lobby
As with any other UI, keep exactly the information that is usable on this screen, nothing more nothing less.
Here’s an example start screen:
Figure 3 - Shock's Start Screen
Main Screen Popup Controls Layer
The main screen contains various controls, such as login/logout windows, instructions, boxes to enter names, codes. All of the elements that are visible on the start screen, but are invisible inside the game, should go here. During game play, this screen will have its Visibility set to Collapsed, to increase the performance of your game. Panels with Visibility=”Collapsed” will be skipped by the Silverlight rendering pipeline.
Figure 4 – the Instructions control is part of the Main Screen Popup Controls Layer
4. Silverlight Game Internals
The Game Loop
The “game loop” is a function or set of functions that are called periodically (for example, 100 times per second or when a key is pressed), and does some computations and screen updates.
A typical game loop in pseudo code looks like this:
The above loop does not have keyboard and mouse handling. Why? Since Silverlight fires events on key presses and mouse movements, part of the “game loop” executes asynchronously in separate functions. For example:
Depending on the type of game you’re building there are different choices for a game loop. The most important thing to consider is:
Are you making a real-time, fast-paced game (e.g. space shooter), or a turn-by-turn one (e.g. Chess)?
ü For turn-by-turn games, you don’t need to get very creative with the game loop – pretty much anything works. I recommend using a timer in this case – see DispatcherTimer class in MSDN online.
ü For fast-paced, action-packed games, you need more than a simple timer.
The reason why you can’t just get everything working with a simple timer is because you can get at most, at the time of this writing, 15 milliseconds (msec) resolution from the Silverlight DispatcherTimer class. Someone may think that’s enough: 1000 msec/15 msec is about 66 frames per second (FPS), and regular TV broadcast is about 30 FPS. What is the problem?
The fundamental issue is that although 30 FPS may be enough for the screen to update smoothly, it may not be enough for all internal calculations to work properly. For example, if your game fires a super-fast projectile at a speed of 1 pixels/msec, the projective will pass about 15 pixels on the screen for 15 milliseconds. For 15 pixels, the projectile can easily miss the target.
In my initial implementation of the game loop in Shock the fastest balls sometimes went straight through bricks instead of correctly bouncing off them. How should we fix it?
There are several approaches to mitigate the problem. For example, you could start a storyboard instead of timer or a separate thread for computations only – which yield higher resolution than DispatcherTimer.
I decided on this approach: simulate a higher resolution timer in the lower-resolution timer function. The default DispatcherTimer can still be used, and the same game loop suitable for both turn-by-turn and fast-paced games.
Here is the updated game loop using the simulated high-resolution timer:
In the new game loop, the calculations are done every 1 msec (=1000 times per second) instead of every X msecs where X is the resolution of DispatcherTimer (typically X = 15 msec). This ensures that a fast ball will hit the brick and a projectile will not pass through the target.
How did I choose 1 msec? Depending on the game, you should choose the largest number that works correctly in order to minimize the amount of computations in your game loop. For example, if your fastest projectile travels with speed 2 pixel/msec and your smallest target size is approximately 10x10 pixels, your step should be 10/2 = 5msec, because that step is good enough to ensure that there will be calculation every 10 pixels at most and the projectile will not miss the target.
Depending on the game, you may want to avoid the artificial high-resolution timer altogether and do some other checks instead – e.g. in the projectile case, check if the line drawn between the position of the projectile before and after the calculation crosses the target.
Try to optimize your game loop for speed, since as your game gets more and more complex you may need every free bit of processing power of your target users’ PC.
Some Classes That You’ll Likely Use in Every Game
The Game Class
This class stores information about the current game such as state (GameOver, Paused, Playing), current level, lives left, where things are on the screen, such as the player position.
The Game class has functions to start a level, go to the next level, update score, and other functions related to the game being played.
Defaults Class
Your project will use a lot of pre-defined values. Some can be related to the gameplay itself, such as the number of lives a player starts with. Others are specifying the environment in which the game executes – such as default screen resolution and zoom. I encourage you to group and put all your default values at this single class: it is a big time saver when you start tweaking the game and/or other values later.
Globals Class
You will also use quite a lot of global variables within your project. Putting all of these at a single location makes them easy to find and easy to change. The Globals class contains information and the current state of various objects that change during gameplay – such as Silverlight TextBoxes, Panels, and the current Zoom level (which is initialized to Defaults.Zoom initially).