Xform Game Development

Time is ticking!

2012-02-03T18:11:00.003+01:00

Hello all!

Today a new blog about the "snowboard game with cars"! First of all, for anyone that goes skiing or snowboarding: don't try this when you get the chance to do it... Only if you are really that good:)
Last week I had a week off and went skiing and the first day I tried a barrel roll myself and didn't end up that well. Didn't broke anything, but it hurt, haha. I was skiing downhill and making my turns, only somehow I lost my balance and my ski got stuck in the snow. So I went airborne, made a nice barrel roll and landed on my side in the snow! From that moment I knew that I don't need to so some tricks like in the "snowboard game with cars"!

Taking the ramp!

Ok, enough about my holiday! Let's talk about the game. :)
It's almost finished! I know you all can't wait to see it, but you still need to wait a little longer. Currently we are working on some minor issues that has to be done. Many things have to be tested and fixed if it's bugged. So my work/task/todo list is quite big, because all of the things that has to be done.
So for example we had this nasty bug at the finish, when you should go back to the menu from the track. All animations were playing twice as fast and when one ends, the game crashed and you weren't able to continue, so you had to restart the game! Double checked the function, but just couldn't find the error..
So finally after some testing/debugging hours I finally found what went wrong. The function was called from a button what is pretty normal. Only when you hit that button so fast that it didn't even got the chance to delete himself he would trigger the function twice. So after this bug I could fix some other bugs that were related to this one.

Greetings,

Michael

The Big "Xform: Start Of 2012" Quiz

2012-01-27T16:12:00.001+01:00

Hi all,

2012 is only one month old and it started good! For us it started with the launch of our newest games: Traffic Slam 2!
We're very proud of it, because it's our second Flash 3D game. And it worked out very well. Try it yourself here: http://www.agame.com/game/traffic-slam-2.html

Or watch the trailer here: http://www.youtube.com/watch?v=U4inNhHGIdI

Of course this isn't the only project that we've worked on during this first month. In fact, we're never working on just only one project. Unfortunately, I can't give too much details about the upcoming projects for 2012, but they're going to be great!
But I do want to share our current projects with you, so with this blog I will give you a sneak preview:

1. Welcome to the Jungle

2. Ain't No Mountain High Enough

3. Space Jam

4. Le Carnaval des Animaux (Finale)

Can you guess on which games we're working?
Another hint: they do contain either explosions or cars!

Answers will be revealed in the upcoming months.
And many, many more games to come... So I keep you posted!

- Shirley

Flying pickups

2012-01-25T11:18:00.003+01:00

Dear readers,

For one of our new games we have flying pickups which move towards the player when an enemy is killed. The kind of movement we want is shown in the image below.

What's important about this movement is that it has a nice curve to it. The problem here is: how do we get this curve given that the starting and end position of the curve are different each time because they depend on where the player and the enemy are. Also the maximum height of the curve should be easy to change.

I've split the problem into two components: movement of point A to point B on the XZ coordinates and the movement on the Y coordinate as can be seen in the images below.

As you can see the movement in XZ coordinates is a simple line segment (linear interpolation between A and B).
The movement in Y coordinates is however not as simple (the height of the end point B happens to be fixed at 0.5). But this curve looks oddly familiar. Indeed, in (one of my earlier blog posts) I wrote about how Pieter needed a function with certain properties. Now a few months later it seems I need a similar kind of function, just a little but more dynamic as the height of the curve is now a variable as well as the starting point Ay. Again we want to find the a, b and c coefficients of the second degree polynomial f(x) = ax^2 + bx + c. So we go back to pen and paper and calculate a, b and c as a function of H and Ay (and t which is the point where f(t) = H). Here's a photo of the calculations, they're similar to the calculations I described in the earlier blog post.

Calculating the a, b and c coefficient of the second degree polynomial function.

Also a minor correction on our previous blogpost: if you want to see the flying souls move up, you need to scroll the texture (UV coordinates) down and not up. Otherwise the flying souls move down into the ground.

-- Stijn

Scroll down please

2012-01-20T17:59:00.001+01:00

Developing browser based games has the drawback that we generally can't use too much animations or effects. The reason for this is that they take too long to create or simply cost too much processing power which slows down a game.

But we do want our games too look good and not too static. You can imagine it's kind of dull looking when there is nothing animated or moving in a game environment.
Luckily for us there is a simple animation trick which can be used an a variety of ways to add "life" to a scene! It's actually one of the oldest tricks of the trade.......scrolling!

Scrolling a texture/image over an 3D object or plane can be simply done by animating the objects UVW coordinates.

Momentarily I'm working on an update of Go Kart Go which will have new characters, tracks and some updates of the old tracks. One of the new tracks has a spooky ghostship theme. For this track I wanted the souls of dead pirates to come out of the ground and move up into the sky. I used the scrolling technique to achieve this effect.

First I created a vertically tiling souls texture (with transparency) and mapped it onto a 3D plane object. Scrolling the texture (UVW coordinates) vertically up accross the plane will move the souls.

I placed a few of these objects in the scene and modified the mesh to get a cool "wave" effect on the souls. This looks especially good when a few of these soul planes are placed behind each other.

There are countless ways a scrolling texture can be used. For Go Kart Go it's used for flowing water and lava, turbo pads, dust particles, rain, moving clouds, smoke and (of course) the souls!

Cheers,
Matt

Frostbitten Mountain 1

2012-01-18T16:04:00.002+01:00

Hello all!

A quick update about the awesome "snowboard game with cars".
The last couple of months I've been working on the tracks. The tracks are subdevided in 3 mountains. Every mountain has their own settings, assets, etc.

One mountain has an Austria mountain idea (a famous country for people of Europe to have the winter sport holidays). This mountain is a sort of tutorial mountain where you get to learn this game. My main goal for this mountain was to get this mountain friendly and fun to ride on and not hard, pointy rocks, deep clifs or other craziness.

For this mountain I've made some typical things you see when you go skiing, snowboarding, or whatever. So there is this Ski lift hanging over the track here and there, some wooden cabins in areas where there are trees, some typical Austrian/German buildings and more!

Here is a screenshot of the buildings in my 3Ds max viewport without textures. I started to do some research, finding reference etc, making some mockup textures to modify those later. Then I start making the assets, first I make them look realistic like I told before in the blog about the Pick-up. After this I cartoonify the whole bunch to get them the look I want. Then I update the texture where I need to.

Hails,
Eugene

Finalizing mockups

2012-01-11T09:23:00.001+01:00

Hello!

Past few weeks I've been working on multiple projects, but want to give you guys an update on my previous blog. The levels I was talking about a few weeks ago are nearing completion. I managed to get all of the 9 mockups up and running in time. It was a bit of a rush though.

Our game/level designer took the game for a spin and gave me feedback on things to change. We discussed things like the overall 'shape' or 'direction' of a level. This image should explain what I mean by 'direction':

When having a specific setting for a set of levels, for example a jungle environment, it is important that the player instantly recognizes each individual level despite having the same art assets and setting. Next to the 'direction' and 'shape' of the level a different weather/sky setting is also very important. In addition to these basic design guidelines each level should have a specific landmark which amplifies the difference between the levels in the same environment setting even more.

The next step was to finalize the mockups and implement the changes. I usually divide this process in several smaller ones. For example, I always start with the big things first. In this case, I fixed the ' direction' of the levels first if necessary. Also finalizing the specific landmarks per level could be placed in the list of 'big-things-to-do-first'.

At this point every level has the correct shape/direction and landmark we want them to have. Since these levels are for a semi-platformer kind of game the levels need.. platforms! Some of the mockups already had some, but it was far from what it should be in the final levels. I made a set of 'platforms' for every environment setting. This is an example of a platform set in the desert setting:

The last step artwise is to add small objects such as crates, plants/foliage and other background element. These little objects have pretty much no effect on the gameplay, but it is important that they're there. They are the final touches.

If you've been following our facebook page you might know that there are some new xform games coming out soon. All I can say is that I'm very excited about all of them and can't wait to play them myself! :) Keep an eye on our facebook page for the latest updates!

Greetings,
Joep

Can't live without them!

2012-01-06T16:40:00.002+01:00

Hello all!

It's been a while since my last post, so a quick update. In some earlier posts, people blogged about a "snowboard game with cars" about some awesome stuff! And I am also working on that project, so here another "snowboard with cars" blog! The game is getting there week by week. We still got nice ideas we have to implement, but first something about animations!

Last couple of weeks I implemented all the animations for the menu and interface screens that are all designed by Matthew. It was the first time for me to implement animations for 2d screens, so I had to do some research! In the mean time I made notes for all the animations that has an In/Out animation in the scenes. So I made a big list something like the lists Shirley blogged about a couple of weeks ago! So finally I found out how everything works out and I could finally start animating those screens.
It's important to make a list if you got multiple objects that have to be animated. Otherwise you will end up with models that won't show when needed or in the wrong scene.

So after a while it was going pretty well and I felt pretty good about it. Only then I noticed I wasn't even halfway. Nah, it was pretty fun besides all the timing and special animations that Matt created.
So now we got some cool animations for our Interface and Menu instead of just switching the models on and off! Most of them are pretty simple, but you get used to it very quickly. But it's quite important because it's weird to imagine a car driving on the road with wheels that dont spin unless it's year 3594 and we got some awesome floating stuff:P

Greetings,

Michael

Animated Crowd

2012-01-02T18:00:00.003+01:00

The past few days we've been working on our "snowboard game with cars" finish setting which is some kind of stadium filled with animated crowd. We didn't have a lot of time for all this so we used some shortcuts to create this.

One of the most important things to keep in mind when making a crowd is that it must look like there are a lot of individual people. In our game we have 12 different people to make up our crowd. But instead of creating 12 new 3D models we took the games original characters, just two, made some slight mesh changes (a bit fatter, smaller, etc.) and changed the textures.

For most of the textures only the colors were changed. We also switched/removed some hats. The results can be seen below, they look quite varied don't they?

Using these 3D characters in-game to make up the crowd wouldn't be a good idea and most likely cost a lot performance. Instead we chose to display the crowd as an animated texture with four frames. We've made one texture which holds all of the animations frames, these frames are mapped onto planes and are switched in-game by animating the texture coordinates.

And finally we've placed the crowd planes in the stadium resulting in this:

Cheers, Matt

Xmas at Xform

2011-12-23T17:08:00.002+01:00

We wish everybody a merry Chrismas and of course a great 2012! Filled with free games! Greets from everyone here at Xform!

- Diederik, Pieter, Matthew, Joep, Stijn, Eugène, Michael and Shirley

Making meters and New Kids!

2011-12-14T13:33:00.001+01:00

Hello!

Past few days I've been, literally as we call it.. 'Making meters'. Which means that I've been concentrating myself rather more on quantity than quality. My job for this week is to create 9 mockup levels for a new project. Priority number one for me was to get it done as quickly as possible, so that the programmers could continue developing the game itself.

I started by blocking out the levels with 3D tiles we already had from another project. This saved me a lot of time. Using the tiles I was able to block out the 9 mockups. My main focus was.. well to be honest getting myself 9 mockup levels up and running at the end of the week in the first place.

Then, our Game/Level designer is the one to decide if a mockup level's design is good enough or not. He then gives feedback on what to change and add or remove from the mockup. I mean things like: Making the level longer/shorter, making the level going uphill or downhill, adding trees, removing trees, adding/removing a rock here and there etc.

The next step is to finalize the mockups into final levels. This is what I'm currently working on. Trying to change/improve the mockups as much and as fast as possible following the feedback the designer gave me. I'm not able to work on the placement of every rock or tree.. since the final levels should be done this Friday.. And with this project we really have little time to do it. So having the 9 levels all operational is priority number one :)!

Last night we all went to the movie 'New Kids: Nitro'. This movie is uhm.. not sure how to describe this.. strange, hilarious and fun. I think you need to be Dutch to understand it. Anyway, it is about a group of friends who live in a small town called 'Maaskantje'. They are to say the least, not the smartest and wisest people on the planet and they are in a fight with a near by town called 'Schijndel'. Maybe you just have to see it for yourself, see the trailer below:

-- Joep

Shoot those cyborgs to bits!

2011-12-09T16:38:00.002+01:00

Hello everyone!

This is my first post for the blog so I will introduce myself. I’m Michael, new programmer at Xform, started at the same time as Eugene and also worked on the same projects. It’s no coincidence that we started at the same time, because we are brothers. We studied together and done most of our projects together. Also we did our first internship together at Xform. And since then we got ruined by them. And there is no way to undo that so, only one option remains.. Join them!

So we started our first project "Earth A.D."! Uhh?! "Earth A.D." yeah also known as "Shootin’ Cybertrash". The idea was to create the best "web based side scrolling gun and run action shooter game"! A side scroller which has the elements of the good old NES/SNES games.. A game which you really need to play over and over again to become good at. Remember positions of pickups, weapons, enemies. So basically hard as hell, but super fun to play. Can't remember how many games I played on those consoles but some of those titles I do remember. One of those games which also is our main reference is "Contra"! That franchise is super awesome, play as "Rambo" with a HUGE gun and shoot everything to damnation! Every alien, robot or evil being will be blown to bits with your super gun that can switch from normal fire to a flamethrower/ rocket launcher etc.. Took a while to finish it on the NES but it was worth it. Still got the game for my NES, still play it sometime to just get the feeling back of the good old games :P

But enough about "Contra", I was talking about "Shootin Cybertrash"! Hell yeah! We got some nice reference for the game and a nice idea about it. So then "Earth A.D." was created..
We wanted to make it even more difficult then "Contra", so we started to make some mockups with hordes of enemies.."Serious Sam" but then side scrolling :P You think the first level is hard now? In the beginning it was insane! Overdid it too much so we redid it until a hard level was created, but not too impossible :) After a while we needed a more catchy name so "Earth A.D." became "Shootin Cybertrash"!

Some tips.. Just play it a lot and learn their actions and try to dodge their bullets, it's possible, go and see the trailer below! And play the game here!

http://www.youtube.com/watch?v=9f3oBNyn3as

Good luck!

Michael

Let that camera roll!

2011-12-02T17:17:00.001+01:00

Hi all!

I'm back. With a brand new post. About fans.
Not the ones that are standing outside right now, waiting for us to leave the office, screaming our names real loud while taking pictures. But the ones that are truly dedicated to our games.

Fanbase
Yesterday we were having a social media meeting. We have these meetings on regular intervals to evaluate and schedule the online activities of Xform. One of the recurrent topics is our fanbase.
A few months ago I posted about the importance of your target audience. Knowing who your target audience is is really important during the development process. But after the game is released it's still interesting to follow them. You can track down all kind of info by using site statistics.
But another way to learn more about them is to listen what they say. Or even more interesting... see what they create!

Burnin' Rubber Fanvids

Uploading our content
A fun way to take a closer look at the Xform fanbase is to spend some time on YouTube. If you start watching our game trailers on this channel you will also notice a huge variety of homemade fanvideos from our players.
There are Xform gameplay videos, reviews and How To's. They differ considerably in length and quality, but that doesn't matter. The fact that someone takes the time to create a (simple) video about your game to share it with others is very flattering. In fact, it's like a tribute.

How to... Defeat the baboon boss in Rhino Rush:

Area Zero review: (You don't have to understand the language to hear that this guy is really excited!)

And of course some gameplay footage of the extremely popular Burnin' Rubber series:

The value of fanvids
The biggest value of a fanvid is that it shares your game content. It's a way of free publicity. This means it can attract new players to your game. Any publicity will do. In fact a negative review of your game can attract even more players, because they want to check by themselves if a game is really that bad.
An interesting thing happened with the Burnin' Rubber videos that show game glitches. Apparently people find it funny to see things that go wrong. Because instead of keeping talking about these glitches, other fans started to upload their Burnin' Rubber glitches as well!
Another important thing is that fans start to communicate with eachother through the videos. They leave comments, ask for help or give tips and tricks. Based on their discussions you can find out what they like or don't like about your game. And you can use this information for new games.

We noticed that some of our games have a lot of fanvids, others have less. And of course we want to know why this is. So the next weeks I'm going to do some more research on this subject. But now... it's weekend time!
Feel free to add new Xform fanvids to YouTube. We love them. The more the better!

- Shirley

Transformation pipeline and reverse

2011-11-30T17:29:00.001+01:00

Dear readers,

In my current project I needed to have a ray from the camera on the point where the mouse was on the screen. The problem here is: how do we get a three dimensional ray from a 2 dimensional point?

To understand how this is done, you need to know a little about the transformation pipeline, these are a couple of matrices together which convert a vertex position in 3D to a point position on the screen.

The transformation pipeline.

To specify viewing, modeling, and projection transformations, you construct a 4x4 matrix M, which is then multiplied by the coordinates of each vertex v in the scene to accomplish the transformation. The viewing and modeling transformations specified are combined to form the modelview matrix, which is applied to the incoming object coordinates to yield eye coordinates. Next, if you've specified additional clipping planes to remove certain objects from the scene or to provide cutaway views of objects, these clipping planes are applied. After that the projection matrix is applied to yield clip coordinates. This transformation defines a viewing volume: objects outside this volume are clipped so that they're not drawn in the final scene. After this perspective division is done to produce normalized device coordinates. Finally, the transformed coordinates are converted to window coordinates by applying the viewport transformation. The dimensions of the viewport can be manipulated to cause the final image to be enlarged, shrunk, or stretched.

Now when we wish to get a three dimensional ray from a 2 dimensional point, we go the other way around all the way to the eye coordinates. What we actually get is a 3 dimensional point located on the near plane of the viewing volume, but from this we can calculate a ray from the camera.

Point (sx,sy) on screen, to point (wx,wy,wz) and ray from camera.

-- Stijn

What's the name of the game?

2011-11-29T17:19:00.004+01:00

When starting a new game project we usually make up a working title without putting any good thought into it, often it's just the first thing that comes to mind or just something stupid/generic.

Some working title examples of our games are:

"Blaster" for "Area Zero" (nice and generic)
"Super Racert" - "Power Driving" (Yes the "t" is intended)
"Super Kart Game" for "Go Kart Go! Turbo" (Super Mario Kart was already taken apparently)
"DressUp Game" for "Girly Trends 3D" (another great generic working title)
"Joep VS The army of the Damned" for "Army of the Damned" (for the record: Joep is our technical artist)
"Ground Zero" for "Traffic Slam" (Guess we can't use that name anymore since 9-11)
"Jetski Game" for "Hydro Storm" (Couldn't use the term Jetski in the name because it's originally a brand name)

To come up with a working title is easy but to come up with a final name can be quite hard, this is also the case for our "snowboard game with cars" we're currently developing.

Last week I needed to update the game logo which currently reads "Auto Games" to a more final design, I needed the game's final name to do this. In order to come up with a name all Xform employees have the opportunity send in suggestions which for 99 percent are totally stupid or unusable like "Super Car Olympics 2011 Deluxe Edition".

We do collect all these suggestions and start making lists with associative words. For example we know the game takes place on snow covered mountain tops so words like "snow, piste, mountain, snowstorm, deep, cliff, steep" are written down in a list. When the list is completed we start mixing these words and making different combinations and see or they match the game.

For "Auto Games" we came up with "Snow Stunt Heroes", this name focuses games stunts and drivers instead of the cars. The word snow is added to give a hint in what sort of environment the game takes place.

Finally the client has to approve this title, we'll know if this is the games final name at the end of this week, otherwise we're back to making lists.

Matt

Pickup Convertible!

2011-11-23T16:58:00.001+01:00

Hello all!

Last couple of weeks I have been working on the super awesome snow game with cars! It will rock!

I’m going to show you one of the cars I have been working on.

The idea was to have a big car in the game like a truck or a pick-up.
First I started to look for some reference before rushing into 3DS Max.

After collecting tons of pictures of pick-up trucks I’ve chosen a couple pictures to be my main reference. Now I can finally start modelling the pick-up truck!
I used a blue print of a pick-up truck for the silhouette.
After this I added some details, bumpers, rear lights, front window, etc.

Now the most fun part of all! I had to “Cartoonify” it! Hehe.
First I had to take of the roof! And make it a Pick-up convertible,
ever saw something like that? :P

To make things more Cartoony, I had to make things out of proportion,
over exaggerated some details.
To give it a big and clumsy look, I made the bumpers way bigger, added a broken license plate, made the lights and side bars bigger.
I added two vertical truck exhausts for a more tougher look.

And this is the screenshot of the outcome when I was done!
The texture will do the rest and finishes the job.
But you will see that later!

And now back to work!

Hails,
Eugène

Character animation

2011-11-17T09:01:00.003+01:00

Dear readers,

This week I've been working on character animations for our top secret SSX-with-cars project.

Character animations in 3D are most of the time done by using a relatively simple skeleton, matching the general shape of the character's mesh. These skeletons include all of the important joints that are needed to create the required deformations. The mesh of the character itself is linked to such skeleton. When a bone moves, the related vertices of the mesh move with it. The proces of linking the vertices of a mesh to such a skeleton and the creation of a skeleton itself is called 'rigging'. After the character model is rigged properly, we can animate it.

The animations are created by making keyframes of the skeleton, not the mesh. A keyframe in 3D is basically a pose of the skeleton at a specific time. I always start by creating the most extreme poses of the animation. For example, I was working on an animation where two characters were highfive-ing:

Click to see animated GIF

I created the starting pose and the pose where the two hit eachother with their hands. These two keyframes are seperated by empty frames. The computer calculates the motion between these poses/keyframes. At this point we only have the motion and timing of the animations but it is far from finished. The motions of a bone from one keyframe to another can be displayed by showing its trajectory. These are pretty much straight, from one point in 3D to another. But when having the highfive animation, I want the arms to swing. Therefor I have to adjust the trajectory. This can be done by adding extra keyframes in between. This adjusts the curve of the motion. Most of the time I use only one extra frame, because adding too much frames can cause jittering and unsmooth motion.

- Joep

Faking car physics

2011-11-11T12:14:00.002+01:00

Dear readers,

Today I'm going to write about faking car physics, in particular adding a sense of weight to the car. What I mean by this is as follows: when you see a car breaking you'll notice how the car tilts forward as the center of mass moves forward. In the same way when a car accelerates you'll see how it tilts backwards. Likewise when a car turns left, it banks rights and vice versa. See these images:

Car tilting forward

Car tilting sideways

To fake this effect I'm applying two extra forces on the car: one force that lifts the car and one force that pushes the car down. The trick is to find the proper points.
See the following image:

Applying a lifting force (arrow up) and pushing force (arrow down).

Here we have a lifting and pushing force that are moved along the red circle. The lifting force is always directly on the opposite side of the pushing force on the circle. In this particular situation we are pushing the nose down and lifting the back which corresponds to a car that is decelerating. Other situations can be done in the same manner.

So now, given the car speed in global coordinates, how do we find where we position the lifting (and pushing force)? First we store the difference in speed between the last frame and the current frame: this is our deceleration/acceleration vector and determines where we are going to apply our force. This vector should be in car space (not global space) and determines where we apply the lifting force. The larger the length of the deceleration/acceleration vector the stronger the lifting force. At exactly the other side (simply multiply the position of the lifting force by -1) we apply pushing force with the same strength.

This should already work nicely, but a problem with the circle is that the car is longer than it is wide, as a result if we apply the same forces the car will bank too much and even flip the car. So we have to correct for this by either changing the forces when they're applied near the side of the car or change the circle to an ellipsoid. Either should work fine.

-- Stijn

The things that you (need to) do

2011-11-04T16:43:00.002+01:00

Today I want to tell you something about task management. Maybe it's not the most exciting subject, but it's something (game) projects simply can't do without.
And in the end... you're glad you're using it!

But first I like to start with an update about the good stuff of the Xform life this week:
- Watching Gremlins during our lunch breaks.
- Eating some very delicious cake.
- Our intern Sander passed his drivers test.
- We found a dead rat in our office.
- We're working on 6 new awesome browsergames!

And with this last point we're back on topic: task management. Because Xform is a small company, most of the time the people here are working on more than one game project.
When working on a project, for you it can be quit simple to remember what you have to do and in what order. But when you're part of a team not only your tasks that need to be done. Everyone has his own list of activities. This means you'll need someone that can keep the overview. And for our game projects it's my job to do that. Sounds easy. It's not. 'Cause when there's too much to do (and believe me, there always is) it can get quite a mess.
For example: at this moment we're working on one of our new car games. Although there are just a few days before we reach the Beta milestone, there are still 36 tasks to do. Try to memorize 36 things that need to be done, in the right order. You simply can't. That's why we use Intervals, project management software that helps me to control all tasks and milestones.

To manage tasks you need to know exactly:
1. What needs to be done.
2. Who has to do it.
3. When it must be completed.

Tasks always take time. Even the small ones. And it's those little activities that are easy to forget. When you start with task management it feels weird to schedule tasks that only take less than half an hour. But they're part of the project, so they need to be managed as well.
That's why we at Xform don't only schedule our milestones. We schedule every (!) single, little task. This gives me a complete overview of the entire project and I can easily see what's finished and what still needs to to be done.

In between all the management stuff, I still find some time to create the game trailers.
Here's the one of Area Zero:

Play the game here and have a nice weekend!

- Shirley

Stunt Double

2011-10-31T17:23:00.001+01:00

A few posts back I mentioned we were working on a new game prototype which was basically a downhill ski-game with a special twist. Well the special twist is that in this game you're driving a car downhill while slaloming, grinding and jumping insane ramps!! It's like SSX but with cars!

The prototype proved to be quite fun to play so we got a go on this project.

There was one problem we've soon noticed while playing the prototype: the car stunts looked a bit boring when the cars only turned, rolled and twisted in the air. It missed that extra wow factor you need in an "extreme sports" game like this.

Another problem is that cars can't really give the player any feedback when successfully performing a stunt, we could have shown some sparks or particles but that wouldn't look very impressive.

Then someone here got the ingenious idea to turn the cars into cabriolets and put two characters inside. Now we're not only limited to car stunts but we can also add character stunts and even combine them. This change made the game instantly more fun to play and by adding the characters we can give the player much more feedback by making them wave, cheer and shout. It also adds to the overall arcady feel of the game.

Work in progress image of the two characters inside a dummy car.

One of the drawbacks is that this decision does add to the complexity of the game, beside relatively simple the car animations we also have to animate two separate characters which also have to interact with the car and each other. We do think this extra effort will set this game apart and make it much more attractive and fun to play, I guess we'll know in a few weeks when the game is released.

-Matt

Shootin’ Cybertrash!

2011-10-26T16:04:00.002+02:00

Hello all!

Let me first introduce myself, my name is Eugène and I now work at Xform for several months as a 2D/3D Artist and it’s a hell of a job! :D

I’m going to tell you about my first project here. It is an unannounced game, not released yet. I am not sure if I can talk about it or show much of it.

But what I can tell it’s a “Browser Based Side Scrolling Gun and Run Action Shooter” game with 3D graphics! We tried to give you the feeling that you are playing an old school 2D Shooter game of the Nes/Snes era! So expect a difficult game!

It takes place in a destroyed Earth and you have to make your way through hordes of enemies and tons of explosions with a kick ass character! This game will rock! Ha!

For this project I’ve been working on the levels, menu’s, modelling and texturing stuff, placing dummies (enemies in game) etc. In every level you will face enemies, hard jumps, upgrades and more. Some enemies are placed in really sneaky places where you don’t expect them!

Here is a sneak peak of one of the levels.

This is a print screen of my viewport in 3DS Max. You can see some dummies which are in the game enemies. The big blue boxes are “camera triggers”. If u pass these objects (you won’t see them in game so don’t worry) the camera will zoom towards or away from the player to gain a better view of your surroundings and what lies ahead. The explosive objects.... I think those things don’t need any explanation of what they do!

This game is going to be called “Shootin’Cybertrash”. We will keep you updated about this project. And wish you all good luck in completing this hard game hehe, when it is released of course. J

Well this was a little introduction of myself and the game where I’ve been working on. Next time I’m going to talk about the project where I’m working on now.

Greetings,

Eugène

Jumps!

2011-10-19T17:29:00.000+02:00

This week I've been working on a 3d mockup environment for a new project. It is going to be a car game. I can't tell you that much about it yet though.

The game does feature big jumps, they are actually a big part of the game. These jumps should be easy, spectacular and inviting for the player to take. The player should be able to just drive on a ramp, perform the jump and land almost perfectly on the other end without much of trouble to continue driving. It was my job to test several jump setups using the mockup to see what kind of distances, heights and speeds we should use. We also wanted the jumps not to be too low in height, it should look spectacular!

The first step I took was to gather information of what we already got. I already had a test version of the game with the main physics up and running, so I could check how the car behaves on the mockup. I knew that our car has a certain speed at the moment of jumping, behaves in a certain way in the air and while landing. I was not able to change the car speeds/handling for this test. I started by just setting up a simple jump over an imaginary river or cliff. I used big numbers to quickly test what works and what doesn't. For example, the first jump I made was planned to be 10 meters in length. This jump felt way to short, I instantly jumped over the landing zone. Therefor I increased the length by, easy numbers, 10 meters. So now I had a jump of 20 meters in length.

This was already more like it, but still a bit to short. Most of the time I still landed to far over the landing zone, so the distance wasn't far enough and I increased it by another 10 meters. This did the trick and I was now able to land pretty much perfect in the planned landing zone. However I wasn't pleased by the height of the jump, it wasn't high enough. I started tweaking the ramp, to get more height out of it. First I tried 'straight' ramps, not curved. This worked fairly well but gave a harsh ' bump' while driving on the ramp when it got steeper. Curved ramps was the solution, and gave the car a smooth ride into the air.

Now the jump was looking good and it felt 'big'. However changing the height of the jump also influences the jump distance. I reduced the jump length by 5 meters, and reduced the angle of the ramp slighty which gave a perfect jump with good height. The hard part is to give the player enough air time to enjoy the view as well as making the jump not to short in length. I hope to be able to tell you more about this game soon, it is going to be a pretty interesting project :)!

-Joep

Skidmarks!

2011-10-13T09:52:00.000+02:00

Hi!

It’s been a long time since I wrote something. Too be honest I didn’t have anything worthwhile to write about as I was hands deep in deploying our new augmented reality kart racer. Play it on www.redbullformulaface.com. It is great fun!

At the moment I have a bit more time to look into other things. A couple of years ago we did a small kart game (http://www.shockwave3d.com/gamepage.cfm?id=794) which was extremely fun to work on.

The last few years we occasionally put some time into expanding it, so we have quite some stuff lying around to make a ‘new’ game. Well, we’re not actually remaking it… it is not really a sequel… it is more a ‘rebuild’ with additional stuff. Nevertheless, it was time to finally upgrade and implement skidmarks!

I’ve been tackling skidmarks for quite a while now. I found it to be harder than I would like. Not really the technique behind it, but more in an Adobe Director kinda way. There were three options I looked into.

1. Create small transparent planes at the bottom of each wheel. Place them each frame or after a certain threshold distance compared to its last stored position.

2. Draw into a texture. Have an additional texture layer and paint in it where the wheels are. If you have a lightmap texture you could also draw into that one, I think.

3. Build a mesh trail.

Honestly I didn’t do any real stress testing on the first two as I already knew they weren’t really viable. Although I’d really like solution 2. In the end there shouldn’t be any performance issues on how many skidmarks you have and above all they will be displayed indefinitely! Solution 1 and 3 need to be ‘tempered’ so performance won’t drop too much. Unfortunately, I still think it might be too slow to do any additional raycasting and lookups to know where you should draw into the texture. Furthermore, you can’t directly draw to any texture in the VRAM in Director, so when updating skidmarks you constantly have to send the texture to the VRAM as well. You’d also want a decent texture resolution or else your skidmarks would look like huge blobs. All in all this will cost too much CPU power and performance will drop. A cool solution, but currently not feasible. I went with the 3^rd option.

A couple of our games feature rockets. The rockets leave a trail behind when fired. I used this as a base to create a skidmark feature. The very first version of this effect would rebuild an entire mesh each frame (or each update). Meaning the mesh could become very large, complex and time consuming to update. I rebuild this effect with two optimizations.

1. The mesh uses a maximum amount of vertices and faces. It is created as a long segmented plane. I build this mesh beforehand (or sometimes I store more of them to be used and reused) so we can avoid any performance drop when creating a skidmark. The downside is that the mesh and detail is limited. So a trail or skidmark cannot be very long. The mesh will also get 2 sets of texturecoordinates (and a new shader). The first layer is a tileable texture. The second one a transparent texture (a gradient), so we can fade the trail at the end.

2. All vertices are initially placed at the location where they should spawn. Each frame (or update) all 2 vertices (of each segment) will get the position of the 2 vertices (previous segment) before them in their vertex list. So i.e. vertex 5 and 6 will get position 3 and 4. The only exceptions are vertex 1 and 2. This will be set to the source of the trail/skidmark. So each update we 'move' the mesh 'along' the previously stored positions.

These updates made it much faster. So ‘fast’ that at my current work machine I can have multiple sets of skidmarks for 8 cars at the same time. Not sure if this will make it into the final game, but it is worth testing J

-Pieter

A math problem

2011-10-05T11:01:00.002+02:00

Dear readers,

Today I'd like to write about a little math problem. Pieter came to me asking if I could find a function with some desired properties. To give a simple example of why this could be useful: Suppose you want to make an animation of an object bouncing by simply changing the y position of the object. For this you could use a function that given a certain time in the animation returns you a number which you can use as the y position of the object. You can easily control the animation by adjusting the function and you can also easily skip to any part of the animation.

Now for the problem: Pieter wanted a function f(x) where the following properties hold: f(0) = 1, f(10) = 10 and somewhere between x = 0 and x = 10, let's call this t, the function should reach it maximum point at 12, so f(t) = 12. The image below shows the function he was roughly looking for:

The red line shows the possible function. The blue dots represent f(0) = 1 and f(10) = 10. The green line represent y = 12 where the function should reach it's maximum, we call this value t.

Now we could of course use a spline that is fitted to the function, but this is not as efficient (or as fun) as a parabola. A parabola is a second degree function of the form: f(x) = ax^2 + bx + c. So how do we find the a, b and c values? We start by substitution of the desired points. For f(0) = 1, this becomes: f(0) = c = 1. So c = 1, that was easy. Now for f(10) = 10: f(10) = 100a + 10b + 1 = 10, simplified to: 100a + 10b = 9. We have 2 variables here and only 1 equation, to solve for a and b we will need another equation. The problem now is that we don't know a third point which would give us another equation. We could try to just guess a point, for example f(6) = 12, but the resulting function will not have it's maximum at y = 12, but higher.

The crucial thing here is to realize that when we reach a maximum the derivative of the function in that point is exactly 0. For a parabola the derivative is of the form: f'(x) = 2ax + b. We can use this to get another equation as we want to reach our maximum at t (it does not matter where t lies as long as it's between 0 and 10). So we want that f'(t) = 0. Using substitution we get: f'(t) = 2at + b = 0. Good, now we have the 2nd equation we were looking for and can solve for a and b you might think. But unfortunately we've added another variable t, so now we have 3 variables and 2 equations! That didn't seem to help us very much then... But wait :) Let us now try to express a and b using t. Using the equations 100a + 10b = 9 and 2at + b = 0, we can express b as b = -2at, plug this into the first equation to get 100a - 20at = 9, from which we get that a = 9 / (100-20t). We can then substitute a into b = -2at to get b = -18t/(100-20t). So now we have our a and b expressed as t to get the following function: f(x) = (9 / (100-20t)) x^2 -18t / (100-20t) x + 1.

Now remember that t is the point where the function has its maximum which we want to be at 12, we can express this as: f(t) = 12. From this we get another equation: f(t) = (9 / (100-20t)) t^2 -18t / (100-20t) t + 1 = 12. We simplify this and get: -9t^2 + 220t - 1100 = 0. We solve this using the abc-formula and obtain two values for t, namely t1 = 7.011 and t2 = 17.43. Clearly t2 is not between 0 and 10, so we pick t = t1 = 7.011. We then plug t in to a and b and get the final function: f(x) = -0.22377 x^2 + 3.13769 x + 1. Which can be seen here:

The final function with the desired properties: f(x) = -0.22377 x^2 + 3.13769 x + 1

-- Stijn

Level of detail

2011-09-22T15:19:00.000+02:00

This week I worked on some bugs of the robot shooter. There was a descent list of fixes, tweaks and optimalizations after the first QA session. The last one, optimalization is what I want to talk about today. In this case I want to look into simple, or high level optimalizations.

First some theory to start with. Games in general are rendered realtime to your screen and displayed using 'pixels'. Imagine having a 3D model displayed close to the camera. It fills up a lot of pixels with its shape, texture and polygons, because it is relatively close to the camera. We could say that how closer the 3D model is towards the camera, the more pixels it uses to display itself. Since it uses so many pixels, we are able to see all of the details of the model.

Now, when moving the 3D model away from the camera, it eats up less pixels to draw itself. Sounds logic right? This means that a single pixel on our display covers up some of the detail we have in the 3D model. We could say that the model is less detailed displayed than it actually is. While it is still being processed the sameway, with all of its details. Which actually costs performance. Therefor we could replace the model by lower resolution version of itself, if the model is on a certain distance. A system like this could be called a 'LOD', or 'Level Of Detail', system.

Model and image by Owen Shepherds

In our robot shooter it is possible to turn on pixel shaders, which is render bit slower than the regular hardware shaders. In fact, when playing with a descent amount of enemies displayed on the screen using these pixel shaders, there is a noticable delay. We had the same problem in 'Army of the Damned'. Pieter wrote a little 'LOD' system which switches shaders on enemy models. They switch between the regular shader and the pixel shader. This speds up the game a lot and is barely noticable (visual wise) for the user. Since we had the same issues in the robot shooter I took Pieter's system and made it work with the robots. This, as expected, improved the peformance.

There are some drawbacks though. The system in this example uses 'distance to the camera' checks to know what to do. Distance checks can be expensive too, and sometimes can be even more expensive than just rendering extra polygons or models with a bit more complex shaders. But keep in mind that these LOD systems don't require to be updated every frame, which can also speed things up. It is all about finding the balance between direct optimalizations and LOD systems.

-Joep

Xform Games - Gotta play 'em all

2011-09-09T14:50:00.000+02:00

Hi all,

The last couple of weeks we are very busy completing some of our bigger projects.
And because I think they all deserve a lot of attention and everyone should play them, I like to update you on our latest releases.

Army of the Damned
First of all there is Army of the Damned, the first person zombie shooter that many of us already have written about. The game was released on August 10th in two editions: a less gory version on Shockwave.com and a bloody version on AddictingGames.com.

Check the Army of the Damned official trailer:

And you can play the game here. (Don't worry, it's a link to the bloody version!)

Red Bull Formula Face
Secondly, last week Red Bull Formula Face (our super secret project) was launched.
A game totally different then our zombie shooter, because you won't see any blood. And it's not just a kart racing game. It's a kart racing game with mimic tracking! Yes, you have to control the game with your face.

Of course, we alse made a trailer for this one:

And don't forget to play at RedBullFormulaFace.com.

Robot Shooter
As third, we are working on a Robot Shooter. You can scroll down this page for some preview images. This game isn't released yet, but we work hard to bring you this awesome free online shooter as soon as possible. You may expect this new game in a few weeks.

Between all our busy schedules we still found a little time for a trip to Cologne, to visit Gamescom. It was a long, long, but really great day! With a lot of games. And beer!

Grüße aus Köln!

- Shirley

Particles again!

2011-09-09T10:14:00.001+02:00

Dear readers,

The last post by Pieter was also about particles, but as I'm working with different software we have to redo some of the particle work. I'll go a bit deeper into the details of the implementation.

First of all a particle is a simple quad (but in general doesn't have to be) which always faces the camera. To make particles always face the camera we could calculate the transform needed for it to exactly face the camera. But doing this for all particles on screen is a bit expensive. Instead we simply take the rotation values of the camera and apply it to all particles. The effect of this is that not all particles are exactly facing the camera but they are roughly and the difference is not really noticable and it's a lot cheaper CPU-wise.

Second, the spawning and deleting of particles is expensive. Instead we're using a particle pool. In this particle pool there are only unused particles (not in the scene). Whenever we need to spawn a particle we take it from the particle pool, assign properties and add it to the scene. When the particle has to be removed, we're not going to delete it, but we return it to the particle pool. In this way we avoid the expensive operation of spawning and deleting particles.

Third, particles often fade out by using changing the alpha (transparency). Currently the only way we can change the alpha is by changing the material. In this case it would mean we cannot share the material across particles as changing the alpha of one particle would change the alpha of all particles. Using one material per particle would be possible but is very expensive as per material it requires shader program switches on the GPU. So we want one material for all particles but still change the alpha per particle, what now? Well, we can still change the UV coordinates of the particle (quad) and have different images with different alpha settings. We do this by using one large image which has several smaller images in it, see image below. For the first image we change the UV Coordinates to be between 0 and 0.125 (on the 'x' axis), for the second image between 0.125 and 0.25, etc. This functionality is also useful for animation.

Until next time!
-- Stijn

Faking a complex 3D background

2011-09-05T16:11:00.000+02:00

For our latest game we wanted to create an impressive looking start screen where a camera moves around the main character in a "frozen" 3D environment. We wanted the environment to look detailed with lots of enemies and action going on, but we also wanted to keep the file-size small and complexability low to keep the downloadtime short and system performance high.

We tackled these issues by creating a scene where only the main character and some small effects are true 3D models and where the rest of the environment is displayed as a panoramic texture mapped onto a sphere.

A panoramic texture can easily be rendered in 3ds Max using the Panorama Exporter which can be found in the Utilities panel. The result is a distorted looking image which looks normal when mapped onto a sphere and when viewed from the spheres center. The images below display the rendered panorama image and the Photoshop edit which was used for the final scene.

The next image displays the final 3D scene for the start screen.

Here the panoramic texture has been mapped onto a sphere, the spheres bottom has been flattened so it won't look like the 3D character is hoovering above the floor. A plane with the characters shadow is placed below the character to make it fit better into the scene. There are also some extra objects like bullet streaks, impacts and a big muzzle flash coming from the characters gun which exaggerate the 3D effect when moving the camera. The cameras cannot be moved outside of the sphere and moving the cameras closer to the center results in less distortion of the panoramic image.

Here are some screens of the final result.

Cheers Matt

Technical Talk

2011-08-24T08:31:00.000+02:00

During the development of Army of the Damned we also started another first person shooter project. The plan is to create a similar game like the zombie game, but with a more arcade type of gameplay and graphics. Today I want to talk about how we are going to do the 'Shooting' in this game. You might think, 'Well it is a first person shooter just like all the others, so what is the point of discussing this?', which in fact is pretty much true. But what we want to do is make all of the bullets visible. Not just instant hits, as we did in the zombie game. The main reason for this is to amplify the arcade feel of the game. It also changes the experience slightly, because it takes a slight amount of time for the bullet to hit it's target.

The technical difficulty of these visual bullets doesn't come with the bullets themselves. They just function on their own. When spawned they move forwards, if they hit something they die. And while a bullet is 'a life', it is visible to the player.
The problem comes when shooting the bullets, or better said, spawning the bullets, from the first person perspective. Normally what you can do to 'shoot' from a first person camera, is just to shoot a ray down the center of the camera's transform into the 3D world. If it hits anything create a bullet hole, hit an enemy or something else depending on what the ray hits. But when having visual bullets, and a visual weapon in view where the bullet appears to be coming from it isn't that simple.

This figure shows our problem:

If we just spawn a bullet at the end of the weapon's barrel, and shoot it in the direction the barrel is facing it will never get to the target the player's aiming for. It does go in the correct direction in general, but this will be unusable when having targets on a decent distance. It will also look very strange because the fired bullets won't move towards the displayed crosshair in the interface, which makes the crosshair in fact pretty useless.

The solution is to shoot a ray first from the camera, the same way you would do when shooting 'directly'. This should give you some sort of intersection point in 3d space. Then it is time to cheat a little. The bullet we are about to create should spawn at the end of the barrel, but not be pointed in the same direction as the barrel. Instead it should be pointed at the intersection point we got from the ray. This will make sure that bullets always travel towards the target or object the player is aiming at. It will look correct because the bullets will always move towards the crosshair in 3D space.

The only problem occours when the first ray fails. We don't have a reference point. A simple but yet effective solution to this problem is to calculate a intersection point far a way from the camera. And then point the bullet to that new location.

Until next time,

-Joep

Pimping art for stills and print

2011-08-05T17:52:00.002+02:00

The past week we've been finalizing our zombie shooter "Army of the Damned". At this stage we need to prepare the artwork for marketing and print purposes, which of course has to look much better then in-game screenshots or standard renders and also must have a much higher resolution. Luckily I took this into account when creating the game's main menu which in-game is displayed at a resolution of 800x450. For this image I tripled the size to 2400x1350 pixels, which is more then enough for what we want to do with it.

It's always good to figure out what you want to achieve with the image before starting on the artwork, this will keep you from creating art which in the end you don't need.

For this image I wanted to show a detailed player character, some zombies closing in on him and a plane dropping a bomb in the background while keeping in mind the title and menu would be displayed on top. I also wanted the image to have a grindhouse look. After some quick layout sketches I posed the 3D characters and rendered an image which can be seen below.

As you might have noticed the rendered image looks a bit bland, the big zombie on the left has too little contrast and there is no clear light-source, no problem we're going to fix all this in Photoshop!

First we need to determine where the light comes from, in this case most of it will come from the explosion in the background. In Photoshop I placed a layer on top of the character where I painted the lit areas with an orange color and set the layer to color dodge.

On another layer I painted the shadow area's with a dark color and set the layer to multiply.

Next I added the background which is composed out of a sky, mountain, plane and explosion image. I also added some smoke coming form the gun muzzle.

The image is getting there but it still looks too clean and the background looks too detached from the foreground. First I added some noise on top of the image and a "scratched film" layer to make the whole thing look old.

When you look closely you might notice the left side of the image has a red hue and the right side a green hue (red=bad guys, green=good guy). This is achieved by adding layer on top set to color dodge (of soft light) and lightly using a red and green brush.

Finally I placed another layer on top which is set to overlay, with a white brush I painted over the area's which needed to be more brightly lit. These where mainly the explosion area and the players chest.

So that's how you pimp an image!

Cheers, Matt

The zombies are coming..

2011-07-27T10:41:00.001+02:00

Hello!

Time for another blogpost today. First of all I want to bring some good news.. Our zombie shooter is nearing completion, it is almost done! Last week we did some playtesting to find and fix bugs and glitches. But we actually couldn't stop playing the game itself! Stay tuned, the trailer is coming soon ;)

Screenshot Zombie Shooter

The playtesting, or QA (Quality Assurance), is very important. A game, when released, should work. And not just be filled with bugs. During this process bugs are found and listed to be fixed after the QA session. If someone encounters a bug while testing. He or she creates a so called 'QA Ticket'. The bug or glitch is explained in the description of the ticket and also the steps to reproduce the bug are written down. This in particulary is important, because the programmer who's going to fix the bug can reproduce it for debugging. Imagine something very simple like this:

Problem: The sound isn't muted when pressing 'Mute Sound' in the options menu.
Procedure: 1. Start the game 2. Go to the 'Options' screen 3. Clik the 'Mute Sound' button.

This is a straight forward bug, and probably not so hard to find and fix. Bugs that occour during gameplay are much thougher to reproduce. Sometimes the player needs to be at a specific location within the game world. If so, we add a screenshot to the 'QA Ticket'. So the programmer can go to that location in-game, and follow the steps to reproduce the bug. Instead of starting a process of 'Trial and error' just to reproduce the bug in the first place.

The next step is to fix the bugs ofcourse. First the blocker ones, the bugs that cause game freeze's or prevent the player from making progress. What I mean by 'Making process'; A gate for example that should open after some actions, and it doesn't. The player is then not able to walk through it towards the end of the level, and thus not able to finish the level. Then the other critical bugs are fixed. Such as sound/music bugs, graphic issues, getting behind the boundaries of a game level where the player shouldn't be etc.

If the blocker and critical bugs are fixed, a new QA session is behing held. The QA process starts again until the game is ready for release.

Happy QA'ing ;)!
-Joep

Tell me who you are

2011-07-15T16:15:00.006+02:00

Hello developers/fans/people who accidentally landed on this site,

Today we have tested one of our new games, which is (surprisingly) a super secret game.
Of course this is a very interesting process. If you like to read more about test days, you can read about it in an earlier post of Stijn.
But unfortunately for this project there's not much to tell, because the game is such a big secret. Instead of boring you by telling how great this game is going to be and that you can play it really soon, I like to tell you about something else: target audiences.

Target audiences? Why?
As you may already know, at Xform we like to make games that we ourselves love to play. But that doesn’t mean we don’t listen to our player base. We just want to know who they are, where they are from and why they especially like to play our games.

Target audiences are very important. For every product. For every game. Whether you are creating console games, mobile games or browser based games, you need to know what kind of people (are going to) play your games.
Are they kids or adults? Male or female? At what age? When do they play games and how much time do they spend on it? Do they play alone or with friends?

Knowing who they are and what they like is very valuable information when making a game. It’s most common to use this information for marketing and promotional activities, but you can also use it for game design.
This doesn’t mean you should base the entire game production on target audience facts. After all game development is a creative process and it is fun to surprise your audience with things they don’t expect. But, for example, if you know that your type of game is mostly being played by people that do not spend more than half an hour per day on gaming, then it doesn’t make sense to create levels with loads of side quests and fights that will take at least two hours to finish. Although this may seem quite obvious, there are just too many games that don’t match with their target audience.
You can also use your target audience analyses to treat your audience on extras like special enemies or funny easter eggs. They will appreciate it!

How to define my target audience?
To define your target audience you have to do research. And of course there are millions of options to start with this.
If you have a lot of money you can spend it on an exclusive research institute that will do all the work for you. Or you can hire some specialists and start a research department at your own office. Unfortunately, at Xform we don’t have this opportunity yet. We have to do the research by ourselves, which is actually very interesting.

My advice for starting with your research is to keep it small and simple. Stay close to your company and take advantage of all the information about game target audiences that already exists. Believe me, you can spend hours on reading books and web articles about this. Now it’s your task to find out which information is valuable for your game.

If this is the first game you’re working on you might start to take a closer look at similar games from the same type of platform. What kind of people play this games? They might want to play your game too.
When you already developed some games you can also do research on these games. Find out what’s the target audience from your previous games. Internet offers you some interesting tools that might be useful for this. Every social media site has an option to track down user data and information from your fans.

We also started to use Google Analytics for our Xform website to see who are interested in our company and games. So now we can see how many and for how long people visit our site, if they were looking for something in particular or that they just accidentally stumbled upon it.
A lot of information might surprise you. I didn’t know most of the visitors on our homepage are from Brazil:

visits on the Xform website (last two weeks)

Have a nice weekend!

- Shirley

Replay fun

2011-07-13T16:55:00.004+02:00

Dear readers,

I've been working on another car game and last friday afternoon after doing some boring stuff I felt like doing something fun and that could be done quickly: a replay function. None of our games currently have this, but for the game I'm doing now I think it would really add something.

Before we can replay anything of course we need to record. The first thing that comes to mind is to simply store our key input and on replay the stored key input is used as input for the car. But as we're using a physics engine which I don't trust to be deterministic (the same input results in the same output) it would lead to a different replay which of course is not what we want.

Another approach which is easy and sure to work is to store the transforms of the car each frame in a list and when on replay simply go through the list and setting the car model to the stored transform. This is what I currently do and it works well. But let's analyze it. We're running at 30 frames per second and thus storing 30 transforms per second. For each minute of replay we store 30 * 60 = 1800 transforms. Assuming each transform is stored as a 4x4 matrix of floats, so 16 floats at 4 bytes per float: 64 bytes per matrix. And so for each minute of replay 1800 * 64 = 115200 bytes. Considering today's RAM capacity in computers this is peanuts. But this of course is only for a single car and additional actions have not been recorded (for example car damage, firing of weapons, etc). One way to reduce the size of the replay list would be to store the transform every X frames and interpolate between transforms, although you do lose accuracy with this approach. Another way is to only store transforms when they've changed 'enough' with respect to the previously stored transform. In this way a car that does not move would not cause the replay list to increase in size.

With a replay you can think of simply watching what you (or someone else) did. Currently I implemented it as a replay while you're playing: like a ghost rider (See image below). In this way you get the feeling you are competing which in my opinion adds to the fun and I hope the option will be there when we release the game.

Image from 'BMX Ghost'. A ghost rider is shown displaying the best round you previously played.
-- Stijn

New prototype

2011-07-13T16:47:00.003+02:00

Hi all,

A few weeks back Stijn started programming a new game prototype which is basically a downhill ski-game with a special Xform twist. Last Monday I was put on the project to create a track and some (temporary) graphics for this prototype. The game just needs to look and play good enough to get a good impression of what the final product could be, therefore I won't put a lot of time in designing and fine-tuning the track. I'll keep you guys updated on this project when (and if) it goes into full-development.

Cheers, Matt

New Game Sneak Preview

2011-07-05T21:07:00.002+02:00

When you don't have anything to write about you can always post a super secret screen of an upcoming game!

Greets,

Diederik

Baking data..

2011-06-29T16:26:00.003+02:00

During development of the zombie shooter we were experiencing an increasing amount of loading times due to all of the new features which got added. This isn't unusual, since it is something logic as cause and effect. But the loading times were getting a bit too long. So we decided to take a look at it to find out where we possibly could find a speed up.

Some technical systems in the game use a lot of data calculated/generated during the loading stage, which takes time. One of those is the pathfinding system which uses the most data at the moment. It generates all of the node data needed for the zombies to walk from A to B during startup. As you can imagine, having a decent amount of nodes to be processed every time the game loads up takes time. Too much time in fact for our needs.

So how to solve this. Since it is a system which is 'calculating' things to be stored in the computer's memory for realtime use after loading, it is possible to capture this calculated/generated data. The trick is to save this generated data and store it in some sort of file from where it can be loaded directly during startup of the game.

Now having the data we need saved in a file, it doesn't need to be recalculated/regenerated anymore during loading. We could say, the (navigation) data is baked into a file. With the data already present in a file, it is possible to directly load the data into the computer's memory instead of calculating it first during startup. This is much faster than calculating/generating the data on every startup of the game.

The main drawback of doing things like this is the need of recalculating and saving data everytime something relevant to that data has changed in the game. The plan is to create a system which automatically detects changes, or at least is possible to force into a mode where the already saved data needs to be overwritten by new generated data.

A lot of technical talk, hopefully next post some more images ;)

-Joep

Particle stuff!

2011-06-22T17:45:00.007+02:00

Hi all,

Unfortunately, most of the time I am working on ‘secret’ projects or projects on which we simply cannot share as much as we would like. So this post will be about something I am doing in my ‘spare’ time. At least what is left of it ;)

As some of you might know I am a big fan of everything that involves particles. Especially explosions!

Unfortunately, Adobe Director’s own particle system doesn’t really suit my needs. It is ok for a lot of quick things but for the games we make it is a little outdated. For example; you cannot rotate or animate particles individually and you don’t have any blending options (additive blending) yet. Finally, there is no general time or speed multiplier for the entire particle system. Our games sometimes feature slow motion and so we’re unable to dynamically change the speed and lifetime of the system. All in all it was time for our own particle system. So about 10 games ago (more or less,..) I decided to create my own particle system from scratch.

At this time, 10 games later, I still haven’t got a perfect particle system up and running. Mostly because I noticed early on that creating a system that could do everything that I (or one of my colleagues) want is simply not possible. The variations are impossible to count. Furthermore, as I can’t go as low-level as the default Adobe Director particle systems I run into performance problems.

So as we speak we have a default particle system class which handles general particle behavior and when we need an additional or new effect we simple use this one as a base for new particle classes. The default setup handles birth, life, texture animation (if necessary), position, rotation and scale. For the transform properties we also have speed and direction. The slightly more advanced ‘default’ ;) version also does drag, gravity and wind. Each frame the particles are updated until they reach the end of their life after which the are deleted. When all particles are deleted the particle system cease to exists. For most particle systems we use planes (simple 2 triangles forming a square) on which we display the animated (texture). However, we could also use other types of geometry (which we could even add to the physics solution). With the basic setup we can pretty much build any possible particle system we need and can do everything the default system can’t. The biggest and perhaps the only downside is that bigger, more complex system can cause too much of a performance drain.

So to end this post a couple of short cases of particle effects based upon the base particle class.

1. Particle trail

Sometimes you want a consistent trail of particles with a constant size. You cannot spawn a new particle each frame, because;

a. The distanced travelled can exceed the particle size and thus creating gaps
b. In slowmotion this would mean lots of particles would be spawned at almost the same place.

For this system I calculate the distance and direction between the systems current position and previous one. If this exceeds the size of the particle (with buffer) I fill the distance travelled with particles (not forgetting to update all particle settings accordingly).

2. ‘Volume’ explosions

It always bothered me that our previous explosions always start from a single point and move outwards. While this would work perfectly for a grenade it always looks weird with bigger objects. I could spawn a explosion particle system and update it instantly at how it would look over 10 frames or so. I experimented with this, but I simply wanted an explosion to fill up the object. There were a couple of options. Iterate through all vertices of an object and spawn a particle at that world position. Still something I would like to test ;) but I didn’t expect this to be very fast. So for a quicker solution I opted to use the volume of the bounding of the object to define particle positions using a 3d grid. As I store bounding boxes of available meshes anyway this could be done fairly easy. You could say this won’t look nice with weird irregular shaped object and I agree ;) Nevertheless, most of it is blocked by smoke and fire and it all looks cool anyway!

I am off now!

Cheers

Pieter

Pleased to meet you

2011-06-17T17:35:00.002+02:00

Hi all!

First of all, let me introduce myself. My name is Shirley, brand new production manager at Xform.
The previous 7 weeks felt like having a crash course in game production management.
Having my roots in theatre and media, working in the games industry is totally refreshing.

Although I have some experience in project management, managing an entire game production is new for me. But I really like it and day by day I am learning more about the production process.
For me the best way to learn is through practice. And that is why I am lucky to join Xform at this time of the year. At this moment we are working on several game projects and they are all very different.

Besides scheduling, meetings, reading and writing documents for these games, I also did some video editing.
So with this post I proudly present this teaser trailer. Please sit back and enjoy:

Yes, that's our Zombie Shooter game, which can be played online soon. So stay tuned!

- Shirley

P.S. If you know any good books about game production and -management, please let me know. :)

Car physics

2011-06-15T15:00:00.003+02:00

Dear readers,

It's been a while since I wrote. In the meantime I've been working on some racing games about which I cannot say much. What I can tell you about is how our cars are (roughly) implemented. First let's briefly explore an idea, evaluate it and then improve upon it.

We start with creating a rigid body: a physics object with properties such as mass, friction, linear velocity, etc. This rigid body collides with other physic objects such as our track. So let's create a rigid body (without the wheels for simplicity of explaining) with the shape of a car as shown below (sliding on ground):

Sliding and hovering

To move the car forward we can impulse the car in the direction it is facing. And to turn left or right we can apply an angular impulse. Tada! Done! Well no, not quite. One issue for example is that the car would regularly spin around wildly as it is moving over the track. This is because the car is constantly colliding with the track and the physic engine reacts upon the collisions with unwanted results.

To avoid the collisions we make the car hover over the track instead of sliding on it. One way to do this is by shooting a ray from the center of the car straight down (red arrow) and when the track is within the hover distance we impulse the car back up (countering gravity). In this way collisions are avoided (and we get a nice bounce effect as well) but when driving over the track we'd still have collisions when driving up a slope. We can avoid this by shooting more rays: from the four places of the wheels (blue arrows). We could even take this idea further and shoot multiple rays per wheel as shown below, but shooting rays is not for free and requires CPU cycles.

Shooting multiple rays per wheel

This is a rough and simplified explanation of how our cars work and it works quite well for our needs.

-- Stijn

Lightmaps

2011-06-10T18:09:00.001+02:00

For the zombie shooter we're currently working on we want to have an atmospheric environment with light and dark areas. This is hard to achieve with directors/shockwaves default lighting system. It's possible to place some realtime Omi lights but only a few can be used and they won't give the result we're looking for.

Instead of realtime lights we've decided to use lightmaps to tint the environment. A lightmap is simply put an extra texture image which contains the "baked" light information of a 3D scene.

Once the lightmap image has been made it can be superimposed on top of the 3D models original Diffuse texture giving the result as seen below. As you can see the color nuances of the lightmap image are transferred to the environment mesh.

That's it for this post.

Cheers,

Matt

Long time no see

2011-06-01T14:10:00.000+02:00

It has been a while since our last blog update. And no... we weren't on holiday past few months! ;)
In fact we've been working on our new projects. One of them is our new upcoming zombie game! Shooting zombies from the first person perspective.

At the beginning of this project I've been working mostly on the 3D models. The zombies themselves, but also on the environment in which the game takes place. But the past 3 weeks I did some programming. My main focus was the zombie AI. Which is, at first thought, not so hard... Just walk to your target to eat it's brains!

The main challenge was to create a system which guides the zombies through the environment without bumping/walking in to walls and other obstacles. Once again I got back my pathfinding system from Panic at the Zoo (PATZ), which worked pretty good in that game. But for this game it had it's drawbacks.
PATZ's pathfinding is grid based, not node based. Which wasn't a big deal since the environment of PATZ was small. But with the zombie project we want to have a bigger and more organical (not squarish, as with grid based systems) kind of space to work with. Therefore I decided to write a new pathfinding system which uses a node network based on a 3d mesh. A so called 'Navigation Mesh'.

To keep it short, each vertex in a so called 'Navigation Mesh' is a node, and the triangulation of the mesh for example, determines the node's connections. Since the nodes have connections and positions in 3D space it is possible to calculate paths between them. Currently the basic zombie AI is working and it is already pretty scary to see all of those zombies walking towards you...

Also, check out our brand new Facebook page about this project! :)

-Joep

Creating a simple race track

2011-04-04T08:43:00.000+02:00

In this blogpost I'm going to show you how to build a simple racetrack using two splines and a texture using loft in 3d studio max. With this method you can build and texture a track in no time and have a lot of options to adjust and edit your track without messing up the mesh or the UVW coordinates.
First we need to create the shape of the track using a spline, next we need to determine the profile of the road also using a spline. In this example I've made a shape that resembles the profile of the road and the sidewalk.

Now we are going to create the track using loft. First select the track spline, go to the Create tab and select "Compound Objects" in the drop down menu. Now press the Loft button and change Instance to Copy in the Creation Method menu. Now press the Get Shape button and select road profile spline. The result can be seen in the image below.
Turn off automatic banking in the Skin Parameters menu, we'll add the banking manually
Note: Sometimes its necessary to flip the objects normals. There is a flip normals option in the Skin Parameters menu.

A big advantage of the loft is that it automatically creates usable UVW coordinates. Now create a road texture and apply it to the track mesh. You can set the tiling of the texture in the Surface Parameters menu, now tile the texture until it looks ok.

And what if you have done all this and you're just not happy with your track shape? No worries it can easily be adjusted without messing things up. To edit the spline expand the Loft menu by clicking on the Plus icon in front of the Loft text (see image below). Now hilight Path, as you can see Editable Spline appears below, now click Editable Spline and start editing you shape. In this example I've raised some of the vertexes to give the track some higher parts. When you're done exit the Editable Spline menu and go back to the Loft.

Now we'll add some banking to the corners, this can be done using the Twist option in the Deformations menu. Here you can determine the banking of each part of the track.

Fiddle around with all the options in the Loft menu to see what they do. Here's a close up image of the end result.

That's it for this post,
Cheers Matt

Test Day

2011-03-18T18:49:00.000+01:00

Dear readers,

Today is the test day for one of our games. Luckily it's not my game being tested as it always provides some stress. As a tester you have to try to find bugs by trying many actions. If at a certain point you encounter a bug you have to remember what actions you did that led you to the bug. Then you try to reproduce the bug. If you can't reproduce it then you either forgot to do an action or the bug is very subtile or time-related. We also tag our bugs with priority. Naturally a bug that prevents game progress is a bug of high priority. Bugs like "this button has the wrong text" should be fixed but are of lower priority. Other bugs like the one shown in the screenshot below (where an explosion decal is partly in air) are not very useful to commit as they won't be fixed due to it being too hard to fix. Removing it all together however would cause lack of detail (you'd miss it).

An explosion decal is partly in air.

Luckily I didn't find many bugs in the part I was testing or perhaps I didn't test well enough (there are endless combinations) :P

-- Stijn

Happy face....sad face.

2011-03-17T18:16:00.000+01:00

It has been a while but here's finally another blogpost by Matthew. After some nagging, begging and harassing programmer Stijn approved one of my "feature requests" (probably just to get me off his back). The feature that got approved was some relatively simple face animation for the player character of Rhino Rush. The Rhino only needed some basic expressions like smile, fear, hurt etc. Here's how we set it up.

Stijn finally added some code to dynamically switch between the expression meshes. Even these few expressions give the rhino much, much more character. Looking at the end results gave us both a happy face expression. :)

Matthew

Something new

2011-03-16T09:35:00.000+01:00

Hello readers!

As you might know modern console games use a lot of pixel and vertex shaders to draw their 3D worlds and characters. Slowly we also want to go in this direction with our own games. But this comes with a lot of technical difficulties, also seen the platform we're developing on.

Today I made a 3d model for Pieter to do some tests with. It has 'next-gen' specs (although you could call it 'current gen' these days). It uses a diffuse, normal and specular map.

First I made a rough highpoly version of the fusebox. Which I used later to get the basic normals information from. I made the main shape out of some 'plate' like elements, as it would have been constructed in real life. I kept the rest of the highpoly simple and added all of the smaller normalmap details during the texturing stage.

It was nice to be working on something new, something we don't usually do. Normalmaps are always some kind of magic to me, makes everything pop so much more :)!

-Joep

Still alive!

2011-03-14T17:08:00.000+01:00

Hi all,

A short, but important update. We’re still alive! J

As Stijn told you in his previous post it has been very busy for all of us in the last few weeks. I it is not likely that this will change any time soon, but this also means that we’ll have some cool stuff coming up/out quite soon!

Rhino Rush will be released soon on a portal near you and we got a nifty first person shooter thingy planned. Definitely keep an eye out on this one as it will push Shockwave to its limits. There will not be a cooler and visually more impressive online first person shooter on the webZ!

Currently I am finishing up an update of one of our hit games which needs to be tested internally at the end of this week. Not really looking forward to it as it’ll mean everybody will be shouting and screaming at me about things that aren’t working/unclear or are, simply put, ‘stupid’. Sigh… anyways…

To end on a positive note. Diederik, Matthew and myself were at the GDC at San Francisco and we had a great time, met a lot of cool people and drank some beers J

It was a good visit and based on this we have some cool things to look out for this year. From now on we’ll update the development blog more regularly again so, if somebody is out there, keep checking for updates!

Cheers,

Pieter

Rhino Rush Wrap Up

2011-03-11T18:00:00.000+01:00

Dear readers,

It's been a while since any of us has written anything (and I for one am deeply ashamed for all of us (and especially for Matthew! ;D)) but don't worry Xform is still alive!

The past few weeks have been busy for all of us, but I'll let the others inform you about that ;)

The platform game I've been working is now pretty much ready for release and to this end I'd like to treat our dear readers to an exclusive shot which is my personal favorite.

This animated image is a APNG-file, internet explorer might not play it.

So I've been working on the last few fixes and cleaning the code up a little here and there (removing code/comments that got obsolete during development and small optimizations). There are some things that in hindsight I would do differently but you really shouldn't make too much changes to the game when you're close to a release as it might have more side-effects/bugs than you originally think. And then you'll have to fix those and you lose a lot of time. There are still some things that bother me and Matthew but we don't have time to change them. Expect a post on the official release of the game soon!

-- Stijn

Shoot the crate

2011-02-04T17:40:00.000+01:00

Dear readers,

Let's talk about something different than the platform game I'm working on. Last week one of our interns had a problem with the physics engine. The scenario was as follows: We're playing a character in first person style and we're holding a gun. We can walk around in the world and there are some non-static crates: if you bump into these they will move. This is all handled by the physics engine itself, there is no effort required by us to set forces or anything. Nice. But now we want that when we aim our gun at the crate and shoot, that the crate receives an impact and moves and spins realistically.

One solution here is to actually create a bullet and make it follow the path along our crosshair. As to whether this is a good solution I'm not too sure: bullets have to travel at high velocities which is something that could 'bug' the physics engine and unrealistic events might occur. I'm not sure this would occur as we haven't tried this solution. Additionally you'll need to create and delete the bullet (on impact) as well as keeping track of it: what happens when we fire the bullet into the sky (i.e. there is no impact, the bullet flies)? The bullet wouldn't get removed. Although you'd probably have to shoot a lot of bullets into the air before you'll notice a performance drop, it's sloppy. So you'd either have to give each bullet a lifetime as well and update it and remove it when its lifetime runs out or seal the world so bullets will always impact. This could all be done, but it's a bit of a hassle and as I said you might get unexpected results. Let's explore another solution.

Solution two is to immediately apply an impulse ourselves. So we cast a ray along our crosshair and get the first intersection. If this intersection is with a crate then we'll apply a force on it. But to apply a force on the crate the physics engine requires us to give a point on the crate and an impulse. Our impulse is whatever we like: for a small caliber gun we could give small impulse and the crate will move just a little. The problem here is that the physics engine requires us to give a point on the crate in it's local coordinates, whereas our intersection point is a point of world coordinates (see image below).

Here W is the center of world (0,0,0), while C is the center of crate (0,0,0) in its local coordinates. Ray r is the ray along our crosshair and I is the point of intersection.

As said, intersection I is returned to us in world coordinates, while we need it in the crate's local coordinates. You might think "Ok, so just take I and substract C (in world coordinates) from it", but this is only correct when the crate isn't rotated. Rotation needs to be taken into account as well because if we take the same crate and rotate it 90 degrees, you'll still have the same intersection point, but a different local coordinate. To get the correct local coordinate of the intersection we need to look at the transform of the crate. The transform is a matrix M which determines the model's position, rotation and scale with respect to its parent (in this case the world). When the model is drawn to the screen all of its vertices are multiplied by the matrix M to get to the world position. So what we need is the opposite: the inverse of matrix M. The inverse of matrix M is a matrix M' that satisfies: M * M' = ID where ID is the identity matrix (that matrix with 0's everywhere except on its diagonal it has 1's). Multiplying the identity matrix by a vector will result in the same vector: there's no change. Multiplying the inverse matrix M' of the crate by C (in world coordinates) will give us the local coordinates of the crate. Hence if we multiply the inverse matrix M' by the intersection I given to us in world coordinates we obtain the intersection in the crate's local coordinates, which is exactly what we want. We pass it to the physics engine and it works perfectly :)

Multiplying M by the Ilocal position brings us to the Iworld position. Multiplying M' by the Iworld position brings us back to the Ilocal position.

-- Stijn

Level Design Pitfalls!

2011-01-31T17:37:00.000+01:00

Hi all!

As you might know, we're in the middle of designing levels for our 2D/3D platformer. Here's my top 5 of biggest frustrations when playing through some of the levels that may require some more work:

5. Are we there yet?
If I stop to get a cup of coffee before I reach the end, your level is too long! Watch other people play your level and keep track of how long they take to finish. It's easier to add a piece of level than to remove if it's too boring!

4. I'm lost!
Some levels have areas that are so generic that the player loses any sense of orientation. A good remedy for this is to avoid scattering enemies, obstacles or background elements too much across your level.
It's best to create groups of particular elements in one particular corner so that player will remember and recognize it. Also avoid multiple paths that lead to the same place if you find your test players going the wrong way. If you have to resort to the use of big flashing pink arrows or minimaps to point players in the right direction, you're in trouble.

3. Dead end? WTF?
Have you ever walked through a level and suddenly reached an unexpected dead end? You probably took a wrong turn somewhere without even knowing it. A player should be able to guess that a path is a sidetrack and that it will hopefully lead him to some extra goodies. Important is that the goodies are there of course. Not a ...

2. Surprise death. Again!
If I jump of a ledge because there's nowhere obvious to go next, I don't expect to land in some sort of death trap. In fact, make sure I always know and see where to go next!

1. Unfair punishing of mistakes.
If I don't make a jump because of bad timing and need to make some jumps to retry, that's okay. When I need to redo the entire level, I will get annoyed very very fast. Come to think of it, being able to skip to the end of the level by falling down a platform is a bit of a problem as well.

To wrap it up:
For some classic examples of bad level design (and some good laughs), try to make your may through some review videos of the Angry Video Game Nerd on http://www.cinemassacre.com/category/avgn/

For even more hilarious fun look at some videos of a game called 'I Wanne Be The Guy'. A legendary game that has multiple very surprizing deathtraps in each level.

-- Diederik

Nothing to tell you...

2011-01-24T16:31:00.004+01:00

Hi all,

It has been almost two months since my last post… Oops :S Normally I switch posts with Diederik each week, but somehow this got mixed up. The holidays and some of my days off didn’t help either. Nevertheless, I am back with another post and nothing to tell you…

At the moment we have 4 projects in development. 2 of them are TOP-Secret. The other 2 are already regularly mentioned on this blog; Panic at the Zoo and our 3d-platform game (title will be revealed soon).

I am working on one of the TOP-Secret projects. It seems like I am always working on these as others can always mention or show something. They only thing I can tell you it is going to be awesome,.. once again… and that is related to racing and cars,… once again. This project shouldn’t take too long anymore as I am already on it for the last few weeks so hopefully some cool detailed screenshots in the next month or so.

For now I leave you with the most awesome water racing game on the web,.. with explosions!

Play it here!!

- Pieter

Xform Interns

2011-01-21T10:21:00.004+01:00

Xform isn't a huge EA like game company, instead it's a company made out of a handful of dedicated people who enjoy to play and create games. Because we're such a small team we always have a bunch of lucky interns who assist us in creating the necessary game art. Right from the start of their internship they're involved in creating game assets and that doesn't mean they only have to model crates and oil drums. We usually give them a task they can sink their teeth into like modelling, unwrapping and texturing a car or a character. They have to create it from start to finish, in the process we guide them and give our uncensored comments on their work (which means we stand behind them and shout "UGLY"). In some cases they have to start over, but always with a better end result in mind. For the interns it's always satisfying to see the art they've made in the actual finished game.

Right now we're working on a platform game and one of our interns; the bearded Remco, was responsible for modelling, texturing, rigging and animating a baboon enemy. He did struggle at some points, but instead of taking the work out of his hands we let him work on it until we we're happy with the result. Finally yours truly made some minor adjustments and corrections. You can see the end result in the image below.

Matt

Almost time to panic!

2011-01-19T13:17:00.002+01:00

As you might have noticed we've announced the time management game! Panic At The Zoo is pretty much done. I still have some minor tweaks, balancing and bugs left to do before it can be released.

We are probably going to launch the game (few weeks after the first release) in different languages too. This will be a last though job to complete. All of the text displayed in the game is dynamic. They are actually textures created through our 'Text Texture' generator made by Pieter. The system needs several variables before it is able to create a 'TextTexture'. For example, a font, text style, text size and of course the text characters themselves are needed. This texture is then drawn using a mesh which defines the text field. The system also supports automatic text wrapping, resizing and some other tricks to make the text fit inside such text fields. Which comes in very handy when dealing with texts in different languages. Something can be short in english.. but may be very long in another language, which causes trouble.

Before I get on with the localisation system, I'm going to create the final build of the english version of Panic At The Zoo.. Fingers crossed :)!

- Joep

Panic at the Zoo trailer!

2011-01-19T11:12:00.000+01:00

Here it is, the Panic at the Zoo trailer!

Keep an eye out for the free Panic at the Zoo game, when it releases next week on all major portals worldwide!

-- Erik

Panic at the Zoo trailer and GDC 2011

2011-01-18T13:34:00.002+01:00

This week I’m working on the trailer for our upcoming time-management game: Panic at the Zoo. I’ll make sure to do a dedicated post here once it’s actually finished, with a link to the youtube video on the Xform channel. The video is turning out very much like the game; hectic, but a lot of fun. As Xform is a company dominated by male employees, I’m very curious what the ladies think of this time management game (known as a genre dominated by female players) and the trailer I’ve made. Xforms’ strength lies predominantly in the production of arcade type genres, but definitely shouldn’t be limited to only these racing and shooting games. The true test will be when the game hits the portals next week and everyone will get a chance to play the game.

I’m also working on a Xform show reel for the upcoming Game Developer Conference 2011. This will highlight some of last year’s best Xform releases in a very short trailer. If you’re planning to attend the GDC, please visit the Holland Pavilion for a glimpse of Xforms’ latest work or if you have any business you would like to discuss, contact us at directly info@xform.nl

Stay tuned for the Panic at the Zoo trailer!

-- Erik

Stick to the path

2011-01-14T15:38:00.008+01:00

Dear readers,

As I mentioned last week I'm continuing work on the boss level of our platform game. One particular problem I was facing is that the boss has to follow a certain path. This path is shown in the image below.

The purple line shows the path the boss should follow in this level

In physics straight paths are fairly easy to do, but paths like this are a lot harder (as far as I know). You might apply the correct forces at every point on the path so the boss exactly follows the path, but when the player character is blocking the path, the boss will slightly be pushed off the path. Then you'll have to compensate in order for the boss to continue to follow the path. I suppose it's not impossible, but I do foresee many fine-tuning problems. Therefore I chose to use a spring-like solution. But first we have to get the path into our program. For this I use a bezier curve. Unfortunately the program we program in does not support bezier curves. Instead I create the curve in a 3D editor (the same with which we design our levels) and at every X distance along the curve place a marker.


Markers placed at every 0.1 distance along the curve

Then in-game I read all markers and use these to attach a spring between this point and the boss each frame. As a result the boss will follow the path and even when it gets slightly off-path because the player is in the way, the springs will automatically pull it back to the path.

-- Stijn

Developing our business

2011-01-11T10:54:00.001+01:00

At this point in time there’s a lot that might happen for Xform in the coming year. Two new games are coming up that don’t fit in the traditional Xform line-up, because they’re not racing/shooting or even post-apocalyptic jetski games (this genre composed at least 10% of last year’s lineup :). As has been mentioned on this blog a lot by the developers already; we’re working on a time management game: “Panic at the Zoo” and a traditional platform game in the style of Super Mario Bros 3.

To get these out there in the world of gameportals and all those crazy flash game sites can be a real challenge. For a start, most sites only deal with Flash-based games and Xform games are made for the Shockwave plugin. The difference between these two is mainly that shockwave handles 3D games a lot better, whereas it’s a lot faster to develop in Flash, the 2D games that you see for this plugin can be as basic as they come. With gameplay consisting of banging the space bar repeatedly.

The market for high quality 3D browser based games is confusing to say the least, but the market is definitely there. Our upcoming games have been met with a mixed reception online, but there are people interested. We hope the gamers will enjoy these so much when they come out and appreciate the difference in quality with other, crappier games that they’ll become avid Xform fans. As for what might be in store for the company this year, there’ll be more high quality games in different, but also the tried and trusted Xform genres. Games for new platforms and new ways to play our games are also coming up! A good way to see our latest games, wherever they might appear online is through our website or on our facebook page!

-- Erik

Alas, no moving platforms

2011-01-07T17:16:00.001+01:00

Dear readers,

In about 6 weeks from now the platform game should be finished and there is still much to do. Yesterday our interns Ruben and Remco started working on levels for the platform game. They will have to make levels with the current available functionality. We noticed however that some more functionality would make the game more fun. After having a meeting about this, one of the desired functionalities was moving platforms. I have experimented with moving platforms before and written a blog about it before. Of course back then the program was much simpler. The moving platforms work, but there are little things like animations going wrong when on a moving platform or being pushed off the platform when it starts moving the other way. All these things are fixable with some amount of work, but with the risk of messing up other things which previously worked fine. For this reason and with our deadline in mind we decided it's better to leave moving platforms out. If there is time left then I'd like to look at again because moving platforms definitely make the game more fun. But it's better to have a game with few features that works decently than a game with many features that works crappy. So I'll be working on other features instead and of course more boss levels.

Here is one of the levels Remco is working on:

-- Stijn

Panic!

2011-01-06T16:37:00.002+01:00

Today we can finally reveal you guys the official title for the "Time Management Game" we've been working on the past few months. It's called......Panic at the Zoo! Right now it's seems the game is just about done, but as you might know it only seems that way. There are always loads of small things to adjust, fix or add and all those things can keep you quite busy. While Joep is perfecting his code I'm finalizing the textures, cutscene images and doing some miscellaneous adjustments. I also need to create and compile some assets which will be used for marketing the game (banners, posters, thumbnail images etc.). Luckily I can use a lot of the game's original artwork which have been made as high resolution images and are scaled down for the game. Scaling down artwork for the final game also has another advantage, it will look much sharper then when it's created in the original size.

Finally I'll treat you with a screen of the Main Menu of Panic at the Zoo. Enjoy!

Matthew

Balancing the zoo

2011-01-05T15:36:00.001+01:00

I made good progress with the so called 'Panic Mode' in the time management game. Currently it is fully playable from start to end. Also all of the trophy functionality in the panic mode is done.

From now on I'm going to work on the balance and tweaking of the panic mode. This is harder than it may look. There are a lot of variables to set to make everything work. Imagine all of the animal timelines and visitor timelines to be written down. We want full control of the game with a random feeling. Therefor we use pre defined 'demand' timelines for the animals. These timelines determine their demands during the game. For example; We want the monkey to ask for a banana after 10 seconds. The visitors are also semi random. The amount of visitors and visitor types are pre defined per game session. But the moment when the visitors need to be spawned, is influenced by the player's descisions and play style.

Working with partly fixed data gives me a lot of control over the different game situations while playing. It does make the game less random though.

-- Joep

Building a new world

2010-12-29T16:04:00.000+01:00

Hello readers!

I had a few days off this week so I don't have much to tell about time management game's progress. Instead I want to talk about the process we used creating the Burnin Rubber 4 environments a while ago.

The first step to take is to create a so called 'mockup' of the environment or 'world'. This stage is very important, mistakes made here are hard to fix later on. The city mockup of Burnin Rubber 4 was done by creating a large flat plane with a basic roadmap texture on top. Basic box shapes were added to define some architecture and buildings. Simultaneously the environment was tested by driving through the mockup world. This gives a rough idea of what the distances are and what size of world we're dealing with.

For Burnin Rubber 4 it was very important that the road mesh was perfect. By road mesh I mean everything that has to do with the 'floor' or ground the player is driving on. It can be a real pain to create all those roads, there are more than you'd think there are. I created a so called 'construction set' to make this process quicker and more enjoyable as well.

These pieces all 'tile' with each other. Building the roads with these pre defined meshes saves a lot of time. And I really mean a LOT! Too often I see people trying to create something similar by creating such roads poly by poly. I agree it works, but it is really time consuming. Even if you're done with the modelling work you still have to do the unwrapping. Bye bye time...

The process of building environments or art assets in general using this technique is called modular modelling / modular design.

--Joep

2010 Online game of the year

2010-12-28T15:42:00.003+01:00

I hope you all have had a very nice Christmas! This year seems to be a lot more hectic with the holidays being in the weekend. You really need those two extra days as a bonus on top of the weekend, this year we even have new years day in the weekend too. That’s just not right…

As you’re reading this Hydro Storm has moved up to the third spot on the shockwave.com “most played” section of the homepage. In varying compositions, Xform games continue to dominate the chart with at least 150.000 players for our games every single day.

This is something that isn’t bound to stop in the near future, so let’s hope 2011 will give us a lot more plays on the site (don’t forget to tell all of your friends to play our games!). It’s only fair that with all these plays and clicks we have two nominations for ‘online game of the year 2010’. Both Burnin’ Rubber 4 and Race to Rome have been nominated. We would appreciate it very much if you guys would like to help us make either Burnin’ Rubber 4 or Race to Rome the online game of the year on shockwave.com.

So cast your vote here! And of course: thanks to all of you guys for playing like crazy all year!

-- Erik

Boss Level

2010-12-24T15:37:00.005+01:00

Dear readers,

Last Friday me and Joep needed a decent version of our games and we're given a list of issues that we should change/fix. We did our best, but weren't satisfied at the end of the day. So Monday and Tuesday we continued fixing bugs. The newest addition to my platform game is the boss level. About two weeks ago we had a meeting discussing the behaviour of the boss (a baboon). The baboon has certain modes. A mode is for example to chase after the player or to taunt. A very common sight in platform games (and which we also do) is that after hitting the boss a couple of times, the boss will start doing something else to break the monotony. This we call a phase. Phases exist of a list of modes together with their duration. The modes in the list are then played sequentially and cycle when at the end. So phase one can be described as (ChasePlayer, 10seconds), (Taunt, 1 second). In this way it's very easy to adjust a phase.

I did have some trouble getting it to work decently with physics. Sometimes I could get stuck and I would have to restart the level which is unacceptable of course. Placing new physic objects is also a delicate matter: if the new physic object overlaps with an existing physic object you'll get unexpected results. It all seems to work nicely now so the next step will be creating more levels and enemies. Here's a little preview of the baboon:

(In case you're wondering: the black bar on his eyes is intentional as we don't like to give everything away. He's not a sex offender in our game or anything. Don't worry...)

Have a Merry Christmas!

-- Stijn

A special Animal

2010-12-23T16:00:00.002+01:00

As we are nearing the deadline for the Zoo time management game and the holidays we at Xform have to push extra hard to finish all the work. Last week we decided the Zoo game should have a few extra animals to make the game more varied and interesting. I won't give them all away but there's one I would like to reveal to you. It's a special animal which is very near to our heart here at Xform. At the beginning of this year I went together with Pieter and Diederik to the Game Developers Conference in San Francisco. Of course we had to do some business there, but the main reason we went there was to have some fun. So where in San Francisco do you go to have fun......the Zoo!! After a long taxi ride we eventually arrived at the Zoo which is located near the west coast. We were all psyched up to see some magnificent animals but couldn't help feeling disappointed once we entered the zoo. It seemed like the animals had an off day, they where lying around doing nothing not even bothering to look up when we passed by. We came across a kangaroo which seemed more dead then alive, an ice bear in the middle of a depression and a seal that should have died a decade ago. But then something happened, we came across a cage which seemed empty at first, so we looked around to find the animal which belonged there. And there it was lying in the corner looking at us with his cute little eyes, this animal was clearly happy to see us as probably most visitors would pass him by without a notice. It was a Tapir, it looked like a bastard child of a hippo and a guinea pig, we immediately felt connected with this animal so we hanged around the cage for a while and took some pictures to remember him by.

This is why we unanimously decided the Tapir should make it to the Zoo game as a special animal. Below you can see some concept art, just now I've finished the 3D model, unwrap and bones setup. I'll post you guys a screen shot of the final tapir when it's done.

We'll be returning to San Francisco next year to visit the GDC and when we can find the time we'll be meeting up again with our favorite tapir.

-Matthew

Stressing in the zoo!

2010-12-22T14:36:00.002+01:00

The time management game is getting better and better. Last week I solved a lot of (small) bugs and worked on the flow of the game. I also made a new build of the game to be attacked by some of the people over here in the search of bugs. Next up is the 'arcade' mode. You might think, arcade mode in a time management kind of game?.. Yes! The time management game will feature a more action based gameplay mode.

The arcade mode will generally be the same gameplay as the player will face in the campaign mode. But it will be much much harder. For a start, the player will begin right in the middle of a 'game situation', instead of gently building up to the rush of visitors and demanding animals. The animals will need a lot more attention and the zoo will be more crowded during the arcade mode. This will force the player to make it's decisions faster. When finishing a 'day' or 'stage' during the arcade mode, the player will advance to the next one. If the player doesn't meet the current 'day' or 'stage' targets and the end of the game session, it is game over.

The arcade mode will be unlocked if a player finishes the normal campaign. During the arcade mode the player is able to find some hidden objects and unlock trophies only unlockable in the arcade mode.

-- Joep

Hydro Storm has arrived!

2010-12-22T10:56:00.000+01:00

The storm has arrived! Sweeping across shockwave.com like a torrent of explosions and post-apocalyptic water racing mayhem!

I present to you: Hydro Storm!

Hope you like the trailer, check out the game here!

-- Erik

A storm is coming...

2010-12-21T14:31:00.006+01:00

Today our newest game will be released. I’m saying “will be” because the launch will take place in the United States of America and the day starts there as our European working day draws to a close. To “blow the whistle” now would be a bit premature. That’s why I’ll make sure to have a trailer posted here tomorrow in a special blogpost/newsblast on top of the normal one. Of course, I’ll also post a link to a playable version of the game. I mean, that’s the great thing about gaming in your browser right? Instant playability!

Meanwhile, I’ll be drafting a press release for the game and will include some cool screenshots to send out tomorrow. On top of that we really want people to review our game! We’re currently looking around online to send everyone we can a heads up of our newly released game. But, of course we would like to see our game reviewed as much as possible (we believe in the quality you see). Are you someone who reviews browser- or online games? Are you familiar with someone or a site that does this (well)? Please let us know, we would love to see our games reviewed on your site. If you have any info that might help us out, please send me an email.

Keep checking www.shockwave.com for our newest game and while you’re there, check out all of our cool games like the Burnin’ Rubber series and Redline Rumble Revolution. Let’s see if we can claim the nr.1 spot on the site again for a while…

-- Erik

Turning 2D into 3D: Level creation

2010-12-20T17:13:00.001+01:00

In one of Stijn's earlier posts you guys could read about how we're doing the level editing for our platform game. He has created a custom 'tool' that enables us to do the level editing retro style. How cool is that. The last few days, I tested it out a bit and it all seems to work!

Our level creation workflow now looks like this:

1. Build level in 2D editor, export to data file.
2. Import data file and build 3D world in 3D modeling package. Export 3D world to 3D file.
3. Test in game.
Back to the 2D editor to make adjustments, until the basic level shape is okay. Then, we can add enemies and pickups to the level and test that some more. If that is fine we can finalize the level (make it look prettier!).

It might seem an awkward way to do things (and of course it would be really cool if step 2 was totally automated). But in fact, being able to make adjustments in a 2D editor turns out to be a real timesaver. Especially since it's very nasty to make size changes in 3D (keeping the mapping of the objects correct).

That's it for now!

-- Diederik

A lot of little things

2010-12-15T13:44:00.006+01:00

Since my post last week I've been working on a lot of small things. Mainly fixing some interface related issues. Some icons were displayed when they shouldn't. There was a major issue with the minigames where some interface elements were or weren't displayed at all. I also worked on the options screen and some 'dialogues' which pop up when the player unlocks a trophy for example. I used the slider system from Stijn to create the sound and music volume sliders in the options screen.

This week I also worked on the game's intro 'cinematics'. The time management game features a small story, which is being told before playing. It is displayed using still images accompanied with some text. There are also some extra elements which 'blink' to make some stills more clear.

Currently all of the still images (made by Matthew!) are in the intro sequence. The timing between the images still needs tweaking. Also the texts to display in the intro haven't been finalized. For now it is ok, this friday we'll need to have a new build of the game. And there are still a lot of other things to do too...

-- Joep

Rush Beta/New Kids Turbo!

2010-12-14T10:27:00.002+01:00

This week we’ll be rushing to make a new version of our platform game for this Friday. At this point both of our newest games will be ready to go out for evaluation just before the Christmas work slump kicks in. I’ve heard some companies even close their offices for the entire month of December, lucky them… The bigger the company is you work for, the more they’ll be influenced by other companies’ schedules. This whole feeling that working in between the holidays is useless gets reinforced because there’s no one to do business with. This spirals into an escalating scale of being unable to do anything at all, possibly aided by a large train defect that will pop up every other day during the harsh weather. This results in a numbing effect for those involved that makes working very useless indeed. You start thinking: let’s work again when this whole mess is over…

I think that’s a good thing, go ahead and forget the capitalist institutions that rule us all for a few days and celebrate life and love while eating till your stuffed! But, when you’re a small developer life is completely different….

There’s no one to blame for not working here at Xform, the work will have to be finished anyway. We’re not dependant on other businesses like the big corporations are. Our production results are what we make of it and responsibility is carried by everyone almost equally. No use in shoving your tasks onto someone else’s desk, it will wind up right back on yours the next day.

This week almost everyone at Xform will have to work on one project in order for it to get to a more playable state next Friday. I’m not directly involved in producing any assets normally, but I’ll be finishing the trailer for our aquatic racing project this week, so in a way, I’ll be part of production for a week. On top of that, I’ll be responsible for making sure that everyone can do their job and have all the tools that they need to do their job, and of course that they’re not malnourished (a lot).

Today is still special though. We’re going to check out the New Kids: Turbo! movie in the theaters. It’s almost impossible to describe to a foreigner how these characters fit into Dutch society, but believe me, you can find them in real life if you look hard enough. They’re funny as hell and it’s going to be crazy! Check out the trailer, kut:

Untill next week!

-- Erik

Minigame sneak preview

2010-12-10T15:19:00.003+01:00

Dear readers,

This week the minigames for the time management game have been finished. I've worked on the giraffe and monkey minigame. In the giraffe minigame the player has to tickle the giraffe's neck causing him to laugh which will allow you to give him medicine. The animations for it are very funny (Good job, Joep). The only thing we're still missing is a laughing giraffe sound. Here's a little sneak preview:

The monkey minigame and the other minigames our intern Richard made you'll see when the game is ready which shouldn't be too long from now.

Now that the minigames are finished I'm back to working on the platform game. I'm currently working on a boss level, coding the boss behavior. Unfortunately I don't have boss animations or even poses yet. This means I can code the behaviour but visually you won't see too much, which makes it harder for me to see if the behaviour is right. Next week the beta version should be ready, I'm not sure we'll make it though. But I'll let you know next week :)

-- Stijn

Unlock them all!

2010-12-08T09:41:00.006+01:00

Many games today feature so called 'Trophies' or 'Achievements'. Also some of our own games have them. The time management game won't be an exception. While playing, the player can unlock trophies. For example, by delivering 10 banana's to the monkey, or by filling up 10 buckets with water. Hopefully this will give the game a higher replay value. People have to play the game more than once to unlock all the trophies. These will be saved locally on your computer. So after you've played, you can comeback and play again without losing your progress :)

In the time management game there will be around 25 trophies to unlock. Varying from simple ones, such as delivering 10banana's to a monkey and trophies which are very hard to unlock. Finishing the complete game with a perfect score for example. To manage these I created a system which keeps track of each trophy's progress. I started by creating a data array which contained a list of trophies and their states, locked or unlocked. This was of course the easy part of the system. Nothing fancy. The difficult and cool part of the system is a second array which keeps track of each trophy's progress. All the trophies have different 'Goals'. So they can't use the same 'progress' data all the time. Therefor each trophy's progress is a unique list. This list consists out of 2 values. One value determines the target 'Score' of the specific trophy. We can say, the target of the 'BananaTrophy' = 10. The player has to deliver 10 banana's to unlock the 'BananaTrophy'. Then the other value in the list is the progress, or better said, the amount of banana's delivered in the game. When the player delivers a banana the progress value of the 'BananaTrophy' gets increased. Once per frame I run a function to check if there are any trophies that have enough progress to meet the target. If so, the trophy gets unlocked and the player gets a notification.

Doing it this way makes it very manageable for me to see if a trophy gets unlocked, is unlocked, is almost unlocked etc etc. Since it is dynamic and not 'hardcoded' it can be expanded without much of a trouble. One thing that has to be hardcoded though is the part where the trophy's progress value gets increased.

-- Joep

Trailers and explosions!

2010-12-07T14:10:00.010+01:00

Trailers tend to be great tools to highlight how cool your game is. Trailers for Xform games have one big attraction: explosions! That’s pretty much always the main feature of our games and logically, also our trailers. I’ll be working on a trailer for our most recent game in the coming weeks. Finally, our action-packed, highly exciting, aquatic racing game extravaganza is only a few weeks from release.

Of course, I want the trailer to reflect the highlights for our most recent effort. So explosions will be the main ingredient for the movie. These explosions will indeed be caused by weapons, which will play a major role in the form of pick-ups during the race to shoot your opponents with. And in turn for them, to shoot you with if you’re in the lead…

Next up are the environments, which, together with the explosions will be the stars of the game as they’ll play host to lots of secrets and shortcuts. Actually they’ll be the scenes for huge, massive, epic, explosions themselves! How that will work out, you’ll have see for yourself once it releases in a few weeks time (don’t worry, we’ll keep you updated on the actual release date right here). Or you can simply check out the trailer here very soon! We’re really interested in how people will like our new release…

So stay tuned for more news on our newest release and the accompanying trailer in the coming weeks. I’ll keep you guys updated as much as I can!

-- Erik

Beat the rush! Join us now!

2010-12-06T21:44:00.002+01:00

It's that time of year again! No, not the holidays! It's internship season! For us, it's all about working through loads of applications and portfolios looking for programming or art talent. As you know, we're pretty lazy folk at Xform. So, if there are any crazy people out there considering applying, here are some tips to make our (and your) life just a bit easier.

The Application
At Xform, we always ask for a proper motivational mail, an up-to-date C.V. and, most importantly, relevant and accessible portolio work. So don't call us and expect to be hired at the end of the conversation. And don't let your school do all the work for you either!
The mail should be a short introduction to you and what you do. Why are you applying at Xform and not some other company? What is your goal after you finish your education? If it isn't landing a job in gamedevelopment, don't bother; internships are scarce as is!
It's always good to have previous fulltime work experience. Even if it isn't in the games-industry. So be sure to list everything on your C.V. All information should be good (providing an incorrect telephone number doesn't make a good first impression). Please state if you're a boy or a girl (to avoid emberassing situations)!
Have a place on the web to display your work. It should be easy to navigate and it should work, doesn't matter if it's your own fancy website or a personal space on a community site. Make sure that the stuff you show is good enough and works (even though that might limit quantity). If you've worked on a lot of team-efforts, make clear what your attribution was. And please: have a proper non-idiotic email address.

The Interview
Okay, so we want to meet you in person. Be on time. We really appreciate nice color prints of your work. Also, don't hesitate to bring crappy older work. It can give us a good idea of where you started out from and how fast you learn. If you really need to bring a notebook, make sure the battery is full and you have the stuff you want to show ready (and tested!). Don't worry too much about things we might ask. It's all about getting a good idea if someone fits in the team or not.
At least try to make an effort not to come across as a total moron. Unless of course, if you ARE a total moron. Then it's good that we get an honest early warning.
The most important thing is that you get a good impression of what working at Xform is about. We usually give a small tour and an impression of what we're working on and how we do it. Remember, it could be the place you'll be spending a lot of time, so don't hesitate to ask if you're curious. Please let us know if you have special needs or diseases! Don't think you'll surprise us though ;).

Can't wait for your mail!

-- Diederik

A change of project

2010-12-03T11:42:00.001+01:00

Dear readers,

This monday I was told at our weekly meeting that I was to work on a different project than the platform game I have been working on. This came as a surprise to me and I wasn't sure if I was happy about it. It's like when you work on your personal project, abandon it for a few weeks and then come back to it, only to find that you forgot the details/bugs of your project. Comments in the code usually help you to get back in to the project faster, which is why I always try to comment my code, even code that seems rather trivial at the time. But at the same time, a change is nice and when I get back to the platform game there will hopefully be more art available as our artists are continuing work on it.

As Joep mentioned, I'm now working on 2 minigames in the time management game and they're coming along nicely. In the process of making these minigames we found we needed a graphical user interface slider. As sliders are common in user interfaces I made a script which attempts to deal with sliders in a generic way so it can be used across multiple projects. Usually sliders are used either horizontally or vertically, but in our game we have a slider that's placed diagonally. So to keep it generic it would be best to have a slider that can be placed in any orientation. The problem then is when we move the slider to find a correct slider position based on our mouse position. In a horizontal and vertical slider this would just be to take the x- and y-coordinate of the mouse respectively, but in an arbitrary orientation both mouse coordinates need to be taken into account. We do this by projecting the mouse cursor on to the slider (see image): projecting a point on a line in such a way that the distance is minimal (the angle between the slider line and the line between the projected point and the mouse cursor point is 90 degrees).

In the images the slider defines the line segment which is shown as a solid red line. The line segment is part of a line, shown as a dotted red line. The line is parameterized with t in such a way that the start of the line segment is associated with t=0 and the end of the line segment is associated with t=1. When projecting we obtain a t value which corresponds to the projected point P. When 0 <= t <= 1 then the projected point is on the line segment. When t < 0 or t > 1 then the projected point is outside the line segment and we set t to 0 and 1 respectively to keep the slider button on the slider. In this way you can define a slider in any rotation and it will still work correctly :)

-- Stijn

Color Correction on textures PART TWO

2010-12-02T11:37:00.003+01:00

Hi All,

Finally I have found the time again to write you guys a blog post, the past few weeks have been very busy as we've been finalizing the "water race game". One of the major tasks we have to do at the end of each project is the color correction of the textures, Diederik already wrote a post on how this is done on a single image, I would like to show you guys one way of color correcting multiple instances of the same image in one file.

For our game we need the same set of four water particle images for each track, but they all have to be color corrected to match the environment of each track. One of the most common ways to do these kind of tasks is to create Photoshop Actions for each image, but I would like to show you another way to adjust multiple images at once. This is how I did it for the water particles:

Click on the images for larger versions!

I created a Photoshop file and imported the images that needed to be corrected, in this case four water particle images, and turned each image into a Smart Object. Next I aligned and placed them into a Group Folder which I gave the name of the first race track. I also set the folder blend mode to Normal (instead of the default Pass Trough). This prevents adjustment layers placed in this group to affect layers outside of this group. Next I paced a Gradient Map Adjustment layer (for color correction) inside the track Group Folder and on top of the Smart Objects. So in this case the Gradient Map only affects the Smart Objects inside the Group Folder.

At this point the color correction for the first track was done now I only needed to create a copy of the Group Folder for each Track, move the whole folder so the images don't overlap and do some color correction by adjusting each copy of the Gradient Map Adjustment Layer.

Now I have one big Photoshop file which contains the corrected water particles for all the games tracks, but how will I save this into multiple images? Here’s where Photoshops Slice tool comes in Handy. With his tool you can mark and name area's (slices) in your Photoshop file which can be saved as multiple images in just one go ( It’s amazing!) by using the Save for Web and Devices option. Finally Just copy each image in the right directory and we're done.

Setting up a file like this can take some time, but once it's done it can make your life a lot easier.

Cheers, Matt

The other way around: 3D to 2D..

2010-12-01T13:28:00.008+01:00

Last week we were experimenting with minigames in the time management game. To see if this kind of variation of gameplay would add anything good to the game. In my opinion it works very well, also the other guys over here think it is a good idea to have them. So this week we decided to keep them and continue to work on the other minigames. Stijn is going to help me and Richard to get these done.

Today I'm working on the interface mockups for the minigames. Our interfaces are actually 3D objects, instead of 2D bitmaps. The interface objects are rendered 'on top' of the camera in the game.

Imagine these 3D objects which represent buttons and frames etc, to be connected together in specific order. Also known as a parent->child hierarchy.
For example. Imagine a small object called 'Options'. Every button/frame which to has to be displayed in the options screen is a child of this object. In the game we use a function to hide or show one complete parent->child tree. To show the 'Options' screen in this example, we only have to 'Unhide' or show the 'Options' root. Which then shows all of it's childs too, the complete options screen.

This makes it much easier to manage menu's, popups, option screens etc. It is critical though to have the 3D file which contains all of this hierarchy information well organized. One wrong link and the system won't work correctly.

-- Joep

From Marketing to Production

2010-11-30T17:18:00.003+01:00

As the snow begins to fall and mass hysteria sweeps the nation over a bit of frozen water, we all start work with ice cold enthusiasm here at the Xform offices. Even the mice seem to be too cold to come out and grab our breadcrumbs. The end of the year is always the perfect time for a bit of contemplation on what has happened in the last year. Mainly because there’s nothing else to do of course. I’m staying inside as much as I can from now on, but before I get cabin fever I want to reflect on some videogame related memories and thoughts for the future.

I started in videogames as a writer. I was so bored with the movie theory I had to read for my study (“Film- and Television sciences” at the University of Amsterdam) that I decided to apply my own theories to videogames. Videogames played a very small role in the curriculum as a part of “New Media” the major (nowadays you would call it a Master) I decided to follow.

I ended up at a Dutch television show about videogames for an internship. It’s a show called Gamekings and they still make damn good television now. These guys were really cool and I enjoyed my time there very much. I learned a lot about work and life in general there and made some good friends. Plus, I got to travel all over the world as a cameraman on location.

After that I made a clean break there, because it felt wrong staying there not knowing what I really wanted (as always with me). I ended up at now defunct Playlogic International N.V. as a Product Manager. My first experience with an actual “office space” got me depressed for a while. But I did see potential in the company at that time and felt the motivation to push on. After 2,5 years I jumped ship just in time and joined Xform.

Now it’s time to switch my work once again, from marketing into hardcore production. I think videogame production suits me the best, because marketing involves too much lying and betraying your conscience in general, not a strong point for me. Being part of a real production company, seeing how products get made and actually get finished is a great experience. Plus, more importantly, you actually get to see the fruits of your labor, once you put something in you’re instantly rewarded with the result of what you do. I’ve had contacts with production at all times during my marketing times and always wanted to know everything about the project. In marketing you’re always treated as someone who doesn’t know what it takes to make a game and your requests are always greeted with a very deep sigh. I think I’ve always known how it works a bit, because I’ve worked in television production, but at Xform I can finally see it firsthand. Browsergame production is actually the most hands on I’ve ever seen videogame production work. It’s production in its purest form and at Xform games tend to be pure fun.

-- Erik

Office Space Invaders

2010-11-29T14:43:00.001+01:00

Hi all,

Bad news! We had a break-in this weekend. Another one…

A couple of months ago we were also ‘targeted’ and all of our game consoles were taken. This time nothing is missing,.. Fortunately… The door to one of our offices was kicked in, but the only valuable thing in there is a TV and it is probably too heavy to carry anyways. Nevertheless, it is a pain in the ***. The door needs to be fixed, a visit from the cops, etc. All sorts of time-consuming tasks you don’t need or want when starting a new week on Monday morning.

Honestly, I don’t really care that much if they would take the PS3 again as long as the leave our computers alone. When something like this happens it always reminds you of making sure your work is properly backed up and safely stored. Thankfully, we've always done this since the beginning. Not only by making regular hardcopy backups (DVD storage and external hard disks), but also by storing your work on multiple computers at work and at home (using file versioning software). So if things go wrong again we’ll always have the most recent developments versions of all of our projects. It is a shame you have to keep this all in mind. Making sure that whatever happens; theft, fire, airstrikes, alien invasions (I am blaming the aliens for this one), nuclear detonations and earthquakes your work is never gone. Wouldn’t want to start Burnin Rubber 4 from scratch again…

Well, to end this post on a positive note. This week we will be starting to work on an update of one of our games. Of course I can’t tell you anything about it, only that it is going to be awesome! Again… ;)

--Pieter

Turning 2D into 3D

2010-11-26T16:58:00.004+01:00

Dear readers,

I've been waiting for artists to continue my work on the platform game, but they were all put on other projects. So it was just me working on the platform game, which is not very exciting. In the meantime I've been working a little bit on a side-project, something that would be useful for the level designers. The levels for our platform game are in 3D and currently our artist Matthew has little bits and pieces that he has to copy and put together to make a level. Only in the 3D program we're using this is not a fast process. Matthew suggested using a 2D tile-program and then converting the 2D tiles to 3D as in the 2D tile-program you can create the level much faster. Good idea, but easier said than done of course. So I investigated a little to see if it would be doable within a short amount of time because if it takes me more time than Matthew gains by it then it might not be worth doing. But I was able to do it within one day and it works nicely and gives us a quick and easy way to make levels. The level designer no longer has to attach vertices himself or detach the grass objects on top. On conversion I also made it so that each disconnected piece of ground becomes an object which makes the game run more efficiently (as we can choose not to display ground objects which are not in the player's view). The level designer will still have to place custom items manually in the 3D program, but the 2D is very nice for quick prototyping.

Test level designed in 2D map editor:

Converted to 3D:

I think I took more time programming this than if it was all done manually, but I learned more about scripting in the 3D design-program we're using plus the names of objects are always correct. So it's very useful :)

-- Stijn

Minigame Mayhem

2010-11-24T10:54:00.002+01:00

The time management game is making good progress. We are entering the final stage of development. Which doesn't mean that there is less work to do. We took a look at the game to see how it plays at this moment. How long it keeps us interested and entertained while playing. In my opinion the game is pretty solid already. But we decided to add a little more to get some variation in the gameplay. At this point most of the 'Levels' you can play feel pretty much the same. They vary in difficulty but the gameplay is generally the same. This is where we want to make a change.

Diederik came up with the idea of adding minigames. Imagine collecting a bucket and a brush. Then fill the bucket with water and take it to an animal to wash it. The minigame to play could be to wash an animal within a certain time limit. Washing for example, could be done by dragging over the animal with a brush as cursor. When the player succeeds, extra points are awarded. This way we 'break' the straight forward point and click gameplay of the main game.

The first 'wash' minigame is currently working with mockup graphics. It seems to blend into the game pretty good. If it works out as planned we probably keep this in the final game. And of course, add more different minigames.

-- Joep

Just another awardless day…

2010-11-23T15:07:00.004+01:00

We at Xform find ourselves at the office again for another day of work. Lately it seems just a tad bit more meaningless than normal… Why? It’s because we didn’t win anything last Thursday at the Dutch Game Awards :(

I’m kidding ofcourse, we’re slightly disappointed, but we don’t need recognition from a… well from anyone really. The fact that a single Xform game gets played by more than a 100.000 people each day is recognition enough that what we do is liked by a lot of people. However, with all that said, we have won a little bit in spirit with Flipper. The game won an award for “Best Mobile/Handheld Game” and the jury credited its only developer Hugo Smits (Goodbyegalaxygames) for this huge achievement in designing and programming the game on his own. The term “Bedroom coder” was used to describe what he had achieved on his own… literally in his bedroom (in Dutch we normally tend to say: “attic coder” for that type of person, just to emphasize the loneliness of it all). He has had a lot of help from us in publishing Flipper, but as this prize is meant for the development, it’s only right that he should take the credit for this on his own. It was great to see Hugo shining with his red owl on stage, a great crown on all his efforts and hard work. It’s still unclear what will happen with Hugo’s upcoming Flipper 2 but I’ll try to keep you up to date as much as I can what will happen from our standpoint. Nothing has been decided on this new game yet, so it’s up to Hugo!

It wasn’t all bad… for me at least… I was able to claim two awards with my former colleagues for a game I’ve worked on in 2009 and 2010. It’s a testament to the open and kind character of the Xform people that I was able to join my ex-colleagues in celebration of the award for “Best Visual Design” and “Best Audio Design” for the game Fairytale Fights. It was my old employer Playlogic that developed and published this game and I helped (my ass off) to make it! The company has unfortunately filed for bankruptcy in the summer of this year. This was after the game proved unsuccessful, with a very small chance the company will start over under new management, but this chance remains minuscule at this point. I decided not to stay for all the pictures at the award ceremony, this is something that the PR person should do, he still represents the company, together with the composer of the game, responsible for the audio. I’m working at Xform now! Next year we should definitely win a prize, as someone that has joined the company very recently I think there’s so much worthy of appreciation in the Xform line up, it’s high time for us to get the recognition we deserve from the jury. In the meantime millions of gamers will play our games, for now that really is all we need to keep going…

-- Erik

Color correction on textures

2010-11-23T10:09:00.004+01:00

Hi all!

The last few days I've been working on some color correction for the textures for the water race game.

In most 3d games, the designer wants to achieve a certain ambience in the level he is building (i.e. dark, gloomy or maybe bright, sunny or even red and vulcanic). Nowadays, this is done by using techniques such as ambient occlusion, realtime pixelshading and shadows and fancy postprocess color correction on (parts of) the screen. As you might have guessed, we can't use any of that :(

Although for some games we do use lightmaps for more defined shadow and shading, sometimes this makes the whole game just too big and sluggish. So for now, we just use real cool retro realtime vertex shading and fogging.

Vertex shading can color the object's faces darker depending on the vertex's position and orientation toward one or two lights. Not really a lot of control on final tinting unfortunately. But at least it gives some more definition to the object's form and perspective.

Next to this we use fogging of objects in the distance. When used with a nice atmospheric skybox this can work really well. We don't want to fog too much though since it may interfere with our transparent objects and particles. Doh!

If done properly, this usually looks pretty okay, but not very special or unique. We sometimes like to add some additional color correction to the base texture to achieve more color depth and tinting, as seen in the final results picture above. Of course, this will make the texture only useable in one particular ambience! For our project, this is no problem.

In step 1, the darker tints in the base texture are desaturated. Often the darker tints of a particular texture are just darker version of the same color. This sometimes makes color spectrum a bit dull and fake. Maybe you could even add a step here to make the lighter colors more saturated.

In step 2, we create a gradient map that defines the color scheme for our level and apply that to a copy of the base texture. We then blend that with the prior result to make the texture fit more into the environment.

In step 3, we add just a tad of fog color to the texture. This will make it blend even more into the environment and sky. It removes too much unwanted distracting contrast and is more pleasing to the eye.

Back to work!

-- Diederik