BlackShipsFillt
22-01-2010, 04:25 PM
I don't have time to write a proper tutorial now... What I do have instead is a simple game with a bunch of features that you guys can cannibalize and use in your own projects. This game has examples of solutions for most of the beginner level obstacles in Unity. All the classes are written in C# so you will need to understand that as well as have some kind of script editor for working in it (I use Visual Studio).
Features that this project has that are useful as examples of possible ways to get things done in Unity3d:
Sprites
Input
Sound
Saving Scores
Changing Levels
Collision testing
GUI functions
Raycasting and other handy physics tools
Particles
The Line Renderer
The Trail Renderer
Prefabing
Though I will warn you that I don't do things the official way in Unity, I like my code simple and dirty and split into as many classes as possible. Also, it may run alarmingly slow, I became obsessed with particles at some point during it's creation.
The Unity3D package can be found here: http://www.blackshipsfillthesky.com/astrocaptain/Basic Example Project (Astro Captain 22 Jan 2010) - 2.unitypackage
Instructions for building this game:
Open up Unity and start a blank project
Open the package file in your file explorer and import everything
Add the two scenes to your File->Build Settings menu. Add the MainMenu scene first, then the GamePlay scene
Go to Edit->Project Settings->Tags and add the tag "Evil"
(optional) Go to Edit->Render Settings and put Fog on and set the fog density to 0.005
Layer
(optional) It doesn't import the Layer names, but the layers are still intact... You might want to give the layers names if plan on fiddling (Edit->Project Settings->Tabs) Layer 8 = "Background" Layer 9 = "Foreground" Layer 15 = "Ships" Layer 16 = "Menu"
I do a lot of things in very particular ways. Xyber once had an entire project of mine thrust upon him, and although he didn't say so, I could sense the contempt for my code emanating from him.
Sprites:
I use the SpriteManager, but I do things a little differently (the SpriteManager in the project may have slight differences to the original one). I don't use the UVAnimation class that comes with it. I assign the frames of my sprites directly from the objects controlling the sprites. I do it this way because it allows me to enter frame numbers in the inspector. If I were to use the UVAnimation I'd have to specify frame numbers with code. The SpriteManager 2 class does make things a lot easy, but I haven't had the chance to use it yet (at the moment it is sold commercially though Unity is likely to adopt it at some point).
So the way I set up sprites: If you look in any class that uses sprites (like Ship.cs) you will see that the class upon initialization find the SpriteManager and then calls the AddSprite function which gives it a reference to a newly created sprite. From then on the Ship class drags around the sprite using sprite.Transform(), occasionally changing it's frame using something like sprite.lowerLeftUV = spriteManager.PixelCoordToUVCoord((frameOffset) * spritePixels, (spriteRow + 1) * spritePixels); which changes the UV's on the vertices of the SpriteManager mesh... Then eventually, when the ship explodes, it calls SpriteManager.RemoveSprite(sprite); and that is the end of that.
If you just want to get sprites into the game then copy the sprite code out of Ship.cs and place a gameObject with SpriteManager.cs attached with the appropriate sprite sheet material selected and you are ready to go.
Pixelation:
I've imported most of my textures with "Point" filtering, this gives the hard pixel edges look. Change the texture to "Bilinear" filtering and you'll get nice blurry interpolation (which is normally what you want).
The Inspector:
I like to use the inspector. If you look at any of the prefabs in my prefabs folder you will see that I've tried to make as much as possible editable in the inspector. i.e. A laser and a missile use exactly the same code but the prefabs define their behavioral differences. In the game I have the prefabs referenced within my objects and then Instantiate the prefab that I need (allot of this happens in Map.cs, have a look at the prefab). The other way to do things is have the differences defined in the code and initialize the objects with many special properties. This would work to, but then you're avoiding the Unity environment.
Sound:
I have made a central Sound class that is called statically from every other class that needs to. This means I'm not using the 3Dness of Unity's sound. If this were a first person shooter I would give every sound creating object it's own AudioSource, but then I'd also have to make sure I didn't destroy the object until the sound had finished. This is works for this project.
Interface:
I have used both the Unity GUI and my own Button system. You can find examples of this in Player.cs and MainMenu.cs. Using both was a bit unnecessary, but they're useful as examples. My Buttons (Button.cs) are more versatile (as they can be attached to any object in the scene) but the Unity GUI is very quick to work in.
Have a look at it, ask me questions about anything that doesn't make sense and I'll try sort you out. The thing took two days to make, so writing a tutorial about that will take at least that long (and I cannot afford that right now)... There are comments in the code so read through it first.
One other thing... Anything here you are welcome to use. The font is free though check the readme first. If you do use anything I've done a little credit would be nice, though I don't mind if you don't.
Features that this project has that are useful as examples of possible ways to get things done in Unity3d:
Sprites
Input
Sound
Saving Scores
Changing Levels
Collision testing
GUI functions
Raycasting and other handy physics tools
Particles
The Line Renderer
The Trail Renderer
Prefabing
Though I will warn you that I don't do things the official way in Unity, I like my code simple and dirty and split into as many classes as possible. Also, it may run alarmingly slow, I became obsessed with particles at some point during it's creation.
The Unity3D package can be found here: http://www.blackshipsfillthesky.com/astrocaptain/Basic Example Project (Astro Captain 22 Jan 2010) - 2.unitypackage
Instructions for building this game:
Open up Unity and start a blank project
Open the package file in your file explorer and import everything
Add the two scenes to your File->Build Settings menu. Add the MainMenu scene first, then the GamePlay scene
Go to Edit->Project Settings->Tags and add the tag "Evil"
(optional) Go to Edit->Render Settings and put Fog on and set the fog density to 0.005
Layer
(optional) It doesn't import the Layer names, but the layers are still intact... You might want to give the layers names if plan on fiddling (Edit->Project Settings->Tabs) Layer 8 = "Background" Layer 9 = "Foreground" Layer 15 = "Ships" Layer 16 = "Menu"
I do a lot of things in very particular ways. Xyber once had an entire project of mine thrust upon him, and although he didn't say so, I could sense the contempt for my code emanating from him.
Sprites:
I use the SpriteManager, but I do things a little differently (the SpriteManager in the project may have slight differences to the original one). I don't use the UVAnimation class that comes with it. I assign the frames of my sprites directly from the objects controlling the sprites. I do it this way because it allows me to enter frame numbers in the inspector. If I were to use the UVAnimation I'd have to specify frame numbers with code. The SpriteManager 2 class does make things a lot easy, but I haven't had the chance to use it yet (at the moment it is sold commercially though Unity is likely to adopt it at some point).
So the way I set up sprites: If you look in any class that uses sprites (like Ship.cs) you will see that the class upon initialization find the SpriteManager and then calls the AddSprite function which gives it a reference to a newly created sprite. From then on the Ship class drags around the sprite using sprite.Transform(), occasionally changing it's frame using something like sprite.lowerLeftUV = spriteManager.PixelCoordToUVCoord((frameOffset) * spritePixels, (spriteRow + 1) * spritePixels); which changes the UV's on the vertices of the SpriteManager mesh... Then eventually, when the ship explodes, it calls SpriteManager.RemoveSprite(sprite); and that is the end of that.
If you just want to get sprites into the game then copy the sprite code out of Ship.cs and place a gameObject with SpriteManager.cs attached with the appropriate sprite sheet material selected and you are ready to go.
Pixelation:
I've imported most of my textures with "Point" filtering, this gives the hard pixel edges look. Change the texture to "Bilinear" filtering and you'll get nice blurry interpolation (which is normally what you want).
The Inspector:
I like to use the inspector. If you look at any of the prefabs in my prefabs folder you will see that I've tried to make as much as possible editable in the inspector. i.e. A laser and a missile use exactly the same code but the prefabs define their behavioral differences. In the game I have the prefabs referenced within my objects and then Instantiate the prefab that I need (allot of this happens in Map.cs, have a look at the prefab). The other way to do things is have the differences defined in the code and initialize the objects with many special properties. This would work to, but then you're avoiding the Unity environment.
Sound:
I have made a central Sound class that is called statically from every other class that needs to. This means I'm not using the 3Dness of Unity's sound. If this were a first person shooter I would give every sound creating object it's own AudioSource, but then I'd also have to make sure I didn't destroy the object until the sound had finished. This is works for this project.
Interface:
I have used both the Unity GUI and my own Button system. You can find examples of this in Player.cs and MainMenu.cs. Using both was a bit unnecessary, but they're useful as examples. My Buttons (Button.cs) are more versatile (as they can be attached to any object in the scene) but the Unity GUI is very quick to work in.
Have a look at it, ask me questions about anything that doesn't make sense and I'll try sort you out. The thing took two days to make, so writing a tutorial about that will take at least that long (and I cannot afford that right now)... There are comments in the code so read through it first.
One other thing... Anything here you are welcome to use. The font is free though check the readme first. If you do use anything I've done a little credit would be nice, though I don't mind if you don't.