Wednesday, January 27, 2010

Confessions of a Slacker (and OneNote Niftiness)

A quick update on DPGA and this blog...

For those following this blog, I've been qujiet for a couple of weeks.  One reason for this is that I've been setting up a SQL Server blog over at http://ozziemedessql.blogspot.com, where I'm doing a series of posts on querying metadata for fun and productivity.  The other reason is that I have been working on building user story cards for the DPGA application.  

As an aside, I've been building the DPGA story cards using Microsoft's OneNote application, which lends itself nicely to this kind of relatively ad hoc documentation.  It's possible to create OneNote post templates containing preconfigured content (which I've done), so that each time you create a new note within a given section it is based on an existing note.  The net result looks something like this:



Is it not nifty?  I just click "New Page" and I get a clean pre-formatted template and can populate data directly into the table.

The DPGA app is fairly complex (lots of different TYPES of functionality), so building user stories isa relatively time consuming process. Anyone who wants to help out by building story cards is more than welcome to do so. Just leave a comment with an email address I can hit you back on and I'll set you up with access to the one-note repository on the DPGA project site. This is a great opportunity to get involved in the design of the tool.

Once I've got all the user stories worked out, I'll publish a "project backlog" (basically a list of user stories to be implemented) and will work through the priorities.  Once that's done, I can start working with code!

Until then - Code Well and Code Often!

Thursday, January 7, 2010

Note: Game Assistant Contributions

Just so people are aware – I’ve created a project on CodePlex for this project, so people will be able to inspect the source code and discuss what I’ve done, how I’ve done it.  I’m happy to accept that my code will not be brilliant quality at the start – this project is as much about teaching me to code as teaching others. 

Also, if people want to help out on the project, I’m happy to accept other contributors.  My only request is that you focus on the real objective of the project – i.e. learning about what’s possible in the .NET framework – and make sure that your code is commented properly.  I’d also ask that you post blog entries on any modules submitted to the project, so both I and my readers can learn from what you’ve done.

Proposed Technologies for Game Assistant

In my last post, I put together a feature list for my Gaming Assistant project. At this point I’m ready to propose a set of technologies that will be used to build my solution.

Technology Selection

I’m going to take a structured approach to the technology selection. There are five key technology choices I need to make, as follows:

  • Code Platform (choices: VB.NET, C#, other)
  • Visual Platform (choices: winforms, ASP.NET, WPF, Silverlight, DirectX)
  • Remoting Platform (choices: WCF, SOAP web services, TCP/IP Sockets)
  • MultiMedia Platform (choices: Live Services, DirectX, WPF MediaElement, SkypeAPI)
  • Structured Data Persistence & Distribution Platform (choices: XML files, SQL Server Compact Edition, SQL Server Express Edition)

Let’s tackle these one by one.

Code Platform

This is a personal choice only, not a criticism of any of the other options. I like the conciseness of C#. VB.NET might be a little “friendlier” to read, but I find myself having to read a lot more code to understand what’s going on in VB.NET than C#. I could possibly also look at alternative technologies with Common Language Runtime support (e.g. IronRuby, IronPython) but I’d be going back to square one, whereas with C# I at least have some idea about the syntax. So… C# it is.

Visual Platform

This is a much tougher choice. Most of the folks who will be using this program will also be geeky enough to have computer hardware capable of supporting all of the DirectX (and thus WPF and Silverlight) vector graphics features. So let’s walk through the pros and cons of each product.

Windows Forms

ProsCons

I have some experience writing simple windows forms

Windows forms is based on GDI+, not on DirectX

Windows forms does not require .NET Framework version 3.0 features, so backward compatibility may not be as hard to implement

This means the “design palette” is not as functional as with other visual platform options
WinForms offers a rich eventing model and provides full multithreading supportWindows Forms offers minimal support for vector graphics – particularly important for map rotation/zoom

ASP.NET Web Forms

ProsCons
I have plenty of reference material on ASP.NETI have minimal experience working with ASP.NET
Using ASP.NET I could build something along the lines of a Web 2.0 “mashup”Managing session state and asynchronous events can be painful
ASP.NET supports the full functionality of the .NET framework in server-side code-behindASP.NET requires extra effort around database security
ASP.NET does not support vector graphics to the same degree as other options
ASP.NET requires a server
For the app I want to build, ASP.NET will have to be mixed with AJAX or JQuery controls, requiring an additional language learning curve

Windows Presentation Foundation

ProsCons
I have done a 3 day course on WPFI have less direct experience working with WPF than WinForms
WPF supports vector graphics and DirectX
WPF uses XAML for form design – and as such is more declarative than WinForms – this simplifies coding slightly
WPF supports the full functionality of the .NET framework in code-behind
WPF does not require Javascript, AJAX or JQuery knowledge

Silverlight

ProsCons
Silverlight is heavily based on WPFI have no direct experience working with Silverlight
Silverlight supports vector graphics and DirectXSilverlight supports only a subset of the full functionality of the .NET framework in code-behind
Silverlight uses XAML for form design – and as such is more declarative than WinForms – this simplifies coding slightlySilverlight is a web-control set, and as such, runs in a sandbox that will make remoting awkward at best.
Silverlight will work on a Mac.

Native Direct-X

ProsCons
DirectX provides high performance access to graphics hardwareI have no real experience working with DirectX
DirectX natively supports most of the things we want to doDirectX is a complex API for developers who haven’t written games before
DirectX offers the opportunity to design a very rich interfaceDirectX is very resource dependent – this could be a strength if I were artistically inclined, but I’m not, so having to create shader textures, rich bitmaps and so forth… too hard
DirectX is a stable set of APIs – it has been around since the mid-90s.
DirectX provides feature-rich audio capabilities, including DirectVoice – it’s audio conferencing API
Because DirectX is a set of modular APIs, it can be included into other visual platforms if required

After working through the list above, I’ve decided that WPF provides the best mix of functionality and access to other tools.

Remoting Platform

What do I mean by “Remoting”? Remoting is the glue that connects one instance of the application to another over the network, allowing sharing of information, feeds (e.g. Chat) and streams (video/voice). Out of the APIs listed above, it’s probably going to be easiest to run with Windows Communication Foundation (WCF), as it serves as a wrapper/abstraction layer for the other two options (TCP/IP Sockets and Web Services).

Multimedia Platform

I think I’m going to park this one for now while I do more research. There’s a lot of options out there (windows native and third party APIs) and I’d like to spend some time evaluating them more thoroughly before I make a choice. Once I get a bit further into the project, I’ll post my reviews online here.

Structured Data Persistence & Distribution Platform

Having spent over a decade as a SQL Server DBA/Developer, the product family of choice for me is going to be SQL Server of some sort. XML is an option, but it’s stored as plain-text and therefore prone to hacking. XML is also a bastard to query – XPath is a pain to use, and XQuery is not supported natively in all situations.

The choice to me seems to be between SQL Server Compact Edition (runs in-process with the application, no support for stored procedures, but very small footprint) or SQL Server Express Edition (provides more features, but also requires a fairly large installation footprint).

For the purposes of this application, I’m going to favour deployment footprint as the determinant of which edition to use. As such, SQL Server Compact Edition will be used. I will use Sync Services to make sure that players can inspect and annotate their character sheets offline, and have their changes synchronized back to the GM once they connect.



I know I promised that I’d add some scheduling to this post, but the platform selection discussions got a bit bigger than I intended.

I’ve had a deeper think about scheduling and decided that I’m also going to manage the activities on this project using a 1-man “agile” approach. This means that the next post will lay out the process of turning the high level features from the previous post into a set of user stories to be implemented. I will rate the user stories by priority and effort, and seek to build a schedule from that.

Note that this is an out-of-hours project for me, so I’m only going to commit 10-15 hours a week to working on it, where the 10 is the actual coding/design effort, and the 0-5 extra is the blogging time. I may spend more time on development or blogging occasionally, but this project should be considered to be a long-term initiative.

Wednesday, January 6, 2010

MIA but now returned…

Wow… what a year 2009 turned out to be.  I ended up doing a lot of travel – especially during the latter half of the year, and ended up working long hours on most of the projects I was assigned to last year.  I didn’t have the spare energy to do the personal learning or the blog posting required to be able to achieve the objectives of this weblog, but I’m back on deck now – refocused, rejuvenated and ready to start chasing Eureka moments again in 2010.

So… to keep myself honest, I’m going to post somewhat of a schedule here that I’ll try my best to meet.  I’m also going to put my dev work in the context of a real-world project that will make use of .NET 3.0 and 3.5 technologies as a way to task orientate my learning, and the information I’ll be sharing on this blog.

So – let’s get started then!

The App

The project I’m going to be working with is a dice-and-paper role-playing game assistant.  I’m an old school gamer (in the pre-PC gaming sense) who has some friends interstate who are keen to do some dice-and-paper gaming, so I want to build an application that can facilitate a distribute gaming session, where participants are in different cities, or perhaps even different countries!  For now, I’m going to focus on Dungeons and Dragons Ed 3.5, as it’s relatively well-known, and still widely enjoyed.  However, once the initial cut is out, I may look at using some extensibility tools to see if I can make the game system “pluggable” and look at writing some plug-ins for the White Wolf “World of Darkness” game system, and perhaps look into wiring up Cyberpunk 2020 and Shadow Run.

Requirements

Video & Voice

The first thing I want the tool to do is display multiple web-cam feeds and play multiple voice streams.  I also want to be able to have the tool enable private conversations between the Game Master (GM – aka Dungeon Master) and individual players.

Text Messaging

The next thing I need is the ability for the GM to send text messages to individual players, and be able to see a feed of text messages being sent between the other players.

Roll, baby, Roll!

Another feature I need to implement is a centralized dice rolling system.  In a distributed gaming environment, relying on players to be honest with dice rolls can – well… let’s call it an exercise in optimism.  So a centralized dice manager is critical.  The dice roller needs to have the ability for all of the GM’s rolls to be made private.  The GM also needs to be able to make certain player rolls private between the GM and the chosen player.

What a character…

Another core feature is character sheet tracking.  Character stats, abilities, experience points, To-Hit and Saving throw targets, Inventory, Banked Inventory and personal character notes all need to be tracked.  We will store some of this information in SQL Server database tables.  The database will also store relevant tables used for resolving combat and non-combat character situations.  I will also need to build a forms-based GUI for displaying and editing information in the character sheets.  The GM needs edit-level access to all character sheets, and the players need to be able to edit certain fields. 

A fast game is a good game…

A “nice to have” feature would be to include an sand-timer that the GM can trigger to force players to come to a quick decision.  This is particularly useful in combat scenarios where you don’t want players “meta-gaming” too much – i.e. haggling over who is going to hit the dragon with swords, where the archer is going to stand, what spell the magic user should be casting, or who the cleric should be healing first.  An alarm that plays in the audio channel of all players when the sand-timer empties should get the message across.

Combat Assistant

Another “nice to have” will be the inclusion of a combat ticker that can help the GM manage initiative rolls, character/enemy action sequencing and resolve the results of dice rolls.  Ideally, this would pop up in a separate window and provide support for various character choices such as subduing an enemy, charging, retreating, performing a defensive disengagement or calling an aimed strike.

Maps, maps and more maps!

Once again, on the “nice to have” list will be a map management tool, that allows the GM to:

  • “Automagically” generate dungeon and building maps (this actually requires some quite complex rules, which is why this feature is a nice to have)
  • Upload maps created by the GM in Visio or JPEG format.
  • Display currently visible map segments to players
  • Manage the “Fog of War” based on player lines of sight.

In-Game Economics and Politics

The final “nice to have” feature (and probably the most difficult to implement) is tracking of in-game economics and politics.  For example:

  • If a band of adventurers clears all the goblins out of a dungeon, who moves in later?  What impact does this have on human, demi-human and humanoid populations in the area?  Who are the movers and shakers in the region? 
  • If the player characters killed the goblin smith who was working on a doomsday weapon for a major political player, can they find out who did it?  And what form will their retribution take? 
  • What about the slightly higher level scenario of a dark army levelling most of the towns in a given region and putting their crops to the torch?  What are the impacts of population change and resource changes? 
  • If the players drain a major shrine of its healing power to raise one of their fallen comrades from the dead, will this anger the locals? 
  • Given the typically feudal milieu that many role-playing games are set in, what sorts of problems might our characters set off by rising above their station, or mingling with lower castes than their own. 

A good GM will typically define a set of “factions” with whom adventurers can raise or lower their reputations.  A reputation tracker will be an important part of this module, but the GM should also be able to do some basic price modelling based on the demand and supply of resources, keeping in mind that humanoid races may participate in black-market economies, and that monsters can have an impact on the local demand and supply of goods (e.g. the undead roaming the marsh-lands, impacting the supply of peat to locals, or the bandits paying for their supplies with fools gold).  These impacts can probably be categorized as geographic, systemic, magic or malefic to help make the modelling easier.


Well… that’s a pretty fair volume of text for a single blog post.  I’ll sign off for now, but in the next post I’ll discuss the technologies I intend to use for the Game Assistant, and start building a schedule for follow-up posts.