Marc Melvin’s Blog

I recently had to find a way to merge a ResourceDictionary that is embedded in a class library into my application’s MergedDictionaries collection, so this is how I did it. I created the following extension method:

    static public class ExtensionHelpers
    {
        static public void AddAssemblyResource(this Application app, string assemblyName, string path)
        {
            if (!UriParser.IsKnownScheme("pack"))
                UriParser.Register(new GenericUriParser(GenericUriParserOptions.GenericAuthority), "pack", -1);
 
            ResourceDictionary dict = new ResourceDictionary();
            Uri uri = new Uri("/" + assemblyName + ";component/" + path, UriKind.Relative);
            dict.Source = uri;
            app.Resources.MergedDictionaries.Add(dict);
        }
    }

Then, to add my resource, I simply call

App.Current.AddAssemblyResource("My.Assembly.Name", "Path/To/Resource.xaml");

It’s a new one on me… seems that everyone on the internet is whining that Android 2 (the update currently available on Droid, Nexus One, etc) doesn’t have multitouch support… what they mean to say is that the built-in Google Apps, like Maps, Gallery, etc. are limited in multitouch support. As an Android developer, I’m perfectly capable of writing the same multitouch applications for Android 2 right now that you see on the iPhone, so stop spreading your Apple fanboy FUD all over the internet. Thank you.

Here’s a link to the Android SDK for proof.

The current version of Tetroid has hit somewhat of a brick wall in terms of ability to move forward, and the fact that everyone is making extremely clear in their comments to me is that it is lacking several key features that should’ve been there since the beginning. Since I had never planned on releasing it in the first place, I skipped over some of the seemingly fundamental design elements needed for a successful mobile game, the biggest of which would be the pause feature.

With that being said, I’ve decided to take an all or nothing approach and rewrite Tetroid from scratch, this time following the recommended practices provided by Google. Here are some of the features that I’ll be focusing on:

• There will be a pause feature in the next version, both manual and automatic.
• There will be plenty of room, performance wise, to add in sound effects and animations.
• Multiple styles of play (not just classic Tetris) that should keep the game interesting.
• Online high score system to make it competitive.

This game was my first Android game and my first mobile game, so I’ve learned a lot in the process. I’m going to take one last stab at going back and doing it right from scratch, then I’m going to move on to my next project which should be a much more original, and hopefully way more fun, mobile game.

Tetroid v1.0.5 for Android is released to the marketplace.

Tetroid v1.0.4 for Android is released to the marketplace.

Tetroid v1.0.3 for Android is released to the marketplace.

• Complete facelift on gameplay screen.
• Movement calculation algorithm for all supported inputs have been improved.
• Sensitivity settings have been improved.
• Width/height of play area can be changed.
• Touch movement support added.
• Touch/drag up and down options for rotate/drop added.
• Level and lines indicator added.
• Game gets a tiny bit faster with each level increase.
• Next and swap preview added.
• Touching the swap area will exchange the next and swap pieces.

And probably a few things I’m forgetting. Here’s a few screenshots of Tetroid for those that haven’t seen it and are curious. Click for larger image:

As always, keep your eyes open for more updates!

 
I’m a strong believer in agile development. No matter how big or small the project, from my experiences, agile methodology always yields the best results. Release early and release often should be every developer’s mantra, and user feedback should be the device that drives future development and modifications. In a perfect world, this should always result in a solid product that matches user expectations while reducing the development time involved.

I’ve been asked by several people in the Android community, “What in the hell were you thinking releasing Tetroid the same night you started it, and especially when you knew that you would get negative feedback on the flawed controls and missing features? Aren’t you worried about all of the negative feedback that will follow the game all the way through to the point when it is polished and perfect?” My answer to this is no. I have nothing to lose from it, and the end-user will win in the end because of it.

First, let’s examine the alternative. Let’s assume for a moment that I had started working on Tetroid over a year ago when the Android SDK was first announced by Google. A year is a lot of time to develop a product, test a product, provide a featureful application, and remove any inherent flaws in the process. After a year of waiting, the first release of the game would probably be very polished and very clean; however, no matter how hard you try, you can’t make everyone happy. There is no software product in the world that is without a negative review by someone somewhere. There would still be negative feedback regardless of how “perfect” it seemed at time of release because everyone’s view of “perfect” is quite different. Unfortunately, after a year of development, most of the processes have been decided upon and are tightly coupled in the application to the point of not being able to be changed easily. To change a piece of an application that is so deeply embedded in the logic at this point is extremely difficult and takes a lot of time, therefore creating much longer release cycles. Something that would seem so simple to change could take weeks, and might not be able to be changed at all without producing a seemingly different application in the end.

Now, let’s examine the agile methodology of “release early and release often.” By immediately releasing the semi-working Tetroid that was designed, developed, and tested in a period of 8 hours, I was able to receive immediate feedback from the user base. Of course the feedback was 99% negative (and actually surprisingly more constructive than I was expecting!), but unhappy customers are the best source for great product feedback, and man did I receive plenty! The following day, I released a second update that attacked the issue that I felt was mentioned by at least 75% of all negative feedback I received: trackball support. Believe it or not, I never had any intention of supporting the trackball (after owning a Blackberry for several years, I am fairly ANTI-trackball). If I had waited years, months, or even a week to release Tetroid to the public, it still would not have had this feature and I might not have put myself in a position where I could add trackball support in a single day like I did. This easily could’ve required weeks to refactor the logic to support trackball input, and the user base’s faith in the product would’ve been completely destroyed by that time.

There are plenty of advantages/disadvantages to using agile and not using agile, but I believe that it has really made a big difference here. Tetroid went from being unplayable to playable in a single day, and it may be only another day or two before the negative feedback relating to ”fun factor” is resolved.

As for the negative feedback following the product through each update, I am counting on the users to change their comments and ratings as time goes on and Tetroid improves. My logic for this is that if they had time to bash it initially, they will probably put in the time to praise it for its improvements. If they don’t, then oh well. The only thing that matters is that the product is improving and the people that are willing to ride the updates and provide constructive feedback along the way are the ones who will win in the end.
 

Tetroid v1.0.2 for Android is released to the marketplace.

• Trackball support added.
• Options menu added with saved user preferences.
• Trackball left/right control can be enabled/disabled.
• Tilt left/right control can be enabled/disabled.
• Tilt forward for speed increase can be enabled/disabled.
• Trackball press can be configured to do nothing, rotate piece, or drop piece.
• Screen press can be configured to do nothing, rotate piece, or drop piece.
• Sensitivity settings for both trackball and tilt controls.

I have been disappointed lately at the quality of games on the Android platform. Specifically, I haven’t seen too many “classics” in the mix, simple games like Tetris, Chess, Checkers, etc. I’ve been meaning to jump into the Android SDK and start messing with it, but last night was the final straw for me. I had to make a playable game for my phone, see the capabilities of the device for myself, and if something good came out of it that I could release to the world, I would jump on the opportunity.

With that being said, I built and released my first Android game last night, from scratch, into the marketplace. It is a Tetris clone that I called Tetroid, complete with a cute little Tetris Android guy for an icon. In about 7 hours, I had to reacquaint myself with Java, learn as much as I could about the Android SDK, and build a playable Tetris clone (including beating my head against the wall to come up with what turned out to be an EXTREMELY simple algorithm for rotating any shaped piece on the fly). Tetris is something I’ve always laughed at other developers for building because of its sheer logical simplicity. Well, I am happy to report that it has started out to be a fun and challenging project, one that I plan to continue working on dilligently over the next few weeks when time permits.

Almost immediately, I have seen the power of the Android marketplace to reach the community. My inbox has been flooded by people praising me for finally building a Tetris clone for Android as well as flaming me for the lack of features. In addition, I’ve received offers to help, lots of positive feedback (which I used to create the nice little to-do list that you see below), and possibly made a few friends in the process. Not only that, but the comments in the marketplace itself have been both enlightening and positive as well as downright rude and ignorant. But I have a feeling that all of this will make me into a better developer in the end.

So, with that being said, here’s my list of to-dos for the upcoming releases of Tetroid:

1. Add trackball support.
2. Add motion gesture support.
3. Add options menu to enable/disable all these options as well as adjusting sensitivity.
4. Make blocks smaller, increase height of playing area, maybe make all of this adjustable if I can.
5. Make game get faster/harder as it progresses.
6. Create a top score service to track scores of everyone around the world.
7. Add optional “special” pieces to add a bit of a twist to the game (like bombs, for instance).
8. Add optional sounds/music support (maybe).
9. Add special effects to the blocks for better visual feel.

It is a pretty hefty list, but I’m already well on my way to completing a few of these right now. For anyone aspiring to create Android games, I must urge you to do so no matter what excuse may be stopping you! It has been an unbelievably positive experience, and I’m not even 24 hours into it yet!

If you have played Tetroid, please leave me a comment or two below and let me know what you think! I will be using my blog to report updates on the game’s status as it progresses, so please subscribe to my feed on the right to stay updated!
 

I’ve been told several times in the past that I have a unique way of debugging .NET Windows services. While most of my colleagues go through the typical process of building, installing, and attaching to the process, I find it much easier to just hit F5 and be done with it. I have a very precise way of doing this that makes it extremely easy.

1. Create a new Windows service project the same way you normally would in Visual Studio.
2. When debugging our Windows service project in Visual Studio, we want to open a console window that can be used for outputting debug messages. Create a helper class called ConsoleHelper (I usually do this in a common shared library that I reuse in all my projects) that looks like this:
   ^?View Code CSHARP

   static public class ConsoleHelper { [DllImport("kernel32.dll")] private static extern int AllocConsole(); [DllImport("kernel32.dll")] private static extern int FreeConsole();   static public void OpenConsole() { AllocConsole(); }   static public void CloseConsole() { FreeConsole(); } }

3. Because we will be running our service as somewhat of a “console” application in debug mode, the typical service start/stop routines won’t be called the same way. Since they default to having protected modifiers, we will modify our service by adding internal Start() and Shutdown() methods, and ensure that the service overrides for OnStart() and OnStop() just call these new methods we are creating for when it actually runs in release mode. I also like to put the overrides in a region so I can hide them away from view and to keep me from adding code to them by accident. All of my service code will go in Start() and Shutdown() now, so I don’t really need them any more. Open the code view of your Service1.cs file and make it look something like this:
   ^?View Code CSHARP

   public partial class Service1 : ServiceBase { public Service1() { InitializeComponent(); }   internal void Start() { }   internal void Shutdown() { }   #region ServiceBase Overrides   protected override void OnStart(string[] args) { Start(); }   protected override void OnStop() { Shutdown(); }   #endregion }

4. Now, we need to replace the entry point of the application to support the special case for when we are running in debug mode. Open the Program.cs file and find your main() method. Find the code that looks like this:
   ^?View Code CSHARP

   ServiceBase[] ServicesToRun; ServicesToRun = new ServiceBase[] { new MyService() }; ServiceBase.Run(ServicesToRun);

   And replace it with this (make sure your service class names actually match your service classes instead of MyService):

   ^?View Code CSHARP

   #if !DEBUG ServiceBase[] ServicesToRun; ServicesToRun = new ServiceBase[] { new MyService() }; ServiceBase.Run(ServicesToRun); #else ConsoleHelper.OpenConsole(); Console.WriteLine("Server-side service started. Press ENTER to stop service.");   try { MyService service = new MyService(); service.Start(); Console.ReadLine(); service.Shutdown(); } catch (Exception ex) { Console.WriteLine(ex.Message + "\n" + ex.StackTrace); Console.ReadLine(); }   ConsoleHelper.CloseConsole(); #endif

   If you run this now in debug mode, you will see a debug window popup, and your “service” will be running very similarly to how it would run if it were actually installed. However, there are a few more things we still need to do, so let’s press on.

5. We still need to take care of adding the typical service installer to our service. To do this, open the Service1.cs file in design view. When the component designer appears, right click anywhere in the designer and choose “Add Installer.” This will create our ProjectInstaller.cs component.
6. Last, we want to make sure that no one accidentally installs a debug build of this service as it will do some very funky things. Not only will it let you install it, but it will appear to actually be working (and then “fail gracefully” with a ridiculous error that makes you think your code is wrong when it isn’t). To do this, we need to add an Install() override to the ProjectInstaller class that will throw an exception when an install is attempted in debug mode. Open up ProjectInstaller.cs in code view and change it to look like the following:
   ^?View Code CSHARP

   [RunInstaller(true)] public partial class ProjectInstaller : Installer { public ProjectInstaller() { InitializeComponent(); }   public override void Install(IDictionary stateSaver) { #if DEBUG throw new ApplicationException("You cannot install the debug version of this service."); #else base.Install(stateSaver); #endif } }

7. Ok, I lied. There is one more cool thing we can do which I will leave as an exercise for the reader. We can create a static Log class to log any event we want throughout our service code. In release mode, we might use this to log our message to the Windows event log or send a horrible annoying email to the developer (remember, that’s YOU!). In debug mode, we can just write our message directly out to the console and our ConsoleHelper window will pick it up automatically. Yay for programming!