Part I – Bare Bones Mechanics

Part II - Basic Classes and Interface Implementations

Part III – Game to Demonstrate Derived Classes and more Sophisticated Interface Implementations

The End Result

This article really starts when I start talking about motivation below, but I want to make the point up front that what I started out to do is not what I ended up doing. What I wanted to do was write some really cool simulations / games. What I ended up doing was writing what I hope is a really cool framework for designing / creating really cool simulations / games and a pretty mediocre game to demonstrate it. But I make lemonade out of that lemon by pointing out that a more complex game would obscure the details of how to use the framework.

Anyhoo, here’s a screen shot of three users logged into the same page and all seeing the same thing but all able to interact with it individually. The idea behind the framework is you can plug in any kind of behavior you want for the simulation objects and rules engine.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

Part I – Bare Bones Mechanics

Part II – Basic Classes and Interface Implementations

Part III – Game to Demonstrate Derived Classes and more Sophisticated Interface Implementations

The End Result

The end result is not what I set out to do. I wanted to write games, but what I ended up with was so brittle it evolved into a game framework which I hope can be used to create all sorts of games.

Here’s a screen shot of three users logged into the same page and all seeing the same thing but all able to interact with it individually. The intent of the framework is that you easily can plug in your own behavior and rules to control what comes out of that basic functionality.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

Part I – Bare Bones Mechanics

Part II – Basic Classes and Interface Implementations

Part III - Game to Demonstrate Derived Classes and More Sophisticated Interface Implementations

The End Result

The end result is a multi-player game that can be played across the internet by users logged into the same page. Unfortunately it’s not a very interesting game, and the question is still open as to whether I can in fact design an interesting game. What I have done, I hope, is to create a framework that can be used to design all sorts of interesting games. As such, a very simple game actually serves the purpose better as it exposes the details of using the framework to create alternative games and simulations and avoids obscuring them with details about the particular game. Maybe there will be a fourth post with an interesting game, but first we have to come up with a game lobby for this one, so who knows?

The large graphic below shows a game in progress, so you can’t see the buttons used to enter the game, shown immediately below. Game play starts as soon as there are at least two players. You can see below that the game is in progress when Red player enters the game and gets the initial Notification “Click button to enter game”.

The goal is to click on an opponent’s player so that your player moves on top. For this particular game, a point is awarded when you are successful, so, back on the Server, the behavior of the particular ooNaThing subtype, in conjunction with ooBerLink and ooBer, is to perform collision detection and increment its score if warranted. A different ooBerLink and ooNaThing might do something completely different, from handling the left mouse click to the consequences of collisions. There’s also nothing to prevent multiple ooNaThing subtypes, all interacting with each other. That’s the part you can plug in.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

LINQ joins, both inner and outer, are not always what they seem and how you go about it may depend on whether you want grouping.

Even for simple projects, I like to use LightSwitch for what I call Back Room screens because it’s just so darn convenient. You’ll see what I mean later, because these first two tables are so primitive, so uncouth, so crude that I don’t even call them tables – LightSwitch will attach to them but only as read-only. I call them MasterRowPile and ChildRowPile LightSwitch, as you will see, wants little to do with them because they have no primary keys. Brace yourselves, they are hideous to behold.



...

 

LightSwitch provides for creating Data Sources in several ways. In the case of an existing database you would typically either specify the database itself or a WCF RIA Service.

But sometimes neither is feasible. I was confronted with a database with no primary keys and incredibly wide tables – so wide that I got error messages about it. And you can’t really do much with a database that has no primary keys. Also modifying the schema was not an option.

This actually turned out to be quite liberating. The reason we wanted to access the database outside of the legacy application it was designed for was to

• Provide views of the data that the legacy application did not.
• Add additional columns

By extracting the data into another database we could

• Eliminate literally hundreds of columns (Yes, I do mean literally)
• Create primary keys
• Create relationships with referential integrity through foreign keys

 

Many-to-Many Relationships A typical validation task that involves a many-to-many relationship involves a User who can update a number of Entities and an Entity that can be updated by a number of Users. For instance a School Book Inventory system where the counts for books at a particular school can only be updated by an employee of that school. Each employee can update a number of counts and each count can be updated by a number of employees. The application must prevent unauthorized data base updates and prevent employees from seeing counts from other schools.

We’ll start with validation. Although this article touches on validation on both client and server, to really understand what’s going on I suggest you see this post by Prem Ramanathan and this article he wrote for Code magazine....

The default Add and Edit screens generated by LightSwitch often don’t allow the control you need to meet the business requirements.  Consider the scenario where an entity must have a password column.  Ideally we’d want the ‘Add’ screen to look something like this:



The default Add and Edit screens are inadequate for two reasons.

No masked password text box A second password text box is required for matching, requiring a property that doesn’t...

 



LightSwitch removes so much tedium from programming that I’m hoping it can be integrated into any Silverlight application. Obviously that requires Custom Controls, so the focus becomes finding the best patterns for interaction between LightSwitch and Custom Controls.

My first goal was to incorporate drag and drop. I spent a lot of time trying to come up with scenarios that were not trivial but also wouldn’t take a long time to set up. But I kept running into a fuzzy area when I tried to think about...

Often we don’t care who the logged-in User is because we can control what they can do through Roles and Permissions. But if the User is a member of some group, it would be handy to place the Users table in a many-to-one relationship with that group. In this example the groups are SalesTeams made up of SalesPersons. All Sales made by a particular team are accessible only by members of that team.

To make that happen a new User is created, if necessary, when a SalesPerson is created. Since a SalesPerson is in a many-to-one relationship with SalesTeam, so is the User. This article shows you how to create the UserRegistration and then two ways to identify the SalesPerson associated with the logged-in User and thereby the relationship with SalesTeam and Sales.

Start by adding a SalesTeam entity:



...