Battle Among The Stars, Day 6

Today I spend time on finally getting the turret rotation to work, and as it turned out I hadn’t really understood the problems that I faced during LD yet – I ended up having rotation wrong again. (It only worked last time i looked at the problem because I had my 2D playingfield in front of me instead of looking from the top at it.)

Now personally i think adding rotational turrets should be something rather easy, and I was a bit annoyed on how long it took me, but I think my excuses are good enough, after all I’m still spending most of the time I work on this figuring out how to use the Unreal Engine, and it shows that the Engine is build to build shooters, most tutorials focus on that, and creating a shooter level is probably easier than to build a game like this from scratch. I might have saved some time using one of the available game templates (two stick shooter), but I figure that would have limited the learning experience.

Anyways, I now have rotating turrets on my ship (it is actually implemented through a blueprint component, something new in UE 4.7), and that are working, and also I implemented a simple zoom in / zoom out control (in the old default distance it was hard to even see the the turrets, so I moved a bit closer (for now) and gave the option to use the mousewheel for zooming in/out. (Not sure how I should provide that for gamepad, probably you’ll need to hold a shift key for that).

Also, i replaced the static ship in the main menu with the same thats being used by the player – which allows for a small turret-rotation animation at the start of the menu.

After that I spend quite some time reorganizing the folders of my project to something a bit less of a mess.

Now, all in all I’m happy with how much I got done, also, at the end of the video there is one more thing I’ve been working on ;)

Also, last friday I showed the previous video to some friends of mine (who are working in game dev), an Martin pointed out something that I’m still thinking about. As you might have noticed, when the ship turns your movement vector won’t change at all, only if you apply thrust it will have effect on the vector. Martin said, that if I fire thrusters to the side, I could make it actually in more of a turning around movement. At that time I thought he meant that I should do the ships rotation by thrusters (which I’m avoiding on purpose at the moment, because that would mean rotation needs counter-thrust to stop, which might make the controls a bit too harsh). Apparently what he meant was, that when the ship goes into a curve, the lateral thrusters (which are not implemented yet, but will come for strafing) could fire, by that helping to change the vector faster.

He actually has a good point there, but I don’t want to automate this behaviour away. Once I’ve implemented it you will be able to manually fire those thrusters, mainly for strafing, but it will allow you to influence the vector as well. The thing is that as with the forward breaking thrusters, those are maneuvering thrusters, and by that they are a lot less powerfull than the main engines, which means that managing rotation and the main engine will still be a more efficient way to control the vector, while the lateral thrusters will be better suited to make small corrections.

This all will get more interesting once the fuel mechanics come into play as well.

Battle Among The Stars, Day 5

So, todays post is rather boring. I spend much more time than I wanted on figuring out how to get a camera which is moveable detached from the pawn controlled by the player.

I wasted a lot of time watching videos on how to use cameras and such, also spend quite some time reading up on answerhub, and in the end I realized, I don’t even need most of the stuff they where talking about (For example: someone suggested using 2 PlayerController instances, so two Pawns, one for the camera and one for the actual pawn can be possessed. Having two player controllers for each player just seemed plain wrong to me).


So I had a closer look on what i actually need, and for now came up with a very simplistic variant to do camera movement. Probably I’ll iterate over it again once I’ve learned more about UE4 anyways. The good thing about all this is that I finally moved the controlls where they belong – to the PlayerController.

Also, if you ever end up using Unreal Engine 4, and you’ve set a PlayerController through Blueprint Icon on the top, but then end up with the packaged build (or stand alone game) not using that controller: Edit->Project Settings is where you have to set it so it is persistant, apparently the one through the icon is only for the current editor session.. not knowing this almost drove me crazy today.

Small video showing that the camera stuff is actually working:


Battle Among The Stars, Day 1 to Day 4

Basically this is a “what happened until now post” as kick-off for the battle among the stars devblog.

If you have me on facebook, you most likely will already have seen the screenshots from the first 4 days, so there won’t be much new in this post. In the future I plan to use this category of my Blog for my Dev-Diary.


Why am I doing this?

I didn’t blog about this, but last year in december i tried to take part in the Ludum Dare 31 – and I failed horribly, which is probably why i didn’t blog about it right away.

I failed because

  • i was hungover from the Xmas party of the company i work, which happened on the night before the Ludum Dare
  • I decided to go solo. Now that alone doesn’t make for a fail, as for the Ludum Dare 30 i wen’t solo too, but within such a short time frame this adds a lot of stress
  • I decided to use an engine, which I never used before: the Unreal Engine 4

Now even though I failed, I liked what I saw from the unreal engine during that time. So I decided to go ahead and build a game outside of a GameJam with it.


what is this game going to be like?

at this time I don’t want to go too much into detail, so I’ll just throw a few keywords out there:

Online, Multiplayer, 3D, top down, Spaceships, Shooting, Tactics, Resource Management, PvP.

what happend so far

Day 1 (February 1, 2015)

On day one I mostly spend my time learning a few more of the basics on how to work with UE4, as well as creating a first pretty rough frame for the game. At that time I hadn’t made a decision on using 3D graphics yet, I was spinning around the idea to use 2D graphics, but particles in 3d space for effects and such.

At the end of Day 1 I had a running application, which would display (and allow to move) a simple 2D ship actor.



Day 2 (February 8, 2015)

On Day 2 I made two decisions:

  1. after trying out a few things the 2D + 3D effects thing turned out to be more trouble than fun, so its gone, I’m using proper 3D Models now
  2. While i can build a simple Model of a Spaceship, I’m no 3D artist, also I seem to be completely unable to come up with cool Textures. Also asset creation costs me a lot of time that I actually would prefer spending with things that I enjoy. So i bought a pack of simple Ship Models – for now they are good enough, and i expect to replace them at *some* point.

Besides toying around, and getting to those two conclusions I set myself to build a menu screen for the game.


once I was happy with that, I actually created a git repository, as I reached the point where I didn’t want to start over again, if something goes wrong.

As long as I work alone on this, there won’t be much of a problem with git, but i learned that UE4 saves blueprints in a binary format, which has the downside that git won’t be able to do merges, and conflicts are solved by throwing away the changes of one of the two contributors. But I decided not to care about that for now, as I’m flying solo on this one.

Day 3 (February 14, 2015)

on day 3 I finally started making some good progress, i created the actual test-map that I’m using to try out the things that I’m building and then build a Ship actor, which is now moved around by applying thrust. Once that was working, I spend some time creating a particle system for the thrusters, which will give a nice visual indication of which thrusters are active.

However I cheated:

  • I was only using one thruster for forward/backward movement, by having the thruster (mounted at the rear of the actor) apply negative thrust for when the braking/forward-mounted thrusters should fire.
  • rotation is not done by thrusters yet – and I’m uncertain on if I will change this at some point. building it is easy enough, but controlling it might be rather annoying for the player (to stop your rotation you would need to apply counter thrust, so most players would at least keep a small amount of rotation constantly going)

At this stage I remembered something from last years global gamejam, where my team build a space-ship game aswell: If you don’t have a visual indicator on where your ship is going, then navigating (and stopping) gets quite hard. So I created a similar solution what we did back then, and added a direction guide.

At the end of day 3 I was quite happy with what i had achieved, and then I looked at my blueprint, which gave me the feeling of creating a big mess – the logic I had created shouldn’t be attached to the ship, and it seemed quite chaotic.



Day 4 (February 21, 2015)

Today I spend most of the time refactoring what I did during the other days, to get less chaos and a better basis for building upon.

I also removed one of the two cheats from Day 2, the braking-thrusters are now actually backed by an own physics thruster. Also the weight of the ship, and the amount of thrust applied by the thrusters is now much more realistic (than the 60kg that the ship had before ;).

However the screenshot of today is probably rather boring, as it simpy shows the refactored blueprint of what was a big mess in Day 3.


Global Game Jam 2015, building airlock

If you follow this Blog, you probably already know that I’m a big fan of game jams. It all started for me 3 years ago during the Global Game Jam 2013, the first Game Jam I attended, so the Global Game Jam is something special to me.

Once again I enjoyed the atmosphere of the HfG, which provided the location in Karlsruhe. When I arrived, meeting quite a few people that I’ve met there in the last years as well, I already felt that this would become a great weekend.

This years GGJ started earlier, rather than 17:00 like in the last few years, the Time of 15:00 was communicated – and I made the mistake to assume this was mostly so people would be there in time. Well, I was wrong, the keynotes started earlier (at 16:30) and the theme was given at 17:00. Lucky, I had arrived early.

The Keynotes


The first keynote, by the woman behind Redshirt (a game I enjoyed playing a while ago) I liked, mostly because it didn’t tell me for the 100th time why I make games, no the speaker knew why we make games, and left no doubt about that.

The second keynote was spanish (or portugese? i don’t know, those two languages sound the same to me), and we had no translation, so I didn’t get much of the Message, but looking at the pictures and the credits at the end of it, it seems that someone tried to pick up on the FlamerGate affair, trying to force a pro-thirdwave-feminism spin on the Game Jam, so I guess i didn’t miss too much.

The third keynote by Reiner Knizia felt like an anachronism, not only had he chosen a visual style for his video that looked like it was made in the 90s, also his examples for connecting classic board games with modern technology made the impression to be years behind. In times where people are building augmented reality games, having a cheap looking plasic volcano that lits up under some conditions just doesn’t seem to cut it.

The Theme


After the keynotes the theme “What do we do now” was announced. To be honest, my first thought was “ok, those guys where pretty high when they came up with this”, but then my second thought was “well, still better than last years theme (We don’t see things as they are, we see them as we are).

While discussing with some of the other jammers I basically formed the Idea of an game where someone would have set directives to various actors, whenever an event arises, and that actor would continue acting by that directive (repeating the same action that was set for this event if an event was known, or asking for an additional directive if an event was unknown), creating a system which would need carefull balance (in form of the directives given by the player) to achive a goal that requires the actors to collect resources, transport resources, build something with the resources and keep each other alive.

I still like the idea, but during the pitches, a few friends of mine actually pitched an idea which I found a lot more appealing for this gamejam, so I joined their team.

The Game


Together, we then build the game “Airlock”, which is basically a game that you can play in a group of 5 to 12 people, utilizing a mobile device as a game master. The players are put into groups of Scientist and Saboteurs, where only the Saboteurs know who else is a Saboteur. Then each round one player will be set to be the “Operator” and create a plan who is going to which room to repair crucial systems of the space station that the group is stranded on.
If the majority of players agrees with the plan, every player gets to act his repair action within the room he was planned for – saboteurs however can choose to commit further acts of sabotage instead. At the end of the turn, the Operator then can check the status of the room (how many repair / sabotage points it has), and is responsible for telling the group the result (but, well which saboteur would be telling the truth to the scientists?).
If the majority votes against the plan, the turn is over immediatly, and the next operator is chosen.
In both cases, whenever a turn ends, one unit of oxygen is used up, if the group runs out of oxygen, the saboteurs win.
If the saboteurs manage to corrupt all rooms, or corrupt a room that then gets repaired, the saboteurs win.
If the group manages to repair a room before it is corrupted, the scientists win.
A room is repaired / corrupted once all its repair or corruption fields are filled with the corresponding markers, which are placed through the actions of the players.

We started with a slightly different set of rules and ideas on friday evening, and the first thing we did was to play the idea through with some cards, just to see if it works. Friday night I then spend looking at what technology we would use to create the game. At that time I was thinking that using a HTML5 app build with AngularJS might be a good idea, and i spend 1/3rd of saturday to look into phonegap, so we could deploy this app to mobile devices. As it turns out getting phonegap to run on an windows machine was already more than trivial, especially if one is used to the linux, not the windows command line (like me ;), so saturday afternoon we made the right decision when we agreed on using Unity as the engine. Now while my experience with Unity was basically “nothing”, having worked with c# before made it easy to be useful. Martin N. took charge of the actual Unity stuff, creating our user interface, while I implemented a huge chunk of the Game logic. Meanwhile the others spend a lot of time play testing more with cards, and involving other people in those tests, to see if/how the balance can work. I’m not sure how (where they took the time for that, if I’d have done it it would have taken me ages), but Martin, Martin, Bjoern and Jana somehow managed to also create game assets (graphics, sound) while doing all the other things, which really impressed me.

Sunday morning we started kinda late, but we had most of the app working, and where able to use the time to tie it all together, do a bit more of testing and a few last minute changes. I think what held us up the longest was the search for the name. As there wasn’t much code left for me to write, i tried to make myself useful digitalizing martin’s hand drawn airlock logo, so we could use it in the game, and finding a nice background (stole it from NASA, thanks for making it CC you guys rock!).

When the deadline approached we had a working build, even though we hand’t managed to get all the sounds going in the game jet, but what we ended up with was good enough to show to others, and to actually play a round.

All in all this was one of the lesser stressfull game jams for me, but it still blew me out of my day/night rythm for several days (hence i didn’t post earlier about it).

The Future

Since the gamejam we have played the game (for example in an Irish Pub after the Game Culture Club, where 4 of us attended), and we have been talking about what we want to do with. There are still a few improvements to the balancing that should be made, and the app itself needs a bit further refinement before we can offer it in the app stores. Also Martin suggested that we might actually offer a card game version, as we had a lot of fun playtesting with cards instead of the app as well.

So, where to get it?

The global game jam site linking to the game, has an apk, that you can throw on your android device. Sadly as we where running out of time with the sounds, this 1.0 version does not include everything, and we can’t update the file there.. BUT you can download the 1.1 version for android here.

CMDR Club: Whats going on with it?

Summer 2014, when the beta of E:D was going on I decided that I wanted to build a few tools around the game, which where mostly to make my own life easier – but as i have done with a lot of the stuff I’ve build to make my life better in EVE Online, I wanted to offer the same tools that I’ve build for myself (in this case it was the first Iteration of the route planner) to all other players as well – as if I’m in the need for such tool, then others are as well.

There is various rasons on why/how someone would spend as much free time as I do on 3rdparty- (or fan-) sites for games. Besides the “I need this tool” they always provide a good platform for myself to test out technologies, and train my own skills further. The route planner is a good example of that – yes i had implemented an a* before, but how would that scale on an application that many people are using, and what can i do to keep it performant?

The big surprise came the day that FD announced there wouldn’t be any wipes anymore. From a few Users that where using the roue planner on a daily basis, the numbers jumped up to several thousand unique users a day, and is still there, which forced me to actually spend more time on the project than I wanted (I was foolish enough to plan playing the game myself ;).

Well now the route planner is running mostly stable, using 2 webservers (hhvm+nginx), and an replicaset of 3 tokumx (a mongodb fork) instances. The only issue I’m having is that FD only provided an extremly limited set of “known” stars to the community, and that the crowd sourcing efforts of those trying to cartograph more have stalled (guess their all busy playing), which means the routes that can be found are far from being perfect, and there are many places – even within the known sphere of human influence – which can not be reached easy. Sadly i can’t do much about that – I hope the community is going to ask a bit louder for this data (or the information on how FD generated that data), so FD gives in and publishes more.

Then I’ve spend a few hours on optimizations that the community has asked for (ranging from a slightly different color scheme, to a more mobile friendly version) – a lot of the things I’ve been asked for I’ve delivered already, and some I’m still working on.

But I don’t want the website to stay “that route planner”, I want to integrate more tools / information, especially those that I miss myself. For example, right now I’m working on an aggregation of News / Blog Posts from various sources, as I feel a more central place where you can find this is lacking.

Another thing I want to add (soon) is proper profiles for registered users – which includes to allow users to name their user (right now its all random names, with the exception of my own profile).

So, feel free to swing by any time soon, there are new features comming.


Peter “Peter Powers” Petermann

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).