Building better project skeletons with Composer

Note: This post has originally been posted at binpress, you can find the original post there:  (

As the two weeks exclusive i gave to them are now over, i decided to put it here on my blog as well for those who might not stumble over it at binpress. If you haven’t heard of binpress, check them out, they are a market place for opensource solutions.

Building better project skeletons with Composer

The more you use modern frameworks and the more modular you build your PHP applications, the more likely you’ll use a skeleton (or template) for creating new projects. In fact, most of the better known frameworks provide skeletons for you to bootstrap your application with.

Those skeletons are great to get started, but it’s very likely you’ll have your own stack of composer packages that you integrate in each project after a while. Each skeleton will be slightly different, so you’ll likely fork your own. This article is meant to provide you with an understanding on how to build a skeleton that will allow you to automate things as far as possible.

Before We Start

I’ll assume you’ve used composer before, and I’ll also assume you have it installed in a way that calling “composer” in your command line will execute the composer commands.

I will use the word “project” a lot, based on the name of the composer command “create-project”. A skeleton, however, can be for either a complete project, a library, a module/bundle or what ever else you can put in a composer package. Hell, you can probably even abuse a skeleton that, in the end, isn’t a composer package. (I wouldn’t recommend that.) The point is, when you read “project,” try to see it as a blank where you fill in whatever form of a project you require it to be — don’t get put off by the choice of the word.

Please keep in mind that the intent of the code you see here is to show you some of the possibilities. You can replace the example scripts with a task in your Makefile (or any other build system you are using), a shell script, a much more complex PHP script — whatever gets the job done.


What’s a skeleton?

You probably know this already, but lets start with what is a skeleton and how to use it. A skeleton is a pre-made project that is copied to create a new project. It contains all you need to start a certain type of project.

How do you use a skeleton?

Lets start with the most basic way to use a skeleton. Zend Framework2 currently suggests using their skeleton for a new ZF2 project by using the following commands:

cd my/project/dir
git clone git://
cd ZendSkeletonApplication
php composer.phar install

Why is ZF2 doing it this way? Basically, they’ve included composer.phar in their skeleton, so you don’t need to install composer yourself. That’s probably okay when getting a new developer new to their framework started, but it comes with a few issues:

  1. You end up with my/project/dir/ZendSkeletonApplication, rather than with my/project/dir
  2. A possibly out-dated composer.phar
  3. A .git dir in your project referencing the skeletons git repository.
  4. You can’t use a script on create-project, as create-project is not executed.
  5. The my/project/dir/ZendSkeletonApplication contains several files that belong to the skeleton project, but are not a skeleton to your project. In this example it’s the, but with other skeletons it might also be build files, rmt config, a changelog…

(Note: Funnily enough, they’ve covered a better way in their

How can we improve it?

Composer allows for a command named create-project. This command allows us to have Composer deal with doing the actual cloning (and cleaning up the .git) for us. All we need to do is:

    composer create-project thecomposer/package my/project/dir

As I’ve used ZF2 for our example so far, here’s the line that you’d need for ZF2 to work:

    composer create-project -sdev zendframework/skeleton-application my/project/dir

Notice the added -sdev. It’s an option that allows installs with a dev stability set. Why? because ZF2 hasn’t tagged stable releases for their skeleton.

If you run those commands, the results will be basically the same as in the previous example. Composer will locate the source through the repositories that it knows, download the source, and run an “install” on them (by default with dev-dependencies enabled). At the end it will ask you “Do you want to remove the existing VCS (.git, .svn..) history? [Y,n]?”, something you should answer with Y(es), as it will then remove the VCS respository that links to the skeleton (allowing you to add your newly created project to its own repository).

So, lets have a look at which of the previous problems have been solved by doing it this way:

  1. Solved: We now have our project in my/project/dir
  2. Solved-ish: We aren’t using the composer.phar from the skeleton, so it doesn’t really matter.
  3. Solved: Composer asked us about the VCF file types, and removed them.
  4. Solved: We solved several of our problem by using create-project, and can do even better by using a script on create-project.
  5. Unsolved: We still have files that we don’t need.

How do we get rid of unnecessary files?

This problem needs to be addressed in the skeleton package itself. As you’ll end up with your own skeletons that contain your own stack of packages sooner or later, this is not an issue. (However if you’re a framework dev, you might want to look into incorporating such cleanup in your skeleton as well).

Composer allows for what are called scripts. Scripts are defined in the root-packages composer.json and will be executed for certain events. In our case, we’re going to use a script for the post-create-project-cmd event, which will clean up our own skeleton for us.

Our Own Skeleton


Creating our own skeleton can be as easy as forking an existing one, or as complete as creating it from scratch. It usually depends on our use case, and for the sake of this, I’ll just assume you have forked the ZF2 skeleton, maybe changed a few files, replaced the (with one giving more information on your own skeleton) and added a (for the skeleton).

I suggest creating a sub directory, for example called “skel” in your skeleton, which contains the cleanup script and a sub directory named templates.

The Cleanup Script (skel/post_create_project.php)

This script is supposed to automate those little tasks that remain after running a create-project. It’ll…

  • …copy files from the templates directory over the files that are for the skeleton, thus replacing them with project-specific files.
  • …replace placeholders in those files with values that make sense for the project.
  • …delete the skel directory, removing all for-skeleton files left.

Note: Remember to set this file to executable chmod +x skel/post_create_project.php.


// We get the project name from the name of the path that Composer created for us.
$projectname = basename(realpath("."));
echo "projectname $projectname taken from directory namen";

// We could do more replaces to our templates here, 
// for the example we only do {{ projectname }}
$replaces = [
    "{{ projectname }}" => $projectname

// Process templates from skel/templates dir. Notice that we only use files that end 
// with -dist again. This makes sense in the context of this example, but depending on your 
// requirements you might want to do a more complex things here (like if you want 
// to replace files somewhere
// else than in the projects root directory
foreach (glob("skel/templates/{,.}*-dist", GLOB_BRACE) as $distfile) {

    $target = substr($distfile, 15, -5);

    // First we copy the dist file to its new location,
    // overwriting files we might already have there.
    echo "creating clean file ($target) from dist ($distfile)...n";
    copy($distfile, $target);

    // Then we apply our replaces for within those templates.
    echo "applying variables to $target...n";
    applyValues($target, $replaces);
echo "removing dist filesn";

// Then we drop the skel dir, as it contains skeleton stuff.

// We could also remove the composer.phar that the zend skeleton has here, 
// but a much better choice is to remove that one from our fork directly.

echo "33[0;32mdist script done...n";

 * A method that will read a file, run a strtr to replace placeholders with
 * values from our replace array and write it back to the file.
 * @param string $target the filename of the target
 * @param array $replaces the replaces to be applied to this target
function applyValues($target, $replaces)

 * A simple recursive delTree method
 * @param string $dir
 * @return bool
function delTree($dir)
    $files = array_diff(scandir($dir), array('.', '..'));
    foreach ($files as $file) {
        (is_dir("$dir/$file")) ? delTree("$dir/$file") : unlink("$dir/$file");
    return rmdir($dir);


The Skeleton’s composer.json

The skeleton’s composer.json should look something like this example:

    "name": "ourvendorname/skeleton-web",
    "description": "Web Skeleton Application for ZF2",
    "license": "proprietary",
    "keywords": [
    "require": {
        "php": ">=5.5.0",
        "zendframework/zendframework": "2.3.*",
        "zf-commons/zfc-twig": "1.2.*"
    "require-dev": {
        "phpunit/phpunit": "4.1.*"
    "scripts": {
        "post-create-project-cmd": [

The important parts being:

  • name is set to our skeleton package’s name.
  • require and require-dev contains dependencies for our project.
  • scripts contains a list of scripts to call on once create-project is done, in this case the list has a size of 1 and contains our skel/post_create_project.php

The Templates

Within the skel/templates directory we can now place files that replace those that are skeleton-specific. In the case of the example that was given in the prerequisites, those would be:

  • An empty / or basic for the project.
  • An empty
  • A project specific composer.json-dist

The first two should be rather obvious, the last one might not be, as we already have a composer.json, that we called install from. We need this one for two reasons, to replace the package name with the project specific one, and to not include the post_create_project in the project itself. For example, our skel/templates/composer.json-dist could look like this

    "name": "ourvendorname/{{ projectname }}",
    "description": "undescribed package",
    "license": "proprietary",
    "keywords": [
    "require": {
        "php": ">=5.5.0",
        "zendframework/zendframework": "2.3.*",
        "zf-commons/zfc-twig": "1.2.*"
    "require-dev": {
        "phpunit/phpunit": "4.1.*"
    "scripts": {

The changes to our composer.json being:

  • The name has one of the placeholders that our script replaces.
  • The script is not contained in this, as this belongs only to the skeleton.

What’s left to do?

Test Your Skeleton

We can test the whole thing simply by making a copy of our skeleton’s folder (for example applied-skel), and manually have composer run the script within that directory.

    cp -r skeleton-web applied-skel && cd applied-skel && composer run-script post-create-project-cmd

Then we can check if applied-skel contains all changes that we wanted to happen.

Once done, we can put the skeleton on packagist, or in whatever private repository we have, and use it.


You should now be able to create one or more skeletons that you can derive your projects from, without having to repeat the task of editing and deleting. Obviously this isn’t the end of the road. You can extend the script to ask for user input and do more things based on that, or you could customize it further rather than using a replace on the composer.json-dist (don’t forget to have your script run another Composer install then). In the end its up to you and your workflow.


So, finally, an EVE Post thats not about 3rd party stuff.

CCP just announced a few changes in a devblog, which are already causing a gigantic forum threadnaught the TL;DR is:
all jump drive capable ships gain the ability to use stargates, but get their maximum jump distance lowered to 5ly (except blackops, they will still be able to go about 8ly). Also there will be a cooldown time on jumping per character (including jumpbridges, titan bridges, blackops bridges and own jumpdrive, excluding stargates), which multiplies per jump, and has a pretty slow decay.

Right now there is a lot of people who actually celebrate this change as the downfall of the large coalitions and the botlrd meta coalition, well they are wrong. CFC and PL have been asking for changes like this for a long time, not because they want the game to be better (thats what they claim) but because a mechanic like this will give a huge defenders advantage, meaning they can keep all this huge sov that they have at the moment, and can use their caps in there within relative safety (anyone remember that the botlrd agreement actually has rules on when and how caps are allowed into which parts of eachothers territory? now there is a change which will make it easier to prevent someone from abusing this).

Now, I’ve already posted this on the eve forums, but i feel this is blog worthy.

…lets have a look through the crystal ball.
Lets assume in Winter there forms a new Coalition, made up by people who are fed up with the botlrd-stalemate, a problem that those large nullsec entities have created for themselves. Lets call them Hipster Kid Coalition for the course of this post. Hipster Kid Coalition is made up of a few veteran corporations/alliances as well as some people new to sov warfare, so you have vets in caps and new guys in support.
One fine day a CFC Member living in VFK forgets to pay their Sov bills. The leadership of Hipster Kid Coalition calls the coalition to arms to go for an surprise attack against the heart of the botlrd-participants – VFK-IV. Fully motivated, chanting “satan your kingdom must come down” they start charging towards their destination.

As their maximum bridge/jump range is now 5ly, they will have to take a route like:

-> Jan
1. Jump -> 4.267 ly MJI3-8
2. Jump -> 4.299 ly GIH-ZG
3. Jump -> 4.278 ly UR-E6D
4. Jump -> 4.282 ly TXME-A
5. Jump -> 3.512 ly VFK-IV

this is under an ideal-circumstances assumption, in reality they probably have to take more jumps (cyno jammers…)

with the fatigue mechanics, assuming no one ****** up, and so all start with empty fatigue this is:
1st Jump: estimated stay in MJI3-8: 1 minute + 4.27 minutes = 5.27 Minutes (5m16s) (reallity: more as the titans bridge first and then jump, so everyone has to wait for the fatigue of the last titan), after decay that leaves a fatigue of about 4.77.
2nd jump: estimated stay in GIH-7G: 4.77 * (1+4.3) = 25.281 Minutes (25m:16s), after decay 22.78.
3rd jump: estimated stay in UR-E6D: 22.78 * (1+4.28) = 120.2784 Minutes (2h:00m:16s), after decay about 118.
4th jump: estimated stay in TXME-A: 118 * (1+4.28) = 623.04 Minutes (10h23m:2s), after decay about 561.
final jump, leaving earliest jump escape to safe the fleet: 561 * (1 + 3.51) = 2530.11min (1d:17h…)

What does that mean:

  • Defender gains Advantage 1: he can block gates on the route to prevent conventional travel, we have seen this in the past, you just bubble up the gates and camp ‘em to death, defender wins.
  • Defender gains Advantage 2: he will have a lot of time to organize if the hostile fleet uses jump travelling
  • Defender gains Advantage 3: cyno jammers are a lot more efficient now, as there are more systems that need jumping through more jammers need to be taken down to get through
  • Defender gains Advantage 4: capitals are now ships where timezone relevance is a lot higher through their cooldowns, and losing a fight might me a no-escape-scenario for the attacker.
  • Defender gains Advantage 5: **** ups during the travel will have a lot more impact, as they will cause a divergence on the timers of the capitals

The only option left for the attacker is to try to move his capitals on conventional travel using the jump drive to avoid one, maximum two blocks on the route.

To me the conclusion that this changes would actually make trench warfare worse, rather than to shake up nullsec seems quite obvious if you play out the scenario, and i really don’t think that

We expect the impact of these changes to be emergent, and as a consequence are unpredictable and will take a while to develop on TQ

makes a good excuse for not looking into the problem.

Rather than buying into the myth of the force projection problem CCP should be looking into shaking up things by incentivicing attacking large entities (for example through rewards from the empires), and creating new toys that allows asynchronous warfare (against super blobs as well as against support-swarms).

Composer & virtual packages

Composer & virtual packages

Composer has been a blessing for the PHP community, and many many people use it today. However most people don’t know all it can do – i for certain every now and then learn something new. A few days ago i stumbled over a “virtual package” on packagist – and found it to be a feature that i was actually missing in composer. Turns out, composer can do it, its just not so well documented.

So what is this about? Virtual packages allow you to have a more loose dependency. Rather than depending on a specific package, you depend on a virtual one, which can be fulfilled by all packages that provide the virtual one. Sounds confusing? Lets have a look at an example.

Lets assume you are building a library, lets call it example/mylib, and this library makes use of a PSR-3 compatible logger. Now obviously your package will depend on “psr/log” in version 1.0.0, so you have the psr/log interfaces available. Now you don’t want to depend on a specific implementation, because you don’t want a user of your lib to be forced to use that one. But since you are building your lib so it needs a log provider injected (and if it is a NullLog), you want your dependencies to reflect that. So, what you do is: you require “psr/log-implementation” in version 1.0.0, just the same way you would require a regular package. “psr/log-implementation” doesn’t exist as a package though, but there are several packages which provide this virtual package so if someone who depends on your library depends on one of those as well, all of his depedencies will be met.

How does a library provide a virtual package? Simple, by using the provide keyword in its composer.json.

Lets look at a hand full of composer.json examples:

Example 1: example/mylib composer.json – our own project that requires a logger

  "name": "example/mylib",
  "description": "...",
  "require": {
    "psr/log": "1.0.0",
    "psr/log-implementation": "1.0.0"

In Example 1 we define our example/mylib to require the (existing) package “psr/log”, and a virtual package “psr/log-implementation”, where the way how require those is exactly the same. To be used our lib now requires that a “psr/log” 1.0.0 and a “psr/log-implementation” 1.0.0 package are available when we install it in any application.

Example 2: somelog/logger composer.json – a random psr/log implementation

  "name": "somelog/logger",
  "description": "...",
  "require": {
    "psr/log": "1.0.0"
  "provide": {
    "psr/log-implementation": "1.0.0"

In Example 2 we have a random psr-compliant logger, and it defines that it provides a “psr/log-implementation” 1.0.0 package (besides providing “somelog/logger”), so if we require this package anywhere, we automatically get an “psr/log-implementation” on 1.0.0 requirement fulfilled. Packages can also have more than one virtual package that they fulfill in their “provide” section, allowing one package to fulfill more than one requirement.

Example 3: myapp/myapp composer.json – an application using our library

  "name": "myapp/myapp",
  "description": "...",
  "require": {
    "example/mylib": "1.0.0",
    "somelog/logger": "1.0.0"

Example 3 shows an application requiring the library and fulfilling the libraries derived requirement for a psr/log-implementation by requiring “somelog/logger”.

This whole thing can do a few very nifty tricks, where you can have the users of your lib customize their stack and still work with your library – basically you raise the interoperability while still hinting on what you need. I wish more projects would make use of this.

EDIT: Matthias Noback wrote a post as a reply to this one which you can read here. Please read it, as he has some valid points.

As disqus swallowed my comment on his blog directly (not sure if it is pending approval or if loging in just made it forget), I’ve decided to address Matthias concerns here.

  1. psr/log-implementation, or any virtual package for that matter, is very problematic as a package. There is no definition of this virtual package. It is merely a phenomenon arising from the fact that some package has the name of the “virtual package” in its provide section. In the case of the psr/log-implementation package, this lack of a proper definition or rules for virtual packages means that there can a) be packages that contain a class that implements LoggerInterface (from psr/log), but don’t have "provide": { "psr/log-implementation": ..." } in their composer.json and b) that packages might say they provide, while they don’t. Which makes the concept unreliable.
  2. Some day, someone may decide to introduce another virtual package, called the-real-psr/log-implementation (they can easily do that, right?). Such packages may be completely exchangeable with existing psr/log-implementation packages, but in order to be useful, every existing PSR-3 compliant logger package needs to mention that virtual package too in their provide section. And so on, and so on. The underlying conceptual problem is: there is no such thing as a canonical virtual package.

Basically I agree with points 4 & 5 of what he wrote. However I’d like to point out that with composer and package naming there are a few issues anyways, and one option to deal with it would be a PSR on how such packages should look – or any other form of convention.

Besides that as a developer you are always responsible to check what packages you include in your application. Just because composer tells you “you need an implementation of package a” you can’t pick a random implementation and hope it will be doing everything correctly – however it is still nice if your dependency management tells you that you need an implementation

  1. Strictly speaking (as in, would the code compile), the code from the library itself doesn’t need a package that provides psr/log-implementation. It just needs the LoggerInterface (which happens to be in the psr/log package).
  2. Of course, in order to actually run the code from the library you will need an instance of LoggerInterface, which means you need a class that implements said interface. But that doesn’t mean you actually need a package that contains such a class. That class can be located anywhere, in the current project, in a globally installed PEAR package, in a PHP extension, it may even be shipped with PHP. If you want to communicate that your library needs a working logger implementation, just using the LoggerInterface – and thus requiring just psr/log – is quite enough.
  3. By depending on an implementation package, you basically undo any effort you made to depend on abstractions and not on concretions. Since a “PSR logger” implementation is by definition a concrete implementation of the LoggerInterface from psr/log. In other words, you have pointed your previously inverted dependency arrow back to concrete packages (although you leave it undecided which concrete package that will be).

1. is correct, the code only needs the interface, but as a package is a bit more than just the code, 2. comes into play, and thats where I disagree, if you use a dependency management system, then you shouldn’t try to fullfill parts with stuff outside of that dependency management – meaning, it shouldn’t be a globally installed PEAR package, or if you can’t do without should wrap it.
Also, just using the interface does not “communicate”, infact just using the interface the dependency management will be fine even if no implementation (thats still required from the application) is included.
I make that distinction between packages and code, so point 3 is not really something that bothers me in this case, infact i’d say a virtual package is the most abstract package you can require, where as not requiring one at all is just missing something. It really is just giving an application that uses (well the dev of it) a hint about what he needs to take care of, while leaving him the choice how to do it.

Bonus: if I’m not completely wrong the App dev can even decide to add a provide to his own app, and include the implementation there.. comment if you tried it.

  1. The notion of an “implementation package” is really vague. What does it mean for a package to be an implementation package. Is it sufficient for it to implement just one interface? What if the “interface package” contains multiple interfaces, which one should the “implementation package” implement? All, one?
  2. The final argument against psr/log-implementation packages is that psr/log (the interface package) itself contains a NullLogger class, which is an implementation of its own LoggerInterface, and therefore this package itself also qualifies as a psr/log-implementation package!

6. is really a no-issue for me, as if I provide a package(s implemenation) I have to provide the complete package. Which brings me to 7, and thats an issue I’ve already thought about posting a rant over. Interface packages such as psr/log should not contain logic. That nulllogger should be in an own package. But that issue in that case is small as psr/log does not “provide”. I’ll write more about that when I find the time to write up on why I don’t like stackphp.

The DoctrinePHPCRBundle Matthias picked is a good example for what I suggested in this post, it requires the virtual phpcr/phpcr-implementation, and both implemenentations of that require phpcr/phpcr which contains the shared interface. Maybe that is a bit of a better example than psr/log, as it is less abstract (example wise) – I did pick psr/log, as it is a very commonly used package, and as I’m a big proponent of the work that the PHP-FIG guys are doing by standardizing interfaces.

Whats that on your arm?

I’ve been wearing a LG G-Watch for about a week and a half now, and I’m surprised on how many people even notice that I’m wearing it. Not only at work or in the Pub I’ve had people ask me questions like “(Whats that on your arm?) Is that the iWatch”, no even when just waiting for a tram looking at the watch because it just vibrated seems to draw attention. Interesting.

Now i decided to blog about the wear to maybe answer a few of the more common questions. The first thing i already answered, no its not an iWatch, its a LG G Watch, which runs googles android wear on it. That means it is paired with an android device (i have it paired with a first-generation Nexus 7), and allows to run android apps on the watch, receive notifications from android apps on the paired device, and transmit information to the paired device. By default it comes with very little apps, and there isn’t that many apps available yet.

my watchface build with facerSo what can it do? Basically the first thing is – it can show you the time (who would have guessed), and since it does that on a display, it can do so in what ever way you like, there is already a ton of watch-faces (skins for the watch) out there, and a few apps that allow people who don’t know how to program to build one as well. I used an app named “Facer” to build my own. same watchface in dimmed modeBesides the normal mode where the full watchface is shown it has a “dimmed” mode, where it is supposed to only show a simple version of the watchface (not all support that properly) to save power.
Personally i have turned off “dimmed” mode, as when i want to see the time, i can simply touch the display, and i don’t need it to display anything when I’m not looking. (turned it on for a screenshot though)

Then it allows to show notifications, notifications in the most basic form are the same notifications you know and love from your regular android device – however, if an app truly supports wear, those notifications get pimped (which needs to happen in the paired devices app, you don’t need to install the app for that on your watch). This allows to add additional pages that you can swipe through (with more information), buttons to touch (that will trigger stuff on your paired device). @here open map

There are some apps which make quite nice usage of that. Some Applications have a minimal app just for launching stuff on the watch, and have it trigger the paired device to send notifications with information – for example this seems how @here is working.

And then there are apps that are actually running on your watch stellio (quite often still communicating with the partner app on your phone), for example i installed Stellio, which is a (very nice) music player that runs on the paired device, but has a good companion app on the watch, that allows for a bit more than the notifications that for example googles own player is using.

The Watch comes with a suite of sensors (compass, acceleration, gyroscope..), is paired through bluetooth 4 (and its amazing, i don’t really feel an impact on the battery time of my nexus 7, but the range is roughly 20 meters with up to one wall inbetween).voice recognition Also googles speech recognition can be used by apps on the watch, which is quite nice, for example bunting allows you to tweet by simply raising the arm (will cause the watch to switch active), saying “ok google..”- trigger googles speech recognition – “start writing a tweet” – opens the bunting app – “just an example tweet for my blog” – the text you want it to tweet device-2014-09-22-183900(example). The Downside is, it will tweet whatever it understood.. without asking if thats really what you want to sent. (can’t wait for for #drunkenbunting ;).

So you can see, there are a lot of possible ways applications can be enhanced or build to enhance the watch experience – useful and fun stuff (yes there is a hand full of games for it already, even though i find those rather silly.. but i think you could improve location based games like ingress with the right companion app). Ultimately the time will tell, so far there is a lot of proof-of-concept apps, and IMHO just a few useful ones, but thats exactly what I’d expect. Developing your own apps is pretty straight forward if you are used to Android development, and i guess sooner or later I’ll end up building one or two of the ideas that wearing this watch has inspired me to.

Since it is right now a bit hard to find the good apps (WTF google, where is a filter in the play store that allows me to show wear-apps?), I’ll close this post with a small list of apps that i like.

  • Google Now & the other Google Apps it comes with/works with.. no link for those =)
  • facer – an app to create watchfaces
  • MiniMaps – an app that will show the map of whereever you are
  • Bunting – Tweet from your watch (and read the last few tweets by others
  • Attopedia – A wikipedia app that gives you wikipedia on your (spoken) command
  • Doctor Wear – an app that will countdown to the next Doctor Who episode
  • Stellio – a brilliant music player
  • IFTTT – a multi purpose app i don’t want to live without anymore.

Obviously there are more, and i have installed more, but those are the ones that i’d install first if i had to reinstall the device.

PS: yes somtimes it feels a bit like having a PipBoy 3000…

PPS: yes i have put on a Knight Rider watchface and pretended to talk to Kitt.. it was less fun than it sounded though

a small follow up…

Quite a few people have read my post where i criticized an article about harassment in the gaming industry, now i’d like to follow up on that post.

There has been some discussion on my post on facebook and some people had problems understanding why I felt it necessary to criticize such an public stance against harassment – while i felt the article was portraying problems as a women-only problem, which i don’t think is correct.

Today i signed an open letter to the gaming community against harassment. This letter in my opinion shows a much better way of adressing the issues than the article that i criticized in my original post, and signing it should leave no doubts on what i think about certain ways of behaving.

Please read this open letter:



a few hints for the PHP crowd..

hello, i thought its time again for a small PHP related post (haven’t done alot of those in ages).

Today, i want to link you a hand full of tools that can make your life a lot more simple (rember: simple is good). This is not going to be a very long post, as you can find enough information about those tools on the net anyways – the idea is more to just point you there in case you haven’t heard of ‘em yet.

Composer – I asume you already know and use composer. If you don’t, chances are that besides checking out composer you also might want to read PHP the right way, which gives you a lot of links on stuff you should look up.

other links usefull when working with composer are – the public repository composer is using (also available opensource you can build your own repository based on it), Satis – a much more simple and smaller tool to build simple own repositories, and hosted private repositories at gemfury. Then, to have it mentioned there is also toran proxy a tool you can setup that will mirror packages you use a lot for you localy, to speed up your development process.

phar-composer – this is a very nifty tool if you have php based command line tools, basically what it does it can create a runable phar file from your composer project. So if you have a command line tool, and you want to install it in a way that you can simply run it – or you want to distribute your command line tool as a single executable, this will make things easy for you. Even better: if the composer project from which it is building the phar file is on packagist, you can even use phar-composer to get it installed. (“phar-composer install liip/rmt” for example). As a note on how it works / which script will be executed: the first bin in your composer.json is the one that becomes the executed script.

RMT – this is a little release management tool, what it does is that it will run several checks (defined by your config) like your unittests, a working copy check and a few others, and then generate a new version number, update version strings in your files (if you want), add your commit messages to a changelog file and tag the release in git or mercurial – which when working together with composer creates a new release package. It comes with a semantic versioning based versioner (but you can use other ways of creating versions too.. but why would you? ;)).

one last trick (i think the manual doesn’t mention it yet) is: you can install an RMT executable by running “sudo phar-composer install liip/rmt” (sudo as it will by default install it in /user/local/bin/rmt).


#LD48.. or building a game in a totally tough time constraint

So, its Saturday 2014-08-23,  and Ludum Dare has started a few hours ago.

What happend so far:

at 03:00 Ludum Dare started, the subject that was voted on is “connected worlds”.

at 06:00 i got up, and read about the theme. Not my favorite, actually i was hoping it wouldn’t be this one, but well – its still better than the theme of the last Global Game Jam.

at 07:40 i arrived at where i thought that the location was – at 08:00 the time it should start i got a bit nervous about no one having shown up yet, so i posted in the facebook group about where everyone is.. turns out Geelab has moved offices, thankfully not too far

at about 08:30 we had breakfast and started thinking about games we could make

its now about 11:00, i think basically everyone has an idea what he/she wants todo, and it seems (so far) as if all of us have decided to go solo.

a livestream is up at

My game idea is basically a game where you play an information courier in a world where faster than light travel has been invented, but no FTL communications yet, so you are connecting worlds. I originally had planned on getting things started trying out loomsdk, as the tools provided should allow for a pretty rapid workflow, but since i run into a few troubles with installation (nothing that i’d see as a problem under normal circumstances, but something that i can’t take care off in this extremly short timebox), i’ve decidd to go with the same lib that i used the last few gamejams libgdx, for all its worth, i’ve at least a bit of experience with it.

I’ll try to update this Blogpost through the day as things happen.


EDIT: 14:00, i got the basic application, the splash screen, a logo, and a background for the menus so far.. feels like i’m way behind, while actually i couldn’t do much more in this time..


EDIT: 17:16, i got a bit further, but i’m still spending tons of time on details (like for example libgdx changed the way a stage is handled by using viewports – nice change, but reading up on how/what/when/why did cost me valuable time again. *sigh*, lets hope that from now on it gets better

EDIT: 19:51, it seems I’ve hit a brick wall about 40 minutes ago. Whenever i hide a dialoge, it also hides all stars.. and i can not figure out why, as the hide action of the libgdx framework dialog should only hide that dialog… i think this is the most frustrated I’ve ever felt on a gamejam, well, I’ll have a cigarette, and then see if I can work around it somehow.

EDIT: 20:55 I’ve been able to work around the problem – not happy with the solution but due to the time contraint it has to do. using two stages now, one for dialog, one for the actual scene.. works.

Last 20 minutes, and i guess 10 more for a break, to recover some energy. Also theres a Beer on my table, i feel that needs to be taken care off.

EDIT: 23:08 Alright, now while i feel more and more like I need some sleep soon, i actually managed to get a few things done. My soundmanager is in, so i can add sound now (already added some music), the worlds (planets) have their entities now, and are comming along, so my mood is a lot better now.

I still think I’ll call it a night soon, get a glas of Whisky, and proceed tomorrow.

EDIT: 23:18 and here a few screenshots of where I’m at from my Nexus 7.

Work in Progress

Work in Progress

more work in progress

EDIT: 08:19 so, i had some short 5 hours sleep and am back in action now – lets try to get something done while still waking up.

EDIT: 10:05 i’m getting things done \o/, i’ve added some basic information about the games state to the ui (fuel, wallet..) also i’ve finished an first iteration of the map-generator which creates random starfields that can be played in.

It seems everyone has survived the night – as all people have turned up (last one a few minutes ago).

Also: one more screenshot:

now with hud and generated stars

now with hud and generated stars


EDIT: 12:39 alright, finished name “generation” for the stars, also added an element that will display the name of the current star. will have a cigarette break now, and after that either start with the contract system OR build the highlight abbility for the current star.

Also, i just replaced the music with music by Chaot, who created a special tune for this (Thanks!)

EDIT: 16:08 so it turns out, scaling an actor didn’t work that well with the clicklistener, and it took me ages to find out.

On the Plus side: the game is now displaying adjacent systems that your jump drive permits you to go to in a green-ish color, and your current system is highlighted too. Also its finally possible to actually change system (within the limitations of the JD).

On the Negative: i doubt i will get the full game going today, i still have the contracts to do, the fuel consumption, adding some sounds, and then the random encounters that would make it interesting. Now this is not too bad, i figure i still can get a lot of it done today – well at least prototypes of it, but we will see.

Oh, before i forget, screenshot of the highlighted systems

system highlighting

system highlighting

i guess with the mouse some mouse-over-name-showing would be nice, but that won’t work for the touchscreen, so i guess i’ll have a click actually pop up an dialog, which will then allow to jump or close – opposed to at the moment where a click/touch = jump. I mean i’d rather keep it that way, but people need some way to determine what system they are jumping to.. don’t they?

EDIT: 19:34  I actually got forward a bit faster in the last 3 hours, it seems that i got over my tiredness. I was able to build the contract creator (well a rudimentary one), and the menus that you get when visiting worlds, including the contract table. I also decided to add a small feature that i found important enough for a small detour – when you select a contract it will highlight the destination star, making it easier for the player to understand where this contract is going.

Time for a food break.


omg! a blue star!

omg! a blue star!


EDIT: 21:45 so, over here most people are done, and the beers are out. I managed to get quite a bit done in the last few hours, but still.. there is a lot missing, and it wont be happening today anymore.

What i did get done: accepting contracts, showing conracts, delivering contracts (and getting the reward) and a credits screen

Whats missing:

  • fuel mechanics
  • random encounters
  • loss conditions
  • adding a lot more of the music / sounds that chaot made

I’m going to call it a day, and build a release now, and then relax a bit for the last few minutes of the weekend. The missing features will come soon(tm), as i want this feature complete.




EDIT: 22:54 getting all the stuff for the android store done took me a while – for some reason i can’t create the apk with idea anymore, but must use gradle… well ok, its working now, and somewhen in the next few hours the first version should show up on the google play store


EDIT: the day after

its available in the store now, i wouldn’t recommend any smaller device than a 7″ tablet though, also you can download a single jar file here which you can run if you have java installed  (java -jar ConnectedWorldsExpress-1.0.jar or on most systems a doubleclick)

EDIT: a few days later:

I just uploaded version 1.1.1 to the appstore, where i fixed icons, added a bit more sound feedback, and changed the settings so it will only be available for tablets (ui doesn’t really work well on smaller displays)


Desktop (Java):

EDIT: a week later, release of 1.2.0 – a few ui improvements and fuel usage done.


Desktop (Java):