donderdag 13 juni 2013

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

woensdag 5 juni 2013

Run Hammer Run!!!!

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



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


woensdag 29 mei 2013

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





woensdag 22 mei 2013

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


woensdag 15 mei 2013

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

dinsdag 7 mei 2013

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

woensdag 1 mei 2013

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

woensdag 17 april 2013

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



donderdag 11 april 2013

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

donderdag 4 april 2013

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

 

 

 

 

maandag 18 maart 2013

Hammer!!!


Hey everyone!

This week I’m going to talk about the character I've been working on the last couple of days.
I’m not going to tell much about the project that I’m working on.  One thing I can tell, it has nothing to do with cars or what so ever.

I had to make a character with the same looks as the main character of the game called “The Hammer”. This is one of the first games Xform made!


 So with that game as my main reference. I started to begin on my character.


I always make one half of an object. I do this with almost everything I make, cars, props, weapons and in this case a character.


During modelling an object you always want to know how the model will look like in total. For this, there are several easy methods in 3Ds Max to get that. Personally I always make an instance of my model.  This allows me to work on one model while the other one also get the same changes. There is also another tool in 3Ds Max what you can use, called symmetry.



When I’m satisfied with my model, I begin to unwrap. After unwrapping is done I attach the model to the other to get it complete. I do this after unwrapping so I won’t have to unwrap everything. Now I just have to separate the unwraps of each other and weld them together.  

After that I added the biped to my character and used skin to rig him.



When the rig is done, I always make an test animation to check if the character is rigged well.

Here is an example


As you can see, there is one vertex that is sticking out. Apparently that vertex was also attached to the Left Upper Arm.
So I select the vertexes that are attached to the wrong bones and reattach them to the correct bones.
This is easily done in the skin modifier.


So after the Rig is completed I started with my texture.  I’m not going into this. That is for another time.

 A nice end pose, added some random weapons. And the deed is done for now!


Hails!

Eugène