Fullscreen XNA games on Windows Phone 8 devices (Featured Article)

This week’s featured article is Fullscreen XNA games on Windows Phone 8 devices by to_pe.

Fullscreen XNA applications actually work as expected on devices with 1280×768 resolution – they fill the whole screen. This is due to the built in hardware scaler which automatically scales up image to the real resolution.

However, when running fullscreen XNA applications on devices with 1280×720 resolution, there are black bars on either side of the screen. This means it’s difficult to support WP8 devices when creating fullscreen apps with XNA. This article explains how to create such apps that will run correctly on all Windows Phone 8 devices.

This article is the 7th winner of our promotion to award a PDP membership and Lumia 800 to Featured Article Winners

Let us know how you like the article in the comments.

Drumkit (Featured Project)

Drumkit is a multi-platform virtual drumkit application which allows user to play percussion sounds by tapping on the screen.

Drumkit was first created for Series 40 using Java ME. It was later ported to Windows Phone (using Silverlight and XNA) and Qt Quick (for Symbian and MeeGo Harmattan (N9) devices).

The Windows phone, Symbian and MeeGo Harmattan version has an option to change the playing view from 2D drum pads to 3D drum kit and vice-versa. Users can also record beats and play them later.

A comparison and implementation of the application on different platforms and the technology used are provided in the project wiki.

– Somnath Banik (on behalf of the Projects Moderation team)

SheepClock for WindowsPhone (Featured Project)

SheepClock for WindowsPhone by spiretos(Spyridon Antonellos) is a clock and alarm scheduler application created using both Silverlight and XNA. The application brings an attraction on a little Sheep that runs and jumps over the fence again and again. It also has a nice set of themes and adjusts with the device accent color to make it more personalized.

The application demonstrates the use of both Silverlight and XNA in the same page along with IsolatedStorage, StoryBoards, handling infinite game loop and many more game elements.  If you are a WindowsPhone lover this application could be one of your learning tutorials.

– Somnath Banik (on behalf of the Projects Moderation team)

Angry Monsters for Windows Phone (Featured Project)

Angry Monsters for Windows Phone by Tero Paananen (tepaa to the Nokia Developer Community) is a   XNA game developed using open source Box2D physics engine. The title of the game is inspired by the famous Angry Bird, but these time its monsters instead of birds. Like Angry Birds, the objective of the game is to destroy the monsters by launching a stone out of a catapult, but you get to re-use the stone over and over  until the job is done.

Tero’s two sons was also a part of this project. They created the graphics, themes and came up with the idea that the stone should be used many a times.  Once these graphics and other game assets were ready Tero codes them all together. Tero Paananen is a mobile apps developer and used his experience to work with his kids to bring their idea to the real world.

– Somnath Banik (on behalf of the Projects Moderation team)

Why Should You Care About Windows Phone 7?

In response to my
technical posting on moving an application from QML to Windows Phone 7 XNA, I
got a private message from a developer who was asking the question, "Why
Should ICare About Windows Phone 7?" If I am going to switch platforms
from QML, why would I choose Windows Phone 7?

 

For
application developers, a more relevant question is, can you afford not to care? The phone is visually
appealing, feature-rich, easy to use, and offers such Microsoft exclusives as
Office, Xbox and the Zune music store. The tile interface is truly innovative; it
focuses your attention on, and tells you at a glance, what is happening now —
like pending messages, game and friend status, and appointments — all refreshed
wirelessly via the web. Email sync is also very reliable.

Here’s
what
AllThingsD says: “The operating system is a mix
of elegance and whimsy that’s a treat to use … sprinkled with delightful
animations on nearly every screen. These include icons that swing out like tiny
doors when selected, and little dots that race across the top of the screen
when something is loading onto the phone. The result is a playful yet
functional interface.”

Then
there’s the development environment. The Windows Phone 7 Application Platform
is built on existing Microsoft tools and technologies such as Visual Studio,
Expression Blend, Silverlight, and the XNA Framework. Developers familiar with
those technologies have a head start when writing new applications for Windows
Phone 7.

Another
great advantage is Microsoft’s position in on-line mobile gaming, the fastest
growing applications market in mobile phones. Games generate more revenue than
any other application genre. With their support of XNA and XBOX Live in Windows
Phone 7, Microsoft is well poised to lead this lucrative market and attract
customers in the highly prized 14-to-25 year old demographic. More young owners
will lead to more ad revenue from both games and traditional data driven
applications.

Business
users can benefit from Windows Phone 7’s support of Microsoft’s .NET framework
for integrated business applications. Support of .NET simplifies the task of
integrating mobile phones with core business services. Much of the client side
business logic can be reused in Windows Phone 7 mobile applications.

But
perhaps the biggest feature is Microsoft itself. Over the
years, the company has shown enormous staying power in markets in which it
wants to win — like games. Windows Phone 7 may only be Microsoft’s latest foray
in the mobile phone space but that’s just more evidence of Microsoft’s commitment
to what most industry watchers see as the future beyond PCs.

So
— given Microsoft’s huge resources, commitment to the market and a well-executed
product — it’s safe to assume that Microsoft will become at least number two in
the market, after Android (which, like Windows Phone 7, comes on many phones)
and ahead of iOS (which only comes on one).

A
Serious Land Grab

Right
now, the biggest thing slowing Windows Phone 7 adoption is a relative lack of
third-party apps. On the one hand, while WP7 may not have as many as Apple,
Google or even the Ovi store, it does have all the mainstream apps you would
expect. On the other hand, if you are an app developer yourself, that is
probably the best reason to care
about Windows Phone 7. Who wants to be the third or fourth developer to market with
a particular kind of application? In today’s environment, numbers 1 and 2 tend
to win big and quickly while everyone else gets overlooked. Given the
advantages in gaming and business applications, now is the time to invest in
Windows Phone 7.

Early
arrivals can also expect more help from Microsoft. As it populates its catalog,
Microsoft will look to fill in the gaps first and worry less about having
multiple offerings for each type of app. Developers looking for help may wish
to consider partnering with their own experts in porting applications across
mobile platforms. What we’re seeing now with Windows Phone 7 may be the last of
the great mobile “land grabs.” Anyone who’s serious about getting their share
should start moving.

In a few days, I will start a series on moving a Twitter application from QML to Silverlight on Windows Phone 7. I plan to show how the transition can be straight forward.

 

Completing the Casual Game Move from QML to XNA

In my last post, I discussed how to build the “Kolobok” main
character in our casual game for Windows Phone 7 from the Kolobok.qml file from
the Symbian phone version.  I also
discussed the method my team used to animate the fire obstacle by rotating
through a list of texture images at a set frame rate.

In this blog, I will finish up the application by showing
how to map the QML MouseArea inputs for the navigation buttons into the input
handlers for the XNA game object. Next I will discuss how to play the sounds
associated with Kolobok’s movement and collision with obstacles.

Input in the QML version of the application is strictly
event driven. Normally we would place button images on the screen in the game
board object and over a MouseArea to catch a user mouse event using an
“anchors.fill” property. This would work for individual buttons but would not
detect two buttons pressed at the same time. For this we need a MouseArea that
would handle Multi-touch events.

QML does not have a predefined element for multi-touch,
however the C QDeclarativeItem provides multi-touch input events. Therefore
we chose to implement a QDeclarativeItem multi-touch object in C and bind it
to QML as a new element. To simplify the implementation we combined the image
and multi-touch elements into one element called MultiTouchItem that has an
image source property and delivers user events as pressed() and released()
signals. These signals are directly connected to the Kolobok characters key handling
methods.

In Windows Phone 7 we will use the event handling methods
and implement the multi-touch events as synchronous tests in the game object’s
Update method. Multi-touch inputs will be passed onto the Kolobok character
game piece’s KeyPressed and KeyReleased methods.

For each game action button in the QML game, we create a
MultiTouchItem object that overrides the QDeclarativeItem::sceneEvent method
and catches the QEvent::TouchBegin and QEvent::TouchEnd events.  The object also catches the Mouse Press and
Mouse Release events in case a non-touch screen input device is used. The
screenEvent method is shown below:

bool MultiTouchItem::sceneEvent(QEvent *event)

{

    switch (event->type()) {

    case QEvent::TouchBegin:

        emit pressed();

        break;

    case QEvent::TouchUpdate:

        break;

    case QEvent::TouchEnd:

        emit released();

        break;

    case QEvent::GraphicsSceneMousePress:

        emit pressed();

        break;

    case QEvent::GraphicsSceneMouseRelease:

        emit released();

        break;

    default:

        return QDeclarativeItem::sceneEvent(event);

    }

    return true;

}

The events emit the appropriate released() or pressed()
signals that are communicated to the Kolobok Element .

In the XNA Game object Update() method, we call the
buttonEvent() method that will poll for multi-touch input and then call the
input methods in the Kolobok.cs file. Multi-touch input is collected in a
TouchCollection container object that can be read using the touch panels
GetState() method. The buttonEvent method is shown below:

void buttonEvent()

        {

            // Windows phone controls

            TouchCollection state = TouchPanel.GetState();

            foreach(TouchLocation
tl in state)

            {

               
// Handle key pressed

               
if (tl.State == TouchLocationState.Pressed)

               
{

                   
if (positonInArea(tl.Position,
closeBtnArea))

                        this.Exit();

                   
else if
(positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Left);

                   
else if
(positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Right);

                   
else if
(positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Up);

               
}

               
// Handle key released

               
else if
(tl.State == TouchLocationState.Released)

               
{

                   
if (positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Left);

                   
else if
(positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Right);

                   
else if
(positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Up);

               
}

               
else if
(tl.State == TouchLocationState.Moved)

               
{

                   
TouchLocation previous;

                   
if (!tl.TryGetPreviousLocation(out previous))

                        return;

                   
if (positonInArea(previous.Position,
leftBtnArea) &&

                       
!positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Left);

                   
else if
(positonInArea(previous.Position, rightBtnArea) &&

                       
!positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Right);

             
      else
if (positonInArea(previous.Position, upBtnArea)
&&

                       
!positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Up);

               
}

            }

 

        }

 

In both the QML and XNA versions of the game, we pass inputs
from the touch device into the Kolobok object’s input methods, and then call its
doMovement() method to update the Kolobok’s position on the screen and respond
to any collisions with other game pieces.

Once we handle input and process game action, the only thing
left to do is play the game sounds and music for each game action.

In the QML game, we create a SoundPlayer object that
contains QAudioPlayer objects from the multimedia APIs in Qt Mobility. The
SoundPlayer contains audio files that play the various sounds depending on the
type of game action. The two main sounds are “Groan” and “Boing” generated when
the Kolobok experiences health decreasing events or collisions with another
game piece.

Sound player APIs are usually very similar and easy to use.
We create the object, set the format, load the sound file, and when we are
ready, call the play or start method.  For QML we create a QAudioPlayer and a
QMediaFormat object. We then set the Format object’s media attributes, bind it
to the Player object, and then call play. The code looks something like this:

QAudioFormat m_format;

m_format.setSampleRate(22050);

m_format.setChannelCount(1);

m_format.setSampleSize(16);

m_format.setCodec("audio/pcm");

m_format.setByteOrder(QAudioFormat::LittleEndian);

m_format.setSampleType(QAudioFormat::SignedInt);

m_boingOutput = new QAudioOutput(m_format,this);

m_boingtFile.setFileName(":/sounds/boink.raw");

 

if (m_boingOutput)

    if (collided) {

        if(m_boingPlaying) return;

        m_boingOutput->start(&m_boingtFile);

        m_boingPlaying = true;

         }

For XNA we use a SoundEffect object
to accomplish the same thing. The following code provides support for the Boing
sound above:

SoundEffect boingSound = content.Load<SoundEffect>("sound/boink");

if (boingSound != null)

   if (collided) boingSound.Play();

 

Note that the SoundEffect object
doesn’t require us to set the format of the file. The reader figures this out
from the content .Load method. Once we know how to generate the sounds, we can
trigger them from the collision detection code discussed in the previous blog.

This posting completes my blog series
on reengineering a QML casual game to XNA. Next week I will begin the steps
necessary to port a simple twitter application to Silverlight.

Developing the Kolobok Game Piece

In my previous post, I developed the Kolobok game board for
Windows Phone 7 from the QML Bounce game posted on the
projects.developer.nokia.com site. In this blog posting, I will discuss how my
team developed the main Kolobok character along with the Cacti, Fire, and Brick
Wall obstacles. In my next posting, I will discuss the input buttons and
methods and how the game components are integrated into the final game.

The Kolobok character is the central component of the game.
Upon input from the user, the Kolobok will roll across the current tier or
bounce upward to a new tier. If the Kolobok encounters an obstacle, such as a
brick wall or cactus, the Kolobok will bounce backwards to a previous
position.  Fire will impede the
characters progress while reducing its health.

As we discussed in the previous posting, the Kolobok
character is defined in the class Kolobok in the file Kolobok.cs.  The class Kolobok is derived from the
GraphicItem class that holds important common properties such as object width,
height, position, texture, rotation angle, and opacity. All game pieces,
including characters and obstacles, are derived from this GraphicItem class.
The GraphicItem class also supports rudimentary animations for the moment of
the Kolobok or the flicker of the flame obstacle.

The original QML file kolobok.qml is an Ellipse Element that
contains the “Kolobok’s” properties and its Image, a non visible Timer element,
Key handlers, and javascript methods that respond to user events, moves the Kolobok
character, detects collisions, and updates the game statistics based on the
collisions with obstacles.

import QtQuick 1.0

import Shapes 1.0 

Ellipse
{

    id: kolobok

    // properties
   

    Image {

        id: kolobok_image

        objectName: "kolobok_image"

        x: 0; y: 0

        width: 100; height: 100

        source: ":/images/face-smile.png"

        smooth: true

        opacity: 1.0

    }

   

    Timer {

        id: timer

        interval: 25; running: false; repeat: true

        onTriggered: doMovement()
    }

       Keys.onPressed: { 

        if (event.isAutoRepeat)

            return;

        keyPressed(event.key);

    }

    Keys.onReleased: {

        if (event.isAutoRepeat)

            return;

        keyReleased(event.key);

        }

        // methods
       
}

QML does
not have an Ellipse Item defined, so we have defined an EllipseItem class that
draws an Ellipse in the C file level.cpp and registered this class in the
“Shapes” library as an Item named Ellipse.

The
KeyPressed and KeyReleased methods referenced above will respond to use input
events. If the input is one of the arrow keys, then the doMovement() method is
called, which will move the Kolobok character accordingly.

Collision
detection in the QML application is handled by the Qt Graphics View built-in
collision detection mechanism. The doMovement() method in kolobok.qml will call
into a method in the level.cpp file that will extract the list of items that
collide with the Kolobok and then update the state of the Kolobok accordingly.

The newly
created Kolobok.cs file will also contain the Ellipse, the Kolobok’s properties
and its image, key handlers, and support methods. The timer is an integral part
of the main event loop in XNA and so it is not explicitly defined in C#.
Because graphics objects are not implicitly self drawn or updated in XNA, we
will need to implement the Kolobok’s Initialize, Draw, and Update methods. The
remaining support methods are based on the original Javascript code, but
rewritten in C# using the XNA libraries.

The Initialize
method is very simple and merely initializes the Kolobok’s properties to their
starting values. The Update method will call doMovement() which will check the
user input for an arrow key press and will move the Kolobok character
accordingly. The update() and Draw() methods are shown here:

        public override void Update(GameTime gameTime)

        {

            base.Update(gameTime);

 

            // TODO: Add your update logic here

            doMovement();

 

            if (health <= 0)

                health = 100;

        }

 

        public override void Draw(SpriteBatch spriteBatch)

        {

            // Set up the color

            Color color = new Color(opacity, opacity, opacity, opacity);

 

            // Set up the origin point

            Vector2 origin = new Vector2();

            origin.X = Texture.Width / 2;

            origin.Y = Texture.Height / 2;

 

            // Set up the render rectangle

            Rectangle rect = new Rectangle(Rect.X + Rect.Width / 2,

                                           Rect.Y + Rect.Height / 2,

                                           Rect.Width, Rect.Height);

 

            spriteBatch.Draw(Texture, rect, null, color, RotationAngle, origin,

                              SpriteEffects.None, 0f);

 

            // Draw the health

            spriteBatch.DrawString(healthFont, "Health:" + health,

                                    new Vector2(20, 20), Color.White);

        }  

Key input
is handled through the KeyPressed() in KeyReleased() called by the input
handler in the game object’s update method. The remainder of the method, called
collisionDetection(), uses the XNA collision detection library to determine if
the Kolobok character is colliding with an obstacle and then updates the Kolobok
state.

The
doMovement(), keyPressed() and keyReleased(), and updateCollisions() methods
from kolobok.qmls javascript code are simply re-implemented in C#.

In QML,
the code to read the game layout database and present it to the game board is
written in C in the file level.cpp. The method load() in the C file uses
the Qt QXmlStreamReader to parse an XML database file and for each vertical
level on the game board stores a string containing a character for each
obstacle. The vertical level strings are stored in QVector container called
“map”. These level strings are used to build the game board as described in the
previous blog. The load method is shown below:

bool Level::load()

{

   

    m_rowCount = m_columnCount = 0;

    m_map.clear();

   

    QFile file(":/level/level.xml");

    if (!file.open(QFile::ReadOnly | QFile::Text)) {

        qDebug() << Q_FUNC_INFO << file.errorString();

        return false;

    }

   

    QXmlStreamReader xml(&file);

    if (xml.readNextStartElement()) {

        if (xml.name() == "level") {

            while (xml.readNextStartElement()) {

                if (xml.name() == "layer") {

                    const QString text = xml.readElementText();

                    m_map.append(text);

                    m_rowCount;

                    m_columnCount = qMax(m_columnCount, text.count());

                }

            }

        }

    }

In the
Windows Phone version of the game, level.cs contains a very similar load function.
Here we use the XmlReader class to read the XML data file and a List container
class to store the level strings. Note the similarities between the two
methods:

public static bool load(string
filePath)

        {

            // Clear the level’s old data.

           
mRowCount = 0;

           
mColumnCount = 0;

           
mMap.Clear();

 

            // Open the level xml file

            XmlReader reader = XmlReader.Create(filePath);

            while (reader.Read())

            {

               
if (reader.Name == "layer")

               
{

                   
string text = reader.ReadInnerXml();

                   
mMap.Add(text);

                   
mRowCount ;

                   
mColumnCount = Math.Max(mColumnCount,
text.Count<char>());

                }

            }

            return true;

        }

 

Now that
we implemented the Kolobok character and the movement logic behind the game,
the only remaining parts are to process input from the user and play background
music and sounds. In my next blog, I will pull the rest of the application
together and show how I completed the port.

 

Re-engineering the QML Bounce Game for Windows Phone 7

In my last blog post I described two environments for developing Windows Phone 7 applications:  XNA for games and graphical applications, and Silverlight for more traditional touch-based, data oriented applications.

In this blog I will demonstrate the beginnings of re-engineering a QML causal game application for the Windows Phone 7 XNA framework. This blog will concentrate on the setup of the game board and definition of each game component.

The demonstration application is a game called QML bounce. It is an animated interactive version of the Russian fable “Kolobok,” which is about a ball of dough that grandma is preparing for baking bread that comes to life and leads grandma and grandpa in a game of cat and mouse across the countryside. In our game, the “Kolobok” will move or bounce around the game board and avoid obstacles that can block its way or diminish its health. To make the game fit on a small screen, “Kolobok” is allowed to bounce vertically in addition to moving across the screen. The vertical direction is divided into 4 or 5 levels with each containing obstacles such as walls, cacti, or fire. To make the game visually appealing, the fire is animated to give it a burning effect. The source for the game can be found at https://projects.developer.nokia.com/qmlbounce.

The image below shows the QML Bounce game board:


The QML version of the game is broken into several files. Each one of these represents a game component. The main QML files are:

  • gameboard.qml – the game board and all of the static game board components such as rocks and cacti
  • Fire.qml – the animated fire obstacle
  • Kolobok.qml – the animated “Kolobok” character that interacts with the user
  • Menu.qml – the on-screen menu for performing in app purchases
  •  

The QML Bounce game also requires three C++ support files for reading the game board obstacles from a “game level” database and providing the level’s obstacles to the QML game board. These files include: 

  • level.cpp – the current game board’s level, containing obstacle locations, and methods for detecting collisions between the  obstacles and the “Kolobok”
  • levelmodel.cpp – the object and methods for accessing the game level database
  • levelcontroller.cpp – which provides the means for purchasing new game board levels from the OVI store.
  •  

To re-engineer the QML Game to the Windows Phone, we must re-engineer each of these files. We will begin the process by moving the functionality of each QML file into a corresponding XNA C# file. Next we will add the objects and methods to implement the game level, game level model, and the ability to purchase new game levels within the application. Finally, we will implement the game board update and draw methods to handle the rendering of the game board and user input.

The next few blogs will concentrate on re-implementing the QML files in C# XNA.

One of the more noticeable differences between QML and XNA is that QML visual elements are self displaying, whereas XNA objects must be drawn by the XNA game object. To re-engineer the game for Windows Phone 7, we start by creating an XNA game project in visual studio that will generate a file game-1.cs which includes an XNA graphics component, derived from the class Microsoft.Xna.Framework.Game. This class contains a “GraphicsDeviceManager” and “SpriteBatch”. The GraphicsDeviceManager will be managed by XNA itself. The spriteBatch will provide a context to the drawing method for rendering the game graphics onto the screen. We will modify this file to create all of the top level components including the game board, pieces, controls, and menus.

The XNA game file includes three main virtual methods that must be implemented for the game to operate. These are the Initialize, Update, and Draw methods. The initialize method is called after the game object is constructed and allows the game to perform any initialization it requires before starting to run. The Update method will be called whenever we need to update the state of the game and collect input from the user. For our game, the Update method will be called at the game frame rate of 60 times per second. After each update, XNA will call the Draw method to update the game graphics. Usually Draw will be called at the frame rate, unless an update occurs before Draw is called. This might happen if an Update takes too long and extends beyond the period of the frame rate.

We will handle input and call methods to update the game board in the Update method. We will call methods to re-draw the game board from the Draw method. The game board, in turn, will update and draw all the lower level game components.

In my next blog I will demonstrate how to re-engineer the QML game board in gameboard.qml and the Kolobok character in kolobok.qml to  corresponding XNA / C# files for Windows Phone 7. The following blog will show how I animate the fire obstacle and process input.

Getting Started on WIndows Phone 7

 

A couple of months ago I wrote that I was learning to
program in Silverlight on the Windows Phone 7 platform and share my experience
with porting applications from QML to Silverlight. Since then my team and I
have ported two demonstration applications from QML on Symbian to Silverlight.  As promised, I am going to share my experience
to encourage others to do the same.

During the past few weeks my team ported two applications
from QML to the Windows Phone. The first is a simple side scrolling casual game
and the second a simple Twitter application. While both applications are
complete, we are still working on the notification piece of the Twitter app
that will update the home screen tile with the count of unread tweets.

The casual game application, called QmlBounce, was
originally written in QML and is available from the URL https://projects.developer.nokia.com/qmlbounce.
We implemented the game using the Windows Phone 7 XNA framework. If you are not
familiar with XNA, it is a C# set of classes and libraries that simplifies the
creation, transformation, and animation of graphical items rendered as Sprites.
The programming model for game components is very similar to Graphics View in
that both provide lightweight objects that draw themselves. Graphics View items
are painted in the paint method, while XNA game components draw themselves in
their Draw method.

To simplify the porting process, we created a new C# class
called GraphicsItem that implements many of the properties and methods of the
Qt QGraphicsItem. We then could use this class to easily implement each of the
graphics objects created in QML.

The Twitter application port was straightforward. Our
graphics team implemented the window, pages and dialogs using the Windows Phone
Visual studio designer. We chose to use a Pivot element , because it closely
mirrored the multi-page look and feel we implemented in QML. The original QML
implementation was hard because we needed to implement each of the controls
along with the page and page stack ourselves. The release of the Qt Quick
Components simplifies this effort as it provides these higher level Elements as
base components.

In my next blog, I will provide a step by step description
of how we implemented the Casual Game. I will start with overall game design
and then work my way though the individual objects, properties, and methods.