In the face - creation of a user interface.

Hi,

I am here to talk a little about the concept and design of our user interface.

In the beginning we basically had 3 premises:

1. Keep it simple/lightweight.
2. Keep the loading times out.
3. Keep it as aspect ratio independent as possible.

Simplicity

What I mean with "lightwight is quite easy to explain: To design a user interface that keeps the impact on memory and performance of a mobile device to a minimum. Our solution to the problem is fairly simple; We decided to make our interface 2.5D and keep the texture requirements low.

That means all the assets are actually build in a 3D software package but rendered to an orthogonal camera which essentially displays everything in a 2D fashion with 1:1 pixel/texel ratio, so we won't have to deal with distortion of our imagery. To minimise memory usage I tried to use as many flat coloured polygonal shapes that were given a small 16x16 pixel square on the texture atlas.

The only reason why I did not get away with just one 256x128 pixel texture for our UI is that I decided to display our logo in a rather large scale, and I ended up with a 512x512 pixel texture. Using only one texture for the whole UI helps in a few ways to get rid of the memory overhead which Unity's native UI system would normally suffer from.
I'll give you a short explanation why that happens. All 2D images or textures in every game using hardware acceleration through the GPU need to use a "power of two" edge length; Meaning every texture has to have a width and height being a multiple of two (eg. 8x8, 32x32, 256x128).

So where is the downside? Well, for now Unity forces the developers who decide to use their build in user interface framework, to use a separate texture for each and every interface element, such as button, labels, text boxes or toggle buttons; and they all have to be a "power of two" texture, which might not be the case for it's original design; Maybe you chose to have an icon being 80x80, which would mean you'd either have to use padding to get to the 128x128 pixels or make the texture 64x64 and scale it up. This of course, will lower your UI quality a lot.

You might say: "But Unity lets me import non-"power of two" textures!". You are right about the importing part, but if you check the texture in the asset viewer it will still claim "not pow2" and rescale the texture to be "power of two" when you export it - that's not Unity's fault, it's just how GPUs expect their textures.
Secondly and even more important, Unity will never scale your image down, even if your icon is close to the lower power of two, eg. 65x65 pixels; This one will be scaled up to a whopping 128x128 pixels. With a single atlas that contains all the parts of your UI, you can see into it, that all elements get their space; Without wasting to much of the texture with blank areas which won't be used at all. I've made a little graphic to illustrate this a little better.

comparing choices for UI textures with Unity's UI framework.

Since we didn't need all the various base components unity offers with their framework, we build our own structure for the UI, so I can have full control over the texture sizes. It also gives me full control over the animation part of the UI without touching any code in Unity, which is much faster to handle when it comes to iterations and adjustments.

So enough talk, let the images speak, all the texture space we need for our menus is what you see in the example down below! Also I've whipped up a little animated GIF to show you how the menus are generally layered.

the texture atlas is displayed scaled, it is actually 512x512px in size.

perspective and orthogonal view of the main menu layers. click it! it's animated!

What I mentioned above brings me to another aspect of "simplicity" and how easy it is for both programmers and artists to work with those menus. In case you decided to animate your menu you will be needing at least 3 animations per menu ("in", "loop" and "out" animations); If it is a complex menu, there might be even more. Fortunately it is really easy to import fbx files in Unity and make them start/stop or loop a certain section of the included animation, so for us this was the way to go.

Loading...

I think most people dislike loading times and even though they are sometimes necessary, I agree with them, loading times can be quite annoying.

So for we thought: "Wouldn't it be cool to press "start game" and the darn game really starts?!". This kind of stuck with us and I think we managed to find a way to get this done. As you might have noticed in the picture above, the menu resembles a futuristic airlock. So once you press that button, it opens and the game starts, no catch, nothing holding it back; It just starts.
It is the same way round when the game ends; You're presented with a result screen which will show how well you did - once you decide to hit the "continue" button, the results screen will animate off screen while the main menu comes in with a "closing door" animation. So you see no unpleasently long and boring transitions between the game's states, which I hope you'll dig as much as we do!

Hey, why is there a gap?

There is always a number of problems you run into when you make a game for several target devices with different display resolutions and aspect ratios. Some are quite easy to evade, some are not. In my professional career, I came across quite a few people who were of the opinion there is a easy solution to a "one size fits all" UI.

The more complex your interface is, the harder it gets to get it right for everyone and everything. The sad truth in fact is, while you can minimise negative effects and drawbacks of different resolutions with a dynamic, scalable user interface, there are always some unwelcome guests you have to let "stay" if you choose this path.
First of all the time it takes to properly set up a dynamic system takes a lot of manpower both in the coding and art department but that still won't give you optimal results for all aspects when creation a more complicated and information heavy interface. Secondly it might warp the imagery and or the white space between elements, thus rendering the solution inadequate or unusable in the worst case, because it might look a little too crowded.

This is yet another reason why we pleaded to the creed: keep it simple! It'll be much more likely to hit the jackpot for a "as close as possible solution" - but don't expect it to work for another project, it might if it's the same target device(s), but don't depend on it; UIs are the most contextual things when it comes to software development.

The sooner you make up your mind about this and the actual requirements for your interface, the better, cleaner and more ergonomic it will be. Don't hesitate to write up what you expect your interface to convey, where and what to to display and how you want the user to benefit with this information. Try to come up with solutions to maximise its size without getting in the way of the game or hitting a physical barrier like the good old memory constraints. Another thing I recommend to everyone making a UI is to talk to people about it; Let them have a look at it or them try it out. They don't have to be into design, just let them look at your ideas, most of the time you will get valuable feedback. Remember it's not you using this interface, it's everybody else and they have to be able to use it!

To get back to the topic of resolution independence, the solution we chose is far more manageable and clean in terms of its look and the time it takes to integrate it into the game then most other projects I worked on. Due to the 2.5D nature of our UI all we need to do is set a scaling value based off the height of the devices display and give the menu enough "meat" around the edges so nothing will flash through unwanted gaps, this will keep everything neat and tidy with a super minimal hit on man power (around a few minutes of added work at max for all the menus combined)

So our drawback here is we can't make it a lot more complicated than it already is, but for now, that exactly fits our needs, so we're fine with that!

So I guess that's all I have to say for today, but I won't leave you with nothing, so here's a bonus; one of our menu transitions from our main menu to the high scores.

Thanks for your time!

cheers
Oliver

Coding Corner - Coroutines

Hey there,

one thing I really love about the creation of video games is, that it is an interdisciplinary process. To cook up a game a mixture of graphics, animation, story telling, character development, sound, music and of course a great deal of technology is required. All those things boil down to an interactive medium that in the end brings a fun experience to the one who plays it. I doubt that this is something that you can say about developing business solutions ^^

One thing I've learned is, that it is of utmost importance to implement all those ingredients into the game as fast as possible and can be experience and tested by those who have actually created the particular asset, may it be graphics, animation, visual effects, sounds, music or code. This will let your team get a better understanding if things work as intended, their vision of that particular part of the game.

That's one of the reasons I like to work with Unity - despite its weaknesses, it gets your assets into the game - fast!

Since this is my little coders corner of the blog, I'll write more about the technical side of the creative process. There might even be some code-snippets here and there. So the faint hearted have been warned!

So lets start:

What are co-routines? Wikipedia says: "Coroutines are computer program components that generalize subroutines to allow multiple entry points for suspending and resuming execution at certain locations".

Ahhh, yep, so what exactly can I do with them?

Imagine you find yourself in the situation where you want to show a nicely animated dialog to the user. It basically goes like this: play intro-animation, print the text, start the talk-animation, stop the talk animation, wait for the user tapping the screen, print the next dialog-line and so on.

In the traditional flow of execution in a video game you can't just wait for an animation, because that would stall the rendering, you always need to finish your computations in 1/30th of a second so that your updates can be shown to the user. So to accomplish the above task you wouldn't be able to write something like:

animation.Play("intro");
while ( animation["intro"].isPlaying )
do nothing
print text


you would keep executing the while loop forever, because your animation isn't even updated. So what you might want to do is something like checking every frame (polling) if your animation has finished and if so, continue afterwards. You have to keep track what you're about to do with state-variables, timers and so on. This can become messy faster than you'd think and makes the code harder to read, because you have to track the state of all those variables.

But fortunately there are co-routines that allow you to resume the execution of your logic at certain locations. So while some lines of your function are called in one frame the next ones might be called in the next frame. In Unity it is done like this:


C#:

IEnumerator MyAweSomeCoRoutine()
{
animation.Play["intro"];

while ( animation["intro"].normalizedTime <= 1.0f )
yield return new WaitForEndOfFrame(); //execution is interrupted here
and picked up in the next frame, awesome!

animation.Play["talk"];
// ...
}


and in your Start(), or where-ever you want you just call

StartCoroutine( MyAweSomeCoRoutine() );

Other languages and environments support this concept as well, but you might have to do a little boilerplate coding, even though it's not that hard to do. python supports the yield statement out of the box. for c++ there's Win32 fibers and libcs swapcontext ( or just use Boost.Coroutine (http://www.crystalclearsoftware.com/soc/coroutine/index.html) ).


If you got hold of this concept, implementing logic constructs like the above becomes fast and easy. So you can move on to more exciting things like implementing this new Laser-Gun you just got some nice particle-effects from your artist.


Thats it
tk
Ben

Hello World errrr Mars

Welcome to our little wonderful blog about our upcomming indie game project, called Life on Mars (who'd have guessed).

A little backstory about it - this whole thing started because we three got together asking ourselves how exactly it is possible that 3 industry veterans can't get a small decent mobile game done (well, we tried before, multiple times... yeah we ARE lazy ;)). We didn't really find an answer to this, except our lazyness, but we'll just try again!

THE TEAM

For now our team is us three, 2xBenjamin and Oliver, all of us living and working in Berlin, Germany. We kind of work with a biased, unfair team configuration, namely two artists vs one coder, but so far Benjamin had better arguments during development, so I guess we'd call it even!

So for those a bit confused now here's the list:
Benjamin and Oliver do art
and the OTHER Benjamin does code, got it? :D

Well now you learned to know who we are, guess what's left is to tell you what the darn game is about, right?

THE GAME

To make it short: It is a super arcady retro sidescroller game. It's about flying, shooting, spaceships, explosions, lasers, and of course survival! So everything you enjoyed while watching TV back when you were a kid.

Some of you might now say, what the heck are they talking about, so our answer is: Images! check them out!

Early environment concepts

Some of the background art

a few of enemy ship concepts

So this is what our vision currently looks like, it's still open for change, but should give you a fairly good impression of what we are aiming at.

THE FUTURE

We are targeting a release for major mobile devices, iOS being our lead plattform for now (we are short on testing devices, so if any manufacturer is willing to send a few in, we'd be MORE than happy!)

On the tech side of things we are using Unity3D as our game engine, as we wanted to have the option to put this game out on a sh*tload of platforms, if necessary, because you might have forgotten the fact, we just have ONE coder, and those poor guys have a lot to do even with a good engine.

We decided to make this blog to give you guys an insight in how this game will come to be and to give out the one or other hint about what to do or not when it comes to mobile development.

So expect us posting about the voodoo heebeejeebee and other stuff that was involved to get the project done ;)

And last but not least, we'd like to say thanks for reading!

The LoM Crew