Interplanetary Arrives to Steam Early Access This Friday!

Surprise! It's finally time to move to the next level: the Steam Early Access version of Interplanetary will be released April 18th, which is this Friday!

We decided that going Early Access was a natural continuation of Interplanetary's journey, as we've already had close collaboration with its players during development. By continuing on to Steam, we'll be able to reach a much wider audience than ever before, which helps the development a huge amount.

Like usual, buying the Early Access version at a reduced price will also give you all the future updates until the game is finished and you'll be able to better influence the direction of the game through your feedback.

New Features

For the Early Access release, we've prepared an exciting new feature: Superweapons. These are unlockable through the Tech Tree and will wreak serious havoc with your enemy's planet.

This planet's going to have a bad time.

Currently, we've implemented two superweapons:

• Asteroid Diversion
• Diverts a group of asteroids towards the enemy planet, causing massive damage. Works similarly to the railgun, except that the starting point is the asteroid field at the edge of the planetary system and you'll be shooting a cluster of space boulders instead of one small shot.
• Solar Laser
• An accurate and powerful weapon, the Solar Laser is fired from it's own orbit close to the sun. Unlike with normal lasers, it can shoot to any direction, unless there are other celestial objects blocking its line of sight.

These weapons are pretty devastating, so make sure you get them before your opponent does!

In addition to superweapons, we've been doing a lot of smaller updates all across the board. Some of the major ones include the ability to have hotseat matches with up to 4 players and many graphical and UI-fixes. There are also plenty of balance adjustments, so make sure to weigh in with your opinions.

Time to get hyped!

Hop onto www.interplanetarygame.com and join our mailing list for timely updates.

Inside Interplanetary: Releasing a Public Alpha

Netcode! What have you done to my planet!?

Good evening, friends! Game Design Sasu, here! We're gearing up for a new alpha update, at the moment. It's looking quite nice, but there are still many interesting bugs to weed out. In addition to that, there seem to be multiple kinds of flu hanging around the TJR ecosystem. We're falling one by one!

In the meantime, I thought I could write something helpful for fellow indie devs. I already talked about this before on our IndieDB forums, but it was deemed useful enough to dedicate a blog post to it.

Today I'm going to talk about our experiences with giving out test versions of Interplanetary.

Preparation

There really is no substitute for a proper user testing. Everyone will eventually grow blind to the problems with their game, so fresh people are needed to give some perspective. We had had a couple of small testing sessions with our friends and relatives, but we needed more and variable data. Reaching out to gamers of the Internet was the answer.

Before sending out your alpha to the masses, consider why you want to do that. Do you need testers, publicity or just people to play your game with you? Our main priority was to get useful feedback, so we took that into account when building the testable version.

We had to make sure to give the testers the features we wanted them to test. The targeting system especially was something we wanted to get a lot of feedback on. This also meant that some of the more irrelevant features would need to be polished not to drag too much attention to them, or simply left out altogether. We didn't want people to just comment: "the planet graphics suck" and leave. When giving feedback, it's easy to grab into the most obvious thing and ignore the others.

Seriously, try to iron out the distractions.

To gather the feedback, we created a survey with SurveyMonkey and put a link to it in-game. Looking back on it, we should've also given the link to each tester when contacting them for the first time - surprisingly many missed the in-game survey link and later asked how to provide feedback.

When creating a survey, it's important to think of the right questions to ask; most people won't bother writing out their life stories. You need to make the survey very easy and to the point. Try to add some very specific questions to steer the testers to concentrate on things you need comments on. The current version of our survey works well enough. People have a chance to comment on many different things, but they aren't forced to fill out every space to submit.

This system worked well until we reached over 100 answers. The free version won't show more than that, so we needed to pay a fee to access the rest.

Distribution

How to actually go about distributing the alpha version to the testers depends on many things. Interplanetary's first alpha version was a very incomplete game, filled with all kinds of issues. To say that we were hesitant putting it out there would be putting it mildly. Ease of access is the key of getting people to test a game which doesn't have an established reputation, but we still decided against simply sharing download links or using the Unity Web Player (doesn't really work out in Interplanetary's case anyway.)

This is when the idea of alpha keys came along. We would announce the alpha testing and ask hopeful testers to contact us to receive a code they can use at our website for a download link. This way there was less room for misconceptions, as we could explain to each individual tester the situation with the game. No one would just stumble across it, thinking it was the final product. We could also draw out the more serious testers; even if the process of obtaining the code is rather painless it's still a step that gets us into contact with the people most interested in the game.

For convenience, we mostly used our Twitter and Facebook to share the codes. We could then use these networks to easily communicate with the testers afterwards.

We also made code cards for live events. Spent some fun nights sticking codes on them.

The whole "system" worked manually: a person would contact us, ask for a code and we would give it to them along with instructions. An automatic system of some kind might have saved a lot of time, but I personally prefer direct contact, so it's easier to answer to questions and such. There was a period when I really wished we had a robot for this, though: the day we were noticed by RockPaperShotgun was absolutely insane! I had to spend days answering all the code requests we were getting.

Once Interplanetary landed to Steam Greenlight, we changed the system a little bit. Partially for the convenience for the users and partially for my sanity, we decided to build a special Greenlight Alpha with a direct link to it on the page. This version was less experimental than the earlier ones and the aim was to make it also work as a sort of a very early demo; a tight package with the main features polished well enough. Being in Greenlight, people would also more easily understand that it's an incomplete version. A playable version, along with screenshots, videos and description, worked well to give people a full idea on what the game was to be and also show that Interplanetary is not a mere concept. Never underestimate the power of screenshots and videos, though: no one would have bothered to download the alpha, even if it's completely free, if we hadn't given them a peek to get them interested first.

A certain website even took the Greenlight Alpha without asking and ported it for Wondows.

As of today, the PC version has been downloaded from the Greenlight page 3,513 times and the Mac version 225 times. We received 34,251 "Yes"-votes during the campaign, so not nearly everyone found their way to the download link, which is probably partially because we couldn't place the link in the main description by the way Greenlight works. We had to make a separate news announcement on the page, but they are not particularly eye catching. We should've pointed this out in the main description.

For the Greenlight Alpha, we opted to use Mediafire to host the game files. Considering the popularity of Interplanetary's Greenlight campaign, this was a good decision: having to pay about 20 cents a download on our server, would've cost us a lot. The only drawback here was that the URL pointed to Mediafire, which isn't quite as "cool" as hosting the files on your very own space. We paid for the service, however, so the link was direct and there was minimum hassle for the players.

External file hosting sometimes makes you evil.

We were and are still giving out alpha codes to people, since the Greenlight Alpha was the only version distributed by a direct link. The latter updates would require a code. This seemed to work quite well and caused relatively little confusion.

Conclusion

I can really recommend using an alpha code system for everyone. We've received tons of good comments and followers because of it. Semi-regularly updating the alpha version also gives you nice mile stones for development. It can sometimes be quite a chore to handle the code requests, but typically the flow is steady enough to manage. We still get a couple of  inquiries every day, but whenever there's media coverage or something else, the amount skyrockets.

Starting to run out of codes real soon, actually, so give us a holler and we'll get you yours! There's at least one more alpha update on the horizon, so expect that!

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!

Greenlight for Interplanetary! (Also New Trailer)

With a new trailer, Interplanetary has now been submitted to Steam Greenlight!

If you would like to see the game on Steam, go give us a vote! We would truly appreciate it.

On our Greenlight-page, there is an open link to a playable Greenlight alpha version. No codes necessary this time! This is kind of an evaluation version for people who want to give Interplanetary a try. Testers with alpha keys may still get updates to the alpha as they come, but the open version stays as it is.

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?

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.

Inside Interplanetary: The Resources: The Material: The Movie

Don't worry, it's just steam. Black, smelly steam.

Yo, everyone! Game Design fellow Sasu is back in action, currently testing the newest build of Interplanetary. Some key features are still missing; it's a little bit difficult to enjoy the game when buildings and cities don't even have life bars, but the game is otherwise quite playable already. Add in a couple of features and balance, balance, balance!

Today we shall delve into a central system, that isn't completely implemented in the game at this point. As such, many of the terms used will probably differ in the final game and the system itself will evolve. In spite of that, let's take a look at the basics of...

The Resources of Interplanetary: Material

We've already mentioned some things about Interplanetary's resources in these posts. There are quite a few, such as Production, Science and Power, but one of the most important ones, for you to keep your eye on, is Material.

Material represents everything, well, material that you need to build structures: concrete, rebar, currency, whatever. It's all lumped under the moniker of Material for your convenience! Along with Power, a bar showing the available Material is always shown to the player; these are the two things that need constant attention when developing your planet.

All those railguns ain't cheap.

As we've explained before, many actions in the game cost Power, the amount of which is recalculated, according to the amount of Power Plants, at the beginning of each turn. Material, however, works more like normal currency, meaning it can easily be depleted, if you consume more than you produce.

The game begins with a set amount of Material for each player, but it won't last for very long. A savvy player will construct a couple of Mines to keep their stocks full. A normal Mine yields a small amount of Material each turn, but they can be upgraded to be more efficient.

The Material doesn't just appear from thin air, though: each planet has a set amount of it, and once it's gone, it's time to start thinking about alternative means of sustaining your development. The planet's Material is divided into three parts: Normal, Aquatic and Deep. The type doesn't matter when building structures, but each of them is acquired in a slightly different way. Most of the planet's Material is Normal and is mined by Normal Mines. Aquatic Material is mined with Underwater Mines and Deep Material is gained by upgrading Normal Mines with Deep Mining capabilities.

Planet Material is like a pizza: tasty and crunchy and I'm hungry.

Initially, all Mines work quite inefficiently and a lot of the mined Material will go to waste in the process to convert it to usable resources. This can be remedied with upgrades, however.

Interplanetary warfare can take a heavy toll on the resources, and you will inevitably run out of Material at some point. When the final drop is consumed, it's time to look to the skies and attempt to colonize a nearby planet. To colonize a planet, you use your interplanetary weapons to shoot Colonization Probes, which in turn will set up a small colony on the planet they land on. The colony is able to, among other things, mine Material and send it back to the home planet.

Long matches may very well end with almost the whole planetary system dry of usable Material. Insert commentary on unsustainable development and the irony of war here.

Hopefully, a complete image on how to play Interplanetary is beginning to form for everyone. We'll be back another time with more tidbits and such. See ya!

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!

Being a tease(r)

Hello, Jukka here. This time I’ll explain a bit about process of creating a teaser and why we even wanted to have a teaser.

We are currently working our way towards alpha. With each step in development, we are also trying to reach more audience. As a young and still pretty much unknown dev team, we need to employ as many means as possible to make Interplanetary and ourselves known out there, unless we want to count everything on people finding us through Steam Greenlight. This is not that reliable strategy because of the sheer amount of other games that go there. Trailers are of course very, very widely used in games and movies, so a we knew we’d be making at least one at some point.

The  Nordic Games Conference was looming in the horizon when we decided on making a teaser, which we could show around. Though some of us aren’t exactly fans of teasers, since the information they give usually isn’t much and doesn't even necessarily include actual gameplay... But, as the name suggest, it’s supposed to tease the viewer to see if we manage to pique their interest or at least when they bump into it in the future, they’d recognize us or the game. Also it’s short, so it’s quite easy to show it around to people in person.

The Idea

So by the time we first wanted to have the teaser we had something of a playable prototype, but its purpose was to test some of the game mechanics and most of all, familiarize the crew with Unity. So it wasn't really something we wanted to feature on a video. Instead we decided to focus on artwork and try to tell something about the setting and the mood of the game.


Romeo & Juliet

So we sat down to think up ideas... And then pretty much jumped the first train which felt interesting: The prologue of Romeo & Juliet:

"Two planets, both alike in potency, In distant cosmos, where we lay our scene, From ancient greed break to a mutiny, Where great arms, shake the grounds apart."

So obviously, we made some modifications to it (here’s the original) and it was only the first few lines we wanted anyways. It kinda fitted and we hoped to get that “I see what you did there”-effect when someone would recognize the source material… We even got someone to record the lines in genuine British accent.

The pacing made it feel much longer than 30 seconds.

NGC

So comes the deadline along with Nordic Games Conference and the teaser is finished. We had planned to have the teaser running at the Kavio Cluster’s booth we shared with our fellow dev teams, but in the end, we didn't have a big display or sound, so Niklas showed it around on a tablet. After he got back we had “post-mortem” about the event and the feedback we got and concluded the teaser didn’t really do what we wanted… Turned out nobody really made the connection to Shakespeare and so it just felt like a poetic narration and the whole shooting-at-planets-thing didn't quite fit, even in any particularly funny way.

Revision

So when the first version of the teaser didn't work, we sat down again to come up with a new plan. We wanted to use the existing material as much as we could and still we wanted to tell something about the setting, so we came up with the idea of following a railgun shot as it flies through space, towards its target.

Execution

My main tools for the job were Photoshop, Blender, After Effects and Premiere. After Effects I hadn't used before and there’s still much to Blender and 3D-modeling for me to learn. For both versions I made a storyboard of some kind. For the first version, I animated some sketches and transitions in Photoshop. Although it gave a good idea on how things would look in the final product, I should have used more time on the sketches themselves. I ended up using more time on animating their movement than on the actual images. So for the second version I stuck with more traditional storyboard and instead put more thought on what I needed from the material that I would need to create still.

Storyboard for the second version 

It is still very rough so if it’s not you who’s doing the editing/material I suggest you put a bit more effort into making it clearer for outside viewers.

Images

I’m not yet a very fast artist, so I often find having to remind myself not to get stuck in one image for too long. I've been also watching the videos from FZD-school channel on Youtube, and one point that Feng Zhu often makes in his videos, is to keep in mind what is the selling point - the most important part of the image - and make sure that that part is well defined and presented.  So, since I didn't have the time I needed to go through the images and make everything detailed, I tried focused my efforts on just certain parts. This also made sense because a single image wouldn't be shown so long that the viewer could explore every part of it.

All the images used in the teasers. Only half ended up in the final version.

While working on the second version Tarita, our artist, suggested we add a bit more life to the images by adding some animation in them. I hadn't planned for this to start with, so it meant a little extra work, but we figured it was worth it. I went through each image sliced them to layers, adding some extra where I needed. Most of the animations I did in Photoshop, except the final image with the city and explosion. It had so many bits and pieces that After Effects was easier to work with than Photoshop CS4's pretty clunky animation system.

Will it Blend?

3D is not exactly my main proficiency, but thankfully, planets are not the hardest thing ever to model, although, if anyone knows a good way of avoiding texture distortion at the poles of a sphere in Blender, I’m all ears! There isn't much I can say about making the 3D material, except that rendering the it as separate images, and using After Effects to turn them into actual video, was a life saver. It was mostly due to me forgetting to adjust some setting or noticing something in the middle of an animation that I didn't like, but having to render the whole animation again would cost me so much time since my work computer cannot handle Blender rendering and working in Photoshop at the same time.

An added bonus was that I could render just the planet on a transparent background and add the background in premiere and adjust it however I wanted.


Music

Although we can find a way to do pretty much anything we want on our own, sometimes it’s just better and faster to rely on other professionals. And concerning the music, we were fortunate to come across Vince Parrish, who agreed on making the music for the teaser and even the game itself.


And that's it, the story of creating a teaser. After we reach the alpha, we are also planning on finally getting some gameplay footage out there. So, look forward to it!

First teaser trailer released!

Well, here it is finally! It turned out quite nice, and while there's no actual gameplay in there ,but the idea of the game is presented in a nice, artistic manner. We'll be rolling with more video updates in the coming weeks, so expect some funky alpha version gameplay stuff soon!

A big hand to our graphics guy Jukka and music maestro Vince for their work on the teaser!

Logos are not built in a day

Hello dear readers, it's Jukka here to serve you another post, this time on the subject of Interplanetary's logo and what went into the process of designing it.

Why do we need a logo?

The idea behind a logo is to provide people with something to recognize the product by. Having just a name for a product isn't quite enough, as there can be other things going with the same name (as long as it's not a similar product/entity etc).

A logo provides the name a unique and recognizable aesthetic. It's a building block of a brand. Brand is something that is born instantly, it's the sum of people’s thoughts and opinions of the matter at hand and those things can take time to form. A logo can give people something to base their thoughts and opinions on, when they first encounter a new brand and also a way to recognize it when they see it again somewhere.

Personally though, I feel that game logos don't need to be as thought out as traditional corporate logos and other product logos, as games have better ways of introducing themselves to new audiences, for instance trailers.

Design process

To start off, you need a name and, lucky us, we already had one. Both I and Tarita, our artist, started by sketching our own ideas.
The name “Interplanetary” was originally just a working title, but as it hadn't been used for a game yet and it did a good job in describing the game, we stuck with it (there's a scifi movie by the same name that came out in 2008).
I like to start logo designs by sketching straight in Illustrator. I combine shapes and use the pathfinder tools to cut out and merge them, looking for interesting results.

Some of the first sketches and their variants.

The world of scifi-themed logos is filled with planet shapes and crescent moons, blocky typography and carbon fiber textures. While I tried to come up with something a bit more original I also wanted to include the idea about shooting at planets... Which at first resulted in designs that mostly remind you of things you learn about animal reproduction in biology class. So in the end I made some compromises and didn't come up with the most original of designs, but rather ones I felt conveyed the idea best.

After a while we gathered up the sketches and chose four we liked most and put together a simple survey to ask for opinions and feedback from our friends in facebook. The survey provided us with good feedback and strengthened our own opinion on which design to choose.

The four candidates we chose for the survey.

After posting the survey I moved on to make a short teaser to show at the upcoming Nordic Game Conference, which ended up taking all my time. As a short time remedy we used a plain white version of the logo that was most favored. This way we had a logo, which would be pretty close to it's final form and most probably wouldn't change so much that it would be unrecognizable.

After the NGC, I postponed working on the logo for some time, while I concentrated on honing the teaser and its idea bit further. The teaser is still a work in progress, but I did finally take the time to put the finishing touches on the logo.

Final version of the logo.

And that sums it up. Hope to see again next time.

Inside Interplanetary: Turn structure

This is the game. All of it.

Welcome to another game design blog post. I'm Sasu and I'll be your host today and I promise that the topic today is much more interesting than it sounds. It's time to finally tell all you folks out there about Interplanetary's turn structure.

Interplanetary is a turn based strategy, so unsurprisingly, it consists of turns. The flow of these turns dictates the very basics of how the game is played and they can be neatly divided into three major phases: Build Phase, Targeting Phase and Action Phase.

Build Phase

During the Build Phase, your job is to manage your planet and devise your strategy. You can directly build your infrastructure, develop technologies and spy on your enemy. This phase is strongly reminiscent of the base building in most strategy games.

The placement of different buildings can have strong repercussions. How to keep up your Power Grid? How to protect your buildings? Should you spread them out over the whole planet or keep them together? The attack might come from anywhere.

I also promise that the graphics will be much nicer.

Depending on the power of your Intelligence structures, you can also take a peek at the enemy's planet and plan your upcoming attack accordingly. Be careful, though: if you're not equipped with adequate counterintelligence methods, your enemy may do the same to you. If you're careless with your building strategy, you can soon  expect to see some missiles, aimed directly at your weakest spots.

Then there's your Technology level. You must choose what technologies to concentrate on and what route to take on your technology tree. Unlocked technologies grant you bonuses and new projects that you can develop in your cities. All in all, there's a lot of room for strategy here.

Targeting Phase

While you can enter and exit Targeting Phase at any time, you'll probably be mostly going there after you're finished with your planet's maintenance.Once there, you may target all the weapons you have built at the enemy planet. That is, if you still have some Power left over from other things to actually fire each of them.

Aiming two lasers and one railgun. 

The amount of Intelligence points you've collected determines your ability to aim at the enemy. You can always try to shoot your cannons at the general direction of the enemy, but some weapons allow you to target specific structures on the surface of the planet. Of course, you have to be able to see them first, and that's one of the main points of Intelligence.

Action Phase

This is the payoff at the very end of the turn. When you click on the "End Turn"-button, the Action Phase commences. You see the overview of the planetary system and both yours and the enemy's aimed weapons launch at their targets. All you can do now is wait and enjoy the carnage.

Argh, the planets move!

After this, the next turn starts and you may start inspecting the damage and reacting accordingly. That's all, in a nutshell. Of course, there's a lot more to discuss about each phase and the little details, especially the exact workings of the targeting system. We've barely scratched the surface here, but hopefully everyone now has a proper idea about the very basic gameplay. See you next time!

Designing the Power Grid

Nuclear power is the safest power. Except for those few times.

Hello, hello, hello! Sasu here again, filling the space for our team leader Niklas, who's still on his Nordic Game trip. Hopefully, we'll see him back healthy next Monday. Adding to that, our programmers have been working hard on planning and design this week, so actual progress has been a bit slow. Soon, we'll be back on full gear!

Meanwhile, I've been coming up with different systems for the poor, unsuspecting coders to implement. This week's subject may become quite a dominating feature in the game; The Power Grid system is something to consider when developing your planet's infrastructure.

Power can be considered as your action points. Almost any action, from building to shooting your weapons, takes a bit of Power. The more Power all of your Plants generate, the more actions you may pull off each turn.

A picture and a thousand words

Structures can be built all over the planet, but the most efficient way of gathering Power is forming one, continuous Power Grid by building them close to each other. Every structure has some amount of Power Connectors: simpler ones have two, while others may have as many as four. When you've placed a new building on the planet, its Connectors attach to other nearby structures, if they are within range. As long as all the buildings are part of a grid with at least one Power Plant, they will function properly and stay online.

It is also possible to make several grids, not connected to each other, but there are some drawbacks to this strategy: the more Power Grids you have, the less efficiently you can actually use the Power generated by the Plants. You will receive less usable Power from two grids with two Power Plants each than one grid with only three Plants, for example. This gives the opponent an incentive to try and bomb your grids into pieces. After a massive attack, you may find your one big grid turned into three small ones and some structures orphaned and offline, without a Power Plant in their grid.

Now you're playing with power! This system is presently being tweaked, but the main idea should stay. It adds a nice layer of depth, especially when mixed with some other systems we're working on at the moment. You'll have to wait until some other time to hear about those.

Designing Tech & Research

When can I finally have a clone to call my own?

Hello, hello! I'm Sasu, a game designer on the most wonderful game, Interplanetary. Lately, I've been working on the technology tree and the progression of upgrades, which will be our subject this week.

One of the main themes of Interplanetary is the development of technology. Players start up with technologies that seem quite plausible to actually exist in a couple of years, but the further the game proceeds, the more incredible they become. Sufficiently advanced technology is indistinguishable from magic, but we still try to make it feel at least somewhat believable. No huge science fiction star fleets, just humble interplanetary space guns. 

In Interplanetary, players gain science points that are used to research new technologies. The generated points are counted towards technological progress at the beginning of each turn. Each technology needs a certain amount of science points. When the goal is reached, the technology is usable and new development options are opened. 

Original diagram, do not steal.

Projects are construction or development operations that take place in cities and span over several turns. Researching technologies not only grants various bonuses, but also opens up the possibility to develop certain projects. For example, the technology of “Quantum Paired Sensors and Communications” allows the player to detect incoming projectiles earlier and to build facilities for “Communications Shielding” and “Faster-Than-Light Communications”. 

All the technologies and projects have certain pre-requisites. You need to research “Particle Physics” before being able to research “High Power Particle Beams”, which in turn allows you to develop “Orbital Laser Defense”-project. Sometimes, a project must be completed to unlock new technologies. No “Orbital Manufacturing” without the help of a “Space Elevator”. 

Research enough technologies and you just might reach something amazing. We might add some wildcard mechanics to the tech tree so some of the more incredible tech may be hidden and only discovered accidentally. That is, after all, how science tends to proceed. Eureka!

Alrighty, that's enough nuggets for now. I can almost promise you that the details will change in some ways, so no frowny faces if they do, okay?

Inside Interplanetary: Cities, towns, colonies and buildings

Beautiful day in the city of Ars Konsepth. What could go wrong?

This time we have a couple of lines (read: wall of text) about the role and functionality of Cities, Towns, Colonies and Buildings in Interplanetary. Again there needs to be a disclaimer: Much of the design described here may change during development. If you have thoughts, ideas or even suggestions, feel free to share in the comments.

Cities are one of the key elements of Interplanetary: They hold majority of the planet's population and generate resources like Production and Science. Each city has 1-6 production slots for different Projects that  provide either one time bonuses, such as population growth boost, or permanent ones like Space Elevator. Permanent bonuses occupy the production slot they are built in.

Cities cannot be destroyed in a single turn, but if their population is reduced enough, they will turn into Towns. It's theoretically possible to destroy an enemy city by precision strikes across two turns by turning it into a town , but considerable amount of firepower is needed as Cities are quite resilient.

Towns could be described as placeholders for potential cities. They appear on the globe from the beginning, but cannot be interacted with directly. Towns hold some population just like Cities, and when the population grows large enough, the town becomes a City. Player can speed up the growth by protecting a city with a  defensive building or building other structures near it. Unlike cities, Towns can be destroyed.

Colonies come into play a bit later in the game. A sufficiently advanced civilization can develop a Project for colonizing another planet in the same planetary system. The main function of a colony is to provide precious material for the player, but Colonies also act as forward platforms for some useful Projects and upgrades that cannot be built elsewhere.

Buildings are megastructures that serve a single purpose like producing resources, defending Home Planet or gathering intelligence. Players can choose fairly freely where they place the buildings, as long as they are not built in water etc. However, placing a building has almost always a tactical side to it. For an example, building in tight clusters makes buildings more defensible, but also makes them vulnerable to splash damage. Some weapons require line of sight, so building them all around the globe might be a good idea as opposed to concentrating them on one side.

So that's the very basics, we may write in more detail about these mechanics later. Lets us know what you would like to read and we will do our best to deliver!

It's alive!

Good news everyone! TJR has awoken from its slumber of outsourcing and school related stuff. Now that we have also been reinforced with a band of new members, the team is stronger than ever.

First and foremost this means we have been able to finally resume the development of Interplanetary. The project was quietly moved to the notorious slow lane at first last spring and ultimately shelved for a couple of months. This was not something we wanted to do, but by switching to outsourcing for a while we managed to ensure steady supply of ramen while having some time to focus on the remaining school related things and smaller projects. Some of us even managed to graduate while we were flying under the radar, so, success!

Interplanetary has evolved quite a bit when we paid less attention to it; the game is now 3D and based on Unity engine instead of the slowly fading XNA. This should allow us to make the game even more beautiful than we originally planned with the option to go multiplatform with relative ease. Here's a bit of a sneak peek to a description we wrote for the upcoming Kavio cluster website. If you are all "what the heck is Interplanetary??" at this point, this should get you on track of things:

Interplanetary is a turn based strategy game about warfare between two planets. Setting of the game is a fictional planetary system where two planets have evolved intelligent life and ultimately become planetary civilizations. These two planets have fallen into a conflict for the natural resources of the planetary system they share. 

Technology level in the game is not too far from ours, and instead of stereotypical sci-fi starfleets, war is waged with massive, planetary weapons and other megastructures, built right onto the home planet. As the game progresses, technological advances allow more and more options to protect your people and defeat the enemy.

Main part of the game is managing the limited natural resources of player's home planet, developing its infrastructure and researching new technology. Each turn ends with action phase where player gets to target the weapon systems at the enemy planet and unleash his military might. The game supports various different tactics from a planetary broadside of railgun slugs to few, but deadly precise strikes of interplanetary lasers.

If you enjoy games with similar elements, like DEFCON, Civilization series or even the old artillery games, we will definitely have a game for you! Interplanetary will be available in most digital distribution channels.

While actual gameplay screenshots still have to wait a bit, we are proud to present some concept art. Stay tuned, there will be more to follow regularly now that we're back in business.

When highscores go global

We have plunged head first into the world of databases and online functionality lately, and while those unlock the possibility to do some neat stuff, there are tons of things below the surface to consider. Data security first and foremost obviously, but what else?

We have been thinking a lot about how people use Internet on their mobile devices. Are they usually on WiFi? What kind of data plan does an average user have? How much data is it ok to transfer each time we, say, download highscore? This article gave us some perspective on the US market, which could be considered our main market area, but we still need to find out how things work in mainland Europe or Russia, both of which are also important to us.

So as much as we would want to see our new shiny database filled with entries, we politely ask the user if they would like to have just an offline highscore funtionality instead.

So this is what we go with right now:

Last week we finalized our newest addition to WP7 catalogue, which should be though the  certification process this week with any luck. More on that later!