blog @ pebbl

Ok, so in reality this release happened a while ago... but it has taken me until now to actually write about it.

This work has been going on in the background of my life for a while — true, the birth of my daughter definitely pushed what was already background beyond whatever layer you might imagine lies behind that. But considering Pebbl has been in development since 2007, it is probably used to coming second fiddle to everything else.

Prior to this recent release, I had been playing around with Unity (something which I completely failed to mention here, and I still won't, because the work — not the knowledge or the technology — is now obsolete).

You can see those experiments (along with other previous examples) by clicking one of the images below. Be warned you will need the Unity Player installed for some of them.

Part of life as a developer is to be constantly checking and re-checking what is available to help do your job. Over the nine years of Pebbl works, I haven't just been naively re-inventing a wheel with my bespoke code. I have constantly been on the look out for decent Game Dev libraries. Those that will help me speed up my work, whilst at the same time give me the control that I need.

This research has spanned a number of solutions: EaselJS, PaperJs, Box2D, Unity, Early Phaser, D3, Three, and then smaller subsets like TweenJS, Spine (for animation), and PolyK (for polygon handling). If you combine the above with all my work on ALWTM, the effort spans further into other technologies like Flash, Silverlight, C# and more.

Unfortunately, for all my attempts, I couldn't find anything fully satisfactory. Hence the reason for trying to building my own libraries with very small amounts of free time. Certain libraries would start off promising, only to fall down at some pivotal point later on. Usually this would either be in terms of performance, or a particular missing feature. That is at least until I started using Pixi.js, and the more recent version of Phaser. Both have given me the ability to happily put together the following:

True, I must be quite demanding customer when it comes to Game Dev libraries. Considering there are a lot of Games and "games" already out there, that have been powered by the technologies I have already mentioned. But there are a number of abilities that I want my online worlds to have, that have ruled out a lot of what is on offer (at least not without some serious extension of existing code).

Polygons, where for art thou Polygons?

One key issue is the ability to hit test against polygon shapes. I flirted (as mentioned above) with complex physics engines for a while. Most give you this ability (at least for convex polygons) out of the box. The problem is, whilst you may gain a lot from a physics engine like Box2D — it simplifies very complicated interactions — it actually complicates all the other parts of a game that would usually be easy to code. The likes of working with platforms consistently, or just trying to get objects to sit still, becomes a real headache — especially if you insist on slopes.

The curving of a slope

This has been the part that has made nearly all my personal projects difficult. I could obviously just concede and produce another platformer with a tile map; but where would the fun be in that? Both ALWTM and Pebbl require slopes — Pebbl is very annoying in that it requires curved platforms... and I have yet to come across a Game Dev library that helps properly with this (without using a physics engine). I attempted to use Phaser's Ninja Physics, but it wasn't flexible enough — but to be honest, what I'm requesting is a tall order.

Latest version

Pebbl v0.3 still uses Phaser (powered underneath in part by Pixi) but I've added in my own collision handler called imagination.js:

http://pebbl.co.uk/v0.3/scripts/imagination.js

I say my own, but to be honest the hard work so far has been done by the brilliant PolyK library — without which I think I would have given up.

For Pebbl, the PolyK lib allows me to raycast out from an entities position, and detect if there was a collision against quite complicated shapes. The system is still very buggy — as you will see in the demo. Especially if you attempt to walk underneath the plant. But this method is much easier to build a game around than using a physics engine; and I will iron out the kinks over time.

This system allows me to add polygon hit areas to static (or programmed motion) entities. I don't think I'll extend the work to dynamic motion entities just yet (not until I can get static to work properly). This at least will cover all the elements I actually need to support polygons... for now.