Well the game that I alluded to in some of my previous posts is now live. I am biased of course, but I am pleased with how it turned out. I think it is pretty fun to play and that is really the most important thing.
Anyway, there is quite a bit of discussion around the Flash/Flex and Silverlight development communities about which platform is better and why. While most of these conversations have been primarily speculative I think that after going through an actual development cycle with Silverlight I have something to contribute to the conversation. The Adobe camp radicals would have you believe that Silverlight will never amount to a hill of beans, and the Microsoft camp radicals would have you believe that Silverlight is going to put Flash six feet under. In my opinion they are both wrong. Right now a meaningful comparison between the two products is very difficult because of the state of Silverlight. It just is not fair to compare a full release product suite with one that is in various stages of development. In spite of that I am going to talk about some of the things that Zero Gravity utilized successfully in Silverlight and the processes we went through to build the game along with some of the things that are lacking and caused me some frustration, discuss some design considerations, and then wrap up with what I think the current state of Silverlight is.
As I mentioned in my previous post, we had quite a bit of concern initially that the size of xaml files would make web delivery of a moderate to large scale Silverlight application prohibitive. However the ability to archive assets and extract them at runtime provided a solution which the game utilizes in the form of a preloader. Virtually every asset, with the exception of some very small xaml files embedded in the assembly for the textbox control, are archived and pulled during the preload process of game initialization. Also, all of the video (wmv), audio (mp3), and images (png and jpg) in the game are built from dynamic MediaElement and Image construction. Their sources are set directly from the archived asset. I expect that asset archiving of this nature will quickly become a standard practice in Silverlight development unless Microsoft jumps the gun and gives us utilities to abstract the process entirely.
Included in our asset archive are all of our xml files that specify the metadata about each game board and the definition of the boards themselves. Unfortunately right now the only utilities that Silverlight provides to manipulate xml are the XmlReader and XmlWriter classes. For those who are not familiar with the .NET framework, the XmlReader class is a low level xml string tokenizer that allows forward only analysis of an xml string. It is a cumbersome way of parsing xml and will hopefully become unnecessary due to the eventual introduction of LINQ to the Silverlight platform. You can learn about LINQ here. I have not seen a specific date on when it will be introduced, so if you plan on building a Silverlight application anytime soon, say hello to the XmlReader.
On a more positive note, network communication development in Silverlight went surprisingly well for us. Initially I stubbed out a class where I intended to write my client side code for the communication to the web service that I knew was going to be built with ASP.NET and dummied up the returns so that my UI development could continue. Now normally in a Flash world, at some point myself and the service engineer would sit down and agree upon our data exchange format and API, then go off and write our respective pieces, and then come back and integrate them. But in Silverlight, we were both working in Orcas under the same project solution, and the service engineer was able to build his project right there and write both sides of the communication interface, one in his web service, and the other in my stubbed out class within the game. At that point all I had to do was refactor a bit of code to make sure my method calls matched his slightly modified API (due to emerging specs of course) and we were done. We were both pleased with how it progressed and the efficiency we gained from building the game with that paradigm.
Alright so enough of the infrastructure stuff and on to some view coding. Unfortunately when I started this project I had only an understanding of the C# language, but lacked any understanding of conventional visual windows programming. Perhaps if I had that understanding the concept of custom controls would have immediately clicked for me, but I didn’t discover their power until several weeks in. At this point I would equate them to Flash components because they serve the same sort of role but with an added facility which became the solution for a real stumbling block for me in Silverlight. In xaml markup, you can name your visual elements using the x:Name property and then use that name to locate the element in your managed code. The catch is that the names must be unique, regardless of where they fall in the structure of the xaml. Giving two elements the same name in a xaml file will cause an exception when the xaml is read, regardless of how you try to read it. Another even more problematic issue with this is that even if you have unique names in a xaml asset, you can only ever have one of those registered in the display list, because if you create another and attempt to add it, a name collision is occurring somewhere in the tree. The solution to this is the custom control. Each control creates a namescope which prevents name collisions between multiple instances of the same asset. Once I discovered this, I refactored all of the games board elements such as the player, the ship, the blocks, tubes, teleporters, and switches over to controls. The controls then encapsulate all the logic necessary to manipulate the asset, including its xaml defined animations, and expose functions necessary for clients to use them. I also used controls to expose properties in a simpler and more familiar way. A couple of examples of this are Canvas.LeftProperty masked as an “x” setter, a xaml defined ScaleTransform masked as a “scale” setter, and a xaml defined RotateTransform masked as a “rotation” setter. In general I do not think that the power of controls is adequately explained in the Silverlight tutorials, but then again, the documentation is currently quite sparse, so the power of a lot of things is not adequately explained.
The other view element that I want to discuss is controls and containers. Basically Silverlight lacks some very fundamental controls right now, most notably a text input facility, and does not support containers at all. Their absence means a huge loss of productivity for anyone currently trying to build a Silverlight application. Zero Gravity uses custom code to achieve its liquid layout and uses a freely available controls/containers library published by Dave Relyea which you can get here to implement its text input fields. Daves’ controls were quite helpful to me but they cannot take the place of actual Silverlight framework support for these facilities (Dave never claimed they could). The upside to this situation is that I have been told in no uncertain terms that a control and container library will be added to Silverlight but I do not expect it by the release of 1.0.
The promises of controls and containers are not the only promises Microsoft is laying down right now. Data binding and skinning support are also slated for the framework. When they get included is something I cannot answer, but the fact that these discussions are taking place, combined with the current state of the 1.1 alpha leads me to believe that Silverlight has a very bright future in the development community. However, that community is only half of what makes successful RIAs. We can’t forget about the design community and I do not think they are nearly as excited about the power of the Expression Suite and Silverlight.
Expression Blend is the primary animation facility for xaml assets and from my perspective it is so far out of sync with Silverlight right now that an efficient workflow between developer and designer isn’t achievable. Basically Blend is entirely geared toward WPF right now and the xaml it produces isn’t going to function in Silverlight without rework that a designer isn’t likely to do. The end result was that I had to edit quite a large amount of xaml by hand to get the assets to work. I don’t blame my designers for this at all. Sure you can see the xaml that Blend is building in the program at any time, but should a designer really need to understand that Silverlight does not support the Viewbox yet and that Canvas has to be used for everything? No, that would be ridiculous. This particular stumbling block is very much on Microsofts radar and I know they intend for the integration between the applications in the Expression Suite and Silverlight to be very tight. I am not worried about them fixing it in the future.
However, there are other design related problems that unfortunately I cannot speak to first hand, but can give at least an impression of. Blend is reportedly a fairly weak alternative to Flash when it comes to animation. Apparently the tools are rudimentary and the control required to animate efficiently is absent. I think that if anything is going to slow down Silverlight, this is it. Microsoft cannot sway a large number of designers the way the can sway a large number of developers because the pool of developers ready to learn Silverlight is so vast, while the pool of designers ready to leave Adobe is so small. Only time will tell with this and I wish I could give more insight into the situation, but I cannot animate my way out of a wet paper bag in Flash or Blend so I will say no more.
Looking back over this post you might have caught on that there are a lot of things left “to the future” with Silverlight, which goes back to my original point that making comparisons with Flash right now is just premature. The potential of Silverlight is obvious and very real, but I would caution anyone looking at it as a solution today. Right now Adobe has a superior technical and design platform, and that isn’t going to change over night. I believe Microsoft is going to close the technical gap quickly, and how fast they can close the design gap remains to be seen. Overall I would encourage any RIA developer out there to investigate what Silverlight has to offer because it might not be long before it becomes a very marketable skill.
-Casey
Tater Salad 