Divide and Conquer

In my previous post I discussed how I found a way to edit my iOS MonoDevelop (MD) projects in Visual Studio (VS) on my PC, but that I could not compile there and wanted to fix that. In this entry to discuss my solution.

At it's heart the problem is that by default iOS projects reference the MonoTouch (MT) library that wraps the standard iOS libraries (Cocoa, Core*, etc). These projects also have some special configuration options for iOS devices that VS doesn't like. Furthermore, if you are creating a typical iOS application then you probably need to interact with the MT libraries a lot. On the other hand, if you can divide your project into we separated layers, then all but the device specific functionality should be able to exist in standard .NET code and be fully compilable in any platform. That is exactly what I did.

Initially I had a single .NET project with 3 main components:
  1. OpenGL setup - A modified version of the default OpenGL related classes provided when you create a new MT iOS OpenGL solution. The modifications are relatively minor, although they do include also setting up OpenAL.
  2. Graphics and Sound utilities - Classes I'd written to provide some more object oriented constructs for base graphics and sound functionality. For example, I created a simple Texture class that was simply a set of coordinates that defined a triangle in the OpenGL world along with its matching triangular coordinates of the texture to show there. Another example is an AudioSample class that encapsulates an OpenAL audio sample that can be played, stopped, etc.
  3. Game logic - The actual game related components of my game.

So, what I did was to separate these 3 components into separate projects with only the first one referring to the MT library. In addition I created a new version of the first component that was compatible with the PC. If you're paying attention you might wonder about how I could create a PC project that relies on OpenGL ES (ES is the version of OpenGL that is for mobile devices) and on OpenAL, neither of which are standard functionality in Windows. I'll go into some details of this in future posts, for now I'll continue the discussion of the project reorganization.

I should mention that this project separation includes the unfortunate requirement of having parallel project (.csproj) files, one for MD and one for VS. This means that anytime I add a new file to my VS project I need to eventually add it to the MD one as well. Fortunately these new files quickly show up as missing when I compile, so it hasn't been too much of a burden yet. I do hope that MT supports VS better in the future, though.

On the coding side, one of the challenges I faced was that I didn't want to have anything in my first 2 projects that was specific to the game I'm writing. All of that should be only in the 3rd project. At the same time, the loading of data into my Texture and AudioSample classes is platform specific. For example, on the iPhone it is recommended that you have you audio files in CAF format. On the PC WAV is more typical. Also, UI interaction is platform dependant. Specifically the iPhone provides multi-touch events and the PC mouse events. Fortunately, it turned out to be relatively easy to handle all of this.

For the Texture data loading I simply pass a Func<string, Texture> to my main game class' constructor. This takes a string (the filename of the texture data) and returns a fully instantiated, platform independent Texture object.

Similarly, for the AudioSample I pass a Func<string, AudioData> that does that same but returns a platform independent AudioData object.

Finally, for the UI interaction I just have few methods on my main game object that are called for touches/mouse event. At this point I don't have any interaction that is iOS specific (i.e., multi-touch) that is not possible on the PC. If I get to the point that this is required then I'll have to come up with a work-around for the PC side.

One thing that's implied in all of this is that I did need to implement the texture loader and sample loader twice, once for each platform. This is true, but was relatively simple. One other huge advantages of dividing my projects in this way now is that I'm setting myself up well to support Android and Windows Mobile 7 devices later. Although, I should mention, I am still writing my game classes with a certain amount of reliance on OpenGL, so porting this to another graphics framework would probably be a bit more work (Does Windows Mobile 7 have OpenGL or some mobile DirectX?).

Next time: OpenGL ES 1.1 on Windows.

P.S. One other note on this...
My initial version written in MD on the Mac used standard .NET System.Drawing.PointF structs to keep track of coordinates. Unfortunately, I ran into a problem with this when I separated my projects. Apparently MT does not include a full implementation of System.Drawing and only bundles a few parts inside the main MT library. This means that when I separated my platform independent project for which I did not want a reference to MT they also lot their reference to PointF. My solution was to change to use OpenGL's Vector2 struct, which is basically the same, although it is one of the reliances on OpenGL that I mentioned above that I would prefer not to have.


MonoDevelop isn't bad, but I really prefer VisualStudio

In my last entry I described how I decided to do my iOS development on MonoTouch. Now I discuss how despite the increased efficiency of a familiar language (C#), I still struggled with the MonoDevelop IDE.

First, let me say that my dissatisfaction with MonoDevelop (MD) is in due to comparing it to Visual Studio (VS). According to Wikipedia, VS started in 1997. Clearly it isn't fair to compare the maturity and depth of features of a product that has been under development for more than 13 years to one that is only a few years old. Also, I'm sure the size of the development teams are greatly unequal. Despite that, the reality for me was that I found MD falling short of what I was used to wanted.

I noticed on the MonoTouch Roadmap page that they plan to extend Mono for Visual Studio to "allow developers to use Visual Studio to develop iPhone applications", but since no timeline is given I have no idea when this will happen. So, I tried to do something on my own.
MD saves projects in the same format as VS, so my first thought was to just open the project there and see what happens. I tried this, but VS complained of some error. I did a search and found a page suggesting a solution called VSMTouch.

The solution was to convert the MD projects so that VS can open them. Although the format of the files are the same, the MD projects refer to certain iPhone specific libraries, which don't exist on a Windows PC, of course. What this means is that even using VSMTouch will create a project that can be open in VS, but can't be compiled.

Well, although that  allows me to edit in my familiar environment, I still was not satisfied. VS has some great features that require the ability to compile (e.g., FxCop and built-in unit test framework). Also, I knew that I would want the ability to run my game relatively often as I develop it to test new things. Additionally, in the long term, MT plans to support Android, and Windows Mobile 7 will support .NET out of the box, so there are strong incentives for me to be able to develop more fully across platfroms.

Next time: Divide and Conquer.


iPhone Does .NET

In my last entry I described how I began the process of developing a game for iOS. Now, I'm going to continue that story with what's changed since 1 and ½ years ago when I started.

When I was developing initially I was reading a number of news feeds related to iPhone development to try to learn as I went. I remember at that time Novell announce a Mono based platform for iPhone development. This was very intriguing to me at the time, since Mono is an opensource implementation of the .NET framework, with which I have a lot of experience; far more than C, C++, and Objective-C, which are the default languages for iPhone development. I didn't really look into it at the time as it was pre-release and, if I remember correctly, advertised as being around $1000 for a license.

When I recently returned to developing my game, however, I again quickly became frustrated by the Xcode development environment and the learning curve involved for me. Around this time Apple announced greatly relaxed development restrictions and I remembered the Novell announcement and decided to see how the maturity of the platform was now. As it turns out, MonoTouch (the name of the Novell platform) is still undergoing rapid development and is at the point where it is quite usable. Also, the price either changed or I misremembered and is down to $399 for individuals.

Novell has a free version of MonoTouch that has only the limitation that you can run your program only in the iPhone emulator and not on an actual device, so I downloaded that and started porting my game over from the old C & C++ & Objective-C version I'd previously worked on. I should mention that MonoTouch includes a version of MonoDevelop, an opensource .NET IDE, that integrates well for developing for iPhone.

After a bit of work I got enough of my game running to see that it would work on MonoTouch and that it seemed to run fast enough on .NET on the emulator on my Mac. But, I was a bit worried how well it would run on an actual iPhone.

I debated for a while, but then noticed that Novell was having a sale for MonoTouch of 15% off in celebration of 1 year of MonoTouch, so I jumped in and signed up. I then deployed to my iPhone and was pleasantly surprised at the performance. Everything looked fine.

Admittedly $399 is still a bit of an investment, but I'd already paid for a used iMac (about $300 or $400, I don't remember) and 2 iOS Developer licenses ($99 each year), so I decided to double-down and improve the chances I actually finish the game this time.

Next time: MonoDevelop isn't bad, but I really prefer VisualStudio.


Zoing: The Beginning...

About 1 and ½ years ago I decided I wanted to write an iPhone game. I've had the game idea for a long time and actually implemented a mostly-working version on my Amiga 20 years ago or so, but with the App Store and the iPhone ecosystem, I felt there was finally a way to get the game out there and into peoples hands.

I bought a used iMac from a coworker, signed up as an iPhone OS (now iOS) developer, and began. I immediately ran into a bunch of issues that slowed me down. I hadn't used a Mac in many years, I was new to OpenGL and found most documentation targeted the full OpenGL API, not the more limited mobile version (OpenGL ES), and I found the Apple Xcode development environment unintuitive and feature-limited (sorry, Apple, but despite you repeating that it is a great IDE, it absolutely pales in comparison to Visual Studio).

But, I kept at it. I figured out how to get around the Mac, I found a few OpenGL ES examples to get me started, and I was able to set aside the features I prefer in Visual Studio and use Xcode well enough. Within a month or so (I have a day job too, so I can't put too much time into this), I got enough running to show the main idea of the game. Heck, I even got OpenAL (the audio system to play sounds in the game) included.

Then I changed jobs, and I became very busy at my new job and had no time to work on my game. Then time passed, and my iOS Developer subscription expired.

But, now I'm back. I've renewed as an iOS Developer, and I'm determined to get the game done and released.

Next time: iPhone does .NET.