Nowadays Everyone is a Developer

I just discovered the Developer Tools in IE8. WHAT THE?! When did things get so complicated? I suppose when browsers got so capable – however goes some way to explaining why people treat the browser like systems in their own right now. And IE8 and I should fancy also Firefox and everything else has a console I can try stuff out on. How weird – I mean for someone who has not had call to write a website by hand in a long time. No wonder web “developers” can exist purely in web land and still make a lot of noise – web land seems to have all the resources to keep people verybusy and make something like a 20k piece of wondercode seem cool enough to make people’s lives a lot easier. Still, all that piece of code appears to be is essentially a vimrc – a rewrite function that subverts the way the engine works. So what is the browser now – a kernel, an engine, a database? Are developers just DBAs, tweaking and poking the engine to do it what they want it to? And does anybody care about all this cleverness if they’re not actually another web developer? I mean we hear about jQuery and HTML5 but the world is still turning the same way and web pages are as shonky and slow and unreliable as they always were. So what gives with me and what gives with the world of the web?

But I can start to feel a fundamental change in my assumptions. Rather than the browser being the add on – the browser is at the centre and everything else floats around that. But Google tried that and it plainly didn’t work for some very good reasons that Berners-Lee said on a mailing list not so long ago which I would only misquote if I could find it. And so I digress into a Friday reverie of simpler times when you could understand what was going on and not everyone thought they were a developer.

Except of course back then everyone told you to read Zen and the Art of the Internet and The Internet Worm and consider those as even more simple times and looked down their noses at poncy C++ developers with their modern ideas.

Another Rabbit Hole

The last few days have involved all sorts of user interface ridiculousness.  WPF, .NET, Java, Swing and Eclipse and then back to .NET and then on to C++ and then back to .NET again.  It’s nice getting on top, underneath, beyond, behind and inside of things sometimes and then it’s also nice to hear something like this announcement and just think – Ok perhaps this is where I should be going now.  Stop running around like a headless Christmas Chicken.

MonoGame is doing what Unity and GameMaker Studio and and Xamarin and all those other platforms are doing – they’re allowing you to target multiple systems (iOS, Android, WP7, XBox etc) with one codebase utilising a clever framework.  What MonoGame does differently though is that it builds on something that is already there and established (i.e. XNA) and it targets all those platforms from pretty much the same codebase (they say) and it’s open source and it intends to stay that way.  The others are going to charge you money to do this – a lot of money.   The paid-for ones have fancier tools but they all essentially do the same thing.

So I now have something new to look at.  After a year of XNA fiddling with Friendlier and having made progress with Android and OpenGL development I feel I can have an objective look at something like MonoGame without feeling that I’m taking the easy way out.  I’m already writing a framework, I should understand their framework.  And this might be a good opportunity for a little decluttering of the projects that have built up over the last year…

Platform Transform

I’ve been burying my head in Brazil – the framework – over the last few weeks.

The first step was taking Friendlier and making it work as an API. Cutting vast blocks of functionality (which forshame resided mainly in one or two huge files) into firstly addressable chunks and then to plump out this component based API with blocks that would equate to finer grained control with subsequent apps.

To whit – I parcelled up the old stuff and kept it working while creating new things that had a cleaner and therefore more reusable interface. The output of this phase of work was a half completed game called Paulo. This is what Christmas Chickens is turning into. A 3D XNA game written using Brazil.

So once I had satisfied myself that the framework was usable I set about moving it immediately on to another platform. Why not finish the game? Well my goals are bigger than ‘just’ writing games and also not limited to one platform. I could just write a game in XNA if I wanted to target that platform. I wanted to see if this framework would translate to another platform – and I didn’t want to wait any longer to test out the theory.

Next stop – Eclipse, Java, Android OpenGLES. Big change from the (yes) cosseted world of Visual Studio and XNA 4.0.

Select java version, install java SDK, get Eclipse (or another IDE), download the Android SDK and virtual device (AVD) manager, then select and download target Android SDKs, integrate the Android and Mercurial plugins for my IDE and fire up a new Android project.

Then on to the OpenGL integration. Subclass the Renderer object and port my existing C# framework into Java. This bit is relatively straightforward as C# and Java share a great deal of syntactic similarities. The larger challenge is working out how much abstraction to keep in Brazil for Java. OpenGL is a lower level API than XNA is therefore the choice is to bind directly with it or introduce some XNA like helper components such as Vector3s and BoundingBoxes. However, so far so good. I have a working Java framework and a working application and I’m able to fire up a virtual Android device and see the app working.

Next steps will be Paulo for Android and then I tackle the next platform. I’m documenting this transformation here and also over on the xyglo site where you can see code examples.