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.

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.