IronDuke's Space Game

I like this a lot. The ship looks straight out of the I-War universe, complete with undockable head section and all. Would really like to fly this beast myself!

P.S.: It was fun to see you in the Limit Theory forum!

I hadn't even looked at the link. I wasn't expecting there to be screenshots. It has some obvious resemblances to the Dreadnaught, and the roundness of the body reminds me of the puffin/heavy corvette. IronDuke, you are way past me in the 3-d modelling department.

Chessking wrote: I hadn't even looked at the link. I wasn't expecting there to be screenshots. It has some obvious resemblances to the Dreadnaught, and the roundness of the body reminds me of the puffin/heavy corvette. IronDuke, you are way past me in the 3-d modelling department.

I designed the ship to look like a heavy corvette turned patcom, with Dreadnaught elements. But the similarity to a puffin was purely coincidental. I made the fuselage by stretching a sphere, which is what PS did for the puffin. Also, the ship is based on the Phoenix in the game lore, so I had to keep similarities there too.
BTW, I doubt I'm really all that much better than you at modelling. This is the first model I have definitively completed in Blender, with UVs, texturing, and what not. If it's any consolation, I know so little about procedural stuff that I go "Huh?" every time someone says perlin. :blush:

Great to see you too, soda man! It's always wonderful to see people getting into other space games. (It means mine might have more fans... (runs away really fast))

--IronDuke

I have completed a model in Blender, minus UVs and texturing. I haven't imported it to Unity yet, but would really like to import it to EOC. I haven't found a way to import as a .lws yet, though. For comparison, I have attached an image of my model (a spaceship of course).

I am trying to enter a competition about the science of the future, and my submission will be on Procedural Content Generation. I have been working hard the last few days building rendering engines for 2d textures. I have not been using Perlin noise in these engines. I have not yet figured out how to create a non-repeating, but always shifting texture, the way Ken Perlin did (although I still have some untested ideas). Here 's a page written by Mr. Perlin that I need to study more. My largest inspiration for Procedural Content Generation has been Limit Theory.

!!! TEXT WALL INCOMING !!!
!!! EVASIVE ACTION !!!

Guess what guys??

How do I take a three-dimensional position in the scene and find the closest spot to it on the UV map?

I found out! :evil:
Turns out Unity has this handy little function where you can do a raycast on colliders, catch the UV position of the raycast hit, and from there get the pixel where the raycast hit. Since lasers and other light-speed weapons use raycasts, and I have a special high-speed collider I programmed (that NEVER goes through stuff by accident) using raycasts as well, things are awesome today.

I got a little test working, which uses a special texture updated every frame. The texture is not applied to a model or material or anything; it is never seen. It is used as a way of storing damage at positions on a ship. I got a little test working, where I used a quad and a little extra code to have the mouse play laser and leave a trail on the quad. Normally you wouldn't see it, but I cleverly wrote code to set the visible texture pixels to the same as the damage texture pixels. I also wrote a loop that runs through every pixel on the damage texture and increases the color slightly. Autorepair, anyone??

Where the mouse is positioned is detected every frame using a raycast, as mentioned above, and whatever pixel got hit I reduce to color 0. (The damage texture is alpha only, to save processing power - don't need color here.) The autorepair causes it to fade in, making a glorious laser trail wherever the mouse goes on the quad.
And the best part? I did it all in under 100 lines of code!! :evil:

NVidia Geforce Experience isn't working right, or I'd record a video with Shadowplay to show you guys my baby in action. (I don't use Afterburner anymore...) I'll try to re-install it, and give your eyes a feast!

Things still needing done before I can implement the system as a gameplay device are:
1. Make the pixel trail a trail. If I move the mouse fast enough, the affected pixels might be twenty pixels apart each frame, making a trail of separated dots. :blush: I just have to save the position of the affected pixel each frame, then on the next frame, catch all pixels between the previous and the current one. Then spread a frame's worth of damage across them. This way sweeping a continuous laser beam across a ship in one second does less damage where it travels than if you took three seconds, and holding it in the same spot may expose the enemy ship's innards. (This is a good thing...:lol:)
2. Make the trail of damaged pixels have width. Currently it is just a one-pixel line, so what I need to do is have lasers affect an area with damage fall-off from the center. I will also make it so that tightening up your weapons' shots will result in a smaller hit area with the same total damage, resulting in increased damage to those affected pixels, meaning a higher chance of punching through the hull to damage systems. I'm not sure how to catch pixels surrounding a single pixel, but Unity helpfully includes the source code for the image effects, and I plan on learning what I need from checking how they did it for light bloom, which spreads out from a single location with fall-off from center. :whistle:
3. Make the autorepair more realistic in how it works. One part of this will be not affecting all pixels simultaneously and equally, which is ridiculous. Instead, the maximum number of pixels that can be repaired at a time will be determined by the autorepair effectiveness (more expensive ones can do more work, naturally). Also, I plan to make pixels only repairable if at least one neighboring pixel has health above 30%. This way repairs won't start in the middle of a hole in the ship. :blink:
4. Speaking of holes, I also plan to write a thingy that will check for detached hull sections. Basically, if you manage to decrease the health of an amount of pixels to 0 and by that separate an area of the ship (like make a circle/donut of killed pixels or a band around a wing), then detach that geometry entirely from the ship and assign it its own gameobject, rigidbody, whatnot. The autorepair would only be able to fix that problem if it's small, and it would take a LOT of autorepair materials. You didn't think you had infinite autorepair or something, did you??
5. Set up a proper relationship between the visible texture's pixels and the damage texture's pixels. This will be something like this: at < 80% health of the damage pixel, the corresponding visible pixel(s) will start turning gray. At < 50% health, it/they start turning black. Burn marks, woohoo! At < 20% health, it/they start to glow from heat. At 0% health they become transparent to show that there is now a hole, and any shots hitting there will have all damage dealt to the ship's internal systems, which is really the only way to destroy a ship in my game. No more reduce hull to 0 and boom! Gotta get PAST hull, and kill insides to render the ship unable to fly. Don't worry, there will still be highly explosive stuff inside the ship to guarantee pretty booms.
6+. There will be other things that will crop up, so don't expect a short timeline. But I'll try to get a working thingy as fast as I can.

Any questions, hurl my way and I'll answer with glee!

--IronDuke

Awesome!

The only problem I see is that when a section of the texture is turned invisible (indicating a hole) the player would probably be able to see through the ship, since the insides aren't rendered. You would need something to cover up the hole.