SPACE PIRATES!
Heya! Busy working on a space pirate thing! Been working on this for about 2 weeks now. I want to put in another month or so and see where it goes.
Some old stuff for the blood and graphics test:
And More recently:
Some old stuff for the blood and graphics test:
And More recently:
Comments
Will you be able to make small holes in the walls of the ship that suck you (and the atmosphere) towards them?
Obviously the blood test in the first video is super rad.
Yeah, if you do have walls that can be damaged to suck air into space, you could limit it to particular walls, as well as make the area of effect only a few blocks, as well as make the first enemy (or large object) who gets sucked in plug up the hole (if you needed further limitations).
"ATTACK POD"
I just see scenarios where some fuel on the ground is lit, burning towards a barrel, exploding a hole in the hull sucking out some enemies :) Adding in lots of elements that can interact in different ways could really make this a lot of fun (which it already looks like).
Some ideas just flying around in my head:
Fuel puddles - Can be ignited, ignites/damages everything that stands on it.
Acid Barrel (or weapon) - Eats holes in other barrels (fuel leaks out).
Gas Canister - When damaged, speeds of at a random angle leaving a fire trail behind.
Enemy Reinforcement Docking - Because that docking procedure is just to bad ass to see once per stage :)
Gravity Grenade - Sucks enemies and barrels towards its centre.
Melee Kick - Sends enemies/barrels flying turning them into projectiles that can start chain reactions.
If you get sucked out into space, use your gun as propulsion to get you back to the hull breach (entering the breach closes it)
Really looking forward to the first playable build!
Now time to make the enemies suck out of holes.
@BenJets Thanks guy!
I really appreciate the frequent updates, its really fun to watch the game develop :D
Not a ton of improvement here, I've gone away from unity's default pathfinding system, to a third party one. Apparently, you cannot rebake navmesh's at runtime, which is no good for this game. Also haven't quite got the blood working on the random levels yet, but its moving forward none the less. The level generator is kind of broken, but it is detecting rooms and trying to connect them which is cool. And I can make more circular rooms or square rooms. The next thing I try with the random ship thing, is making the level symmetrical.
Btw. hit.textcoord returns the texture coord of the MESHCOLLIDER it hit, not the texture coord of the MESH on the MESH FILTER. So if you move the uvs of the mesh on the meshfilter make sure you update the mesh collider with the new instance of the mesh, otherwise you will be returning the uv coords of the original mesh instantiated on the mesh collider. Thanks for letting me know unity.
Loving the progress updates, btw.
@blacksheepZA Ruan actually said that too when I showed him, I hadn't heard of it before no. I'm really excited to play it, just because it's in the same vein.
@SUGBOERIE MAGIC ^_^! It actually not super hard once you get everything going, It's more just figuring out the process that took all of the time. If one thing is wrong the whole thing falls to pieces, so it can be a bit tricky. Its also nigh impossible to find imfomation on which was hard.
SO..... basically.... :
I don't know how far you got with it or what you are battling with, so I'll start at the beginning.
1) For the collider returned from a raycast, you can use hit.texcoord or hit.texcoord2. for UV set 1 or 2 respectively. to return a normalized vector2 for the uv coordantes of the raycast hit. The uv coordinates returned are for the UV coords on the mesh collider not your mesh renderer. So if you change the uv's of your mesh at runtime, you have to update the mesh collider with those changes.
2) The collider returned HAS to be a non convex mesh collider. other wise hit.texcoord will return Vector3.zero. I have an interface that just toggles colliders on and off for when it needs to draw on something, or whether it needs to use physics. If you don't have super specific UV's like me, and if your uv's take up the whole texture sheet (like a quad for example), you can make this work with a box collider. you just have to get the (hit.point - col.min.extents )/ col.bounds, etc and you cannot use hit.texcoord.
3) Once you get that working, to get the pixel of the respective uv coord returned by hit.texcoord just multiply it by the texture width.
4) You can use Texture2D.GetPixel (x,y) of that Vector2 to get the color32 of that pixel. And you can you Texture2D.SetPixel (x,y,Color.XXX) to set the colour of that pixel.
4a) The texture you are writing to has to have a few things changed on it. It HAS to have read/write enabled (Textures created at runtime will have this automatically, imported textures won't). And the texture format that works best for me is ARBG32, any of the floats should work though. You get all this if you change the texture type to Advanced in the inspector.
5) If you want to splat down a whole texture you can imagine that you just have to run through a for loop of all the pixels in the texture you want to copy and change them in the texture you want to change. In Unity 5.4 you can use a new thing, Graphics.CopyTexture(), which I think does this on the graphics card (I'm assuming), but I haven't tested it much.
6) texture.Apply() afterwards to apply the changes.
7) The changes to your texture are obviously permanant.
NOTES:
I do have a shader now, just a simple one, that has 2 textures, texture 1 is the main texture that is mapped to the first set of UV's, and texture 2 is a blank white texture that I create at runtime, and draw red to for the blood. This texture uses UV set 2, and is multiplied with texture 1.
You want to do some checks along the way, like if surface color == the colour you are writing, return. Or if the texture / renderer on the collider is null return. Just because this can get a bit expensive if you have lots of particles. Can also just pop the whole thing in a coroutine as well.
You can't change an imported texture to read/write at runtime. You can either do it in your import settings, or you have to change it in your inspector.
I was initially writing to the lightmaps, which doesn't work for me anymore because my space ships are going to be procedural. If you want to write to lightmaps at step 3) you have to check the lightmap index is over 253, and then you can use hit.lightmapcoord. The process is the same after that (You still need to change the format of your lightmaps so they can be written to at runtime).
Let me know if you have any issues!