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.
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.
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.
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.
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 support||Windows Forms offers minimal support for vector graphics – particularly important for map rotation/zoom|
ASP.NET Web Forms
|I have plenty of reference material on ASP.NET||I 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-behind||ASP.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
|I have done a 3 day course on WPF||I 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|
|Silverlight is heavily based on WPF||I have no direct experience working with Silverlight|
|Silverlight supports vector graphics and DirectX||Silverlight 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 slightly||Silverlight 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.|
|DirectX provides high performance access to graphics hardware||I have no real experience working with DirectX|
|DirectX natively supports most of the things we want to do||DirectX is a complex API for developers who haven’t written games before|
|DirectX offers the opportunity to design a very rich interface||DirectX 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.
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).
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.