LightSwitch for Games Part 4: OData Access from C++ Client Code with the C++ REST SDK

NOTE: Although this series is aimed at small game developers, it is equally applicable to anyone wishing to learn how to use LightSwitch.

In Part 2 of this series we built a user account and profile database on our LightSwitch server, and in part 3 we showed how to make a web interface to allow users to edit their account details. In this part, we will look at how to enable new users to register and existing users to log in direct from your C++ game (or application) code. If you’ve ever played a console game which requires log in to EA’s Origin servers or something similar, you will be familiar with this workflow and why it is useful to have in your game; that is, it saves users from having to go to a web site to make an account before they can play.

You don’t need to have completed part 3 in order to follow along with the tutorial below, but your LightSwitch project and database need to be in a state that matches at least the end of part 2. The web interface from part 3 is a fully distinct code path from what we will do below so it is not required for this code to work.

This article assumes some familiarity with:

• HTTP requests and responses, methods and headers
• JSON
• OData transactions (covered in part 2)
• a moderate understanding of C++ (including C++11 lambda functions)
• a basic understanding of threading
• setting up include and library directories for a project in Visual Studio

You will learn:

• How to interact with LightSwitch OData endpoints using the C++ REST SDK (codename ‘Casablanca’)
• How to use PPL(X) tasks and continuations
• How to use OData to create new users (write table rows) and fetch user profiles (read table rows) from our server’s database programmatically in C++
• How to update and delete rows with HTTP/OData directly or from within C++ programmatically
• How to make the code error-resistant (for example if the user is disconnected from the internet)
• How to separate the client-side logic (interacting with the server) from the user interface
• How to access the server asynchronously (that is, using multiple threads so that the rest of your game or application does not stall or block while waiting for the server to respond)
• How to create a basic framework of C++ classes to make your code easily re-usable and extensible

Project Goals

We need a client-side framework for communicating with the LightSwitch server before we start adding game-specific features and plugging the code into an actual game, so for this part our goal will be to create a simple console test application which allows us to create new users and fetch their profiles.

NOTE: The code presented below makes heavy use of C++11 features. You need Visual Studio 2013 Preview or later to complete the tutorials in this article. You can re-write portions of the code without these features if you need to compile it with Visual Studio 2012.

Advertisement

How to statically link the C++ REST SDK (Casablanca)

You are trying to use the C++ REST SDK (Casablanca) in your Windows application. You have one of the following problems:

• you need Windows XP support
• when your code executes you receive a debug assertion: _pFirstBlock == pHead
• you get unpredictable behaviour or random crashing
• you need to build an application which links against static libraries

You have 30 minutes to solve the problem. Here is how:

The issue is that the C++ REST SDK only supports dynamic linking. The solution is to re-build the SDK with static linking.

2D Platform Games Part 12: A Framework for Interactive Game Objects

IMPORTANT! To run the pre-compiled EXEs in this article, you must have Windows 7 Service Pack 1 with Platform Update for Windows 7 installed, or Windows 8.

This article builds upon the demo project created in 2D Platform Games Part 11: Collision Detection Edge Cases for The Uninitiated. Start with 2D Platform Games Part 1: Collision Detection for Dummies if you just stumbled upon this page at random!

Download source code and compiled EXE for the code in this article as well as the complete source code and compiled EXE for the level editor.

We’ve spent a lot of time adding different types of platforms and collision detection behaviour to our project, but of course the real meat of any platform game is in the objects you can interact with like coins, baddies, levers and switches and so on.

Goals and Terminology

Over the next 5 parts of this series, we will build a framework in which we can place interactive game objects like enemies and collectibles, and look at all the complexities of this topic which must be tackled for a complete working implementation, including:

• Defining a class hierarchy for interactive game objects (which I’ll call game entities from hereon to differentiate them from actual C++ objects and platform geometry and instances) (Part 12 – this article)
• Handling the movement logic of static game entities (those which do not move in the game world), game entities with pre-defined paths (for example enemies which move backwards and forwards in a fixed pattern) (Part 13) and game entities which can move around the game world of their own accord under the rules of physics we have already defined (which I’ll call free-roaming) (Part 14)
• Handling animation of game entities with a unified animation function (for example, changing the sprites used for animation depending on the direction the game entity is travelling in) (Part 13)
• Unifying the collision processing code for entity-platform, entity-entity and player-entity collisions (Part 14, Part 16)
• Allowing entities to have custom behaviour on collisions with other entities, platforms or the player (for example, making a coin disappear and adding its value to the player’s score when the player collides with it) (Part 16)
• Unifying the internal representation of the game world to simplify the code and make it more easily extensible (Part 16)

We will also review the collision detection code and go through some really tricky edge cases that only come up when non-player game entities are added to the world, in Part 15.

Finally, I shall also present a new level editor which will allow you to place game entities and modify their properties, in turn giving way to a new level definition format for our level files (the level editor also contains a lot of other minor improvements and bug fixes).

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 110,000 times in 2013. If it were an exhibit at the Louvre Museum, it would take about 5 days for that many people to see it.

Click here to see the complete report.

From Katy: Thanks so much to everyone who supported my blog and donated in 2013! Personal circumstances are difficult these days but I will do my best to write lots more interesting and informative articles in 2014! Love to all of you, Katy.

Cutting Your Teeth on FMOD Part 6: Recording and visualizing sound card output

In this article, we’ll take a look at how to intercept and record the output from a sound card. Our primary focus here will be to create a visualizer that reflects the output sound using the frequency analysis technique discussed in part 4, however you can of course use the recording code for any purpose you wish.

I won’t go into the details of FFT frequency analysis here (see part 4 for that); we’ll just look at how to capture the real-time sound output then provide the visualizer as a usage example.

LightSwitch for Games Part 3: Creating a Web Interface for your Users

NOTE: Although this series is aimed at small game developers, it is equally applicable to anyone wishing to learn how to use LightSwitch.

In this article, I present a fast crash course in a raft of commonly used LightSwitch techniques. You will learn:

• how to make your web site base URL re-direct to your LightSwitch application
• how to enable remote error viewing in a LightSwitch HTML client application
• how to create new LightSwitch screens (web pages and dialog boxes)
• the difference between Browse, View Detail and Add/Edit Detail screens
• how to add buttons that allow the user to navigate between screens
• how to associate queries to LightSwitch tables and use them as the basis for new screens
• how LightSwitch categorizes data sets into All, Set and Single types, and how each data set type can be used
• how to create local properties (client-side variables that are associated with a single screen)
• how to make table rows and local properties on one screen input parameters to another screen
• how to create a button which executes custom code when clicked
• how to access table rows and local properties from client-side JavaScript
• how to perform custom client-side validation in JavaScript
• what the new LightSwitch ServerApplicationContext API is and how to use it
• how to make generic handlers (.ashx scripts) which can be used from client-side JavaScript to query and change data on the server from a LightSwitch HTML screen
• how to use jQuery to send data (with HTTP POST) and retrieve the response from a web page (in this case, .ashx scripts)
• how to use promises in LightSwitch to store a future result that is currently unknown (generally, the result of a request to the server) and make asynchronous (non-blocking) requests to the server
• how to create a custom control in JavaScript to represent a masked text box (a text box where the contents are replaced with asterisks or dots, like a password entry box)
• how to access the name of the currently logged in user with client-side JavaScript (for rendering purposes)
• how to change the default theme of a LightSwitch HTML application
• how to customize the default images in your LightSwitch HTML client application
• how to customize the LightSwitch HTML client login screen to match the rest of your web site

This article assumes some familiarity with:

• HTTP GET and POST methods
• HTML and CSS
• JSON
• a basic understanding of JavaScript (no jQuery knowledge is needed)
• a basic understanding of C#

Project Goals

In part 2 of this series we looked at how to securely allow anonymous users to create full user accounts for themselves, and how to expose this as a service via OData over HTTP to our future game clients. We looked at the basics of OData, WCF RIA Services, how to assign permissions and roles and how to limit a user to only accessing their own data. In this part, we’ll look at how to create a web-based user interface to allow gamers to edit/update their accounts. Our goals:

• allow the user to log in to a web site using their LightSwitch account
• allow the user to view and edit their profile (except their username)
• provide a change password dialog which requires the old and new passwords, and the new password to be typed twice
• customize the appearance of the site to your own company style

NOTE: You need Visual Studio Professional 2012 Update 2 or Update 3, or Visual Studio 2013 (Preview) to complete the tutorials in this article. Note that in Visual Studio 2013 (Preview), the organization of items in Solution Explorer has changed so some items may be in different places to those indicated below.

Tetris: Adding gamepad support

In this article, we will look at how to add gamepad support to a game using our Tetris clone as an example.

Simple2D 1.11 includes gamepad support using XInput – the new replacement for DirectInput in DirectX 11 – and makes it ridiculously easy to add support to existing games as we shall see here. If you would rather code everything yourself and want the nitty gritty, check out my 2-part mini-series XInput Tutorial: Adding gamepad support to your Windows game for the low-level details.

Download (SimpleTetris 1.5): Source code | Executable

XInput Tutorial Part 2: Mapping gamepad buttons and analog movement to Windows keyboard events

In part 1 of this mini-series we looked at the basics of the XInput API and how to read the state of all the analog and digital buttons on a gamepad, then wrapped it up into a simple Gamepad class. In this article, we shall look at how to translate button pushes and analog stick/trigger movements into Windows keyboard events for those applications which use the Windows messages WM_KEYDOWN and WM_KEYUP to handle user keyboard input.

The problem

XInput requires you to poll the controller each frame to get changes in state. If you currently use a function like GetAsyncKeyState() to check for keyboard key presses in your game, this is fine, but if you are using the Windows keyboard messages WM_KEYDOWN and WM_KEYUP, this will not fit in with your current model, and the game will require a bit of re-engineering to handle polling as well. Ideally, we would like to avoid this and just funnel controller movements and button presses through WM_KEYDOWN and WM_KEYUP as if they were normal keyboard key presses.

To do this, we will expand upon our basic Gamepad class to include keyboard mapping and event dispatch functions.

NOTE: If you can’t be bothered with the low-level details and just want to shoehorn gamepad support into a game really quickly, my Simple2D library (version 1.11 and above) includes gamepad support – see the Tetris gamepad support article for a quick example on how to use the library to add gamepad support in just a few minutes!