Kings Can Fly

by Firedroid

Archive for the ‘Production’ Category

The quest for level exploits

Posted by Willem On July - 11 - 2012

We discussed how setting and maintaining a difficulty curve helps with keeping people interested in your game. However, the player can only experience it correctly if your levels provide the challenge intended by the designer. Our test data provides us with information about how many fans users place in each level. When compared to the intended solution we sometimes find differences, indicating that testers used solutions that shouldn’t be possible. One could argue that having multiple solutions is a good thing, and if it’s intended it certainly is. The problem is that we cannot guarantee a continuous difficulty curve when the levels are not solved using the ‘balanced’ solutions and players might not learn the things they should have. In short, with unintended solutions to the levels, we lose control of important aspects of the game and might end up with confused users. The hunt. Now that we know which levels are solved using incorrect solutions, we’ll have to dive in, look for the exploit and plug it! If the exploit can’t be found using our eyes and the game, we use a tool. It’s neither finished nor very… user friendly, but KAI (Kings’ AI) allows us to find solutions we might’ve missed. A solution found by KAI.
For example, we didn’t foresee the possibility to use the mountains on the right to remove the need to use your lift-fan twice.

The intended solution, drawn with a red line. This is the intended solution. It’s more difficult and teaches the player to reuse the lift-fan. To enforce the correct answer, we removed the problem piece of mountain. It usually comes down to shifting groups of hills around, placing bridges or removing low-land. Roughly half our levels have been modified to prevent exploits. Making challenging puzzles is hard!

Difficulty curves

Posted by Willem On May - 25 - 2012

Our level design was a bit of a trial and error process.

At first, our leveldesigner drafted a progress in which the various game elements were to be introduced and used. Then, we all spend several weeks producing a whole range of ‘raw’ levels, that did or did not follow the guidelines.
The leveldesigner then sorted these levels and edited each of them. At this point we had around 60 levels and we did a closed test round with tens of people.
The feedback that followed was a bit discouraging. We had made the levels too simple. We did so to make sure everyone was able to play our game, but it removed the challenge and thus prevented people to be entertained.

It was time to use more theory than practice. Our testers had to rate each level on clarity, difficulty and fun. No surprise that the last two are in close relation to each other. The more challenging a level was, the more fun the people had in solving them. Now you would say: “Of course it is, so you guys just made every level more difficult?”

It’s not that simple.

Next we devised a way to rate our levels more precisely. This was done to give points to the elements and thought processes used in a level, combined with the levelsize and number of fans required to finish it. This difficulty-index reflected the rating our testers provided.

With this, we plotted a ‘theoretical difficulty curve’. The idea behind it was to rise very swiftly to the point where people started ‘to have a lot of fun’. And from that point on rise very steadily. Just to keep the player’s brain working, but without letting them hit a solid wall.

After we had our theory done, the process began to match the levels to their newly determined difficulty. Needlessly to say, it took it’s time. But we’re confident it made the most important part of the game, namely, the puzzles, a whole lot better. And we’re sure people will have a great time playing it.

Don’t worry, we will perform more test rounds with different people to ensure our new difficulty curve is spot on.

ingame GUI design

Posted by Rachel On August - 18 - 2011

Even without any professional knowledge of interfaces or interaction design… an interface has to be made.

In the game itself the most important things are buttons that resemble the fans and the time control panel. The GUI has to look like its part of the game, not just some buttons that were ‘just’ placed there. To match the look and feel of the game I wanted to implement wooden planks. After doodling some shapes on paper, I came up with some rough digital sketches.

Just wooden planks seemed to plain, so I added some golden details to make it more ‘chique’. Although I like the idea behind the third one, it isn’t really practical or logical with the buttons in place.
At first I thought that a ‘heavy’ non-transparent GUI would fit the game best. So I came up with the following ideas.

I preferred the second one, once again because I thought that ‘just’ two planks were too plain and it didn’t fit the setting of a wealthy transport company.
Combining the time control and the  background for the fan buttons, I came to the following GUI layout:

I left out the golden corners of the time control panel, because the gold just was too much with the background for the fan buttons having that much gold as well.

A few weeks ago, I went back to the drawing board. The GUI was too present and it turned out to be quite unhandy in the levels in which the player cannot use the jump pad. The GUI maintains its size, even though it has less content. We needed a more transparent GUI, which actually is more used by gamedevelopers for mobile/tablet games. I came up with this:

And of course all the buttons needed their own different states, an overview:

About tilesets and repetition

Posted by Willem On July - 28 - 2011

Our first mountain tileset was actually pretty good. It looked cute and did convey the message: “I’m a mountain, don’t bump into me.”
It had it’s problems however. First off, it did not tile correctly in every situation. And placing several straight tiles in a row to create a wall resulted in a hideous repetition.
Rachel tried to solve both with several re-texture attempts, but all of them had the same problems, or were to bland.

So, we tried to solve it with new mesh.
Willem made a new tileset, that featured the solution: Several alternate straight tiles that were different in length (next to a length of one unit, we now have a piece for two, three and four units long).
Since, this elevated the tiling-repetition problem, Rachel could now make a texture that had contrast. It still has to tile nicely with even more combinations however.

The way the UV map is made has changed too.

The first mountain UV was fragmented. Every tile was separated from the other. This made it hard to create a tileable texture. So in the second gen. it was connected. Although this made it easier, all the angeled lines made texturing as a whole a pain.

So the third generation, that we currently use, is horizontally straight. Makes texturing a breeze.
But: as any UV-mapper out there knows. This makes the texture distort enormously, since the UV is not a accurate representation of the actual mesh. We were surprised with the distortion, it’s not really noticable.

Clouds and skirts

Posted by Willem On July - 7 - 2011

Sadly for us, the iPad 1 is very weak at rendering alpha (semi-transparent surfaces). So using clouds is a bit of a problem, seeing how they’re a significant part of the game’s look and feel.

Performance-wise we can get a single alpha-rendered plane covering the entire map, and then only when the mesh below is flat and has just one solid texture. We get about 28 fps when the alpha plane is covering 2/3 of the screen, which gets better when more solid mesh is visible (rendering alpha is fill-rate bound on the iPad).

Instead of going for a single solid plane with clouds painted on it, and a similar cloud filled alpha plane above it, we opted for loose 2d clouds. The “semi-alpha planes” are cut in half, the center part does not contain an alpha shader. This to reduce the amount of alpha drawn.

Because all the clouds are flat they clip though the mountains, which breaks the illusion and looks weird.
Our answer to this are “skirts”. This is a mesh around the side of the mountains containing a texture with alpha that has a gradient to transparency at towards the mountain and towards the cloud-layer. This gives the illusion that there are clouds around the mountains and blends it together to look smooth and natural without a big performance penalty.

Lowland Fan

Posted by Rachel On July - 1 - 2011

We’ve added a new feature, where players can now also place fans on the ground, instead of just on the mountains. We’ve given the new fan more body and made them look cuter. The current model has 292 triangles.

The original designs for this fan:

Balloon Brothers and Tiled

Posted by Roy On July - 1 - 2011

As our development progresses we’re closer and closer to a version that supports puzzles and can be played as a game (although it’ll be a work-in-progress). So we’ve had to think about how we’re making those puzzles and how to feed them into our game. Now we already stumbled upon the Tiled Map Editor, which is a free and opensource mapping tool for games that are based on tilemaps. We filed it away as a great tool for later use, while we focused on the basic elements of the game.

Recently that core has become complete enough to warrant a second visit to Tiled and see how we could use it to build our puzzles. We made a tileset and set to work!

First up is handling rotation. The tileset has four different versions for straight lines and corners, as they can go up, down, right or left. We only have one 3d model for such things, so they needed to be mapped to the tileset. We thought about building fancy and complicated solutions but in the end we simply used an array with objects that contain information about the tile. Each tile in the tileset is coupled with such an object, which holds information like rotation, direction, height, etc, everything the engine needs.

Tiled outputs an XML file containing the information about the map size, layers and tiles in it and after fiddling with some Unity scripts people wrote we decided to just use C#’s native XML functions. In the end this works really neat and we’re very happy with Tiled as our tool for building levels since it’s a good map editor for our needs.


Balloon Brothers on the iPad

Posted by Roy On June - 23 - 2011

After some minor issues with licenses and software we finally have our work in progress running on the iPad! This was amazing to see and test after waiting for so long, since it’s hard to guess what will have a big impact on performance and what our game’s performance would be at this point.

After a few modifications to our input system the game ran pretty well and it would seem we’re clear from any performance problem, which really takes away some worries. It’s also way easier to show others our game now!

It’s running pretty stable at 60fps at this moment, although we won’t be able to make the full game run this fast; there is still a lot of geometry and textures to add. All in all, we’re very optimistic and happy with it’s current performance.

Tech progress week 11

Posted by Roy On June - 18 - 2011

On the tech side this has been a productive week. Last week we implemented placing fans and having fans influence the ship’s route through the level. This week we expanded on that, implementing the wind indicators and fixing a bug with the ship’s roll.

After that we heard that our Unity iOS licence was about to get ordered, so the focus shiften to rotating and moving the camera around and about on the playfield. We were still using buttons and since the iPad has none of those, it was important to have it done by mouse since it’s a small step from mouse location to finger location.

Later into the week we added the four fans on the right to check whether we could easily add fans that followed the world’s rotation, seeing how we want to set limits to the amount of fans per direction available to the user.

So there you have it! The camera can now freely move and rotate by using the mouse and fans work nicely.

A video showing all the recent goodness:

Art progress week 11

Posted by Willem On June - 17 - 2011

It’s been a busy week!

Our to-do list said “create a spawn and finish point.” Or rather, Roy (programmer) said: “Hey, what about those spawning points? Still using cubes over here.”
We looked at each other and started talking about the hangar idea that was proposed weeks ago.

After the first rough sketches Rachel (artist) headed straight for full-glory concept while Willem (modeler) immersed himself in Blender. Ironically, both finished at the same time.
The hangar was textured and animated in the following days.