WiMo-GF Silverlight Engine Now Supports Multi-Touch

WiMo-GF has been updated to include Multi-Touch support for the Silverlight version of the game engine.  Now Zune HD and Silverlight both support Multi-Touch, Windows Mobile supports a single touch point.

http://www.wimo-gf.net/touch.html

-twb

The Efficient Coder is now “The Wolf Bytes”

Welcome to my new and improved blog.  Over the next few weeks, I’ll be rebranding my blog from “Efficient Coder” to “The Wolf Bytes”.

I have to give credit where credit is due.  Inspiration for the name came from http://twitter.com/jaykimble 

Stay tuned for a new and exciting look as well as some “Killer” graphics.

-ec
-twb

Software Development Moment of Clarity

I believe the following is accurate for developing 95% of business applications:

1. People buy software to solve problems, that can be making their life easier, making money or providing pleasure (don’t read too much in to that =D)

2. Features enable solutions to problems.

3. When we write software, we build features.

4. With the right level of abstraction there is a common and finite set of features to be implemented in code.

5. Applications should be built by tailoring features to solve a user problem.

6. If tailoring features has to be done by writing code, so be it, but this is very costly in terms of time and money.

7. It’s preferable to have this done via configuration.

-ec

WiMo-GF Now Targeting Silverlight

The open source gaming engine WiMo-GF has been updated to target Silverlight.  That means the games you build for Windows Mobile, Zune HD will be able to run on Silverlight 3.0 as well.

Here’s our sample game Y.A.B.O.G. (Yet Another Break Out Game).

WiMo-GF is still in the preview phase but is mostly feature complete.  Anything built targeting the existing interfaces will work in the final version.

-ec

Oslo – State Machine Editor in Silverlight

If you remember in our previous post we discussed how to model a state machine in using MGrammar.  Up next, we are going to actually do something with this grammar.  Since we last met, I released the project MGraph2POCO on codeplex.  This library will allow us to parse our MGraph into POCO’s or Plain Old CLR Objects.

We are going leverage this project to build a small Silverlight Application that will allow us to parse input and build up an object graph that we can use to start running our state machine.

Here is our architecture, nothing fancy here.

Here is our application, click here to run it online.  If no one has been to the app for a while, be patient, the squirrels are working as hard as they can to spin up an ASP.NET instance in IIS.  See the previous post for samples of acceptable inputs.

To call the WCF service, we simply start a timer each time the text changes.  If the text changes again before the timer fires, the timer is reset.  Eventually when the user pauses typing the timer will fire and we will parse the text.  Currently the timer is set to one second.

The code within the Silverlight application isn’t all that interesting.  One thing to point out is that we are using an awesome free Rich TextBox control from VectorLight.net to do our syntax highlighting.

The server side is where all the magic takes place.  Our WCF service will return an instance of a custom class we created called ParseResult.  For our example this is tied to a StateMachine instance.

The class StateMachineParser that does the heavy lifting and is worth looking at.  Here we are using MGraph2POCO that provides an extension method to DynamicParser to return a StateMachine instance.

To perform syntax highlighting within the Silverlight application, we are handing the TokenMatched event and adding the start and end locations for keywords to our parser result.

If we can’t parse the input, we set the Parsed flag to false and set some properties to also help us identify the error within the Silverlight application

Download Source

So in this step, we have built a mechanism to parse the input and provide feedback to the users.  Up next we need to validate and/or compile the definition to make sure our state machine is valid.

-ec

Oslo - Series

If you’ve been keeping up with my blog, you know I have a 'big-time’ interest in a little technology from Microsoft called Oslo.  To make a long story short, the fundamentals of the way we develop systems has changed very little since I entered the industry in the early 90’s.  Oslo, or probably the concepts behind Oslo could fundamentally change things.

As I go through the learning phase, I’m going to capture the experience in my blog.  As articles and how-to’s get added, I’ll update this page.  If you are interested in Oslo, you might want to book mark the permalink for this post.

Oslo – State Machine Editor in Silverlight – In this post we build a mechanism using Silverlight to capture the user input and provide feedback.

Oslo – MGraph2POCO – Open source library to deserialize MGraph to POCO.

Oslo – Modeling a State Machine – Third in a series of posts.  This goes through the exercise of building a grammar to parse state machines.

Oslo in the next Generation Architectures – Second in a series of posts that will attempt to layout how Oslo could be used in building non-trivial business applications.

Oslo, what is Oslo? No, Not the city in Norway - First in a series of posts that will attempt to layout how Oslo could be used in building non-trivial business applications.

Parsing MGraph – a how to on using MGraph

Embedding MGrammar Files within your project – How to use MGrammar and Oslo in your .NET project.

Oslo - MGraph2POCO

When working with Oslo one of my biggest wants was the ability to deserialize MGraph to POCO (Plain Old CLR Objects).  It doesn’t look this was going to happen anytime soon so I decided to just go ahead and write one.  It actually turned out fairly well and I’m sure other people might find some use in it so I decided to put it on CodePlex.

http://mgraph2poco.codeplex.com/

Enjoy!

-ec

Oslo – Modeling a State Machine

If you read my previous post, you would know it’s time for me to get a little technical and start describing how to use the actual bits.  The premise of my previous post was that modeling Finite State Machines (FSM’s) could be one of the core building blocks of real-world implementations of Oslo.

I’m working with the May 2009 CTP that you can download and follow along.

So the idea is we want to build a couple different grammars for parsing our state machines, one that is plain text English and one that is more terse.  Here are some examples of the inputs we want to parse.

Plain Text English Version:

The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue, Cancelled.

Terse Version:

Invoice States:  New, Reviewed, Submitted, Paid, Overdue, Cancelled;

And input for our transitions:

Plain Text English Version:

An Invoice can transition from New to Reviewed and Cancelled. 

An Invoice can also transition from Reviewed to Submitted and Cancelled. 

An Invoice can also transition from Submitted to Paid, Overdue and Cancelled.

An Invoice can also transition from Overdue to Paid and Cancelled.

Terse Version:

Invoice transition: New to Reviewed, Cancelled;

Invoice transition: Reviewed to Submitted Cancelled;

Invoice transition: Submitted to Paid, Overdue, Cancelled;

Invoice transition: Overdue to Paid, Cancelled;

After you have installed Oslo you should see a new program you can start called Intellipad this application is an extensible Swiss Army Knife for working with Oslo.  We will use Intellipad to construct and test the specification for our DSL.

First thing we need to do to is change the mode to “DSL Grammar Mode”.

One you do that we need to setup our view to create or Grammar.  The view we want is “Split New Input and Output Views”.

This will give us four panes:

Let’s start out by authoring our Domain Specific Language or DSL.  We want to build a DSL Grammar that will be used to parse the following text.

The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue, Cancelled.

 

An Invoice can transition from New to Reviewed and Cancelled. 

 

An Invoice can also transition from Reviewed to Submitted and Cancelled. 

 

An Invoice can also transition from Submitted to Paid, Overdue and Cancelled.

 

An Invoice can also transition from Overdue to Paid and Cancelled.

To build our Grammar we need to start out by adding some basic building blocks, these will allow us to start defining the “stuff” that makes up our Grammar.

Now that we have Word and Word and NameWithSpace defined, we can go ahead and describe the syntax of the data we want to extract, in our case we would like to get the name of the entity we which we are modeling the state machine, a name of the states as well as the from state and to states for our transitions.

Next let’s go ahead and define some of the tokens we will be using to parse out our state machine:

Some things to note about this

1) Notice on the keyword transition we say “transition” “s”? this will allow us to use either the word transition or transitions note the plural.
2) If we use the the @{Classification[“Keyword”]} we will get syntax highlighting  as shown here:

Next to make our life a little easier we define what I guess would be similar to a C# Generic, basically a template that can be applied to certain syntax within our Grammar.

This allows us to create a list like:

Note the separator of both “,” and “and” as defined by (“,” | “and”) in our ItemList(n) definition.

This will recursively be built by going through the list and come up with something like:

 

Now that we have our building blocks in place, we need to start describing our grammar, let’s start by looking at the grammar to parse the states in our state machine.  We will want to parse either of the following syntax:

Invoice States:  New, Reviewed, Submitted, Paid, Overdue, Cancelled;
The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.

Our grammar to parse this is:

Which will produce the following the following MGraph from either text that would be parsed:

Looking at this a bit closer we will see we identified some additional tokens

There are used in our first definition to identify the syntax.

So the following bit of grammar:

Could be used to parse any of the statements:

The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.

States of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.

The States of an Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.

The States of a Review are New, Reviewed, Approved.

Now that we have the ability to parse with our grammar we need to describe how we want to project or shape the data into MGraph.  The following syntax will do that:

and generates the following MGraph:

If you remember our goal was to allow two different types of grammar, one that is fairly close to a sentence structure and the other was rather terse.  Adding the following straight forward definition will allow us to parse the terse grammar, the shaping of the data is the same as the original rule.

Next we need to add in our transitions, our transitions can be described as either of the following syntax:

An Invoice can transition from New to Reviewed and Cancelled. 
Invoice transition: Reviewed to Submitted Cancelled;

At this point there really aren’t any surprises in our syntax:

Which will generate the following MGraph 

The final thing we need to do is to bring all this together at our main statement which will build our top level MGraph, this is fairly straight foward:

You can see here that we want exactly one set of state lists and a set of descriptions for the transitions when in each state.

So as everything comes together your final MGraph looks like

To run this sample on your computer

 

1) Install OSLO

2) Start Intellipad

3) Switch to DSL Grammar Mode

4) Set the Mode

5) Download  and copy the MGrammar for the State Machine into the “DSL Grammar Mode Pane”

6) Download the sample text to be parsed to the windows labeled “StateMachine” mode.

What’s Next?

In the next post in this series we will take the MGrammar and do something useful with it using a C# application.

-ec

WiMo Gaming Frameworks

Software Logistics, LLC is pleased to announce the release of a technical preview of an open source product intended to make it easier to write casual games for Mobile Devices.

For more information, check out the WiMo Game Frameworks or WiMo-GF on codeplex.