Happy Holidays! Way back in Part 1, we looked at how to set up a Windows 10 UWP app that would use MonoGame to draw some sprites on the Screen. If you are wondering how to move things around the screen in a non-XAML kind of way, MonoGame is perhaps one of the simplest ways to get started. It adds APIs for creating and drawing sprites, and frankly that’s all you need to write the kind of simple games we enjoyed until about 1985!

Now we can take the app we created, and take it a little further. Nothing fancy: but it’ll introduce collision detection and using a Microsoft Dial as a game controller. It’s certainly something you can build upon and experiment with. In fact, if you don’t have a Surface Book and Microsoft Dial, you will need to experiment a little in order to get it to do anything. Don’t worry, I’m not going to make you retype anything: you can find it all here on GitHub.

Bat and Ball and Dial

And here it is. Enjoy the beauty that three different sprite textures and the mostly basic “physics” can create.

The Basics

This a simple hit-the-Ball-back-and-destroy-the-blocks game. Move the bat, hit the ball back (or don’t – at the moment, it’ll just bounce off the bottom of the screen) and try to hit all the blocks. Moving the block is done with the Dial, and the ball just updates it’s position every game iteration. There’s a check to see if the ball has hit anything, or the edge of the screen, and that’s all there is to it. It is ripe for your improvements.

Open up the project in Visual Studio, and you’ll see it doesn’t contain very much that isn’t boilerplate. The only files you need to worry about are Game1.cs and SpriteClass.cs. There are also some PNG files for the ball, bat and brick.

The SpriteClass.cs code is used by the ball, bat and all the blocks. It contains the texture associated with the sprite (the PNG file, created in Photoshop), and keeps track of the X,Y co-ordinates that define where on the screen the sprite will be displayed. Some extra values (DX,DY) are also available to store in which direction the ball is moving. A bool to define the sprite as circular is also used (it is required for the collision detection stuff). The SpriteClass also contains the drawing code which actually displays the sprite. There’s an optional DrawColor method which is used when drawing the bricks to use the tintColor to change their appearance.

The Game1.cs file does the hard work of creating the sprite objects, and in the Update method the location of the ball is updated and any collisions between the ball and bat, or ball and bricks is checked for. Rather than update the ball’s location with the same value every time Update is called, the time difference between previous loop is used: this keeps the movement at the same speed no matter what PC hardware you are using. That is what this code is about:

 ball.X += ball.DX * (float)gameTime.ElapsedGameTime.TotalSeconds;
 ball.Y += ball.DY * (float)gameTime.ElapsedGameTime.TotalSeconds;

Scaling issues

If you are using a Windows computer with a high density pixel display, you might sometime see some scaling issues. For example, the MonoGame template for UWP apps seems to need a little help in order to get accurate values for the size of the screen. If you look in Game1.cs, you’ll see the following code:

ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.FullScreen;

screenHeight = (float)ApplicationView.GetForCurrentView().VisibleBounds.Height;
 screenWidth = (float)ApplicationView.GetForCurrentView().VisibleBounds.Width;

 // Take high density screens into account, such as Surface Pro
 DisplayInformation d = DisplayInformation.GetForCurrentView();
 screenHeight *= (float)d.RawPixelsPerViewPixel;
 screenWidth *= (float)d.RawPixelsPerViewPixel;

This tries to make sure the screen height and width values returned are a little more sensible. However, the rest of the app pretty much ignores this information, so if you try the game and the bricks are all over the place and the bat is missing, start looking at the hard-coded values for X,Y co-ordinates and maybe divide them by two to see what happens.

Collision detection

MonoGame doesn’t come out of the box with built-in collision detection, but it’s easy to implement a simple version based on overlapping rectangles or rectangles and circles. You’ll find the code in the SpriteClass, and it includes a few different kinds to best match your sprites. In this particular game, the Rectangle-to-Circle is all you need, and it look like this:

bool RectangleAndCircleCollision(SpriteClass otherSprite)
 {
  float r2 = otherSprite.texture.Width / 2;

 if (this.X + this.texture.Width/2  otherSprite.X + r2) return false;
 if (this.Y - this.texture.Height / 2 > otherSprite.Y + r2) return false;
 return true;
 }
}

All it does it make sure the objects are not overlapping. It’s called the “bounding box” approach.

Dial support

The Microsoft Dial shipped as part of the Surface Studio, but it’s also available separately for $99 from the Microsoft Store. It connects via Bluetooth to a number of compatible computers, including the Surface Pro and the Surface Book I used for development. You need to be running Windows 10 Anniversary Update for it to work (and make sure any new Visual Studio project you create is set for that version of Windows too).

There are a few magic spells required to configure it, and then you just sit back and let the handler get called every time the user rotates or clicks on it. It returns an angle, which is easy to transform into the X co-ordinate for the Bat. This game also waits until the user clicks on the Dial to start.

If you don’t have a Dial to play with, you’re going to have to add your own keyboard or mouse handling code to make sure the ball starts moving and the bat position changes. You could use a touch screen, or something more esoteric like the angle at which the tablet is being held to control how the bat moves.

That’s about it..

There’s not much more to say! This app simply demonstrates how easy it is to create a UWP game using moving sprites, and even to make use of the latest hardware such as the Dial. As it’s a UWP app, you can fix it up and submit it to the Microsoft Store to distribute it. And even port it with minor changes to run on the Xbox (haha! it might look a little primitive on the Xbox! and even HoloLens. Got any questions? Just post in comments.