Rhino and his friends!

Hi!

Today im going to tell you something about making a Player script that can actually be used on anything and how to maintain a better view.  But first im happy to tell that we are working on some new projects! Together with Matthew Im working on a spin-off of a game Xform made 2 years ago.

Of course everyone knows this little fellow!

Rhino with the T-Rex

As you can see we are making this game in Unity. I've been busy with learning my way around in Unity cause mainly code in AS3. Luckily the difference between AS3 and C# isn't that big, if I compare it to lingo:)

So when I started almost a month ago I started programming with the player script. Not knowing what the project will be about or what the rhino will be doing. So I started my playerscript, like any other, basic input, assigning a model&materials, some physics,etc... Just some basic functionality.

But then there was a meeting and we decided that the rhino won't be the only that can be controlled. So now I know we will be needing a dynamic script for switching the models/materials/animations. Not that hard, we can set that in its "Init" function to let it know which prefab it's going to need.  These prefabs are perfect for us programmers, we can drag and drop it to the scene, sets its material, physic collider(box, sphere, mesh), animation(done by artist), save it as prefab and its ready for use!

But what if all these controllable objects will be having different states or lives, resets, switches..

Now comes the fun part, at least I like it. We will be needing a BasicPlayerScript that will handle some basic functionality.

• No hardcoded links to prefabs!
• Basic Init, get and set its paramters, and let the specific init handle the rest.
• Float function, so we wont have collision all the time to save some performance
• Variable movement, every object has its own speed, jump force
• Able to receive input and handle input. Create the most common behavior and if a object is going to do something else we can override the function and let it do something else.
• State machine! :) Handle the current state. Walk when it needs to walk, wait, jump, die, etc.. Here again, make them very common so when an object needs to do something else let it override the normal one.
• Generic stuff.. like changing materials, reset, pickups, and if we need something specific we can easily run its original and add extra functionality if needed

This way we can easily create objects and let them use this script so we can control it. Why are we doing this, well, if we want the rhino to run and jump, same goes for a car, flamingo, rex or whatever we wont need to type or copy paste the same code over and over. And when an object needs to do something specific, instead of jumping flying, we can easily adjust in its own script instead of messing with the basic functionality. 

So when we want a rhino, flamingo or whatever we will create a script that will extend the BasicPlayerScript.

This is something you really want when you are dealing with multiple objects that have the same functionality. When there is a small adjustment it will be done for all and if you need a specific adjustment it will done its own script.

And check out our latest release 
http://www.agame.com/game/super-mud-mania.html

Greets,
Michael

The Sound of Music

 

Hi everybody!

Melvin here, back for his second Xform blog. This time I'm going to tell you kids about the creation of music in games, with a small part of history in game music.

All games authoring software support wav. Most of them also support pre-compressed audio files, such as mp3 and ogg vorbis. UDK however only imports 16 bit WAV files, but compresses them internally using OGG compression with the ability to tweak the quality/size ration. Unity3D on the other hand almost imports all audio imaginable and also has the built-in option to compress audio files (OGG) with quality options.

When considering music one of the first question you'll have to ask yourself is:

What do you want to do with your music?

Do you just want background music, which plays and loops till the next level start? In that case we're talking about linear music. Next to studio recordings of music with real vocalists and musicians, we also have music created with DAW (Digital Audio Workstation) software such as Logic Pro, Propellerhead Reason, Ableton Live, FL Studio. And it's somehow still more obvious in the gaming industry than using recordings. I myself am a big fan of Propellerhead Reason.

 

I've been using it for 12 years now and all the music I composed for Xform are created with Reason, including the first Burnin' Rubber (2006) track "Alpha Beta", which was remixed for Burnin' Rubber 2 in 2008. This definite version is also heard in the latest, Burnin' Rubber 5.

 



 

Before Reason, I used Fasttracker 2, a tracker program for DOS to make music modules (mod). Mod was a format that originated from the demo scene in late eighties. Next to MIDI this was a format that was frequently used in games because the files were very small yet relatively high in fidelity, until mp3 compression became popular. Other games used music that was on the audio section of the CD-ROM. 

Interactive soundtrack

Do you want more complex event triggered music. Layers of sound fading in and out. Or seamlessly cross fade between a level soundtrack and a boss soundtrack? In that case it's possible you'll be composing something that will never sound the way you initially created it, because the player is semi in charge of the composition.

All major engines (Unreal 3, CryEngine and Unity3D) have FMOD integration. FMOD is middleware for managing interactive sound and music. I haven't done much with it myself. And here at Xform most of the music composed here is for linear use. If there is a demand for interactive music at Xform I'd probably check FMOD out, because of the integration in Unity3D. Other interactive sound middleware are for example Miles from Rad Game Tools and Audiokinetic Wwise.

The only project where I created an interactive soundtrack was my own graduation game project back in 2005. I composed the song in Reason, then chopped it in segments and used these segments in a tracker (see Fasttracker 2 above) to create a mod with 52 separate channels. Events in the game activated or deactivated channels, which resulted in a varied soundtrack consisting of a nice blend of instruments. This is one of the simplest form of interactive music, which is also used in classics such as Super Mario World (when Mario rides on Yoshi's back).

In my next blog I'm going to write about composing in Reason and you'll be hearing music excerpts of a new Xform game.

Till next time!

Melvin

Dealing with slow performance

Dear readers,

This week I'll talk about slow performance and how we deal with it.
Suppose at some point during game development you're playing the game and it starts running slow, big frame drops. The first thing you should pay attention to is what you did to reach this point. Then try to reproduce it. Sometimes it's a freak incidence and you won't be able to reproduce it as it may not be a problem with your game but rather with windows or the game development program (luckily these occurrences are rare). Ok, so you've go a reproducible moment in which the game starts running slow. Now what?

First diagnose! To determine the source of the problem you can:
- Go through the latest changes that have been made and assess whether these might be the source of the problem. In some cases you won't be able to see anything that should lead to this problem. That's because your changes usually have side effects and so the performance drop might occur somewhere else in the code. It can also happen that this problem was actually always there but has never been noticed before.
- Use a profiler. Unity for example has a handy built-in profiler that allows you to see how much time is spend in what areas.
- If you don't have a profiler, you can also use time to measure how much time is taken for certain functions.
- Comment pieces of code until it is running smoothly again. From there you can usually check the commented code and find the problem.
- Debug using breakpoints. This allows you to go through the code at run-time step by step allowing you to see what exactly is happening. I usually consider this to be a last resort and I barely ever have to use it. It may however prove handy when debugging complex code.

The Unity profiler, showing you how much time is spent in each area. (Click to enlarge)

Now solve it! So you've found the source of the problem, what you can do now:
- It may be inefficient coding. For instance looking up objects in the scene every frame when you can just as well look it up once and store a reference to the object. So optimize!
- If you cannot optimize anymore, you could consider faking the effect you're trying to achieve. Many games fake a lot of effects and it's not even noticeable for most players.
- If you cannot optimize anymore, you can use a different calculation that approximates the effect. While less accurate it may still prove acceptable.
- If you've exhausted all possible options, it may be that what you're trying to achieve is simply not possible. The game design may have to be altered, but this is usually a last resort. Most game designers usually have a fair understanding (or at least should have) of what is possible and what is not. Also most programmers will pick up on computational complexity when reading the game design and discuss it.

As an example I recently had a problem with performance in which the game started running slow when there were too many enemies of a certain type. I got to the point where the game started running slow and opened the unity profiler (as seen above). Here I quickly noticed that 'ParticleSystem.Update' was taken way too much time per frame (over a 100ms). At the same time I noticed how many particles where active in the scene (see image below). This is usually not so much of a problem for Unity, except that each of these particles had collision with the rest of the world which is quite expensive and unnecessary! The problems really became noticeable when many enemies were throwing these projectiles with particles on them. Artists tend to look at what's cool and so much of how cpu or gpu heavy it is. So in this case the problem was quickly fixed by disabling particle collision. Unfortunately not all performance issues are this easy to solve ;)

The particles on these cookies were causing slow performance as each particle had collision on objects.

-- Stijn

I'm the boss!!

Hi there,

We've just released Burnin' Rubber 5 (BR5) about a week ago and we're very happy with all the positive feedback it's receiving. We hope all you guys have as much fun playing BR5 as we've had making it! 

Please note this post does contain some BR5 spoilers!!

A while back I posted about the creation of an epic boss for an epic game, now I can tell you it's the final stage/boss for BR5. When writing the post we just started on the 3D models and textures, now that the game is done I can show you a lot more about how we setup the files in 3ds Max. 

The final boss/stage is split into three files: one for the environment, one for the skybox and one for the giant boss vehicle we've named "the Crawler". 

The Environment file

The final battle starts off in the desert where the player approaches the giant Crawler in his car. His first task is to open the rear hatch by destroying two power generators within a time limit. 

We didn't want to create a huge desert environment and wanted to keep the file and download-size small so we only created a small tile-able desert model. This way it's easy to create an "endless" track.

Here's an explanation of the markers of the image above.

1. Total triangle count for the desert environment
2. A one sided "half pipe" model with a tiling cloud texture applied. In the final boss sequence we scroll this texture to simulate speed.
3. A dummy object used as a location marker for the game's final credits. Dummy's aren't visible in-game but are only used as reference objects. Dummies don't contain a mesh but do have a position, rotation, scale and can even be animated.
4. Invisible wall object to prevent the player from going places he shouldn't go. Hidden in game of course.
5. Tile-able desert mesh
6. Simple plane with a tiling and scrolling dust texture applied. This creates a simple dust wind effect.

The Skybox file

The skybox is a very important part of the final scene as it's mostly responsible for the tone and feeling.

In racing games like BR5 the player doesn't look up and down a lot but mostly into the horizon therefore we've used cylinders for our skyboxes. This way we don't spend texture space on sky areas you'll hardly see and they are also easier to create. :)

1. Total triangle count for the skybox
2. The skybox model
3. Skybox position dummy
4. Vertically tiling skybox texture. 

The Crawler file

This might be one of the most complex 3D files created in the history of Xform. In the image below you only see the outer shell and objects, there's loads more stuff on the inside.

To destroy this beast the player has to enter it through its rear hatch, drive up to the second level, battle four opponents continue to the third level shoot the Crawlers core and jump the exploding vehicle. Meanwhile the crawler's top detaches itself and starts flying. Crazy stuff!!

Here you can see how we set this file up. Open the above image in a new window to get a better view.

1. Total triangle count for the crusher
2. Crusher 3D model which is constructed of multiple parts. We use a lightmap on the second UVW channel to shade this beast.
3. A dummy for a pick-up. Which pickup it will be is determined by the dummies name.
4. A position marker to lure the player to this location where it will trigger a cut-scene when driving through. As you might notice the marker and some other objects like the engine flames have a black background. These objects will be set in-game to a different blending mode (additive) which "extracts" the black and makes the rest appear to be glowing.
5. Scrolling arrows to guide the player in the right direction.
6. This file has about 300 objects which can make it hard to keep track of things. This is why we group everything into layers which can easily be shown and hidden from view.
7. All scene objects are listed in this window. It's crucial to name every object correctly!
8. Dummy for a turret position
9. AI vehicle position dummies
10. Player respawn position dummy
11. Al waypoint to guide the opponents through the vehicle
12. An animated cut-scene camera
13. The crawlers shadow. Real-time shadow's can cut heavily in the game's performance, this is nothing more then a simple texture of the crawlers shadow on a 3D plane. This plane will hoover just above the desert floor.
14. The tracks. This isn't a complex animated mesh but just a small tile-able scrolling texture which give the impression of moving tracks.
15. Invisible wall to prevent the player form going past the sides of the crawler.

I hope you've gotten some insight on how we setup our files here at Xform. If you want to see the crawler in action just take a look at this youtube video of one of our players or you can play it yourself online.

Have fun!

Matt

Distorting pixels

Hello everyone!

Today I want to talk about refraction, what it is and how you can use it to enhance special effects in your games. 

In the image above, you can clearly see that the pixels are distorted, they are not rendered at the place you'd expect them to be. The light seems to bend around something in the 3D world. This is what we call a refraction effect, gamewise. In the real world refraction works a bit more complicated than just pixels being distorted on the screen, but that doesn't matter for now. I think you can clearly see the point of what I'm trying to explain from the image.

There is a shader involved which renders this effect using simple geometry ( billboarding plane). The shader renders the object as of its 100% transparent. It also renders the object after the first 'transparent object render pass', this is important. In Unity you use the tag ' Tags { "Queue"="Transparent+1"} ' to achieve this in the shader. 
However, it also transforms the already rendered pixels behind this piece of geometry according to a normalmap. This all sounds quite complicated just from plain text, maybe some pictures can make it a bit more clear.

The above image shows you schemetically what normally happens during rendering without any refraction effect applied. As you can see every geometry is being rendered using its material onto the screen, nothing fancy. 

The second image shows you what the refraction shader is doing to the already rendered pixels using the simple billboarding plane geometry and it's normalmap texture.

This render techinique can be used to enhance your special effects. For example to visualize a shockwave moving through the world coming from a big explosion. Or a heat effect, wich makes the light 'ripple' in front of the viewer's eyes.

One big issue with this technique is that you can't fade the refraction effect by default. In the non-refracted shockwave particles I created, I made the particles fade out by altering their alpha values. However this doesn't doesn't affect the normal distortion off course. I fixed this problem by taking the vertex alpha's into the normals calculation of the effect. 

During the lifetime of a shockwave particle, it's alpha decreases from 1.0 to 0.0. I multiply this value by the normals I get from the refraciton normalmap. Less alpha means less distortion, which makes the effect able to fade in/out.

When taking this technique several steps further you could combine it with reflection to create realistic looking water reflections and distortions.. the possibilities are endless :) !

Greetings,
Joep

Recycle for a better game environment!

Hi!
Today some news about a new game! Just like Eugene im working on a new project as well!
And I am going to tell you a technique to reduce the memory usage by recycling objects.

In this game we are re-using a lot of objects during the game. Like in every other game but this time we are re-using it at the time we are not using it any more. So when we are following a path, we pass numerous objects. Once we pass them we will recycle it and not destroying it. We set it to the next possible spot. This way we won't need to delete it and create it again.
Just a quick reset of its variables and visuals and then set it again for another use! A very nice way of recycling!

Level unmodified

Well this sounds very promising but we need to cooperate with the artist for this. Normally u want to place all these objects in Max and export it the normal way. But since we are recycling all of those objects we don't want a normal export. The export we want, to save some memory and size, has to be modified.




Their are some things we need to know of that model, name, position, scale and rotation. So its name and transform. This can be done in several ways without actually exporting the models. Write all of its data to a text file or replace the model with a dummy and give it the same properties. There are several other ways but we are going to use the dummies. To do this we are using a max script that will search through the scene and replace all the models with dummies.

Models replaced by dummies

We can then search for the specific dummies and add their transform to a array.
So let's say we want to create different sets of objects we now know the type, position, rotation and scale of that specific object. The next part to make it all work, we need a pool of those object types. For each object type we need an original model so we can clone that and put it in a object pool.
So when we need to create a set of objects we can get it from the pool, get its transform we listed before.

This can sound a bit weird but it's very useful.
This can actually increase your game's performance if you use the same objects over and over again. Instead of destroying them on the end and allocating new ones later we are now recycling them. So stop wasting the garbage collector with the same stuff over and over again!

In game

Greetings,

Michael

The Art of Looping

The Art of looping

 

Hi everybody!

Melvin here, senior audio designer and animator at Xform for just about two months now and this my first Xform blog ever.

Well kids, today I'm going to tell you a story about a thing called "looping". The reason why I'm going to discuss this is that I want to show you the relation between sound and movement. And also because this is something you have to deal with, whether as an audio designer or an animator.  In music and sound we use the word loop where in animation we often use the term cycle.

They key thought when creating a seamless loop in audio and animation is that the loop should roughly be like a sine in a graphical approach. I mentioned roughly because it's not necessary to be as curvy as a sine. You could see a sine as a drawn circle, cycle or better yet, a loop in a certain time. We could say we have come full circle!

A sine starts at y=0 and ends at y=0, the origin. The audio example below consists of two sinuses, thus two loops or cycles.The red markers indicate where the loop starts and ends.

Avoiding this story to sound as your monday morning mathclass, I'll just say the more your visual representation of your audio file or animation resembles a sine, the better your loop will be. Thus, if you want a flawless loop, your start and end should have the same y-coordinates and the same angle. The y-coordinate doesn't necessarily need to be 0.  If you do not do this, your animation loop will stutter and in case of your audio loop, it will pop and click.

There are some exceptions in animation where you actually want mirrored angles. A bouncing ball is an example of that.

Here is an examples of bad a loop. (the loop is indicated in blue)

Although the loop start and ends at the same y-value, the loop will pop because the angles are mirrored.

3ds Max users know that if you open the Track View - Curve Editor you will see the graphic representation of your animation.

Here is an example of the movement of a biped pelvis in the animation above. Notice the similarities between this graph and that of the sine audio example.

Of course in real life sound isn’t just one sine and neither do all of we have the same walk cycle. Otherwise everything would be monotonous and boring.  If we look at a more complex audio loop such as this lava audio loop, we can see all of different sorts of sinuses. This gives the sound authenticity.

Importing files

I always save my sounds as wav files, and consider them as my master source files, which I can encode to other formats such as ogg, wma or mp3. I try to avoid saving to mp3 because of the problem, that mp3 encoding places several frames of silence at the start and end of the waveform, which makes looping impossible. The way Unity3d handles audio files is actually quite nice. You can import wav files and choose in Unity3d how it handles its audio files. It also ogg-vorbis compression to keep your final file small.

So this is a small portion of what I do at Xform, I hope haven't dozed you off  to sleep and you can use this in your own work.  
Lets's say goodbye with a seamless loopable track from the forthcoming smash hit
Burnin' Rubber 5.

Enjoy!
 

 

Cheers,

Melvin