GAME CHANGER - A little overlooked law of aerospace science.

[DaddyHoggy]

A loooooong time ago I had a discussion with somebody (I think it may have been Commander McLane!) about creating an ubership, but with a fatal design flaw - the "Death Star exhaust Port" type thing. A good commander could punch a hole in the shielding cowling just below the inverse flow rate manifold (i.e. a handwavium subentity) and the ship suffers a catastrophic chain reaction that blows it to smithereens.

What stopped this idea then was that you would have to have built a ship where the fatal part was actually the ship (that had the energy level) and the rest of the ship was actually the subentity... but this was in the days before .js scripting, so I was wondering if this was still true? Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?

That way you could have an ubership, but the good commander could strike its Achilles Heel and still come out the victor?

[Commander McLane]

Well, on that topic, I am going to take an extra five and make a more standard Wyvern, too. The main cool features are the weapons and the superb recharge rate. So, that way, there's still something to work with most missions.

That will depend entirely on the particular mission. If for instance the mission is designed to make the player use their cloaking device wisely, a big energy recharge rate will make a huge difference. If the mission is designed to give the player very little time to fulfill a specific task at the other end of the current system, a big ship speed will make a huge difference. If the mission is designed to make the player choose their pylon-mounted equipment wisely, a big number of pylons will make a huge difference. Etc, etc.

When I design a mission my aim is to come up with a task that will be thrilling for the player. Their choices are meant to matter ("can I afford to mount another fuel tank or do I need the pylon for another missile?"). The mission is meant to be challenging ("Will I survive the next encounter with tough enemies? I'd better save my game now, just in case."). A player ship which has everything in spades takes the decision making away from the player ("Yes, sure, I can take two or three additional fuel tanks, and still have more than enough free pylons for weapons. What's the deal?"). A player ship that is nigh invincible takes the thrill away. The mission tends to become boring and pointless instead of thrilling.

As long as all player ships have comparable stats there is no big problem. One ship will excel in a certain part of the mission, another ship will be better suited for a different part of the mission. Overall there is a comparable level of difficulty. If there is a wide range of very good ships available which are altogether on a different level than the original ship set, things change. The mission that was fun with one of the original ships will be less fun with an über ship. And I can't simply raise the overall difficulty level of the mission to accommodate über ships, because that would make it impossible for the few blokes who stick to the original ships.

Ship designers want their freedom. Freedom to create the ultimate ship (it's always about the ultimate ship; there is not a lot of interest in using their freedom to design under-performers). As such, that's fine. Nothing to say against it.

It's just that by using their freedom they automatically and irreversibly are taking away the same freedom from mission designers. Mission designers can't do whatever they want, because there is already a ship OXP available that undercuts everything they could come up with. As mentioned several times in the discussion, creating an über ship is actually a piece of cake. It just requires typing some numbers in a shipdata.plist. Creating an intricate mission scenario which is fun and challenging for any interested player on the other hand is not a piece of cake. Ship designers get a lot of appreciation here for their work. I wish they would also sometimes appreciate the work that mission designers put in balanced mission OXPs, and spend a thought or two on the impact their latest ultimate creation is going to have on the work of mission scripters. That's all I wish for.

Sorry for hijacking this thread. I just thought that, now that the subject has come up, it would be as good a place as any other to verbalize some rough thoughts on the subject of the relation between ship OXPs and mission OXPs. If it sparks a debate, feel free to split, moderators.

[Dragonfire]

Well, you definitely bring up some very good points. I guess it comes down to a balance, really, between the goals of the ship builders and the goals of the mission builders. Then, it is up to the players to download what THEY want, whether it be omitting a ship or omitting a mission.

By the by, my main goal in having the third Wyvern version is just due to some people (like you) not wanting super fast ships in their Ooniverse, and quite understandably.

[Okti]

Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?

I am not sure about it. I had a quick look in the wiki, but could not see a property stating the subentity has been destroyed. If the count drops than that can be used. If any one can state a quicker answer that will save a lot of testing time.

[Commander McLane]

A loooooong time ago I had a discussion with somebody (I think it may have been Commander McLane!) about creating an ubership, but with a fatal design flaw - the "Death Star exhaust Port" type thing. A good commander could punch a hole in the shielding cowling just below the inverse flow rate manifold (i.e. a handwavium subentity) and the ship suffers a catastrophic chain reaction that blows it to smithereens.

What stopped this idea then was that you would have to have built a ship where the fatal part was actually the ship (that had the energy level) and the rest of the ship was actually the subentity... but this was in the days before .js scripting, so I was wondering if this was still true? Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?

Yes, I remember the discussion. And yes, a script that would cause an NPC to explode as soon as a specific subentity is shot off would be fairly simple, I think. The hit detection with subentities is sub-optimal, though, and you may end up destroying the death star when you hadn't aimed anywhere near the exhaust port.

But the real question is: usually we're talking about player über ships. Should they have an achilles heel, too? If your opponent hits a certain spot on your ship's hull you get an instant "Press Space Commander" moment? Would players want that? And would ship designers be willing to implement that, even if it lowers the chances that players will actually use their ship?

[Dragonfire]

Which brings up the question of, in my Wyvern OXP mission...how exactly DOES one destroy a Black Wyvern...?

[Thargoid]

Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?

Yes you can do it, and I must admit I do like the idea a lot.

You can read the list of subentities a ship has with the array this.ship.subentities (logically enough). So what I would do is set the ship up with the "ubersecretdestructbuttonsubentity" as the first sub-entity (this.ship.subentities[0] in array terms) and give it a suitable role. Then you can use a timer to check if this.ship.subentities[0].hasRole("myRole") exists and is true. If it is then carry on, if not then this.ship.explode...

The only restriction will be the ship has to be frangible (so the sub-ent can be shot off without having to take the whole ship down) and to have suitable stats to make the main body indestructable (suitable energy and recharge rate) and the relevant sub-ent not so.

Edit - Ninja'd!

[Commander McLane]

Well, you definitely bring up some very good points. I guess it comes down to a balance, really, between the goals of the ship builders and the goals of the mission builders.

I'm afraid that this ship has sailed long ago. If I take a look around the boards, it's all about ship builders and what they want, and it's all about the arms race towards über ships. Mission building doesn't count. Game balance doesn't count.

So I don't feel motivated to re-visit Cataclysm, and much less motivated to develop another mission (I have another half-developed mission OXP sitting on my hard disk for many months now).

[Commander McLane]

Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?

Yes you can do it, and I must admit I do like the idea a lot.

You can read the list of subentities a ship has with the array this.ship.subentities (logically enough). So what I would do is set the ship up with the "ubersecretdestructbuttonsubentity" as the first sub-entity (this.ship.subentities[0] in array terms) and give it a suitable role. Then you can use a timer to check if this.ship.subentities[0].hasRole("myRole") exists and is true. If it is then carry on, if not then this.ship.explode...

The only restriction will be the ship has to be frangible (so the sub-ent can be shot off without having to take the whole ship down) and to have suitable stats to make the main body indestructable (suitable energy and recharge rate) and the relevant sub-ent not so.

I haven't tried it yet, but I think it should be possible to give a subentity a ship script of its own. That would make it even easier. You wouldn't need a timer, but just a shipDied in the subentity's script, and then this.ship.owner.explode().

[Smivs]

Could we now design a ship where if the script detected a subentity had been destroyed, the ship blew up?
That way you could have an ubership, but the good commander could strike its Achilles Heel and still come out the victor?

Funny you should say that
The OXP Workshop (an un-holy alliance of Smivs, Okti, El Viejo and Staer9) are currently working on a major mission OXP which uses something very much like this as the Grand Finale.
Won't be ready for a while...

[Fatleaf]

I'm afraid that this ship has sailed long ago. If I take a look around the boards, it's all about ship builders and what they want, and it's all about the arms race towards über ships. Mission building doesn't count. Game balance doesn't count.

So I don't feel motivated to re-visit Cataclysm, and much less motivated to develop another mission (I have another half-developed mission OXP sitting on my hard disk for many months now).

This makes me sad. Cataclysm is one of my favorite missions. At least I know now why you haven't updated it.

But on the points of ship choice for a while I was using the Uber'est ship available to date the Caduceus Omega, but recently I have been going back to the Cobra III and now Staer9's Chopped Cobra is out I can see myself sticking with that. Stick on a Railgun and you always have something to fling at them when you red line the front gun. I must admit since going to a less uber ship my enjoyment for the game has increased, yes it was fun for a while to be the big bad ass but after a while it gets a little old never having to think about your tactics in game.

With an uber ship you just wade in and slaughter everything. With a balanced ship then you have to use your mind. I'm reminded by an old saying "Not by strength but by guile"!

So my opinion is firmly with Commander McLane with this point. As for a lot of us here good quality missions really make the game so much more fun to play. So if the balance is lost and the maturity of people along with it then the game will just become dull.

So I would appeal to ship builders to take a bit of time, look at Staer9's latest work, it adds so much and takes nothing away. Think about quality not invincibility, long term playability not short term cheap thrills.

[Cody]

What leafy said!

[Dragonfire]

Well, I would like to add in that the Wyvern OXP mission I'm working on is more brains than brawn for sure. Ubership aside, you're fighting your own kind.

[Thargoid]

I haven't tried it yet, but I think it should be possible to give a subentity a ship script of its own. That would make it even easier. You wouldn't need a timer, but just a shipDied in the subentity's script, and then this.ship.owner.explode().

Last time I tried something like that it didn't work, but that was a while ago.

If it does work now then yes I agree it's a much simpler way, but I'm not sure you can hang separate scripts off sub-entities. Hence why I suggested the rather less streamlined method instead.

[Commander McLane]

Well, I would like to add in that the Wyvern OXP mission I'm working on is more brains than brawn for sure. Ubership aside, you're fighting your own kind.

Yes, forcing the player to use a specific ship in order to even get offered a mission is certainly a way to eliminate some of the variables.

But isn't it at least a little odd, in the name of freedom for ship designers and übership-lusting players, to take away other players' freedom to use the ship they want to use for a mission?