Where Am I?

Once again after getting fired up to write a slew of blog posts, I’ve disappeared off the face of the earth. Where did I go?

Well, it’s been an exciting year-or-so. Semester 2 of 2012 was very busy, and myself and various teams finished off various assignments for university. The large team software project (for which we were using agent-oriented programming and the Prometheus design methodology) went very well, and we won the award for best large team project at our expo night (out of three teams, but still).

Then I got to have a short break over Summer, but somehow snuck into being accepted for an internship with Google, and since Sydney was full, I got upgraded to the Googleplex in Mountain View! This is now without a doubt the highlight of my resume, and it was an enormously educational experience, especially since it was also my first ‘real’ overseas trip (that is, excluding New Zealand). I was working on upgrading an existing internal web application, which was definitely relevant to my interests, but unfortunately I can’t show anything off.

One of the most valuable things I learnt from working at Google is that I don’t want to work at Google. Yet. Without a doubt, it lives up to all the amazing stories you’ve heard and it’s perhaps as close to corporate paradise as a software developer will find, but I’m not at a point in my career that I want a corporate paradise. Despite all the free food and events and amazing people, I spent most of my time sitting at a desk writing code for other people. I learnt that I want to write code for myself; that I want to work on projects that are of total personal interest to me, and I want to direct their development.

Basically, I want to run a startup. So that’s what I’m going to do.

I’ve been watching Steve Blank’s How to Build a Startup course on Udacity, and it feels right. It feels like the kind of thing I want to do, and sits outside my comfort zone in the right way. I’m at a stage of my life that is ideal for taking this kind of risk: I have no job commitments, no family dependents, enough money to survive on, and most importantly, a project at uni with a good team that is starting to get off the ground, and the project owner is very keen to spin it off for commercialisation. I think it has real potential, so I’ll be working full-time next semester to build out the foundations a little more funded by a convenient government grant. It will be at least a year before it’s ready for sale, but I’m cautiously optimistic, and it deserves at least six months (of paid work!) to give it a go.

On top of that, I’m planning on reviving Buffex from its slumber on the side. This has come about for two reasons: I’ve been playing with Google’s Dart language and I’m liking it a lot; and a friend found the holy grail of open financial data sets on Quandl. That gives me everything I need, and it’s already coming along quite nicely. My goal is to launch an MVP for that in about 3 months of part-time work, though I haven’t done any scheduling yet, and that’s probably infeasibly aggressive. But I’ll definitely try to keep a record of the development lifecycle, as this is as likely as ever to be my first real self-driven product to come to market (with a business plan, anyway).

So I should be back on the air, but I won’t make any silly promises. I’m blogging because I know it’s a good habit to express one’s life story somewhere, even if nobody reads it. If nothing else, I’ll be back to read it in 50 years. Hopefully I didn’t let you down, future-me!

Holiday Direction

The updates have been fairly sparse recently, but as Christmas (or equivalent) approaches everyone gets pretty busy. Fortunately, a few of the things I’ve been very busy with are Piemaster-related: I’m breaking some new ground with Forgbook and Buffex, and exploring a couple of other potential projects on the side.

Forgbook has received a lot of competition lately, as numerous development teams small and large have release highly polished task management applications, such as AsanaDo.com and Orchestra. Many of these have a strong emphasis placed on collaboration across tasks, but still none offer the ability to arbitrarily break down tasks into subtasks. This seems like a pretty fundamental thing to want to be able to do, and is of course the cornerstone of Forgbook.

However all of these applications do offer very slick user interfaces, and to at least be competitive, I’ve realised that Forgbook requires a modern makeover. As such, I’ve finally taken on learning some JavaScript properly, because against my wishes it has undoubtedly become the modern web’s lingua franca. I’ve been mocking up a few single-page AJAX applications with the very handy Backbone.js library, which drastically simplifies (or at least provides structure to) the MVC design of the user interface. It’s quite reminiscent of my time with Adobe Flex, minus the constant annoyances of Flash, and I’m hoping to write a bit about it once I’m a little more comfortable.

On that note, I’ve been approaching Buffex from a more modern perspective as well. I noticed I haven’t mentioned Buffex in a post before, and indeed the project page has been a rather misleading “Coming soon.” for the past year or so, but you’ll hear a lot more about it soon. Since the minimum viable product (MVP) incarnation of Buffex is relatively simple, I’ve decided to focus my efforts on that for the time being before pressing on with Forgbook (which is looking much slicker than it used to, but has a lot of work to go). I’ll be taking a Backbone approach to Buffex too, to try and have nice, snappy interface and keep everything nice and simple.

That’s more or less where my head is at the moment. Those couple of other ideas I mentioned will get some more attention next year, but I can say that one of them has been born out of my recent fascination with gardening. If there are any gardeners out there, let me know! I’m trying to bring a rather unorthodox approach to it, and would love to discuss it with others. Techies tend not to be very enthusiastic garderners however, which is both a good thing and a bad thing in some sense. Regardless, I know I’m looking forward to it.

Pre-introducing: Carrot

Jario was never supposed to be a full-blown game, it’s merely a tech demo for Artemis, and something of a framework to go onto bigger and better platformers. I thought I should mention that one such game is now in the works. It’s still very early days, but it’s codenamed Carrot.

Like Jario, Carrot is a 2D platformer using the Slick game library and Artemis framework. Unlike Jario, I intend to build it up to be a good and proper game. I’ll keep you all posted and release some more details once we’ve actually figured them out ourselves!

Artemoids now on Softpedia!

Softpedia logoJust dropping by with a quick note that Artemoids is now available on Softpedia!

I was entirely unaware of this until I received an email this morning telling me as much, and honestly I don’t understand why, but hey! If someone enjoyed it enough to bother submitting it, then I’m not complaining! Then again, it’s listed as a game for Mac, so maybe Macs really are that desperate for entertainment once the thrill goes out of making photo albums and home movies.

Anyway, in celebration of being branded Piemaster Studios without my knowledge, I’ve set up a Piemaster Studios Facebook page so you to can show your support for the fastest-growing independent software developer in the last two hours!

Also good to know is that the extensive codebase of Artemoids was “tested in the Softpedia labs using several industry-leading security solutions and found to be completely clean of adware/spyware components”. So there you go – finally a crappy Java game that you can play in your browser without infecting your computer! Badge displayed proudly below:

Softpedia 100% Clean Award

Jario Update: Sounds and Semi-Passability!

Yes, thank you Chrome, only one of those is a word, and yet Jario now has both! Sounds were ridiculously easy to add through a generic SoundSystem with a handful of static sounds (courtesy of http://www.freesound.org/) and a static queue-push method, and then the single-line calls were peppered throughout the systems as required. The result is a game which is a lot more fun to play! Despite still being about 60 seconds long.

Go ahead, try it out!   Launch Java Web Start button

The issue of passability is a more technical one. Previously, all detected collisions were handled directly by each of the colliding entities. This is great for many cases, but there are some times when you don’t want to handle a collision, or when you want to not handle it under certain conditions, and for which adding in a bunch of conditional guards is ugly and inefficient.

My solution was to sneak an extra layer into my collision handling hierarchy (which I’ll talk more about when it’s a little more polished), right up the top, to manage collision persistence. In this context, persistence means that when two entities collide, all future collisions that are detected until they stop colliding can be grouped into a single collision, and handled only once at the beginning. This is important for a number of gameplay mechanics.

For example, the two cases I added just now were semi-passable platforms and improved handling of player recovery. Semi-passable platforms are those ones that you can jump through from below, as well as stand on top of. One way to get this behaviour is to say “if the collision is not from the top edge, do nothing, otherwise block the entity”. This may work, depending on your collision detection mechanism, but for the time being mine is very basic, and detects the edge of the collision based on the X and Y distance the two entities are overlapping by. The result is that if you jump through from the bottom, a bunch of collisions will occur for the handful of frames you’re passing through, and as you are about to exit from the top, one of those collisions will be detected as “top edge”, and the default behaviour is to place the player on top of the platform. The behaviour we want is for the player to keep jumping, eventually fall back down, and then be placed on the platform.

My solution is a little more complex than perhaps it needs to be, but it’s a good starting point. When a collision occurs, the handling systems can register the collision as a “passing through” case, after which future collisions will not be handled by the entity that is passing through (the ‘passer’) until the entities separate. However, the entity being passed through (the ‘passable’) will continue to receive handling calls in case the circumstances of its passability change. It can therefore also check whether the colliding entity has been previously registered as a passer. All of this handling is contained in PersistentEntityHandlingSystem class, which all current collision handlers extend.

In the case of the platforms, this is straightforward. On the first collision, if the player collides with a non-top edge of the platform, the platform registers the player as a passer, and the player continues unhindered. Once the player exits at the top, they are unregistered from the platform, and the next collision will be handled appropriately on the top edge.

Player recovery is a little trickier. By “recovery” I mean the period of invulnerability you get after being damaged with >1 health. During this time, you shouldn’t be able to stomp enemies from inside (i.e. walk into them from the left, then jump and kill them on the way out). So for this case, when the player collides with an enemy, he first checks whether he’s in recovery mode, and if so, if the enemy is not already registered as passing through, then the registration occurs. The enemy passing through the player means that the enemy is oblivious to the collisions (and so can’t die until the player leaves and comes back), but the player’s handler is still called each frame. Therefore when the test for recovery fails (i.e. recovery time has expired), then the enemy is unregistered as a passer, and the collision can be handled normally.

But wait, there’s more. It’s possible for recovery to expire while the player is standing right in the middle of the enemy, and if the position is right, it will register as a top-edge collision, and “handling normally” means the enemy will get stomped. This is not the desired behaviour – if the the player is standing inside the enemy when recovery expires, the player should get stomped instead. To work around this, I added a parallel map that records which passable-passer relationships should be unregistered in the next frame. This gives the player collision handler a chance to handle the collision manually and correctly (take damage) before unregistering. If the player manually takes damage AND unregisters in that frame, by the time the enemy handles the collision it will appear unregistered, and the potential top-edge problem persists. By delaying it one frame, the player’s damage will have been fully accounted for, and the enemy collision will not occur at all.

Problem solved! You can see all that in PlayerHandlingSystem if you like. Like I said, it’s quite complex and I’d like to simplify it a bit, but it’s a start. By experimenting with this approach, I’ve gained even more of an appreciation of the Artemis framework. You really can tackle your problems one at a time, in isolation. Even in the case of a two-entity collision, the collision handling of the two entities can be neatly decoupled. The future is looking bright!

Jario Update: Kinda Working!

I’ve just pushed an update to Jario with some pretty nice changes since I last mentioned it. As usual, you can check out the source if you’re interested or just Launch Java Web Start button!

I’ll be quick:

Features:

  • All the important items – coins, mushrooms, fire flowers and stars.
  • Goombas, Koopas and even empt shells, with the ‘proper’ graphics and animations.
  • Vastly improved input and collision handling.
  • Added a marginally more satisfying ending, though it still doesn’t do anything.
  • Fixed many, many bugs (but not the intermittent collision mesh one yet).

Architecture:

  • Cleaned up collision handling systems into a hierarchy of similar handlers for increasingly concrete entity types. I’ve found it to be very flexible and reusable so far, which is nice, since the logic of a game is little more than input and collisions.
  • Refactored image and animation spatials into a hierarchy of intermediate abstract classes, and added a SpatialComposer to group the different spatials of individual entity types and handle different states.
  • Inserted a hierarchy layer for spatial effect handling. Currently only processes changes in rendering alpha value, but does so quite nicely.
  • Played around with a TimerSystem to be used in conjunction with a Timer component, allowing systems to easily register callbacks with individual entities to be executed after a given delay. Makes it very easy to add temporary properties to entities. For instance, giving the player X seconds of invulnerability (hurt with >1 health, or press I) reduces to a single static function call. Still need to play with Artemis’ DelayedEntityProcessingSystem to see if that does a similar thing.

That’s all the significant bits so far. Still plenty more to go, though! Some of the above will need to change in order to support a complete level, which will be interesting. I also need some better game state transitions, though that’s nothing to do with Artemis. I’ll talk a little bit about some of the more interesting points soon, such as the collision handling and spatials, since those two are key to getting a game working smoothly.

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.

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!

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.

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.