Interplanetary Whack-a-Dev Days and Update Info

Hey, everyone! Having fun with Interplanetary?

Since the game is currently multiplayer only, it needs a strong community to stay alive and well. To help bring all the players together, we've planned something we hope everyone is happy to take part in.

Interplanetary Whack-a-Dev Day!

Fanfare! Starting this Saturday at 3:00pm GMT, we're kicking off the first Interplanetary Whack-a-Dev Day. We're planning on making this a semi-regular event, timing it with new updates to the game. Here's what we have planned for this Saturday:

• Whack the devs!
• Team Jolly Roger will be hosting games of Interplanetary! If you have a beef with any of the devs, now's the time to get out there and break their planets!
• Steam Key giveaways!
• We'll be tweeting Steam Keys for Interplanetary every time someone manages to beat one of us!
• Screenshot Competition!
• Share screenshots to Interplanetary's community hub, with the text "Whack-a-Dev" in their description. The one with the highest voted screenshot at the end of the day wins a little prize.
• Streaming!
• Enter Elysium and Rushlock will be joining us this Saturday to stream some of their matches. You can either join the streams to spectate or play the game and get the chance to appear there yourself.

With screenshots like this, we have high hopes for the competition!

In Other News: Patches and Updates

As you may have noticed, we released an online connectivity patch for Interplanetary this Tuesday. If you previously had some problems connecting to other players, they should hopefully be fixed now. Here's a proper changelog of the major things in the patch:

Interplanetary Version 0.0.3922

• Online connections more stable 
• UPnP settings added 
• Port selection option added
• Passwords added to online games 
• Defeated players' orbits are now greyed out 
• Minor fixes to the tutorial

We're also planning on giving Interplanetary a proper feature update this Friday. Among the features we're hoping to add is in-game chat, a popular request by the players. 

Hopefully, we can finish implementing the chat until Friday so you can also bash us devs verbally, if you want! Hopefully, you don't want to.

Interplanetary Alpha Update: New Features

It's finally here: a huge alpha update, full of interesting new features and fixes to test drive! Might also be the final alpha update that will be available with a code, if there are no massive issues with it. We're steadily rolling out towards the beta version and we have something different in store for that.

Anyways, here's a little list of all the major features in this one:

• Intel Mechanics
• You now need to build Intelligence structures to be able to see your enemy's structures; however it's also possible to hide your activity by building counter intelligence structures.
• Tech Tree
• An experimental, simplified tech tree lets you unlock buildings and gain additional bonuses.
• Construction Yards
• Structures are now functional only the turn after they're placed on the map.
• Ruins
• Destroyed buildings leave behind ruins
• Networking Fixes
• Better stability for matches with more than two players

Full change list available here.

Unfortunately, online play still doesn't work properly for people using a mobile connection, but we're working on fixing that for later. 

The update can be downloaded for Windows, Mac or Linux from interplanetarygame.com using the alpha code. If you don't have a code, you can ping us at Facebook or Twitter and we'll get you one. 

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 Wiki Launch and Networking Fixes

Like a bolt out of the blue, it's Interplanetary Wiki! Curse has been gracious enough to offer us a space on their Gamepedia and now we have our very own space for all knowledge on Interplanetary. Being a wiki, anyone can add to it and they should! So to all you wiki enthusiasts: go have a field day! Just keep in mind the usual rules of conduct.

Can't wait to see what kind of things will start popping up there! Of course, we may join in periodically to add in some super secret information...

What about the Game?

While the wiki is a pretty awesome thing, I'm sure you're curious about how Interplanetary is progressing. We are still planning on rolling out with an alpha update within the coming weeks and we haven't forgotten about you Linux users either! I'd say that the big thing causing us trouble, at the moment, is networking.

A common problem reported to us has been the non-functional "Start Game"-button in the Online Lobby. We've found the problem, and while the fix hasn't been implemented, it is possible to work around it by restarting your computer and trying again. The problem is connected to the way the game chooses a random port to use in the online game, and if the port isn't free, the game won't start. By restarting your computer, the game chooses a new, hopefully free port.

Frustration!

We were actually working on updating the alpha over a month ago, but while adding the new features, we noticed that our online game just didn't support them well enough. Back to the drawing board, then! For now, we're working on adding support for the upcoming features, in addition to fixing some of the other things. As some of you may have noticed, Defenses aren't very reliable in online games; this is not by design!

Other things that we're fixing include the addition of host migration, accurate victory screens and better data synchronization between players.

It's been a doozy, but solving the issues with networking will surely make things easier for everyone. Expect an update in the coming weeks, but be patient! There's still a lot to work out.

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: 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: 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!

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!

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.