Level Editing in Photoshop

Hi all,

The past few weeks I've been working on a new Rhino Rush game. The original game is a classic platformer where you (a baby rhino) explore a number of stages in order to face a mad baboon at the end.
The new game however will be an "endless platformer" where the main goal is to get as far as possible in one single level. The rhino (player) automatically runs to the right and it's up to the player to jump platforms and avoid hazards. It's a bit comparable to a game like "Jetpack Joyride". 

It can be quite hard to design level layouts without knowing for instance how high or far the player actually can jump. You can easily design an impossible level with unreachable platforms or gaps that are too wide to jump.

For this game I made a simple "level editor" in Photoshop where it's easy to check the level for "impossibilities". I should mention that this game is a grid based 2.5D platformer so only the side view is shown what makes it perfect for a Photoshop "level editor".

Before creating the editor I needed to know how high and far the rhino actually jumped so I created some playable mock-up levels just to test and tweak the rhino's jump height and distance. This took some time to tweak but i'ts important to get this right because all the level design will be based on this. 

First I needed some visual feedback of the Rhino jump curve in game, we did this by drawing a line at the Rhino's location at each frame.

Jump curve made visible in Unity

I took some screenshots and imported these in Photoshop. Because the game is grid based I could easily scale the image to a convenient Photoshop grid and made a "Jump template" as seen in the image below.

"Jump Template" in Photoshop

This template is a single image which can be moved around the Photoshop file to check distances between platforms and gaps.

Next I inserted images of the level assets like platforms, crates and pickups and created grid based Photoshop Smart Objects of these. Smart Objects are extremely convenient when you need a lot of instances of the same image in a single Photoshop file.

When all this has been set up I only need to snap copies of the level objects on the grid and check with my "jump template" if all platforms etc. are reachable.

a level design mockup in Photoshop

When I'm happy with a level design I save it to an image and use this to create the level in Unity.

Cheers,

Matt

Run Hammer Run!!!!

Hello everyone, 
already level 50 with Burnin Rubber? Beated Super Mud Mania on hard difficulty?

http://www.shockwave.com/gamelanding/burnin-rubber-5.jsp

http://www.a10.com/racing-games/super-mud-mania

Last couple of weeks I’ve been working on the Hammer game. Been doing all kinds of stuff, character animation, been working on the level with Joep, did some weapon related stuff, yeah there will be weapons and explosions again!!! :D

Ever heard of the M202, well that’s just one of all the weapons that will be in game.

.

The M202, made by one of our interns

Last time I've talked about the Hammer, about symmetry, rigging etc etc. I want to continue were I left off.

So the next step is animating the character.

I've been doing all Sorts of animations, run, idle, jump, roll, slide, an sort of uber uppercut!!

Creating a run animation was tricky. It needs to loop perfect, the way how the body moves during an run, how the arms swing (or not when holding and aiming with gun), on what frames the feet touch the ground, etc etc. 

That the feet touches the ground and stay on the ground can easily be done with planted and sliding keys. When the feet touches the ground make sure it’s a planted key, then change it to a sliding key, so it slides nicely over the ground while you moving your biped up or down.

Here you see a part of the run animation. Started with the right foot going down, touching the ground and sliding back as it moves forward, then going up, then that same sequence begin only with the left foot, then right again etc etc. 

So now we have done the running animation, time to add the guns!! We can easily align those with his hands, with the align tool.  

Then in the schematic view we link those on the hands.

If we don’t link the weapons with the hands, they won’t follow the hands during the animation and just be staying at one point.

When it looks good and the hands are proper animated. Unlink the weapons again and make it export ready, so it can be placed in game. 

That’s all for now, 

Hails,

Eugene

Endless worlds

Two weeks ago, the project I was working on went gold. More about this new release soon, I promise J. So I switched to a new project. The new project which I’m currently working on is all about running in infinity without knowing it! This may sound kind of strange and somewhat impossible (infinity), but in fact it is not that complicated and I’ll try to explain it to you.

The new project will feature you, the player, as a running character through a world that is endless. The world is infinite. We do this by creating a variety of ‘Blocks’ of the world. Think of this as a slice or tile of an environment.

Most of the blocks can be placed (snapped) next to each other. We can say that they 'Tile' with eachother. This is possible because the road is always the same width for example. Also, all of the blocks have the same dimensions, this is very important. Creating the blocks this way lets us tile them behind each other seamlessly to create infinite worlds. Well infinite infinite.. More of a repeating world kind of, as you can see here:

As you can see in the above image, the world looks pretty repetitive. Which isn't surprising since there just is one block involved to create the above tileset. On the other hand, placing three of the same blocks after one another as a 'section' of the world doesn't feel that strange. I found that moving through three blocks of the same type was actually quite satisfying IF there was some variation after the tileset. It makes it kind of feel walking from one neighbourhood to another.

Next to the city's downtown area we decided it should have some other area's too. We came up with a few and one of them is a subway area. The player runs along the subway's railroad tracks towards.. infinity. The subway area has several blocks ranging from plain straight ones to some which have little subway stations and platforms in them. One good thing of using the subway as a theme for this kind of game is that a subway is quite repetitive from itself already. This makes it feel, and this may sound strange, less repetitive in-game. Since you and me accept it being repetititve J. 

This all sounds nice however, a subway and a generic city street don't match up that well, being tiles in our game. Also the subway being underground makes it not logically align with an above ground street. There for we created several 'Transfer' blocks. These blocks are used when we want the player to dive underground into the subway while running on the street for example. The other around visa versa, we need a kind of transfer block to get the player out of the subway back above ground onto the street. 

To go back to the street from the subway we use a similar transfer block:

So now we have our running towards infinity pretty much covered. However this doesn't make it a game yet ;). We decided to place several obstacles along the way for the player to avoid. When the player makes a mistake and hits one it is game over.

Placing obstacles isn't anything new and fancy. Just place nodes with the corrensponding names of the obstacle you want to put there and voila! The programmers now have their reference points of where to instansiate what object for a player to avoid. But remember.. Our world is infinite.. so how would that work?

Playing through the same obstacle composition all the time wouldn't be much fun would it? No.. not really. Especially not when every level block tile has the same corresponding obstacle set which doesn't change .Every block would be the same when the player walks through them again, which is boring. Also it wouldn't be possible to make the game harder over time, resulting in the player never dying in the first place if the obstacle sets are too easy. Or it could be the case that the first ever obstacle set which the player encounters is too hard and instantly makes the player go game over.

The solution we came up with is to create several obstacle sets per block. These obstacle sets are divided in several difficulties ranging from very easy to very hard. The image below shows 3 difficulty sets of obstacles for one block, ranging from easy to hard.

Now when playing the game, it doesn't really matter what kind of block tile the player encounters first. Since every block has it's own obstacle sets in all difficulties available. It is now possible to start with block A and have it use it's Easy obstacle set. Then move over to let's say block B with an obstacle set in Medium difficulty, keeping the game getting harder in a linear way. After block B we can use block A again but this time using block A's hard difficulty obstacle set.

If we have enough block sets and enough obstacle sets per block we can make the world feel infinite for the player. We also can have a complete different world combination the next time the player plays it by using a different order of block tiles and obstacle sets. This contributes to the replay value of the game, since the player encounters a lot of variety in gameplay everytime he or she starts the game again.

Greetings,

Joep

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