Creative process and GUI design #2

Hello again!

Tarita here, the artist who has been tasked with the challenge of creating a passable looking UI for Interplanetary.

So, last time we were left with a combination of UI styles, right? I promised I would show you where the UI is currently heading, so here's a mockup:

Please keep in mind that the look of individual elements is far from being set in stone, and that the image above is just a mockup and does not accurately represent what the in-game UI currently looks like. We have just begun alpha testing, and in the light of the new feedback we may have to adjust some things.
The mockup should, however, give you an idea of what kind of style I'm aiming for.

Overall, the style is pretty simplified, and I like having some empty space between stuff. Even when adding detail, I'm trying to keep things simple and stay consistent with the limited amount of colours and light effects. I prefer not to add any extra fluff that doesn't have a distinct function or a reason to be there.

The elements in the mockup are somewhat large. This is partially because they have to work with a variety of different screen sizes, and still stay readable. I think that the increased size complements the simplified style nicely, but some people have told me that it makes the UI look "cute", which may or may not be problematic.

Earlier I told myself that the boxes would be neither blue nor gray, but in the end I had to go with gray.
Why? Because I found that only gray was neutral enough for the rest of the game.
I wish to leave the main stage for the planets and the space background, so the UI can't be too colourful or pop out too much. I don't want the player to miss the subtle details of the starfields on the background just because I insisted on having screaming, bright- yellow boxes on top of everything. This is, incidentally, also one of the reasons why I favour transparency and lack of boxes whenever I can.

Sometimes things pop out too much.

The other reason for the gray main colour is that I'd like to introduce some colour-coded information to the UI, such as icons and text, which are more visible on a muted background. Having a few splashes of colour is a breath of fresh air that also makes the dark graphics of Interplanetary feel slightly less grim and murky.


That's all for today, thank you for reading! In the future I may write more about the individual elements and the design choices and concerns behind them.

You can follow the progress on Interplanetary on Facebook, twitter or the game website.

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!

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?

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.

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!