Creative process and UI design, part one

Hello!

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

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

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

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

Pictured: creative process

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

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

To be continued...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inside Interplanetary: Targeting Problems

One of these must hit!

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

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

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

Let's discuss...

The Difficulty of Hitting Your Enemy

Well, I guess one did.

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

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

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

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

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

We Have Some Ideas

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

Looks a bit complicated on paper.

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

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

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

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

Art of Interplanetary: Maps

The end result

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

From chaos to order... Sort of

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

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

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

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

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

Touch of fictitious realism

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

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

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


If only planets were cubes

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

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

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

Check out our IndieDB-page for more goodies!

Inside Interplanetary: Weapon Types

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

The Weapons of Interplanetary

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

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

Railgun

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

Stupid gas planet, messing up a great shot.

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

Missile

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

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

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

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

Beam

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

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

Everything's in the way!

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

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.