June 28, 2013

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.

June 26, 2013

Free Your Play 13, thanks Supercell!


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

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

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

The crowd gathers and the event is about to start.

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

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

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

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

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

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

Official program is over, time to mingle!

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

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


June 14, 2013

Meet the Team!

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

Niklas Saari, team lead
Favourite Game: Cave Story
Special Skills: Turning otherwise useless information and cat videos into inspiration and game ideas.

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


Antti Tikkakoski, programmer
Favourite Game: Deus Ex
Special Skills: Cynical person

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



Jussi Hyttinen, programmer
Favorite Game(s): Final Fantasy VII / Silent Hill 2
Special Skills: Vivid daydreaming and remarkable skill to forget everything that doesn't relate to gaming

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


Jukka Kivijärvi, game artist
Favorite Game: Changing by the month, currently, Kerbal Space Program
Special Skills: Jumping from one thing to the other, learning it as he goes.

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


Tarita Tammela, game artist
Favorite Game: Baldur's Gate
Special Skills: Overthinking, turning into a bookworm on full moon

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


Teemu Tammela, programmer
Favorite Game(s): Dark Souls, Ace Attorney series
Special Skills: Surreal logic, catlike curiosity

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




Olli Leinonen, programmer
Favorite Game: Avoid Writing Your Profile Info
Special Skills: Not writing his own profiles, numerous club memberships

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



Valeriya Paykacheva, marketing idler
Favorite Game: Katamari Damacy
Special Skills: Being amazing, complementing herself, pronouncing her last name correctly

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


Sasu Kemppainen, game designer
Favorite Game: Grim Fandango
Special skills: Great at making pizza and eating it

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




Riku Leinonen, code monkey
Favourite Games: Phoenix Wright - Ace Attorney
Special Skills: Breaking the repository, playing Super Mario eyes closed.

Code monkey likes tea and Dr. Pepper
Code monkey likes immersion and emergent gameplay
Code monkey very simple man
With a taste for silly hats



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

June 7, 2013

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!

June 1, 2013

Developing Interplanetary GUI: Thoughts on Unity

More pictures from the early proto, the game will actually look good.

Greetings, dear reader. My name's Riku. I'm one of the programmers in the team, and I'll be your tour guide to the world of Interplanetary development today. We decided to try something different this time and take a little more in-depth look in the technicalities of the development process. Programmers to others ratio in the team is so skewed anyways, it's about time we take some load off the poor bastards' overworked backs and represent ourselves to the public!

As you may know, we are making Interplanetary with Unity, and started the development by creating a working prototype of the game. One function for creating the prototype was to get ourselves familiar with Unity development, as we hadn't really used it much in the past. We indeed came across several quirks that we're glad to be aware of when working on the next build of the game. One of those quirks was the graphical user interface framework Unity offers out of the box.

Our first builds of the prototype had a bug where the UI didn't take into account elements placed on top of each other. Clicking button in the GUI made everything behind the button to be clicked as well.

Not where I wanted to place that shield generator!

That's not working as intended at all! This behaviour encompassed the 3D scene used for things like placing buildings on a planet. This caused bugs where, for instance, selecting a new building from a menu also immediately placed the newly selected building on the spot behind the menu item. We fixed the issue in the prototype with a wide selection of conditional statements scattered around the code, but that wasn't really good enough for us. It was a pain in the rear to maintain, and we figured something should be done about it.

Fortunately we've had the privilege to have a programmer much more experienced than us available at hand to consult us. Jukka Jylänki from LudoCraft is no newcomer to Unity development, and offered to walk us through a solution to our UI problems.

In Unity, each script attached to a game object gets the chance to implement several methods the Unity engine then automatically calls at suitable times. One of those methods is OnGUI(), that gets called for each GUI event detected by the engine. GUI events include things like mouse buttons being pressed or a GUI element being redrawn. For each such an event, the OnGUI() method of each script implementing it gets called. In theory this offers a convenient way for each thing that cares about these events to process them, for instance for GUI buttons to check if a mouse click event caused the said GUI button to be pressed. In theory. In practice, the system has problems such as there being no easy way to enforce and determine in which order the OnGUI() of each element gets called, which makes it a hairy endeavor to implement things like buttons on top of each other. With the default Unity behaviour it's not very convenient to find the topmost thing that cares about mouse clicks and ignore all elements behind it.

To solve this, more control over the OnGUI() calls is needed. This can be achieved by creating a single GUI master object, which is the only object in the game that implements the default Unity OnGUI() method. It holds a collection of custom-made GUI elements, sorted by depth. When a mouse button is clicked, iterating through the elements front to back should easily find the topmost GUI element that the mouse cursor rests on top of. If we don't hit any GUI buttons with the mouse, we just let the 3D scene handle the event and do things like placing a building in the clicked position, right? Right.


It just so happens that in addition to handling mouse clicks, we are also supposed to draw the elements during an OnGUI() call when a repaint event occurs. The elements need to be drawn in the opposite order, back to front, so they properly appear on top of each other. Because of this, each time OnGUI() gets called, we need to check what kind of event caused it and iterate through all the elements on a different order depending on that. But wait, there's more! When drawing the elements, we want to highlight the topmost GUI button the mouse is resting on. So when a repaint event occurs, we need to first travel through the stack of elements front to back, testing against the current mouse coordinates, until we hit a button. This is the closest element from top that the mouse rests on, we want to highlight that. So we take note of this element, and go back to beginning. We then start drawing the elements from the other side, back to front. Upon each element, we check if it is the one we marked for highlighting and tell it whether or not it should be highlighted.


This kind of solution does solve the issue, but such a basic problem really ought to have a more elegant answer. Due to issues like this, we've found the Unity's default GUI solution somewhat lacking, and are currently experimenting with third-party GUI libraries from the Unity Asset Store. They seem to do a lot of the heavy lifting for us when building the UI for our game, so we can direct our efforts elsewhere and spend less manpower maintaining and managing our own custom GUI code.

And here ends the story of Interplanetary GUI development. We've hopefully communicated something about what actually goes on in the day-to-day development of the game. This post is kind of an experiment for us, we have no idea how interested you readers are in this type of bit more technical content. Please let us know what you think, your response may very well dictate if the boss-man lets us programmers take the wheel again!