Game engine summer cleanup

Hello everyone, we thought we'd take the chance to give you a brief update on what has been going on with the game these past few weeks. :)

We finished the first version of  our internal alpha build just before the end of July. And while most of us went for a holiday Sasu bravely stayed behind to do some testing. We were still missing some features due to some technical difficulties and Sasu also found few bugs and some room for improvement.  So after we got back from our holidays the programmers have been focused on improving and fixing the underlying code structure before we continue adding any new or missing features.

Upon entering the alpha we first introduced some networking capabilites into the game, which ended up causing trouble with how things were wired before. Previously all the UI  elements were always intrested in who the 'active player' was, and with the addition of the networking there were suddenly two active players and that resulted in the UI acting like it had lost its mind. For example making both players research technologies in the same technology tree.

To fix this Jussi started making a UI Manager that handles all the different UI elements  more independently. This means that only the UI Manager will have the player reference and then give it to the smaller individual UI elements (resource system etc.) when they needed the information. This fixed a lot of issues with showing the right player's data, but it also meant bigger change to the whole game engine in how it handles the players.

This bug didn't actually have anything to do with the UI but it was still pretty freaky.

Another change came about from Sasu's notes from the testing he'd done. In the end of each turn,  the game displays the results of actions taken during the turn. This means, for instance, displaying the flight of any projectiles the players fired. But it might get rather tiresome watching the pretty pretty particles flickering on the screen for 5 seconds after every round, so we should give the player the option to skip watching this part of the turn.

This called for an overhaul of how the action phase worked. Previously the game displayed the movement of planets, projectiles and other game objects just as in any realtime game, calculating projectile trajectories on the fly. In networked multiplayer, the host's machine would sample object positions every now and then and send that data to all other clients to keep the displayed scenes on sync, and also send signals at events like a projectile hitting something and getting destroyed. All clients would see the scene played out at the same time, and it wasn't really possible for one player to skip ahead of others.

The new system we have implemented works in a manner where the host machine calculates the whole action phase and jots down its results before the action phase is visually displayed to any player. The results of these calculations, what projectile hit what and when and so on and so forth, are then sent to all clients. This way, the clients can independently control the flow of the display, without it affecting the results of other clients. Now a client can skip straight to the end of the phase and start playing their next turn, while others are still watching the fireworks at their own pace.

Onward we go!

The cleanup/ rework on the engine was finished today and starting on Monday we will be moving on to first adding the missing alpha features and continue from there.

Also, our friends over at Rust0 games had spotted a sweet deal on the Space graphics toolkit in the Unity's asset store (it's over now unfortunately) and hinted that we might be interested...

A sneaky peek of what you can do with the Space graphics toolkit. This hasn't been implemented in the game yet.

That's it again for today and see you again soon. :)

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!

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!

The second most popular gaming conference in the north

Networking ®, the Trading Card Game

Hello! Now that our bearded scout squadron (with glasses) is back from Sweden and recharged, it's time to write a couple of lines about our trip to Nordic Game Conference, Unite Nordic and some related events.

For us the trip went very well. People seemed to like the idea behind Interplanetary a lot, and Hedgehop, one of the games we still very much hope to finish at some point, was very well received by the few people I had a chance to show it.

We thought about writing a longer post mortem and a more detailed description of the events, but there are plenty of those around at this point, and you can always watch some of the presentations online. So, instead, here are some things you should keep in mind when it's your time to travel to NGC. (Majority of these points apply for most games industry events.)


Nordic Game Conference tips for the newcomers:

Plan ahead.
Make it clear to yourself what you require from the trip and plan your actions accordingly. Is there someone you want to talk with? A company you want to connect to? Are you looking for a training place? Do you want to find a publisher for your game, or are you there for advice?

If you travel with a group, discuss your goals beforehand. This way you can keep on the lookout for your friends as well: If someone spots a person you want to talk with, they can give you a call.

Cutting out your 150 fliers manually is very indie.

Prepare some material for your game or team.
Think of the message you wish to deliver to your target audience, and what that target audience will be. Prepare the materials early. You may also want to prepare an elevator pitch for your company, team and/or your game.

Make reservations as early as possible.
This allows you to find cheaper flights and accommodations. Comfort Hotel Malmö is a good choice, it's located right next to the Slagthuset where the conference is held.

Pack light.
You'll end up needing only 1/3 of what you have in most cases. Linens and a towel are usually not needed, even if you stay in the cheapest possible hostel.

Wear good shoes.
Your trip is likely to involve lots of walking and standing, and it'll be a lot harder to focus on important things when you have blistered feet.

Be aware that the price level in Sweden is very high.
This is true even from a Finnish perspective. You can expect a McDonalds meal to be around 10€, a beer in a bar around 8€ and drinks around 12€. There's a good China Box at Gustav Adolfs torg which is not exactly cheap, but it's a good alternative to the other fast food places.

Data roaming is around 0,8€ / MB and wifi access in the conference area is pretty unreliable, so you might want to consider Swedish prepaid for the event.

Conferences offer lots of quality content for social media.
You can post interesting things often, and if you tag the people or companies you meet, there's a chance you will get retweets/shares etc.

Travelling in good company is optional but recommended.

You don't need to attend every talk.
Though the talks may appear to be the main thing, most of the information you will get is something you can find by googling. The real value lies in stuff that you can learn when discussing face to face with the professionals. Attending their talk may be a good way to earn a chance to speak with the person later, though.

Have some business cards with you.
It's so much easier for the people to remember you afterwards if you give them one. Offering yours is also a less awkward way to get one.

It may be a good idea to wear clothing with your team/studio/game logo.
This makes you more recognizable and memorable. It also makes it easier for people that know your game to recognize you and start a conversation.

Make use of your previous contacts.
Game industry people are usually friendly and eager to help- it's usually ok to ask them to introduce you to someone they already know.

Go to the afterparties every day, even if you don't drink.
There is a good chance you will get your most important contacts there. And if you do drink...

Don't drink too much.
Most of the evening parties offer free drinks, but you'll get more out of them if you stay reasonable.

Most importantly, talk to people.
This is the core of everything. Only by socializing you'll end up getting new contacts and strengthening the existing bonds.


So there you have a couple of points to keep in mind, some of which we have learned the hard way. Hopefully now you can avoid them and have even more fun and productive conference experience!

All in all, the trip to Malmö, Sweden, was very, very worthwhile. Thanks to Neogames, Wooga and Kavio Cluster for making it possible!

What news from the south?

This week was an interesting one! We traveled to Helsinki with some fellow Kavio game developers in the beginning of the week and got a change to present the very early prototype of Interplanetary to some game industry professionals. Thanks again Frozenbyte for having us!

Needless to say, we got some very good feedback. While there are still some problems with the proto, we we're happy to notice we are moving to the right direction and the main parts of the game work as intended. It's also very encouraging to notice that nearly all of the issues that came up were something we had already acknowledged.

The Interplanetary proto is now officially finished. Though we didn't have enough time to try out all the features we wanted, we now have a good idea of the final game design and we are ready to start working on the final version.

This week's blog post was delayed a bit by busy busy business and a thunderstorm, sorry about that.

It's alive!

Good news everyone! TJR has awoken from its slumber of outsourcing and school related stuff. Now that we have also been reinforced with a band of new members, the team is stronger than ever.

First and foremost this means we have been able to finally resume the development of Interplanetary. The project was quietly moved to the notorious slow lane at first last spring and ultimately shelved for a couple of months. This was not something we wanted to do, but by switching to outsourcing for a while we managed to ensure steady supply of ramen while having some time to focus on the remaining school related things and smaller projects. Some of us even managed to graduate while we were flying under the radar, so, success!

Interplanetary has evolved quite a bit when we paid less attention to it; the game is now 3D and based on Unity engine instead of the slowly fading XNA. This should allow us to make the game even more beautiful than we originally planned with the option to go multiplatform with relative ease. Here's a bit of a sneak peek to a description we wrote for the upcoming Kavio cluster website. If you are all "what the heck is Interplanetary??" at this point, this should get you on track of things:

Interplanetary is a turn based strategy game about warfare between two planets. Setting of the game is a fictional planetary system where two planets have evolved intelligent life and ultimately become planetary civilizations. These two planets have fallen into a conflict for the natural resources of the planetary system they share. 

Technology level in the game is not too far from ours, and instead of stereotypical sci-fi starfleets, war is waged with massive, planetary weapons and other megastructures, built right onto the home planet. As the game progresses, technological advances allow more and more options to protect your people and defeat the enemy.

Main part of the game is managing the limited natural resources of player's home planet, developing its infrastructure and researching new technology. Each turn ends with action phase where player gets to target the weapon systems at the enemy planet and unleash his military might. The game supports various different tactics from a planetary broadside of railgun slugs to few, but deadly precise strikes of interplanetary lasers.

If you enjoy games with similar elements, like DEFCON, Civilization series or even the old artillery games, we will definitely have a game for you! Interplanetary will be available in most digital distribution channels.

While actual gameplay screenshots still have to wait a bit, we are proud to present some concept art. Stay tuned, there will be more to follow regularly now that we're back in business.