Introducing: Jario

Jario logoYou saw Hario, and you revelled in its technical prowess. Now, the summer (winter) blockbuster of 2011 has arrived.

Jario is a port of Hario, and is similarly a very basic Mario clone, the quintessential platformer. From Hario’s C++ and HGE, Jario is running with Java and the Slick game library, as well as the brilliant Artemis entity-component framework, and it is an exploration of how to apply such a framework to a platformer-style game.

It’s currently in its very early stages after about a week of development from scratch, but it runs, and it already has more features than Hario. And although you may not believe it when you see it, it has superior graphics as well. There is no art more noble than that of a programmer.

It’s important to note that Jario is not a game so much as a proof of technology for the foundation of a game. As features are implemented it will become more game-like, and if I ever ‘finish’ it then it will perhaps be a game, but in my eyes it is just a body of code. The good news is that I can now refer to this code as I discuss Artemis and entity-component frameworks in general, which I certainly will get around to now. Jario is just the first step on the path to bigger and better things.

As usual, you can download the Web Start or run it in your browser. In addition, since it’s basically a piece of tech, I figured I should release the source code on Bitbucket to get some feedback from those with a little more Artemis experience. Finally, for this release there’s also a bonus feature: a pretty button for launching the Web Start! Behold:

Launch Java Web Start button

NOTE: Google Chrome users (such as myself) may find this button just downloading a JNLP file rather than launching anything tangible. To resolve this, click the little down arrow next to the downloaded file on the downloads shelf (the toolbar across the bottom) and select “Always open files of this type”. This will tell Chrome to launch JNLPs automatically (as well as downloading) rather than making the user do it, just like the other browsers.

Jonathan Blow on How to Program Independent Games

Braid image

I’ve just got done listening to a university presentation by Jonathan Blow, creator of the fantastic Braid, on his insights into independent game programming. It’s very good.

The talk is about 38 minutes with another 40 of Q&A, and he talks mostly about the “aesthetic” he maintains for being “brutally productive” the way he is required to be to create (and finish) something like Braid (with around 90,000 lines of code) by himself in just a few years.

Since it’s a talk to a group of computer science students it’s a little technical but not especially so. The key points are about not making things more complex than they need to be; effectively Keep It Simple, Stupid.

  • Avoid premature optimisation, including sophisticated algorithms and data structures, which are essentially about optimisation.
  • Don’t generalise a program more than necessary, even to the point of avoiding refactoring a 1,000 line function.
  • A “good” programmer will get things done quickly and solidly, and simply, with an emphasis on actuallygetting things done.

This is very congruent with my mentality, which is why you’re unlikely to see my writing about fancy algorithms and data structures (or the dreaded topic of “web scale“; warning, justified language). I like doing things, creating things that don’t already exist, and although I’m still relatively inexperienced I do very much hope to one day reach that point where I can put together something like Braid given a good enough idea.

Anyway, I’ve embedded the talk below (audio + slides) because I can (the embed code was provided). As an added bonus, you get to listen to him talk about The Witness (or more precisely, it’s editor) which he’s happily showing off on a different screen.

Migrating Windows Mobile to Android

Windows to Android SMS conversionToday was the day I finally broke free from the shackles of Windows Mobile 6.5 on my HTC HD2 (brilliant device, merely decent OS), loading a ROM for Android 2.3 (Gingerbread). I’ll go into details another time, but the only major obstacle for me was transferring SMSes. After much Googling, it was still not obvious how to do it, but I can now confirm it is possible. Here’s how I did it (short version):

It’s the middle step, the conversion, that is unintuitive. Surely there should be a PIM Backup app for Android? Or an app that imports PIM Backup files? As far as I can tell, there’s not, but this post by the SMS Backup & Restore creator Ritesh Sahu set me on the right track. He created a WinMo app called SMS Exporter, but there were mixed reports of success, so I followed his advice and read through this post by Mario instead.

Mario had written a Perl script to convert the PIM Backup format (semicolon-separated values) to a format compatible with SMS Backup & Restore (XML) such that the converted file could be ‘restored’ on the new Android OS.

Unfortunately I (and other users) couldn’t get his script to work properly, and I don’t know Perl, and he wasn’t replying in the comments, but looking at the code I figured it couldn’t be too hard to recreate in Python. Neither format is terribly complicated after all; each is effectively just a row of attributes for each message.

You can check out and download my Windows Mobile to Android SMS Converter tool from this site. To use it, you just need to have Python 2.x installed (you may have already – type “python” without quotes in your command prompt or terminal), and to perform the conversion, set the working directory to that of the Python script and use the command python pim2smsbr.py backup_file [output_file], where:

  • backup_file refers to the name of your PIM Backup file, something like PIMBackup_20110701.pib (if you created it on the date of this post), and
  • [output_file] is an optional argument that allows you to specify a filename for the output (or you can omit it, and it will output alongside the input file).

The final step is simply copying the output file onto your Android device, opening SMS Backup & Restore, choosing Restore, and selecting the output file (and choosing not to check for duplicates). And then you’re done, congratulations! It should import all the messages rather quickly and they are automatically associated with existing contacts and built into conversation threads.

So that’s it! It’s a ugly, hacky three-step process, but it’s very possible. Enjoy your superior operating system with your data intact :). Let me know of any trouble you have in the comments and I’ll get back to you ASAP.

Retro-introducing: Shadow Quest

Shadow Quest iconA couple of years ago, I took a subject at uni called Object-Oriented Software Development (433-294). Although I had already introduced myself to OOP, this was the best subject I’d ever taken, because the OOP paradigm was my favourite thing about programming, and it’s always worthwhile learning important things formally. On top of this, we had a fantastic lecturer (Shanika Karunasekera) with a bold plan to inject some life into the otherwise tiresome semester project – instead of building a generic banking application or similar, we would be writing a game.

This was, of course, right up my alley, and ultimately the result was Shadow Quest. You can read more about it on the project page, but essentially we were given a set of specific requirements to build an RPG using the Slick game library, and that would be our assessment (though various stages of planning and development). Brilliant. Everyone loved it.

Of course some students found it less challenging than others, and for them the challenge was set to create the best game extension by the end of the semester. So long as the basic requirements were fulfilled, we could add anything we wanted, and the author of the best game would win a book voucher.

I leapt at this opportunity, and set about implementing a bunch of features from Diablo II, my favourite RPG (despite it being a hack’n'slash). I added player experience, levelling, stats, inventory and equipment, magic items, random item drops, gold drops, buying potions, and the thing I was most proud of was my randomly generated dungeon: five levels of caves procedurally generated by a cellular automaton. It took a lot of work, but worked a treat, and I felt like I was in with a chance for best game.

Unfortunately, come judgement day, there was some very impressive competition, including one game which blew all the competition away in terms of features and polish. A giant map, animations, weather, visual effects, magic spells, archery, horse-riding, a town with indoors in the buildings, a bunch of NPCs, and so on. It was the deserving winner, but I still reckon it was the work of more than one person.

Anyway, I dug out the code for my version of Shadow Quest the other day, and decided to post it up here for posterity, with a few tweaks for efficiency. Again, you can check out the project page, the source code on Bitbucket (don’t judge me, it’s old!), or more importantly play it in your browser or download the Web Start. Enjoy!

Why Use Slick?

Slick logoI talk about the Slick 2D game library a lot because I use it a lot, and with good reason. I thought I’d take a minute to go over some of that reason and give a little overview of what Slick is.

Slick is, like I said, a 2D game library written in Java. A game library is essentially a framework which provides a big chunk of functionality that is useful or necessary for creating a game. This primarily involves rendering the visual aspect of the game, but also includes some conveniences such as implementing the game loop and providing simple methods of changing the game parameters (such as the window resolution and FPS limit).

Slick is written in Java, is open source, and uses the Lightweight Java Game Library (LWJGL) for rendering. Many (if not all) of the ‘serious’ commercial game libraries and engines are written in C++, mainly for performance reasons, but Java has its advantages:

  • All the code runs in the Java Virtual Machine (JVM) which is implemented on most operating systems, meaning a game written in Java will be playable on Windows, Mac, Linux and other systems, with no extra effort from the developer.
  • There are a couple of low-effort, high-convenience deployment methods for Java programs. They can be automatically downloaded and run locally using the Java network language protocol (JNLP), or run in a browser applet embedded in a Web page. Both methods ensure the end user always has the latest version.
  • Java is a much more developer-friendly language than C++, which counts for a lot on a project as large and diverse as a game.
  • The performance typically isn’t quite as good as C++, but it’s more than good enough more often than not, especially for 2D games.

It should also be noted that there are an increasing number of handy C# game libraries, comparable to Java but with DirectX support at the cost of being cross-platform (or at least cross-non-Microsoft-platform).

But how does Slick compare to other Java game libraries? The most comparable alternatives in the 2D arena include GTGE (last updated in 2005), JGame (still active, and ported to Flash), and PulpCore (primarily for applets and animation). There are some 3D options too, such as libgdx and the Java Monkey Engine (JME), which can of course render 2D graphics, with a little more arm-twisting. The main advantage of Slick however is that it’s very easy to use, and remains consistently so thanks to its exclusive focus on 2D graphics.

It also provides a lot of practical features out of the box, best expressed in bullet point form:

  • Graphical flexibility for drawing images, primitives, and fonts using OpenGL.
  • Integrated sound and music playback with OpenAL.
  • Integrated and very easy input handling for keyboard, mouse and controllers.
  • Handy functionality built into the library, such as game states and path finding support.
  • Additional libraries to provide further features, such as powerful tilemap support and particle editing.
  • Helpful community, continued development and extension, and plenty of documentation and tutorials.
  • Total library download size of under 2MB, including LWJGL.
  • Open source and totally free (BSD license)!
  • A build in development for Android support, further extending the reach of your code.

Although it may not offer some of the more advanced features such as 3D graphics and physics, it’s a good (perhaps the best) choice for those games that don’t need them. Honestly, the main reason I started using Slick was because it was prescribed in one of my university subjects, but there was good reason for that too. I’ve yet to find a more suitable framework for painless development of 2D Java games.

As an added bonus, it’s the target library of the Artemis framework which I’ve fallen in love with recently, and which I will write more about very soon.

Introducing: Artemoids

As I mentioned previously, I’m back to work, and my first order of business is playing around with Slick and the Artemis framework. To that end, after a mere day or so of coding, I’m pleased to present Artemoids, a simple Asteroids clone using the Artemis framework. I’ll talk more about the framework soon, but suffice it to say that it is incredible, and exactly what I’ve been looking for on and off over the past couple of years.

So. Artemoids is a simple, top-down 2D game in which you fly a ship around in space (zero gravity) and shoot asteroids. If an asteroid hits your ship you die, and when you shoot an asteroid it splits into two smaller asteroids. That’s pretty much it. There’s really no win/lose conditions, because I don’t intend to make a full game out of it; it’s primarily a test and demo of the Artemis framework, and something easy to cut my teeth on to kick off the holidays.

That said, I am planning a much more sophisticated game with quite a few similarities to Asteroids, so the Artemoids code should serve as a good foundation when I kick that off (and hopefully that will be soon, with an accompanying announcement).

You can try it out for yourself right now in a browser applet, or download a JNLP Java Web Start file to run it a little more locally. I’m quite excited about finally getting both of these deployment methods to work happily, as it means I’ll be significantly more able to show off any future Java projects I create.

Also, notably, this is the first project I’ve ever open-sourced, not because I’ve been a selfish git all this time (well, not only because of that) but because my projects have typically been pretty small-scale and hacked together for personal use. Hopefully however Artemoids (and of the some games that follow) will help to serve as an example for how to use the fledgling Artemis framework, and I’ll be referring to some of my code in future posts/articles. You can check out my Artemoids Bitbucket repository to read the source, submit any issues (bugs/feature requests) you find, or even fork the code for your own project. I’m a big fan of FLOSS, and I’m more than happy to lend a hand to anyone with any interest in what I’m doing.

Back In The Saddle

With semester one of university now completed (after my final exam yesterday), I am once again free to kick on with development of the good ship Piemaster and all that sail in her. There’s so very much work to do and I’ve been looking forward to it for quite some time now, having played around with a few new technologies during semester.

One of the primary objectives I hope to complete is to start posting more regularly about interesting new things as I come across them, and retrospectives of my experiences as I have them. I will try even harder now to make time for these, despite having said that repeatedly before.

I’ve also started working on a new game (a simple Asteroids clone at first, then something more sophisticated) taking advantage of a beautiful new framework I discovered, which I will write more about later. I’m putting development of my productivity-type applications on hold for the holidays and diving headlong into game development, for a few reasons: it was (indirectly) the topic of a subject at uni last semester; it’s much easier to get feedback from myself and others; it can more easily be defined as “finished”; and I just really enjoy creating games, whether in my head, on paper or with a computer. There should be plenty to write about along the way.

So that’s enough for now, and I’ll expand on a few of these points in the near future. Welcome back, and I hope to be able to provide a few things of real value within the next 3 weeks.

Forgbook Progress Report

As you can see, there has not been any Forgbook updates for quite some time (a month), despite my resolve to post some. This is for a few reasons, some more interesting than others.

The least interesting is that I’m back at university, which doesn’t leave me quite as much time to work on things, though I’ve been giving what time I can.

More interestingly, I’ve recently stumbled across Pinax, a very smart extension of the Django application framework that offers a bunch of links to reusable Django applications, allowing the user to create the generic skeleton of a web site in a single line, along the lines of pinax-admin setup_project mysite. This provides you with a standard project layout and a collection of full-featured applications for basic capabilities such as user account management, notifications and wikis. Succinctly enough, “Pinax takes care of the things that many sites have in common so you can focus on what makes your site different”.

So I’ve been working on developing a reusable application for activity management within the Pinax environment, and have actually made considerable progress. It’s currently in a usable state where activities can be created, edited, viewed, deleted, completed (various amounts), paused, cancelled, and scored, and these operations propagate through the activity hierarchy. Relatively more advanced features such as categories, tagging, friendships, messaging, commenting, and email notifications are not implemented, but the beautiful thing is that reusable Pinax apps for these tasks exist already, and it should just be a matter of plugging them in with a little configuration. More Forgbook-specific features such as privileges and JavaScript-driven views will take a bit of work, but really Forgbook can function quite happily without them.

Having made that progress, I turned to investigating where such an application could be deployed and hosted so I could start testing it as a legitimate user. The traditional option is just to host all the files on a regular Web server, and connect the Python framework via WSGI. This is not going to be compatible with my current host NearlyFreeSpeech however, because of the rather idiosyncratic nature of their shared hosting setup. Furthermore, a basic Pinax project by itself typically sits in a virtual environment and weighs in at about 50MB, making it unwieldy to just copy, paste and host.

There are a few other options, but I was attracted to Google App Engine, because it’s Google (<3), and it’s pretty much free until the application gets particularly popular. The trouble is that the database used at the backend is a non-relational database, which is a new-fangled way of saying it’s not compatible with every other database. As such, Django is very difficult to support, and Pinax is even more divergent. There are few attempts at workarounds (django-nonrel seemingly the most promising), but it’s otherwise developer hell even attempting to monkey-patch the systems together.

Those remaining options then are a little more pricey but seem as though they will take most of the pain out of Django hosting. There are a few start-ups (Gondor, ep.io and Djangy, all in private beta) specialising in Django hosting which I’m keeping an eye on, as well as a few hosts that are friendly to Django, such as WebFaction (detailed as supporting Pinax too).

Currently the plan is to wait until a couple more of these are available (hopefully sneak into a beta or two) and see what cheap options can be had. In the meantime, development will continue, though maybe not as rapidly with uni in full swing. There are few other interesting activities and possibilities in the air as well, but I’ll discuss those a little later.

In summary, Forgbook is alive and well and even usable, but can’t really come out and show off until it finds a home. Hopefully that won’t be too far away.

Where Is Forgbook Going?

Of my large (and still growing) handful of projects that I’d like to be working on right now, Forgbook is taking up most of my attention. Hopefully I can get some kind of super-early release out in a few weeks, but until then it’s worth noting a few shifts in focus and philosophy.

As much as I love the Web, I find it hard to submerge myself in Web development due to the chronic pains of browser incompatibility, and perhaps the need to be constantly responding to user experience. Once a product is released, I feel an obligation to keep it updated, which can at times conflict with a desire to put a project to the side for a while. It’s much safer in term of user response to work on a project privately until it’s complete and polished before releasing it rather than releasing pre-alpha kind of work and iterating consistently all the way through to a final release. I guess I value my flexibility pretty highly, because after all this work is effectively my free time.

Forgbook is (or will be) my largest, most ambitious project in functionality terms, and I believe it will be of the most value to myself and others, so I want to get it right. I’ve been thinking about what I want it to offer for some time now, and I’ll be updating the project page with more details as I solidify them. From a technology perspective however, the interesting decision I’ve made is that I’ll be switching from a relatively unambitious attempt to combine Flex and PHP to a Web-native Django application leveraging the Dojo JavaScript toolkit for the more flashy UI components. This means however that I have to familiarise myself with the environment Django offers; it’s immediately clear that it’s extremely powerful and scalable, but the decoupling that is its strength results in a variety of idiosyncratic idioms that will take some time to adjust to.

Why the switch? One of the requirements I’ve come to be very passionate about is making Forgbook accessible from any common device – PC, smartphone, tablet, perhaps even consoles – so that it feels more like an encouraging companion rather than a chore you must log into every day. This is best achieved using a native Web interface (HTML, CSS, JS) over something requiring a plugin (Flash, Silverlight), as it should at least be accessible by any device with a Web browser, in the scenario that I don’t/can’t customise an interface for that device. It would be suicide to jump into creating a sophisticated Web application without a framework, and my love for Python (and mere tolerance of PHP) combined with the popularity and support for Django make it a perfect choice. The integration of Dojo via Dojango is a big bonus too.

I’ll document the progress I’m making with Django in the next couple of weeks, and hopefully get a stripped-down-but-working version (basic user and task management) out in the wild before March. From there, I’m hoping the development efforts will feel more rewarding, and I’m sure there will be many more fun things to handle (feedback and reflection followed later by advertising and analytics). I’m looking forward to it as much as ever.

P.S. If anyone can think of a quality name for a sophisticated event/task management application (Forgbook is very much a working title), let me know (comment or contact). If I like it enough that I decide to use it, I’ll be happy to give you free access to pretty much anything I release forever. Hopefully one day that’s worth something significant.

So What’s The Plan?

So it’s now well into February, when I’m supposed to have transitioned out of IBM mode and into personal progress mode. To an extent I have, but it’s going entirely undocumented as it always has, despite the whole point of this site being to remedy this situation.

So it’s time to reassess what the objectives of this site are and start using it properly. Why does it exist?

  • To maintain a homepage/repository/portfolio of my various projects.
  • To facilitate posting about development of and updates to those projects, for my own reflection and the interest of any interested parties.
  • To encourage publishing of articles providing information that I’ve picked up through my experiences that may be of use to others.
  • To generally keep track of the progress of various aspects of my life, primarily those relevant to the above points (e.g. what I’m studying/working on/taking an interest in).

These objectives fall approximately into the two categories of content hosting for sharing with others, and reporting developments for posterity and reflection. The former is purely for my own amusement until I start publishing things worth sharing, but the latter can start generating benefits immediately.

As such, I intend to start publishing a lot more short and succinct blog posts about the goings on behind the Piemaster scenes. These will mostly be filed under ‘Personal‘, so feel free to ignore them if you believe that’s where they should stay. I believe Forgbook is going to be of great value for organising my life, but until then the reflection should help focus my attention.

So if you just stumbled across this site for no real reason at all, and you have no idea who I am, and you read this whole post for wont of something better to do… you are possibly the only person on Earth to have done so. Who knows, with odds like that you may even choose to follow the site for the next week or so just to see what happens. It won’t be flashy, but I’m an independent human being and I’ll try to have something even a little enlightening to say. Either way, wish me luck.