Skip to the End...
I originally started writing this post chronologically. Since the most interesting stuff is from this week, I will start at the end. The history behind it is at the bottom if you want to use it as an alternative to counting sheep.
Onward...
I spent most of this week installing and setting up Xamarin (plus the Android Software Development Kit) and coding up touch and graphics functionality (OpenGLES - the baby sibling of OpenGL used by most mobile devices).
I now have a working prototype of the game running on Kindle with touch controls, albeit with placeholder boxes for the sprites (that bit of OpenGL ES code not done yet).
Pretty pleased. I honestly didn't expect to get this far so quickly, particular as it took me almost a full day of downloading to get Xamarin and the Android SDK installed (5-6 hours).
Screenshot below.
The game is now working on PC and Android (on our Kindle Fire at least!) I have yet to crash headlong into PC style driver compatibility issues as yet.
The PC version looks like this currently: (i.e. with proper graphics, rather than temporary coloured boxes)
It's very early days with this game. I do plan to stick with the vector style but a ton of visual effects and level complexities are still to be added.
My next job is to finish the graphics code then get sound working. The latter will hopefully be quite simple.
Xamarin - First Experiences
This part is only of interest if you're a game programmer (aspiring or investigating .NET / Xamarin).Starter Edition
I downloaded the free starter edition from Xamarin in January. This enabled me to evaluate the tools and have a play around. The starter edition only allows small, trivial applications to be compiled due to a size restriction on the compiled binary.
I compiled a few test versions and ran them on my little lad's Kindle then set about building my prototype game in C# (via Visual Studio on PC).
Shortly after downloading the Xamarin starter, I received an email from one of their development team (James). He was extremely helpful and answered my initial questions. I found this to be a good approach from Xamarin as it cleared a few things up for me.
I compiled a few test versions and ran them on my little lad's Kindle then set about building my prototype game in C# (via Visual Studio on PC).
Shortly after downloading the Xamarin starter, I received an email from one of their development team (James). He was extremely helpful and answered my initial questions. I found this to be a good approach from Xamarin as it cleared a few things up for me.
Indie Edition
This week (May 2014) I purchased the Indie license for Xamarin (Android, iOS and Mac). Initially I'm targeting Android as that's a natural fit with my PC development. When I have everything working satisfactorily on Android I'll port to iOS.
Again, like the starter edition, getting everything set up was pretty easy.
Again, like the starter edition, getting everything set up was pretty easy.
Thoughts on Xamarin Studio
Because I bought the cheaper Indie version (which fits my requirements for now), I am using Xamarin Studio for Android development. Visual Studio plug-ins are available with the Business and Enterprise editions.
As a Visual Studio (2010) user, getting into Xamarin Studio was extremely easy. I created a project in a subfolder of my Visual Studio project and added in the files. There's an option to link instead of copy which makes code sharing very easy and simple.
A book I found most helpful in getting started was 'Xamarin Cross-platform Application Development' by Jonathan Peppers (available on Amazon). It's short and straightforward book that gets you started on Android and iOS.
I had already designed the codebase so that platform-specific code (OpenGL, Sound, Window handling) lives in separate subclasses that can be excluded from the project (in my case via #if).
Before long I had all of the code compiling, albeit with lots of TODO comments and empty functions.
Unlike the C++ projects I have worked on, I encountered practically zero compiler differences. C# seems to be much more consistent across Microsoft .NET and Mono than the various dialects of C++. Also, I had no need to drop into Objective-C(++) as with my 'Starfire Ares Assault' project that used C++/SFML.
Another extremely useful book is 'Beginning Android Games (Second Edition)' by Mario Zechner and Robert Green. It's an Android/Java book but figuring out the Android way of doing things and OpenGLES coding is easy enough to switch to Xamarin.
Finally, I added a bunch of touch handling code to my engine. Again, with help from the Android Games book this was pretty easy. The main thing that tripped me up initially is the fact that events contain the current location of every pointer (finger) in an array. For example for a 'Down' event indicating a finger first touch, the coordinates and other information are provided for the 'Down' along with coordinates for every other finger that's already down.
In addition, the array of pointers contains an Id that identifies the individual finger, i.e. every event related that finger includes the Id. That's one to watch out for!
As a Visual Studio (2010) user, getting into Xamarin Studio was extremely easy. I created a project in a subfolder of my Visual Studio project and added in the files. There's an option to link instead of copy which makes code sharing very easy and simple.
A book I found most helpful in getting started was 'Xamarin Cross-platform Application Development' by Jonathan Peppers (available on Amazon). It's short and straightforward book that gets you started on Android and iOS.
I had already designed the codebase so that platform-specific code (OpenGL, Sound, Window handling) lives in separate subclasses that can be excluded from the project (in my case via #if).
Before long I had all of the code compiling, albeit with lots of TODO comments and empty functions.
Unlike the C++ projects I have worked on, I encountered practically zero compiler differences. C# seems to be much more consistent across Microsoft .NET and Mono than the various dialects of C++. Also, I had no need to drop into Objective-C(++) as with my 'Starfire Ares Assault' project that used C++/SFML.
Android Development Thoughts
After getting the codebase to compile I gradually converted my OpenGL (via OpenTK library) code over to OpenGLES (1.1). This was pretty easy - just some subtle differences in syntax and the necessity to get rid of GL.Begin and GL.End blocks, replacing them with vertex lists. That's the main difference between OpenGL and OpenGLES for straightforward applications.Another extremely useful book is 'Beginning Android Games (Second Edition)' by Mario Zechner and Robert Green. It's an Android/Java book but figuring out the Android way of doing things and OpenGLES coding is easy enough to switch to Xamarin.
Finally, I added a bunch of touch handling code to my engine. Again, with help from the Android Games book this was pretty easy. The main thing that tripped me up initially is the fact that events contain the current location of every pointer (finger) in an array. For example for a 'Down' event indicating a finger first touch, the coordinates and other information are provided for the 'Down' along with coordinates for every other finger that's already down.
In addition, the array of pointers contains an Id that identifies the individual finger, i.e. every event related that finger includes the Id. That's one to watch out for!
Summary
In summary, coming from a C# and OpenGL background, using Xamarin tools to build a game that works on PC (Windows) and Android has been very easy. I haven't investigated deployment or deeper subjects yet but my experiences so far are good.
Xamarin have created a set of tools that are very easy to get along with, particular if you're familiar with .NET already. I look forward to using the tools to build some apps in addition to games.
Xamarin have created a set of tools that are very easy to get along with, particular if you're familiar with .NET already. I look forward to using the tools to build some apps in addition to games.
Background / History (zzzzzzzzzzzzz)
My blog has suffered rather badly for more than a year, largely due to a 15 month contract to develop business software for a client.
In the meantime, I have been investigating technologies to build cross-platform games and applications (i.e. PC, Mac, Android, iOS in the first instance).
I played around with Monkey and had a decent prototype of my current game working, however I began to realise that my skills were being too diluted by the use of another language and Monkey is only suitable for games. I would like to port my kits database application to multiple platforms and don't want to have to learn two cross-platform technologies. Also there's no synergy between Monkey and my business development (predominantly .NET - C#, Visual Basic, SQL etc).
The final nail in the coffin was the main advantage of Monkey over other technologies is the HTML5 support. Unfortunately, the sound doesn't work on iOS due Apple's restrictions.
The logical conclusion is to use .NET (C#). I looked into MonoGame but that seemed too heavyweight and I read mixed reviews of its reliability. Under the hood of Mono, it sits on top of OpenTK (a cross-platform wrapper around OpenGL, OpenGLES, OpenAL and various O/S bits) and SharpDX (a Direct-X wrapper).
Thus, I decided to investigate OpenTK (SharpDX maybe later) and Xamarin. Xamarin is required to code against Android and iOS using .NET (even if you use MonoGame).
In January, I downloaded the free Starter edition of Xamarin and had a play around. I managed to get a demo OpenGL application onto our Kindle Fire, but that was about it. In the meantime, I've been porting my game prototype from Monkey to .NET (C#) using Visual Studio on my PC with a view to using Xamarin.
Anyhoo...
Having finished my contract work, I bought an Indie license for Xamarin iOS/Android/Mac and set about porting. My C# codebase was set up to be cross platform, therefore adapting it to interface with Android functionality (OpenGL ES - the embedded systems version).
... and the rest is at the top
