IronDuke's I-War2 Remake/I-War3

My EOC 2-D thruster system is already the same as yours, except for a few things. I can't add as many thrusters as I want, and I can't change the force of thrusters of the same type. The engine thruster has its own section to store its attributes, including how to draw it. The air thrusters only store the positions, and are all treated the same way. The AI handles the ship the same way the player does, by manipulating which thrusters are on and when. I also do not use a force system tied to each thruster. The force is applied to the ship, and then the thrusters that should create that force are drawn. I plan on modifying my system so I can add more thrusters.

He's dead, Jim.

You couldn't have said it better. :lol:

Regarding my textures, they will get blurry if you zoom in enough. The file I uploaded is 1000x1000*11/8.5 (100x1295) resolution, designed to fill an 8.5x11" page. I can generate textures of any size for you, so yes, there is an advantage.

In fact, here is a 5000x5000 pixel starfield for you. Still less than 100 lines of code, and completely procedural. I could not attach it because of its large file size, but here is a Dropbox link.
www.dropbox.com/s/0vku47ncex7q2sg/Ultima...%20Gradient.png?dl=0

Ohhhhhh, I thought you're starfield system was generated at runtime like the pixel stars currently in the base game. Because that would be sweet. *hint hint*

--IronDuke

The current method runs the algorithm on every pixel of the canvas, which takes a long time. My program runs the algorithm and saves the result in an image, which can be displayed at runtime. When I implement my star-based generation, every time the algorithm is run a new star will be created. These should be able to be generated at runtime, although it wouldn't matter if they are built into the image. For Space Engine, you can see the stars fly past while flying at high speeds, so generating in runtime is essential. In my generator, special stars will draw a flare over the generated position, coloring and scaling the flare in accordance to generated values.

I’ve decided what kind of damage model to implement. Seems to have taken me a whole week to work out.

Imagine the War Thunder armor viewer. Increase the number of armor segments by five to get a typical corvette’s armor layout. The internal systems will also be modelled with their own colliders, just like the various systems in a War Thunder tank. A key difference, however, is a large internal structure unintuitively named “Internal Structure” that sprawls through the middle of the ship. It’s basically the same as any other system, except that it has one function. When its health reaches 0, ship = boom. Another difference is that while the armor in WT cannot be destroyed, the armor in my system has a health value. The following paragraphs describe why.

So take a normal PBC shot. When it hits a ship, the angle of impact, the shot’s damage - decrease over distance, and the penetration are examples of factors taken into account. First, there’s a simple penetration check. Armor type, thickness, health, and hit angle are used, as well as the shot’s penetration and speed. The armor type, thickness, health, and hit angle will produce a “resistance” variable. The shot’s penetration and speed will produce a second “penetration” variable. A comparison of these two numbers will follow. If “penetration” is more than 50% (this might get tweaked some) greater than “resistance,” a full penetration occurs. The shot passes straight through the armor. Only a slight amount of damage is inflicted to the armor chunk, with the rest staying on the shot. If “penetration” is between 50% less than and 50% greater than “resistance,” a partial penetration occurs. Say it’s 10% lower than “resistance.” This would make a 40% penetration, so 60% of the damage is inflicted on the armor chunk, and 40% passes through on the shot. Now if “penetration” is less than 50% of “resistance,” then it’s a no-penetration. All the damage is inflicted on the armor chunk.

So what happens as the armor chunk’s health goes down? That affects “resistance,” as I mentioned that the armor health is a factor. I think I’ll simply have it be a multiplier to “resistance,” with 100% health being a 1.0 factor, and 0% health being a 0 factor.

Now what happens when a shot penetrates? As in WT, there are many systems in the ship. Whichever system the shot crosses will receive the damage, with another penetration check – not to see if the shot should go through, but to see how much damage it will do to the system, to allow some weapons to be better disablers. Nice and simple. In fact, if a shot has enough penetration and damage to go straight through the armor chunk, hit a system and bring its health to 0, then it will continue on, hit an armor chunk on the other side, run another penetration check, and if it passes, then go straight through and keep flying. MESON CANNONS ANYBODY?? :evil: Also, I’ll implement the ability for some shots to have an area of effect. Yup, antimatter PBCs will damage multiple systems easily.

Now how about beams and missiles? Beams will operate the same way. Missiles will be similar, the difference being that instead of tracing a line on their impact path to determine what they hit on a penetration, everything within a certain radius of the missile (the blast radius) is damaged.

There are several advantages with this system. First, it allows for tactical gameplay, making it wise to aim for sections of a ship that have already been hit. Also, it makes the game more realistic, which is a good thing, of course. It also allows for a very wide variety of weapon specialties, with some good against lightly armored ships, others against heavy armor. And finally, while the system in the vanilla EoC would take barely an hour to program, this one is not too hard either. It’s simple math.

Let me know what you think of it!

--IronDuke

It sounds good!

Wait, you could program this in an hour? (Or more, but still a relatively short time.) The thing I would get stuck on is detecting where the shot hit. The way my collision code would work (still haven't written it ) is an if statement running through all the vertices of the object to see if the shot is in the "shaded" area. Unless each piece of armor had its own collision hull, I would not be able to tell which one was hit. Or perhaps there is a way to check collisions on each plane, by checking for collision inside a 3-dimensional shape drawn from the vertices to the center of the model. Any input on this?

BTW, I have only fought one War Thunder battle. Before I downloaded the game, I watched one gameplay video to make sure I wanted it. However, in that short period of time I have picked up most of what I would need to know about the armor system.

P.S. I have downloaded the correct version of Unity.

Regarding textures, the textures I generate can be scaled larger or smaller quite easily, therefore generating a new level of detail. If I could get them generating at runtime, the primary benefit would be for ship textures. The closer the ship, the more detail is loaded, and nothing ever looks blurry. I do not know how this would be implemented in Unity, but it would work great for the game engine I plan on making. The textures viewed on the ship would have two layers: the generated layer, and the detail layer. There is no way I can build all of the aesthetic components of the ships into the algorithm, so these would be saved in an image and drawn as usual. Alpha transparency would allow the generated textures to be drawn. The generated texture file would generate chunks of texture and arrange them on the UV to render correctly, or the UV could be layed out to work with a single chunk of generated texture.

Unity is awesome. When two objects collide, Unity will call any functions in scripts attached to them called "OnCollisionEnter." There's also "OnCollisionStay" and "OnCollisionExit." (Possibly I screwed up the names; I've only used the first one.) It will pass to those functions, as an optional parameter, a class entitled "Collision." Collision has a ton of useful variables including: relative impact velocity, the exact position of impact, the normal of the triangle that was hit, and much more. Literally everything I need is already done for me. :mrgreen: All I'd have to do is write the damage calculations and give each armor chunk its own collider.

This is why I'm not writing my own engine.

I'm honestly not sure how textures updating in realtime would be implemented in Unity either; I'm not too strong on the art side of the engine. I'm not worrying about that for the moment, since coding the gameplay comes before fancy graphics. That and I'm not good at them. :silly: I'm not entirely certain that I understood every single word you said, although I certainly got the drift.

--IronDuke