UDK and 2D

[Ignis]

UDK is great for 3D but what about 2D?

I mean, is it easy to handle 2D sprites? Think about games like BlazBlue, Marvel vs Capcom 2, etc...

I had some designs for a beat'em up mixing 2D sprites (main character) and 3D (backgrounds, some enemies...)

[saymoo]

should be possible, maybe using a plane for the player model, with anim texture on it?
but there should be other possibilities.

Btw. why not making a complete 3d game? i personally think your design is a bit too hybrid for most people's taste anno 2009/10

[Ignis]

should be possible, maybe using a plane for the player model, with anim texture on it?
but there should be other possibilities.

Btw. why not making a complete 3d game? i personally think your design is a bit too hybrid for most people's taste anno 2009/10

Well, it's kinda the point. I'm going for a distinct style, with some 2D hi-def sprites on one side against "modern-age" enemies in a beat'em up game (think, cadillacs and dinosaurs, streets of rage...)

I was thinking about using simple planes for the sprites and changing the texture or something

[ambershee]

It should be possible to handle 2d games using the engine, but the sprite support is a little more rudimentary, seeing as the engine is designed to handle complex 3d environments. Animated sprite support does also exist, it's generally used in the particle systems for the game; you may be able to shoehorn this into reasonable game system, but it will take a lot of work.

[Solid Snake]

Theres no orthogonal view within the game, so you will have to deal with perspective. But I suppose you could just render directly to the canvas. Won't be fast I imagine.

[Ignis]

Theres no orthogonal view within the game, so you will have to deal with perspective. But I suppose you could just render directly to the canvas. Won't be fast I imagine.

In supersmash bros brawl, when playing with Mr Game and Watch it looks like it a texture applied to a simple surface. I guess I could do it too in UDK...

[micahpharoh]

why not just make it 2.5D? That seems to be the trend now.

[ambershee]

Theres no orthogonal view within the game, so you will have to deal with perspective. But I suppose you could just render directly to the canvas. Won't be fast I imagine.

If your sprites always face the camera, and are aligned to the same depth with respect to the camera, which faces down a particular axis like most old fighting games, it shouldn't be a problem.

[Solid Snake]

It won't most of the time. But then you have issues with depth fighting.

[ambershee]

Your character sprites shouldn't be able to overlap; they'd have collision properties.

[Ignis]

yeah, the idea is that the sprites always face the camera and move "up and down" in a limited space just like in streets of rage (so maybe there's no real depth, just moving de Y axis or something)

[Forgetful]

Couldn't you just increment the position of the sprites slightly as they are added or killed off. This way you could prevent a lot of the Z-fighting and you'd only have to move each by like a 10th of a unit.

[AlexSkylark]

maybe he could do like Paper Mario? :) a quad that's constantly facing the camera...

[bariscan90]

Paper mario nice

[TMichael]

UDK makes beautiful games in 3D, 2.5D, and orthogonal 3D. However, if you want make a game with actual sprites in 2D only, it would probably be easier using a different engine (I would name a few, but that is frowned upon in this forum :rolleyes:).

[jmr303]

How about a more complex version of Zombieville USA. There is an interesting article on it here (http://www.thecareergamer.com/braaaains-zombieville-usa-tech-review/). Im sure it would take alot of time to set up but adding more part to characters would let to have a more fluid feel.

[Nickadimos]

I know that this would be the worlds most serious bump.. however, i would like to say something on this subject..

Yes, there are many engines out there that are fantastic for 2D, and even in the long run a little more suited to it..

There is ONE thing that sets UDK apart from these other engines.. Collaboration. The other engines out there don't really have any sort of collaboration features (Levels\streaming\Perforce) like UDK does. That is what sets it apart, and a little more work on the back-end to get the sprites right is far overshadowed by the fact a team can work together.

You would handle a 2D side-scroller game exactly like you would handle a 3D side-scroller game.You would have a single plane with a larger cube for collision. You could easily setup the sprites through UScript or even Kismet (E.G. You push left arrow it changes material parameter to left facing sprite, same with jump, crouch, hit etc)... you would use flip-books, and you could even have multilayer materials for status effects.

As far as other views go, for isometric (2.5D) game you would use isometric sprites setup in the same way except more parameters in the material to handle the more degree of turns. Top-Down games would be handled that way too, with a parameter that rotates the plane at certain degrees based on the direction your turning etc...

Some other bennies of UDK: real-time shadows, awesome particle effects, matinee for animating enemy routines, kismet (better than GML for example), level streaming, Canvas, sound editor, material editor, fractured meshes (works with planes), and of course anything else UDK does! LOL

Thank you,
Terry

[tegleg]

already working on a game like this, the good thing about it is that you can have hundreds of pawns running around with no framerate drop.
i kinda moved on from pure sprites and started using a cloth with flipbook textures on it, its great when they rip lol

so heres a basic sprite pawn to get you started :)
you would have to do a bit more work to get specific animations for actions but its not that difficult

class SpritePawn extends Pawn
placeable;

//the sprite
var() SpriteComponent YourSprite;
//array of textures to switch between
var() Texture2D Sprites[4];
var int i;
//the interval to change textures
var() float AnimSpeed;

simulated function PostBeginPlay()
{
super.PostBeginPlay();

//start a timer that changes the texture
SetTimer(AnimSpeed, true, 'ChangeSprite');
}

//the function that changes the texture
function ChangeSprite()
{
//not moving so dont animate
if (Velocity.X == 0)Return;
//dead
if (Health <= 0){Destroy();}

//change the sprites
YourSprite.SetSprite(Sprites[i]);
//add 1 to i
i++;
//
if (i > 3)
{
i=0;
}
}

defaultproperties
{
begin Object Class=SpriteComponent Name=YourSprite
Sprite=Texture2D'MenuButtons.Materials.0'
HiddenGame=false
end Object
Components.Add(YourSprite)
YourSprite=YourSprite

//flicks between these taxtures
Sprites[0]=Texture2D'MenuButtons.Materials.0'
Sprites[1]=Texture2D'MenuButtons.Materials.1'
Sprites[2]=Texture2D'MenuButtons.Materials.2'
Sprites[3]=Texture2D'MenuButtons.Materials.3'

AnimSpeed=0.5

DrawScale=0.1

GroundSpeed=300
AirSpeed=300

}

have fun

edit:
wow didnt realise this thread was so old

[ambershee]

Yeah, it's old. I've seen a working sprite system out there for UDK, somewhere in the wilds of the Internet, that works very well. Unfortunately I lack the URL.