Interplanetary has been Greenlit! Huzzah!

We did it! Huge thanks to everyone who took the time to check out the game and voted for it!

Now that our pathway to Steam is finally open, we can continue to concentrate on finishing the game. Interplanetary is steadily approaching it's beta state, but there's still a lot to do.

As you may know, you can also help by trying out the current alpha version of the game and giving out some feedback. Once you have an alpha code (available by pinging us on Twitter or Facebook), you can move out over to www.interplanetarygame.com and grab the test version!

Thanks again, everyone! We literally couldn't have managed this far without you!

What's up, Interplanetary?

The game is actually starting to look kind of nice! After all the recent devblog posts, we thought it would be nice to get back to the basics for a moment and give a little update on how we are doing with Interplanetary and internal Team Jolly Roger stuff.

Interplanetary is prettier and more functional!

It's true, a big part of why I wanted to write a quick status update is to showcase some of the new graphics! We've been busy implementing a graphical beauty that we won't be ashamed to show around. Of course, this is still not final, but it's a nice improvement to what we've had in the past.

We've come a long way...

...and we're still not done!

We're currently working on creating something nice looking and playable for o
ur upcoming visit to DigiExpo in Helsinki. Something big is brewing and we'd like to have a nice slice of the game to show to people there, and maybe even let them try it hands-on.

As for the gameplay, we basically have all the basic features of the game present, one way or the other. For showcasing the game, we're concentrating on getting the targeting phase work properly and feel good. It is, after all, a major draw of the game. The other main feature that we aim to polish, is the building of structures and maintaining them. These two features by themselves already make a kind of a nice little game, but there's a lot more in store for the next version.

TJR is a company, for reals!

This is quite huge for us: we managed to break free from the grasp of our university and form an independent company, officially known as TJR Games! We're still the good old Team Jolly Roger, just a bit more official.

Starting a company wasn't a simple thing to do, and preparing for it has slowed down the game development considerably at times. There was a period, when we didn't actually have a work space to do our game development and the team was separated to work in their homes. This rarely works.

Was going to add a picture of the office, but who cares? The game looks nice.

Luckily, we found an office space for a manageable price and filled it with computers and other stuff needed for game making. For a new indie company, this wasn't exactly cheap overall, but at least the situation is more stable now and work can resume in normal pace. Or, extranormal, since we're in a full-on crunch mode! Busy, busy.

Hungry for more screens? Check out our stash of pics, from the oldest of versions to the new shiny ones.

Northern Game Summit 2013 & how to pitch a game

Full house!

Northern Game Summit was held second time last week, and we thought this would be a perfect time to share our experiences.

Kajaani is quite a remote place to hold a gaming conference at, but NGS was still very populated event. (And the only one to date that has started with karaoke!?) All in all the event was pretty excellent, we had a chance to meet lots of new people and keep in touch with old friends. The lectures we're interesting too, even after some technical difficulties.

Afterparty was a big part of the event as usual. The organizers came up with an interesting combination as the stands you would expect to see in most gaming events we're actually part of the party. Worked very nicely!

Ever played Alan Wake on 300" screen?

This time we took part in the pitching contest, which was probably the most important single event throughout the summit. While the pitching didn't go as well as it could have with proper preparation, it was well worth the trouble. Pitching an idea in front of real business people is an excellent way to get some free EXP, something we definitely recommend to any game developer. Since it's possible to learn from anyone, not only from the best, check out this short list of what we gathered:

-Prepare early. This provides you a chance to go through your presentation multiple times and in different mindsets, and gives you more time to...

-Practice. This one should be obvious, but it might still be just a little bit too easy to trick yourself into believing you know your idea/project well enough to present it spontaneously. Do this in front of someone not familiar with you as well, if you have a chance. There a second layer to practice as well: In addition to practicing every single pitch, you should practice pitching in general as often as possible.

-Gather your team, or at least consider doing so. Preparing a game pitch is something you can do alone, but it's almost always better if you can prepare it with your team or even a couple of friends. This helps you to cover multiple points of view, get more feedback and root out some hitches that might have gone unnoticed.

-Back it up. Do some research that prepares you for difficult questions about your target audience, competition, sales estimates, even tech. Including those things in your pitch in a simple format gives a feeling that you know what you're doing, as long as they are facts.

-Make it look good. Having some cool concept art can definitely help you get the point across. Mockups or bullshots are better, and if you have a chance to include a short section of gameplay video, you're all set!

In the process of preparing for a pitch one time too little.

PS. We haven't completely forgotten about Interplanetary either. The development effort is back on track and running smoothly now that we have settled in our new premises. More on that later!

Creative process and UI design, part one

Hello!

I'm Tarita, one of the two artists in our team, and this is my first blog post here. My main task in Interplanetary is to help to make the User Interface fuctional, and hopefully, also pleasant to look at.

Thankfully, I have studied graphic design in the past, and my previous game projects have provided me with enough experience to understand that design work like this involves more than just throwing a few boxes here and there and calling it a day.

So, the theory side is pretty well covered, but my hands-on experience? Very little. Our team size used to be a lot smaller, and as the sole artist my attention was mostly directed at in-game assets. I had made some UI graphics, too, but there wasn't enough time to actually concentrate on them, not properly. Interplanetary is my first chance to redeem the hasty UI:s of the past, so to speak.

Despite this, my first mockup sketches for Interplanetary were conservative: Electric blue elements surrounded by a subtle shine of blue light. I wasn't satisfied. While the combination definitely looks appealing, it's also a very common sight in scifi games, and I wish to avoid sticking to the most obvious style choice. I was looking for something modern and sleek, simplistic rather than cluttered and glossy.

Pictured: creative process

After "some" time, blood and bitter artist tears, I ultimately came up with three different style options for us to choose from: a) A light and delicate combination of solid metal parts and transparent holograms, b) Solid, traditional boxes with a white color scheme, and c) A mix of typography and colourful, yet subtle elements that obstruct the game view as little as possible.

Based on the sketches, we decided to go on with C, but we dropped the main focus from the typography elements and I was requested to tone down the amount of colours. To compensate for the losses, I picked up the white colour scheme (originally from B) and decided to use partially transparent objects instead of plain text.

To be continued...

In my future posts I will shed light on some of the many hassles of designing a functional UI, and provide you with some images of the final UI style. See you there!

Code of Interplanetary: Can I see some ID, please?

Hello there, dear reader. I'm Riku, you might remember me from that more technical post I wrote about making a GUI with Unity. In addition to blogging about our Unity woes, my task has been programming network functionality for Interplanetary.

The game uses a client-server model, where each game client records what the player on that client does during their turn. When the player ends their turn, the client sends all that information to a server for processing. When the server gets this data from all the players, it combines all the player actions together and then plays out the turn, figuring out the outcome. The clients then get back the results for the turn and display some pretty pretty particles flying around to show their player what happened and who shot who.

From the outset I decided that to implement this, I would give everything a unique ID that would be used by different clients and the server to make sure they are all talking about the same thing when communicating. For instance, whenever a building takes damage, the server takes note of the ID of the building, and then tells every client that building number 5 just took a hit. This way, to keep every client in sync so they are all on the same page, I'd just need to make sure they all use same IDs for each object. This sounded very simple at first, but ended up being a little bit tricky in practice.

Let's examine how a building gets assigned its ID. When a building is being built, it should be assigned an ID right away so it can be found again if it needs to be operated on later on. However, the game clients can not be the ones generating the IDs. Each ID needs to be globally unique, and the clients can really only generate IDs that are locally unique to only that one client. They could end up generating same IDs that some other client is also generating for themselves, at which point there would exists two buildings with the same ID. Let's illustrate this with an example. Imagine that ID is an integer, and generating an ID means using an integer one higher than the previous one used. The first building built would have ID 1, the second one 2 and so on and so forth.

Since clients do not have knowledge about each other, they would end up generating same IDs as everyone else. Then, when the information about these built buildings is sent to the server and combined together, the game world would have multiple buildings with, say, ID 2, and there would be no way to know which building ID 2 would refer to. Any time the server would send the clients a message about building 2 taking damage, the clients could not possibly know for sure which building had actually taken damage. This is why all the IDs need to be generated on the same machine, so there won't be duplicates.

The natural option to use here is to generate all the IDs on the server. However, building the buildings happens on the clients' end. It would be possible to ask the server for an ID every time a building is built, but that would create a waiting period whenever a player would build a building and the client waited for the server's response over a network. It was decided that all network traffic would be centralized at the ends of turns, and communicating with the server during a turn would be avoided whenever possible. Because of this, buildings get their ID assigned to them at the end of the turn during which they are built. When the server notices that a player built a building during their turn, it generates and assigns an ID to it. When other clients receive the information that a building has been built, they get the ID for the building in the same package, along with other data like the position and type of the building.

There is one issue left to solve, however. The ID for the building needs to be delivered to the client who built the building, as well. It does not sound complicated at all, but it has some practical implications. For the other clients, the ID was delivered together with the information on how to build the building. They can, therefore, assign the ID to the building as they build it. The one client who already has the building only gets the ID. When it receives the ID from the server, it needs to know which building to assign it to. Normally, whenever the server sends a client instructions about operating on a building, it refers to the building with its ID. However, at this point in time, the building does not have an ID yet! A solution to this is to use temporary local IDs. When a client builds a building, it does still assign a locally unique ID to it. It is not going to be unique across all clients, but it does not need to, as it is only going to be used temporarily until the global ID assigned by the server arrives to the client. The local ID is sent to the server alongside other information about the built building, basically telling the server: "Yo, I just built a building with local ID 5". The server then assigns a globally unique ID to the building and tells the client: "Your building 5 now has ID 7", at which point the client switches the building's ID from 5 to 7. At the same time, other clients just get information about building 7 being built, being blissfully unaware of 5 having been involved with the building at all.

So far things have been relatively straightforward, and were easy to anticipate and prepare for when I was implementing this system. However, there is one complication left to solve, and I admit overlooked it and did not see it coming before I was at the point where it made things not work. Let's look at what might happen when a client builds some buildings.

There are two buildings built on previous turns and the two clients in the game are synced up to that point. Then they both start building buildings and assign local IDs to them, beginning from 3. One client builds one building, with local ID 3. The other one builds two buildings, with local IDs 3 and 4. The server then gets information about this and assigns globally unique IDs to all the buildings.

The global IDs assigned start from 3 and go up to 5. Now, let's look at the second client receiving instructions to replace its local IDs with the newly assigned global ones. It finds the building with ID 3 and switches that building's ID to 4. It then goes to find the building with ID 4, to replace that building's ID with 5. The problem here is that now there are two buildings with ID 4, because of the previous building 3 that was just updated to have ID 4.

The solution I used for this was to fetch a building that needed its ID updated, store its upcoming global ID with it without actually yet updating the ID, and then repeating this process for each building in a need of an ID update. Then I go through all those buildings again, assigning each the ID that was stored with them. In the above example this amounts to finding the building with ID 3, and telling it "your ID is going to be 4, but not yet", then finding the building with ID 4 and telling it it would have its ID updated to 5, and then telling both the buildings to now switch their current ID to whatever ID they were told to switch into.

That is the essence of how things get their identifications in our game so every computer involved can talk about the world state with each other and are able to keep in sync when it comes to the state of the objects. For different objects than buildings the process of assigning the ID is a little different, but that’s something for another blog post. Stay tuned, and maybe I’ll get assigned to talk about those other things in the next episode!

Inside Interplanetary: Targeting Problems

One of these must hit!

Hello. I'm Sasu and I like to write blogs.

Everyone's been very busy lately. We're working hard to get everything essential working without a hitch, but hitches keep coming along. Well, that's the reality of game development and there's not much you can do about that. Except maybe try to design things in a more detailed way.

So, today, let's try something a bit different. Instead of me just telling you about a game mechanic, I'll explain some problems we've come across in testing and some solutions we've formed up.

Let's discuss...

The Difficulty of Hitting Your Enemy

Well, I guess one did.

While testing Interplanetary, we've repeatedly come across a tiny problem with the Targeting System: it's darn difficult to hit your opponent! There are many things that play a part in this.

The planetary system is alive. Once you've set the trajectory and fired your cannon, time unfreezes and the planets start orbiting. It can be very difficult to foresee the movements of this slightly chaotic system. The biggest problem here is that the planets have a large influence on their surroundings, thanks to their...

Strong gravitational fields. Now, this is something that's almost impossible to predict for a mere human. Sure, you can account for a planet moving in front of your firing line, but can you calculate how exactly it affects your firing trajectory with its gravitational pull? We can't.

The planets are quite tiny. Small things are more difficult to hit than big things. Who knew?

When shooting a single railgun slug at your enemy planet, the odds of hitting it are very small, even if it happens to be right next to you. Building 15 railguns and firing them all makes it a bit easier, but managing to maintain such an artillery would be very difficult and time consuming in the final game, not to mention the bother of targeting each and every one of them every time. Something needs to change, but what?

We Have Some Ideas

A planetary prediction system would make it much easier see the future positions of planets. We have plans for a system that shows the player the "shadows" of the planets' upcoming positions, depending on the current trajectory drawn. The future trajectory of the railgun slug, affected by the position of the planets, would also be shown as a shadow.

Looks a bit complicated on paper.

The obvious problem with this solution would be that it takes away the element of predicting planet positions and may make the game way too easy to play. Of course, there would be extensive balancing done to accommodate for this feature.

Lowering the effect of gravitation would be an easier way to tackle the problem, but doing so would also make the game less interesting. In the earlier builds, you only really needed to worry about the gravity of the sun. Other planets' pull was much weaker, so it was possible to actually pull off very accurate attacks. This did take away some of the fun, since crazy, unexpected trajectories didn't happen.

We could just make the planets bigger. This might be the easiest solution and the least problematic for now. The biggest foreseeable problem with it is the change to the visual style. We're trying to keep a "realistic" feel to the game and to sort of keep it grounded. Bigger planets might give the planetary system a caricatured feel. Or, maybe we should give the planetary system more of a "war room"-feel. It doesn't look particularly realistic as it is, so maybe adding more elements to make it look more like a tactical representation of the real thing, would be a good idea.

Now, we simply pick one idea, implement it and test. Or maybe we should use them all? Or something completely different? What do you think?

Art of Interplanetary: Maps

The end result

Hello folks, Jukka here again. I'll share a bit of the process that goes into a creating planet texture for Interplanetary.

From chaos to order... Sort of

Usually, when I've made planet textures or painted planets, I've started with either using Photoshop's cloud filters and level adjustments or custom brushes to create the terrain shapes... And if you simply want to make a planet, this works fine, but for Interplanetary, going with just random shapes isn't that simple, since the texture is a factor in the game balance. For example, small continents will restrict player's choice on where he can build and also can make it harder for the other player to hit buildings, although a successful hit on densely built area would have the potential for greater damage.

The way we're trying to ensure that the maps wont be a totally unknown factor in the game balance is by using a specific ratio for land and ocean. So far we don't have much data from testing on the subject, so we simply decided to start out with 50/50 ratio and see how it works, but with this, the players would at least have the same potential area to build on.

White is land... Or was it the other way around...

Because the land-ocean ratio has be to taken into account, using random shapes to create the continents would become much more time consuming. So, we employed the use of this handy planet generator, which allows you to specify how much water you want. I care mostly about the division of the land masses, so I only pull out the black&white landmask from the generator, which I take to Photoshop for refining. 

The shapes produced by the generator are very ragged and "broken", so I shift parts of the continents and islands around and get rid of the excess of  small islands and lakes.

Touch of fictitious realism

Once I have landmasses ready, I block in some background information, like tectonic plates and ocean currents. I'm not an expert on geography so I just wing it. Even if it wouldn't be entirely accurate rendering it lends some logic into how the map turns out. And, of course, since we're not talking about Earth, there would be many, many things to take into consideration, if we wanted to get close to actual realism.

Lots of iron in the soil, or maybe it's dyed red from the blood of vanquished foes.

The next step is to throw in some colors and plan what kind of environment goes where. And from this point on, it's about painting in the terrain and details. For this I have some brushes I made from NASA's satellite photos, which I use to lay in texture. I go over each area several times with different brushes and slightly different colors to make the terrain look more detailed and natural. I also go in with a small basic brush to clean up and add precise detail to certain areas like mountains and river deltas.


If only planets were cubes

Due to the way the planet model is unwrapped, the poles need some more attention to minimize the amount of ugly distortion (there are a few methods for unwrapping a sphere to avoid the pole distortion, but I won't go into more details now as there'd probably be enough there for a whole new post and it is also still something I'm hoping to improve myself in). I use Photoshop's Polar coordinates -filter to wrap the texture into a circle so that I can see how the pole looks and then paint the details I want near the poles and use the Polar coordinates again (this time with the 'polar to rectangular' setting) to bring it back to rectangle shape.

Left: After using polar coordinates Right: How it looks in unity in my test scene.

That's it for now, but feel free to ask questions, and I'll answer the best I can, and see you again in the future.

Check out our IndieDB-page for more goodies!

Inside Interplanetary: Random Events

Quite chaotic, but not completely random.

Sasu, here! I design games! Mainly Interplanetary at the moment, though.

Interesting times are ahead for our team: we are about to move into new premises. This, of course, affects our pace a little bit, but it can't be helped. Also, many new expenditures are introduced with the change, but we'll manage somehow. We might chronicle our experiences here some other time, just as a curiosity.

But today, something completely different:

Random Events

There are many things to manage when your planet is being bombed by an extraplanetary threat. It can get overwhelming, especially considering all the other things related to keeping up a planetary civilization. We call these other things Random Events.

At the end of the turn, your Event Log shows all the notable things that took place in the Action Phase between turns. Messages like: "Power Plant No.3 was heavily damaged" and "New Intelligence Acquired" are quite common and self-explanatory, but sometimes, something unexpected creeps in. Whoops, a meteoroid is heading straight towards a city and the Nuclear Power Plant No. 3 had a reactor explosion.

Despite their name, Random Events aren't truly random. The odds of them occurring often have a lot to do with player actions; they are just risks that you have to take. For example, building many Nuclear Power Plants naturally increases the odds of accidents happening and developing a sentient AI will have dangers of its own. Of course, some things, such as natural disasters, tend to happen whenever they feel like it, but they are usually reported on in advance. You can always at least alleviate the damage and a Random Event is almost never truly devastating, unless you really mess up your reaction to it.

A good old forcefield can handle pesky celestial bodies raining on you.

Random Events aren't always bad. Your scientists might make unexpected discoveries or your mines could strike into a particularly plentiful vein of Material. Bad events for your enemy are also good for you. Even seemingly negative things you might be able to turn into profit by reacting appropriately.

It's the reaction to these incidents that count. If, for example, something threatens one of your cities, you should spare some resources to build some defenses around it. Sometimes, you may even get a clear choice of action in the event report itself:

Workers of Mine No. 7 have gone on strike.
A) Start negotiations
B) Arrest the workers
C) Terminate the workers

Two of these options are extremely bad for Morale. Can you guess which ones?

That's the gist of it. At a first glance, this system may feel a little unfair, but rest assured, there is a balance to everything. You win some, you lose some and it's the same for your opponent. It's just another layer of complexity that gives you things to do, even during the quieter times. See you next time!

Inside Interplanetary: Cities, the Lifeblood of Planets

Looks like a utopia, but they're just resources of the war, really. 

Hi, My name is Sasu and I'm a game designer. Let's discuss some Interplanetary. 

Testing, testing, testing, not much interesting tidbits to tell about. The soundtrack is proceeding nicely and we have some awesome tunes ready for different phases of the game. We're posting the soundtrack bit by bit on our Youtube channel, so take a look if you're a fan of game music, and I know you are!

I can't believe we haven't thoroughly gone through today's subject yet. It's quite a big part of the game. I'm, of course, talking about...

The Cities

I'm sure some of you have been wondering, how exactly to win a match in Interplanetary. While the exact conditions can change around, the basic idea is to reduce your enemy's civilization to ruins. You do not need to destroy all life on the planet, or demolish every single structure; all it takes is to lower the Population of the enemy's cities enough to make them unproductive.

The Cities house the real life energy of the planet: the Population. The Population of the planet is responsible for generating many resources. One of the main features of Cities is their ability to produce Projects. Each city has a certain amount of Project Slots, depending on the amount of Population in them. You may then assign different Projects on the slots and, once again, the Population amount will dictate on how quickly they will be finished. Projects grant certain bonuses. Some are perpetually active, until removed, and others have a one-shot effect.

Blaablaablöpötiblöö.

If a City's Population is low enough, all its Project slots are lost and the city is deemed unproductive until it manages to grow back to its former glory. When all the cities are in an unproductive state, it's game over.

Of course, it is possible to completely wipe cities off the face of the planet, but that would require quite a lot of firepower. Still, sometimes it's better to play it safe; the opponent can, after all, try to help its cities regenerate by different means. There's no thrill like overkill.

The amount of Population in Cities can fluctuate wildly, depending on many things: a catastrophic event may suddenly kill millions, but new citizens do get born all the time. It is possible to encourage the growth in different ways. For example, keeping a City connected to the rest of the world and initiating Projects to boost the Morale of the populace are good ways to give some incentives to breed. Then again, if you're so inclined, why not just clone people? Might not be the best for the Morale, but it kind of gets the job done.

The amount of Project slots, in each city, is shown as a green life bar.

So, to devastate the enemy planet, you need to be ruthless and make the lives of the people as miserable as possible. Persistent attacks give them no time to recuperate and also wreak havoc on the Morale, which in turn affects many things from Production to Population Growth. Even Technologies get developed slower if there are no people to develop them.

There's quite a lot going on there and possibly worthy of a future post, but these are the basics. Just remember to take care of your cities! Don't litter, and so forth.

Game engine summer cleanup

Hello everyone, we thought we'd take the chance to give you a brief update on what has been going on with the game these past few weeks. :)

We finished the first version of  our internal alpha build just before the end of July. And while most of us went for a holiday Sasu bravely stayed behind to do some testing. We were still missing some features due to some technical difficulties and Sasu also found few bugs and some room for improvement.  So after we got back from our holidays the programmers have been focused on improving and fixing the underlying code structure before we continue adding any new or missing features.

Upon entering the alpha we first introduced some networking capabilites into the game, which ended up causing trouble with how things were wired before. Previously all the UI  elements were always intrested in who the 'active player' was, and with the addition of the networking there were suddenly two active players and that resulted in the UI acting like it had lost its mind. For example making both players research technologies in the same technology tree.

To fix this Jussi started making a UI Manager that handles all the different UI elements  more independently. This means that only the UI Manager will have the player reference and then give it to the smaller individual UI elements (resource system etc.) when they needed the information. This fixed a lot of issues with showing the right player's data, but it also meant bigger change to the whole game engine in how it handles the players.

This bug didn't actually have anything to do with the UI but it was still pretty freaky.

Another change came about from Sasu's notes from the testing he'd done. In the end of each turn,  the game displays the results of actions taken during the turn. This means, for instance, displaying the flight of any projectiles the players fired. But it might get rather tiresome watching the pretty pretty particles flickering on the screen for 5 seconds after every round, so we should give the player the option to skip watching this part of the turn.

This called for an overhaul of how the action phase worked. Previously the game displayed the movement of planets, projectiles and other game objects just as in any realtime game, calculating projectile trajectories on the fly. In networked multiplayer, the host's machine would sample object positions every now and then and send that data to all other clients to keep the displayed scenes on sync, and also send signals at events like a projectile hitting something and getting destroyed. All clients would see the scene played out at the same time, and it wasn't really possible for one player to skip ahead of others.

The new system we have implemented works in a manner where the host machine calculates the whole action phase and jots down its results before the action phase is visually displayed to any player. The results of these calculations, what projectile hit what and when and so on and so forth, are then sent to all clients. This way, the clients can independently control the flow of the display, without it affecting the results of other clients. Now a client can skip straight to the end of the phase and start playing their next turn, while others are still watching the fireworks at their own pace.

Onward we go!

The cleanup/ rework on the engine was finished today and starting on Monday we will be moving on to first adding the missing alpha features and continue from there.

Also, our friends over at Rust0 games had spotted a sweet deal on the Space graphics toolkit in the Unity's asset store (it's over now unfortunately) and hinted that we might be interested...

A sneaky peek of what you can do with the Space graphics toolkit. This hasn't been implemented in the game yet.

That's it again for today and see you again soon. :)

Post-Assembly disassembly

False advertising, we admit. The pizza was a lie.

Hello people of the Internet! We are sorry to have sneaked on vacation without announcing it properly, but we now are back, refreshed and running. This is Niklas, bringing you a few words on the process on Interplanetary and some more on my trip to the Assembly Summer '13 with the rest of the KAMK crew.

Before the well earned holiday we worked Interplanetary to the point where we could start working on in-team alpha testing. Some bugs and gameplay issues popped up immediately as usually happens with tests like this, so we will now focus on making things better. After that, it's time to start dragging in test users outside the team. If you're interested in being one of them, drop us a line and there's a good chance we will include you! Notice that unless you have a friend to play hotseat with, you may need a VPN client and end up playing against one of us.

This is what it's all about to many of us.

Now then, Assembly Summer '13. I will take the liberty to write from more personal perspective as I was the only member of TJR to travel this time. We originally intended to bring a two-man strike team, but Jukka succumbed to a nasty stomach bug prior the trip. But I still had a chance to take part, thanks to the very generous people at KAMK. The event itself was of course awesome as always, but this time I didn't quite manage to get the best out of it.

Here's what lacked, so you can do better!

We did not enter the game compo. This was a decision we made pretty early on. Interplanetary is not the sort of game that fits very well in a compo like this. It takes at least half an hour to really get into the game, and that's simply too long, we thought. However, games are presented to the audience in a game trailer form, which would have been doable for us and the compo is really good publicity. M.A.D, a KAMK game we had running at the stand got a lot of attention, and many people mentioned they had found it through the compo.

We did not bring a game demo with us. This is something we actually planned on doing. The demo wouldn't have been exactly Interplanetary, but instead a modified version of the early proof-of-concept version you can download from right there on the right hand side. We planned on having the game run on a touch screen we had on the stand and have people compete for small prizes. The modifications didn't make it in time though, as we prioritized finishing the alpha. In hindsight, the demo version would've been a better choice.

We did not direct our marketing to the players. I was seeking out professional contacts as usual, even though there weren't many around. This is something we should have considered earlier: Assembly might be one of the best places to reach the target audience directly when you are making a game for fairly hard core PC audience.

We didn't prepare well enough. The event was too fast upon us, and we had decided some time ago to have our vacation right before the trip. Because of simple mistakes like this, we didn't have enough time to think through what would be our goals, prepare marketing material etc.

I neglected social media. Like mentioned in the guide I made earlier, events like these provide excellent content for social media, and it's also a good chance to communicate with people who are either present or just interested in what's going on on site. Unlike Nordic Game Conference and Free Your Play, this time there really wasn't  a good reason behind as we had both working wifi and native 3G to work with.

I brought those awful shoes I had at NGC again. Ouch.

Nevertheless I still consider the Assembly trip well worth the time. I met new people and got to spend good time with some fellow nerdy people. Next year TJR will be there again in one form or another, and we will make the best out of it. See you there!

No matter what the locals say, Pasila can be quite pretty. Next year again!

Inside Interplanetary: The Music

Sasu, here! The HQ of Team Jolly Roger has been quite busy recently. Closed alpha testing is supposed to start very soon and here we are, still implementing some features! I hope we can keep up with our secret timetable.

It's been very nice to hear people reacting positively to Interplanetary. We were pretty surprised to see it featured on a Japanese entertainment blog, Damonge News! Well, it's not like we mind negative reactions either; they can offer some interesting viewpoints. So comment, praise, criticize, whatever you feel like! We might even draft the most enthusiastic people for the alpha testing.

This time, the main subject of this blog post is something that's still very much a work-in-progress:

The Music of Interplanetary

We've been struggling with the music for some time. Everyone has been very busy in actually making the game playable, so inevitably, things that give the game flavor, such as music, have sometimes ended up taking the back seat.

Music in games is, however, a very important feature. It creates the mood, keeps things dynamic and can even guide the player. In Interplanetary, we need music mainly to give the player some kind of pace: different game states, such as building and action, will have their own kinds of music, showing player their progression and making the whole experience much more powerful. As important as good gameplay is, the feelings a game gives to the player, can be considered equally important.

We managed to grab a musician, Vince Parrish, to help us with the music creation. The problem was, we didn't have a clear consensus among the team on the exact feelings Interplanetary should give to the players. The way we decided to go about with this, was to create a short teaser trailer to get a sense of the atmosphere of Interplanetary. Vince was given only vague instructions, in addition to a mock-up teaser, so he had lots of freedoms with creating the music.

Listen here!

Vince's music hit exactly the right notes, but there was disagreement with the actual feeling of the music. This wasn't surprising, considering the lack of collaboration. At this point, we begun to discuss the music more. We changed things around slightly, and managed to create a somewhat satisfying teaser for Nordic Game.

As we explained in the last blog post, we decided to redo the teaser drastically after the convention. This time, we planned exactly what we wanted the teaser to communicate. We finished the video completely, with final graphics, and then started to draw an exact idea on what we wanted the music to sound like.

Within the team, we collected reference music to send to Vince. While going through Youtube, looking for ideas, we came across the soundtrack of Inglourious Basterds.



This gave us an idea. What if the music was very serious and warlike, but in an old-fashioned way? Interplanetary itself is a bit of a mishmash: traditional gameplay combines to create something new and realism collides with the kind of a ridiculous idea of interplanetary artillery war. The music could be old fashioned, but mixed with modern instruments. It could also be so serious that it can turn a bit humorous.

The new music was soon mixed and it fit the teaser perfectly.



With the teaser to guide us, we've started to produce music for the actual game. It'll be stylistically similar and fit the gameplay situations. We haven't yet decided if the music will change a lot dynamically; it would be really cool if it would fit the actions perfectly when the missiles fly towards the warring planets, but this would be difficult to do properly. Time will tell.

I hope this was an interesting look at our process. See you next time, and meanwhile, enjoy this unfinished concept piece of Planet Building music!

Listen here!

Inside Interplanetary: Weapon Types

Game design guy Sasu, here with another post detailing Interplanetary's progress and game mechanics. Alpha is coming along nicely, even though the graphics might not show that big of an advancement. The weapon types have been basically implemented and just need to be fiddled with. A lot. This feels like a nice point to segue into the subject of this blog post:

The Weapons of Interplanetary

This time, we'll expand on our last time's subject of Targeting by taking a look at different weapon types and their targeting features.

There are three main weapon types: railguns, missiles and beams.

Railgun

Railguns are simple weapons, meant to overwhelm the enemy, but they're not exactly known for being accurate. They don't use a huge amount of Power, so it's usually possible to fire many of them in one turn.

Stupid gas planet, messing up a great shot.

The targeting of a railgun is very simple: choose the weapon and select the trajectory. It is, however, very difficult to hit an exact spot on the enemy planet, even with the possibility to put markers on the enemy planet in Intelligence View. Sometimes, it can be quite difficult to even hit the enemy planet, due to gravitational pull's strong effect on railgun slugs.

Missile

Whereas railguns have a bit of a luck element in them, missiles are designed to be accurate. They are not as much affected by their surroundings and it is much easier to hit specific targets with them. Missiles are a bit of power hogs, though.

The targeting of missiles actually consists of two phases. In the first phase, the camera zooms in to the enemy planet and you can get a proper look of its surface. This is basically the Intelligence View. In this view, you'll be able to click anywhere on the planet to set a target. After choosing your target, you enter the second phase, similar to railgun targeting. Now you can set the trajectory and try to hit as close to the marked spot as possible.

You can even target the opposite side of the enemy planet.

So, you've set the trajectory and also an exact target on the enemy building. As long as you manage to shoot your missile close enough to the enemy planet, it will enter its orbit. While there, the missile will travel towards the target point on the planet's surface. The longer the time spent on the orbit, the greater the chance that it will get shot down by defense guns or other hazards. This means you should try to aim as close to the target as possible.

Beam

Beams differ from other weapons in that the gravity doesn't affect them one bit. Their trajectory is always a straight line. Depending on the situation, the enemy planet can be very easy to hit, or simply impossible, because of obstacles in the way or beam weapons placed on the wrong side of the planet.

Beams also have a two phase targeting: once you set the trajectory, you can specify the exact spot the beam hits. The choice of targets is much smaller than with the missile, since you may only target one side of the planet. In optimal conditions, this makes beams the most accurate weapons by far. Unfortunately, their attack power is fairly low.

Everything's in the way!

The weapons in Interplanetary will be based on these three types. Some will have radically different stats and some will have added effects, but the basic concepts are still the same. There will also be slight tweaks to this system in the future, but the idea stays. Hopefully, this has been enlightening. See you next time!

Inside Interplanetary: Targeting System

It does look a bit better than last time.

Hello, people! Game Designer Sasu here again, chronicling our progress on Interplanetary. We are still working on the alpha test version, at the moment. The game is getting prettier and the implementation of many core features, such as placement of structures and targeting, is well on its way! It will probably still be a couple of months until we can send the alpha around for testing, but rest assured that progress is happening. Maybe we'll be able to release some interesting new material, our graphics master Jukka has been working on, soon.

Today, I'd like to go into detail about one of the major game mechanics of Interplanetary. Ladies and gentlemen, may I present the heart and soul of the game: The Targeting System!

The Secrets of  the Targeting System

As you may have noticed at this point, Interplanetary is all about damaging your enemy and keeping yourself safe, using simple base game mechanics that will, hopefully, allow for a lot of strategic depth. The Targeting System allows you to target the cannons you've assembled during the Build Phase.

The Targeting Phase starts as you first choose which gun to target. Its placement on your planet's surface will determine the angle of targeting; it will be somewhat difficult to hit the enemy planet if your weapon happens to be on the wrong side of your planet. It's not impossible, however, since many things in the planetary system will affect the trajectory of the slug. All the planets, and most notably the sun, have a gravitational pull that you can use to your advantage. They can also completely mess up your targeting, unless you're careful.

This is a pretty good curve...

Now that you've picked a weapon, a curve, representing the final trajectory, will appear. By moving your mouse, you can manipulate the curve to make the trajectory to your liking; a good idea is to try and make the slug follow the enemy planet's orbit. Once you've found a trajectory that pleases you, hit the left mouse button and target your next weapon. When you and your opponent have both chosen your targets and ended your turns, the weapons fire automatically.

One more thing to pay attention to is the movement of the planets: once the weapons fire, time unfreezes and the planetary system comes alive. The planets start to orbit the sun and rotate on their axes. You just need to learn to take that into account and aim accordingly, but you can also use a slider to simulate the passage of time while targeting, and even choose when each individual weapon will fire.

...this is not.

When the weapons fire, the slugs follow their predicted trajectories, taking into account the changes in the planetary system. You can only hope you hit the enemy planet and not the other ones, especially your own, or that your missile won't end up drifting endlessly in outer space.

These are the basics of targeting. There's a lot more to it, of course. With the basic system, it's very difficult to, for example, pick a specific target from the enemy planet or just generally to cause a lot of damage. That's why you will be able to use different weapon types with different targeting features. Details on that will have to wait until another time!

Free Your Play 13, thanks Supercell!

At this point we realized the event was a bit bigger than we had expected.

Hello again! Finnish Midsummer festivities made us drop out of our regular blogging schedule, but we're back now with a little description of the excellent Free Your Play-event.

We had a chance to travel with unusually large portion of our team this time. Supercell was generous enough to provide four of us with tickets, and that's everyone who applied. We considered the possibility of traveling by train, but eventually decided a road trip would be the way to go, and that turned out beautifully.

The crowd gathers and the event is about to start.

The event started in the early afternoon, so we had plenty of time to check out, eat breakfast and even do a little bit of shopping before heading to the event site at tapahtumakeskus Telakka. There was even a free buss transportation from Kiasma, which made things a little bit easier for us non-locals.

Ben Cousins, about to present his theory on the future of gaming.

The official program of Free Your Play consisted of a couple of keynotes, interviews and a panel discussion. A recording of the program is available as a webcast here, but feel free to take a look at my nutshell'd version.

Sadly Peter Molyneux couldn't make it to the event, but Ben Cousins covered his former boss very well with his own presentation.  In short, Ben introduced us the idea that game industry seems to be following the cyclic pattern of disruptive innovation, and it helps us to predict the future direction of development. 

After Ben Cousins we had a chance to listen to an interview of Daisuke Yamamoto from GungHo, the creators of tremendously successful Puzzle & Dragons. Turns out GungHo does many things in a more traditional way and even by the feel instead of collecting metrics and trusting them blindly. 

The next part was a panel talk with some hot names working with F2P model, like Lassi Leppinen (Producer of Clash of Clans), Tom Putzki (Director of Communications, Wargaming.net), Tommy Palm (King.com) and Daisuke Yamamoto as previously mentioned. There was way too much good stuff to cover in this blog post, but the general feeling seemed to be full of anticipation and there's still a lot more room for growth for F2P as a monetization model. Is it going to be the only one in the future? Probably not.

Official program is over, time to mingle!

As usual, the most important part of the event started when the official program ended. The guys at Supercell seem to know this very well, and they provided a very good environment for socializing. The food was good, the bands were great and yes, there were free drinks. Again we had the opportunity to meet a great number of interesting people and make new connections. 

It appears that the event website is not accessible anymore, but in addition to the webcast linked above, there is more info and pictures available at the Free Your Play event page at Facebook. Once again thanks to Supercell for hosting this awesome event. Let's hope we can be there next year as well!

Meet the Team!

Have you ever wondered: "Who are these people?" and "Why are these people?" We have taken this opportunity to introduce Team Jolly Roger, the makers of Interplanetary! Step on in, if you care.

Niklas Saari, team lead

Favourite Game: Cave Story

Special Skills: Turning otherwise useless information and cat videos into inspiration and game ideas.

Niklas is the guy tasked with the job of keeping the TJR machine rolling as smooth as possible. Sometimes this means wrench work and pirate language, but usually lubricating the gears with coffee is enough.

Antti Tikkakoski, programmer

Favourite Game: Deus Ex

Special Skills: Cynical person

Single-player hardcore PC gamer. Never have, never will buy a game console (will accept gifts to tinker with, however.) Also likes Sci-Fi stuff.

Jussi Hyttinen, programmer

Favorite Game(s): Final Fantasy VII / Silent Hill 2

Special Skills: Vivid daydreaming and remarkable skill to forget everything that doesn't relate to gaming

Jussi is a UI programmer and really enjoys listening to game music. Usually he sits quietly in his not-so-philosophical thoughts and scans his surroundings for things that don't belong there...

Jukka Kivijärvi, game artist

Favorite Game: Changing by the month, currently, Kerbal Space Program

Special Skills: Jumping from one thing to the other, learning it as he goes.

Jukka is our artist working on whatever the situation calls for, from concepts, textures and 3D to the occasional graphic design tasks. Usually wears headphones when working, but forgets to put any music on.

Tarita Tammela, game artist

Favorite Game: Baldur's Gate

Special Skills: Overthinking, turning into a bookworm on full moon

Tarita is still waiting for her letter from the local school of witchcraft and wizardry. She also practices her ninja skills when around people she doesn't know well. Has a silly pet name. Also has made a pact with a golden dragon.

Teemu Tammela, programmer

Favorite Game(s): Dark Souls, Ace Attorney series

Special Skills: Surreal logic, catlike curiosity

Teemu has been gaming since the age of two. He loves puzzles, including code debugging and creating game wizardry with the power of math and imagination.

Olli Leinonen, programmer

Favorite Game: Avoid Writing Your Profile Info

Special Skills: Not writing his own profiles, numerous club memberships

Olli is a member of the Team Jolly Roger Code Wizards-gang, the spiritual leader of the I-Don’t-Feel-Like-Writing-About-Myself – cult and a frequent member of the quite popular in TJR “Facial Hair Appreciators” club.

Valeriya Paykacheva, marketing idler

Favorite Game: Katamari Damacy

Special Skills: Being amazing, complementing herself, pronouncing her last name correctly

Valeriya is our absolutely fantastic marketing contributor, who enjoys spending her time with boring and tiring people with continuous eager talks about movies, rocking Trivial Pursuit and not caring about Olympic Games. Has never been bitten by a shark.

Sasu Kemppainen, game designer

Favorite Game: Grim Fandango

Special skills: Great at making pizza and eating it

Sasu is our designer extraordinaire, who enjoys talking about Star Wars, playing stupid games and eating bread whenever possible. Determined to either design a genius game or to become a blitzball someday.

Riku Leinonen, code monkey

Favourite Games: Phoenix Wright - Ace Attorney

Special Skills: Breaking the repository, playing Super Mario eyes closed.

Code monkey likes tea and Dr. Pepper

Code monkey likes immersion and emergent gameplay

Code monkey very simple man

With a taste for silly hats



Maybe it was a bad idea to let people write about themselves?