Some basic 2D scripting questions

I'm in the planning stages of creating a Unity 2D game. I've worked as a Flash/AS3/iOS/Obj-c game developer for many years so my mindset is how Flash does things (I used Sparrow in iOS which is similar to Flash).

The game I want to create will be a 2D, side on platform game, similar technically to Broforce. So I need the following...

Scrolling
Destructible tiles
Ideally procedurally created map creation

Even though I come from a Flash background, I pretty much just used it to house the assets (the library), the same with Xcode, and then everything was set up via code which is how ideally I want to do things in Unity. One of the things I don't get with Unity is how you are meant to create everything in the scene, which to me is like setting up your entire game on the stage with Flash. But most games require you to create and destroy at runtime, and it's unclear to me right now how you do that in Unity. So onto the questions (I've been researching and googling all of this for a week now these are the things I'm still not sure on).

1. In Flash to bring a monster (which would be a movieclip type say) onto the stage from the library (assets in Unity I presume) you would do myMonster = new monsterType(); stage.addChild(myMonster), with "monsterType" being the export name for the monster in the library, simple but how do I do the same thing in Unity?
2. What's the name of the stage in Unity? Is there some kind of display list which you add/remove game elements too?
3. What's the equivalent of a movieclip in Unity? (a game element which can contain graphics/animation and has x,y, and rotation values) a GameObject?
4. When it comes to scrolling I would to create all the tiles that should be currently visible, with the next row/column also created offscreen, and then when the player scrolls, tiles are removed and brought on according to the direction the character moves. That's the classic approach to tiled scrolling which keeps the number of tiles on screen to a minimum. Is this a good approach in Unity? or is it better to just dump all your tiles for level on the scene in one go? although this latter approach wouldn't work for endless runners.
5. Regarding the destructible tiles, would I add a 2D collider object to each tile when they are created in the first place? or use my own collision check (simple grid/bounding box stuff) and if there's a collision then at that point attach the collider? ( would also have to add colliders to any tiles that were effect in any way by the initial tile being collided with).
6. I want to do most things with scripts (I prefer a singleton approach), but what's the most basic way to set that up? do you add all your scripts to your camera? or do you create a blank game object and add your scripts to that?
7. What's the difference between a Prefab and a GameObject? in Flash you have 2 main visual types, a Sprite and a MovieClip. A Sprite is more or less a container but it can also have it's own visual. A movieclip does everything a Sprite can but can also contain animation. Is that the same for a Prefab and a Game Object?
8. I created a simple 2 frame .gif animation and brought it into the assets of Unity. I then went to the inspector and changed it to Sprite, and multiple etc, but in the Sprite editor it only displayed 1 frame? there were no 2 frames to split.
9. Also with the same .gif animation. To attach it to a game object, I had to make it single image, but when I dragged it to the scene it was huge. I wasn't sure if I should then scale the image down with it's scaling values in the inspector, or zoom the 2d camera out? the image itself is tiny, 18x21 px.

Thanks for anyone taking the time to answer any of the above questions!

 

1. Instantiate prefabs.
2. "Scene", probably. The scene has an hierarchy.
3. AnimationClip, probably.
4. That's more or less what I did with SpriteTile. Another approach is to use the Mesh class to create mesh chunks of tiles.
5. I used a bit that determines if a tile is a collider or not.
6. You can create a blank manager object and attach scripts to that.
7. A prefab is a GameObject or GameObject hierarchy that is stored in the project so it can be instantiated at runtime.
8. Unity has no built-in support for .gif animation.
9. You can use the pixel to unit ratio when importing textures. Ideally sprites should be about 1 unit in size, primarily because physics works best that way.

--Eric

 

1. why do you instantiate prefabs and not Game Objects? I've trying to get a game object created with code to appear but it's not happening. I created a question about it here http://answers.unity3d.com/questions/888098/beginners-add-sprite-to-scene-question.html
2. Do 2D objects have a layer order in that hierarchy? or is it something completely separate?
3. Can't a Game Object have animation attached to it? or do you attach a Sprite to a game object, and then the Sprite has the animation?
4. Thanks that looks interesting. I see you say "A rich API allows levels to be built procedurally if desired" So I can everything with code? Also can I use SetPixel/GetPixel on a tile in your system?
5. If you were to have destructible tiles as in BroForce, would you just attach collider objects to them all?
6. Is there a reason not to add it to the main camera then?
7. So a prefab is like an object in the library in Flash? something which is waiting to be instantiated ? and it's "instance" so to speak is actually a game object?
8. So I can't break a animated .gif up into it's separate frames inside Unity? I have to display them side by side in a sprite sheet and load that?
9. Thanks.

 

1. http://docs.unity3d.com/Manual/Prefabs.html
2. http://unity3d.com/learn/tutorials/modules/beginner/2d/sorting-layers
3. http://docs.unity3d.com/Manual/class-AnimationClip.html
4. Yes, and you could but that's not related. You can use get/setpixel on anything that's read/write enabled.
5. I guess you could, but it wouldn't be very efficient.
6. Seems to make more sense that way.
7. Anything can be instantiated, not just GameObjects.
8. Yes.

--Eric

 

9. I'm curious about this one. I've been developing with Unity for years now and I constantly see people bring this up, but why does the physics engine care about your unit size? In my head the only things that depends on the 1 unit = 1 meter is the default settings for gravity and perhaps mass? But those are values you tweak to fit your game anyway, yes/no?

I've made a few 2D "pixel perfect" games in Unity similar to Broforce and I've always used 1 pixel = 1 unit. This means my sprites range from 16x16 to 1024x1024 units inside Unity. I do it this way just so that I know that 1 unit always equals 1 pixel, there's no arbitrary scaling involved and I don't have to constantly keep track of how many pixels 1 unit will be on the end users screen, it will always be 1 pixel. For physics that requires me to use very different gravity and mass settings than the defaults, but apart from that everything seems to work as it should. The default gravity of -9.81 meters(units) per second squared inside Unity has never worked for me anyways. It looks like moon gravity. -20 or something (can't remember exactly) looks more like what I would expect from the real world if I stick to the 1 unit = 1 meter principle that people recommend.

 

What do you set the other things to if you use pixel to units of 1? like the camera size?

 

I'm thinking about making a comprehensive "database" of tips & tricks for making pixel art games in Unity while I'm making my 2d top down rpg. But I haven't started writing yet.

There's multiple things you have to do, and I'm not going to go into detail about them here. You'll find them on these forums and by googling or by just fiddling about. I'm currently at work so I can't give you examples either.

I don't think many people bother with pixel art games like Broforce in Unity (even though Broforce is made with Unity) because the tools are not that well suited for it. But when you know how and what to do it it's pretty easy albeit a bit frustrating here and there. You just have to google each separate problem as they arise and find your solutions.

Here's a google search to get you started:
https://www.google.no/search?q=pixe...ISuBsTKOa7XgSA#safe=off&q=pixel+perfect+unity

 

Thanks I've got folders full of forum replies and articles about this issue I've been researching it over the past few weeks, but I'm interested in what settings people who are making games actually use. If you set your pixel to units to 1, then you set your camera size according other factors then? you don't keep it at one setting for your pixel game?

 

The camera's orthographic size should be set relative to the pixel height of your game window (accessed via Screen.height in script). Setting the camera size to 1/2 the height of the screen will give you 1 pixel in game = 1 pixel on screen. Setting it to 1/4 will give you 1 pixel in game = 2 pixels on screen (which is standard for many pixel art games).

Here's an article mentioning it: http://absinthegames.com/unity3d-understanding-orthographic/

I just skimmed it so I don't know the quality of it, but it seemed alright. I'm planning on writing something much more comprehensive. For instance once you start moving your camera in your game you'll notice more issues that you have to fix to achieve a crisp pixel perfect game. These are all issues related to the fact that Unity is a 3D engine at heart and allows objects to be places in between pixels etc. But they can all be fixed. And then you'll have the freedom a 3D engine gives you in your 2D game. You can do some pretty neat stuff with it.

Other things you may want to is to allow your players to set the zoom amount for your game themselves based on their preferences or monitor resolutions. I'll cover most of these. I was going to start writing it last night, but I didn't have the time. I'll try again tonight. I'm not sure how long it will take me to get it to a level where I want to let people see it. I may have to make some changes to my website to accompany such write-ups as well. We'll see. I'll post a link here when I do.

 

Not sure if you already knew this, but Broforce was originally a Ludum Dare 23 entry called Rambros:
http://ludumdare.com/compo/ludum-dare-23/?action=preview&uid=3041

That should tell you a bit about how fast they were able to get a game like that going in Unity. Ludum Dare is only a 48 hour competition.

 

@TwiiK, thanks for all the info. Coming from a Flash, or even an XCode/mobile perspective all this setting up the graphics for the screen is something new to me

I read that article (very useful thanks), and I get how they work it out for 1080p, but I still don't get how that relates to the graphics you create in the first place.

So for example I'm creating my pixel graphics in photoshop at a 1:1 resolution. So the fake screen size I'm designing for in photoshop is 480x270, which is exactly 1/4 of 1920x1080 px. Now in the article you linked too ,they work things out for an eventual screen resolution of 1920x1080, but does that mean I have to enlarge all my graphics in photoshop x4, and export them like that, to be loaded into Unity at the x4 size, or do I export them photoshop in their native 1:1 size, and use the same settings they used in the article for a 1080p eventual screen resolution? Or do I export them from photoshop as 1:1 size, load them into Unity at that tiny size, set everything up in Unity for 480x270 resolution, and then when Unity runs the game on a 1920x1080 resolution screen, it just scales everything up?

 

I did a lot of experimenting before achieving 100% pixel perfect graphics. I'm a perfectionist so it really had to be 100% correct! It's not really that noticeable with all the action but Broforce is not 100% pixel perfect. Just to show you:



It's a bit of a mess of small, large and rotated pixels ^^'

I took a lot of steps to achieve pixel perfection in my game, cause I really wanted to make it look like an old retro game, not just a game that has pixel graphics.

@Biggerplay

You just make your graphics 1:1 and Unity will do the scaling. My game's native resolution is 320x180 and it looks perfect on 1920x1080 (That's 6 times my native resolution).

 

Looking at the Broforce image I probably don't need pixel perfect graphics as you are using for your game. I'm beginning to get a grasp of how Unity sets the screen up

 

You make your graphics in photoshop such that 1 pixel is 1 pixel, don't scale anything in there.

When you add your art to Unity set:
Texture Type: Sprite (2D and UI)
Pixels per Unit: 1
Generate Mip Maps: Unchecked
Filter Mode: Point
Format: Truecolor

Pixels per Unit can be set to anything of course and you can still have pixel perfect graphics, but I like it such that 1 pixel equals 1 unit. This settings just affects the "physical size" of your sprite in the game world. Mip maps are just lower resolution versions of your texture to be displayed at different distances I think, anyway it's not something you want in 2D, it just increases the filesize of your sprites. Setting filter mode to point avoids any blurring or filtering of your art and setting format to truecolor avoids compression artifacts.

Now your sprite in Unity looks exactly the same in Unity as it does in Photoshop.

Now if you set your game window to 1920x1080 you go to your camera and set the orthographic size to 135 (1080 / 8). Drag your 480x270 sprite into the scene view and set it to position 0,0,0. It should now fill 100% of your game view.

However, it will still not be pixel perfect. You need to create a new material (right click in project view -> create -> material), choose "Sprites -> Default" as the Shader from the dropdown and make sure "Pixel snap" is turned on. Go to your sprite in the scene view and assign this new material to it.

Now your sprite should be pixel perfect and 1 source pixel (1 pixel in your sprite) should equal 4x4 pixels in the game view.

You can then set your game view resolution to 960x540 and you'll see that your sprite is still pixel perfect, but now 1 source pixel equals 2x2 pixels in game.

That's the gist of it. I realize I'm gradually writing my article in here. I just need to add some examples to it now and I'm done.

@DSSiege11, Broforce is as pixel perfect as you can get more or less. You took a screenshot of projectiles, particle effects etc. Everything else is pretty much pixel perfect. I'm not sure if you've actually written custom shaders for your game that snap particle effects, rotated sprites etc. to a pixel grid, but I think that's overkill. I honestly didn't think it was possible. But at least in my game I don't care if a rotated sprite or particle effect is not pixel perfect in motion as long as it's pixel perfect when it stops moving. Because I can't tell when it's moving anyway.

 

Floating point precision issues. The larger the number, the less precision you have.

--Eric

 

Thanks for the reply, Eric5h5.

Then I know, at least.

Doubt I'll ever encounter them, but those are easy enough to avoid anyway if they should arise.

 

My game is a really simple platformer like they were back in the days, without particles or rotation effects, you're right that it's difficult/impossible to get those all 100% pixel perfect together. It might be possible in Unity Pro by rendering your game to a RenderTexture of your native resolution and then display that texture on screen

Your workflow is the same as mine btw, though I went a few steps further cause I didn't like how "floaty" Unity's physics are so I made my own collision system. I also make sure that the position of my object are always integer, floating point positions are EVIL!!!

Here an example of what I mean:



I really don't like the sub-pixel movement (top picture), especially for a really low res game like mine. But that's just me, I have no problem playing a game like Broforce but when I make one myself, it has to be "right" XD

 

I see.

But it's not really sub-pixel movement, is it though? I thought the pixel-snap is the shader was supposed to fix that. It's just a problem for you because you're showing 1 pixel as 6x6 pixels and you don't want to see 1,2,3,4 or even 5 pixels, right? Like, you want the thinnest line in your game to be 6 pixels at 1080p, always, right? In that case I understand.

I don't really mind that as long as I don't get the blurriness from sub-pixel movement, but as far as I can tell the pixel snap shaders fix that problem.

I do snap the camera each frame though, but I don't care about the objects.