Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - xenoargh

Pages: 1 ... 319 320 [321] 322 323 ... 338
4801
Lovely sprite, there, medikohl; really turned 'em into something new :)

Mothra lives  :D



Another design by a small person of my acquaintance; he was aiming for a bumble-bee, but the final result looks a lot like a manta-ray, so it's official, the name's the Glaug MantaBee.  Makes perfect sense, amirite?

Also the Glaug Flyter and Flea:



My edit/cleanup of medikohl's Mastiff; mounts two built-in guns and two smalls- a big step up for a pirate wanting to stay Frigate-light but with a lot of punch.


My edit/cleanup of medikohl's Saint Bernard, the Crow:

4802
Suggestions / Re: Resistant Flux Conduits
« on: September 23, 2012, 07:31:13 PM »
It might be easier to solve this by giving EMP hard-flux damage and/or a considerably larger lucky-dice effect, say 0.01% failure rate for all ship weapons and the engines per point of EMP damage taken that frame.  Then EMP, even weak EMP, is a really big deal, simply because a lucky shot may cause havoc and continuous EMP fire is almost as good as Overload.

The big issue is that right now, EMP isn't all that useful; there aren't any enemies stacked for a mainly-EMP assault, and if they were, we'd hardly be shaking in our boots.  While situational EMP from Salamanders is a genuine threat, Insulated Engine Assembly and Automated Repair Unit is a better counter in most cases, because it bestows that 10% armor bonus and the repair rate effects all systems disabled for any reason at all. 

So, yeah, I'm getting it for the no-brainer 10% Flux dissipation, which is, at the cost involved, always worth taking, vs. dumping the same OPs into vents.

I never have had a situation where I'm like, "oh noes, these guys are stacked for EMP, I'm stacked to deal with conventional damage".  Nor have I found most of the EMP-producing weapons are worth it vs. conventional weapons (in Vanilla).  EMP simply isn't effective enough to bother with, vs. just blowing them up.  So make it strong enough that buying a counter that doesn't come with Flux dissipation really does make sense, if stacking vs. EMP-happy factions :)

4803
Suggestions / Re: Problems with broadside logic
« on: September 23, 2012, 12:01:54 PM »
Yeah, I, uh, didn't expect it to keep being tangential  ;D

4804
Suggestions / Re: Problems with broadside logic
« on: September 23, 2012, 08:17:57 AM »
I was trying to explain the issues, is all :)

Anyhow, I've executed the strat manually; it works just like it does in the real world, with a ship that's designed for it; the problem is that the AI doesn't know how to do this kind of behavior :)

4805
Suggestions / Re: Problems with broadside logic
« on: September 23, 2012, 12:07:10 AM »
Delta-V is not specific to any particular time limit.  You're thinking about rockets burning fuel, I'm talking about vector magnitude changes and the time costs.

Acceleration is important, when dealing with delta-v, because you can only change the magnitude and arrive at the correct vector once you're facing the direction where you get the most acceleration along the correct vector and have input enough time.  This is why when you fight an enemy with equal speed and acceleration and they're kiting, if you wiggle, you lose ground.

Turning speeds matter here, too, because they're the amount of total time it takes to arrive at the vector, which is going to keep changing over that period of time.

Anyhow, long story short, ships designed for broadsides should attempt to circle the target, because the enemy's in the area covered by the largest-possible concentration of DPS.  They aren't; they're wasting delta-v and DPS, both.  It's a special situation that only occurs with a ship that's really build specifically for broadside-only engagements, but it'd be nice if it could work, because it'd add more interesting patterns of behavior :)

4806
Suggestions / Re: Trade mechanics; some thoughts
« on: September 22, 2012, 11:52:29 PM »
Quote
X3 doesn't seem THAT complicated...
Well, play it and see, and come back to this :)  In my opinion, X3 is even more complicated than Battlecruiser 3000AD was, and that's saying a lot.

Moreover, unless you really, really really like spending days just moving numbers around, it's dull, and it's my prime contender for "how not to do it", followed by the way it was done in Mount and Blade: Warband (which also attempted a supply and demand economy, but it's not pretty).

If you don't have time to try out X3, read the play-through guides for how to get enough money to do important stuff, like have a fleet.  If that doesn't discourage you, well, I guess we're just going to have to agree to disagree; there's nothing wrong with wanting that level of detail or having to jump through those kinds of flaming hoops, it's just not what I enjoy, at all.

Quote
It's basically supply and demands there, with the price getting higher the rarer the resource.
It's a lot more complex than that; basically your job in X3 is to both seek out wherever the econ sim is going wrong and to purposefully manipulate the AI into doing stupid things that give you a lot of profit.  Neither of which has anything to do with flying a cool spaceship, building a neat fleet, etc., etc.- it's all a bunch of gameplay that takes you away from all of that and in the end, makes it irrelevant.  I'd really prefer that Starfarer didn't go down that road, it's not necessary and it doesn't really increase the fun.

4807
Announcements / Re: Starfarer 0.54a (In Development) Patch Notes
« on: September 22, 2012, 08:38:23 PM »
Quote
Yep, that's already there (the "Navigation" skill uses it).
Wonderful; I can't wait to upgrade my skills to the point where my Evil Pirate Fleet can actually catch those pesky Indies as they flit back and forth with their tempting cargoes of Duranium :)

4808
Suggestions / Trade mechanics; some thoughts
« on: September 22, 2012, 08:36:18 PM »
Basically, I'd like to lay out some thoughts about trading systems in games, and how I think that it could be Fun in a game like Starfarer.
TL:DNR:  I'd like to see an abstract economic sim with some simple rules that keeps the player focused on what they're doing with their fleets, because that's the core of the Fun.
Spoiler
In most games that feature trading, there are three primary approaches taken; each has some advantages and disadvantages.

1.  Trade via defined trade routes and static pricing.  This has a bunch of advantages, starting with simplicity, transparency to players and easy customization.  However, it irks people who expect a game to emulate an "economy", and they start bellyaching that they're merely doing Fedex work (or having their proxies do so), rather than owning their very own means of production.

2.  Trade with a full-fledged economic sim taking supply and demand into account, allowing players to build factories that can change the balance of trade in a region, etc., etc.  This has a lot of serious disadvantages, starting with complexity of implementation, but the most serious problem is one of balance; IRL, if you have a huge number of Widget A factories on one end of the world and Widget B factories on the other side of the world, you rapidly reach a point where technological change or demand-side changes (growing wealth, population growth, etc.) reduces profitability to nothing.  A world in which both AI and human actors are able to have full-fledged control over the location, number and scale of the means of production is basically a whole 'nother game on top of what's already in place, and it'd require a lot of rules to be remotely balanced, otherwise it'll suffer from one of two major defects:

A.  The AI will build stuff in a way that made sense when testing it early, but which combined with human choices causes the markets to disintegrate.  It's really pretty hard to write an AI that can deal with complex economics in anything like a rudimentary way.
B.  Players will find ways to go exponential really fast, and will purposefully destroy the AI's ability to play, because they will lock down all of the means of production to the point of negative profitability other than whatever's working for them (or everything, if they're sitting on plenty of money and simply wish to destroy the AI).

In short, I have a very dim view of this approach; it's been tried a lot of times, and for the most part it's been a mess, other than really pure economic simulations that don't have the option of, say, destroying your opponents' means of production available as a mechanic. 

It always sounds so cool, and so easy, too; "if trading distance A is greater than B and you've got enough C and D, you can make a profit building and delivering A".  But the permutations rapidly get very, very complex; about the only games like this I've seen that haven't been pretty easy to subvert or chock-full of arbitrary restrictions are the turn-based MMO ones.

3.  The third approach is what I'd like to call the "Sim City economy"; i.e., players construct things that interact with a totality they don't have total control over, but they can provide powerful nudges and profit by providing growth opportunities. 

For example, players could build Outposts; these serve as bases that will conduct mining runs and provide the local System with some raw ores.  This in turn boosts the local economy, and the population grows (probably the easiest way to simulate changes in demand) and wants more Stuff than the local auto-factories are making.  Now building some new Widget Factories at your upgraded Outposts makes sense and will turn a profit over time.  On the converse, your enemies may build their own Outposts, stealing some of the local demand away and lowering profits.  All of this is kept abstract; your Outposts are building "industrial centers" and build "trade goods", not making Iron Ingots in Metal Processing Facilities Mk. II.

Obviously, destroying their Outposts may make sense, but what about the political consequences, if the planet's owned by your ally, who's on good terms with this faction?

This creates a pretty interesting dynamic, and it's not a lot more complicated than the first approach, at least to implement the basics; if trade requires actual (if abstract) 'goods' to move from Outposts to the points of delivery, that makes for interesting complexity up to a point; you may have to spend some hours guarding your trade routes personally before you can hire some guards, and guards are probably always less efficient.

Personally, I think this is the way to go, because it would keep the economics fun and not too hard to get into, for new players, and be abstractable on the large scales of Sector-spanning gameplay (i.e., 4 Outposts with X economic Systems and Y guard fleets = some profit level, even when you're half a Sector away).

Anyhow, those are my thoughts about this; I'd really love to play a game where The Economy was kept simple enough that it wasn't a major distraction, where it also encouraged a lot of hands-on, in-my-ship play (guarding trade ships, blowing up enemy Outposts) but where it wasn't as simplistic as simply getting the biggest cargo ships and doing the Kessel Run just before buying the game-ending uber-battlefleet of my dreams, either.  This approach could also be really modding-friendly, potentially; if we want to have a new Outpost Addon called, say, "Astromechanics Shop" that costs X per week but sped up our trade convoys' turnarounds by Y, it'd be fairly simple Java and the whole thing would be pretty easy to extend in various directions by modders.

It also has one other big advantage, which is that Fedex-type questing can exist alongside it without any issues; a mission to deliver X-Synchrotron Oscilloscopes to Corvus VIIa is not going to cause any raised eyebrows, because it's outside the abstract box.
[close]

4809
Modding Resources / Re: Trylobot's ship editor (2.4.5)
« on: September 22, 2012, 07:18:11 PM »
Yeah, it's awesome.  Haven't messed with the nascent gun editor yet; so long as it shows the barrels / missiles and the main turret and allows us to define the barrel positions / angles, it's pretty much golden, most of the other stuff is easy to do.

4810
Suggestions / Re: Problems with broadside logic
« on: September 22, 2012, 07:14:43 PM »
Quote
You only get better acceleration (not delta-V, these ships don't seem to use propellant for in system travel) for forward thrust.
Delta-V is just physics shorthand for the change in velocity over time; doesn't matter what's causing it.  Forward and backwards thrust is purely arbitrary and can be controlled by modders' numbers; strafe, on the other hand, is some magic number that we're not currently allowed to tweak.  Anyhow, that's a side topic.

Quote
More or less: I don't get it. Could you demonstrate with a video or something?
It's pretty simple, really; ships with most of their DPS on side arcs need to act like ships do in sailing-ship sims, where they attempt to keep their side, not their front, facing the enemy.  Look up "crossing the T" on Google and read a little about how naval warfare worked before the WWI / WWII Dreadnought-style of warship became the primary design. 

That design, btw, can deliver both maximally-effective broadside fire and better firepower whilst in the chaser role, allowing the RL ships to kite by delivering a broadside while at flank speeds every time they were able to gain enough distance on the vessel they were pursuing.

For pure space warfare on a 2D playing field, neither design is actually all that efficient, because the rear guns will almost never get used due to the inefficiency of broadsides; the best firepower is always going to be a flying-wing or globe design, for either converging broadsides while kiting or a concentration that no amount of counter-battery is going to block; both designs offer strong advantages and disadvantages. 

But I wanted to put some of this kind of design in and give them enough advantages that they'd be useful and provide something different to shoot at, and what I'm finding is that the AI just doesn't use them right, no matter how they're stacked.  For example, if I put weapons onto the side gun positions that greatly outrange anything else in that turret category, giving it a definitive advantage, it still won't attempt to circle the target, even though at that point it's advantageous to do so, due to using its delta-V to force the opponent to burn delta-V inefficiently to continue to bring itself into range, while the whole period is increasing the accuracy of my fire.  IOW, there are actually some situations where using broadsides makes sense even in a 2D game like this; same argument can be made that if all ranges are equal and the opponent cannot gain a range advantage and permanently kite, if a broadside provides greater DPS, it's time to circle. 

But the AI isn't doing any of that; it's largely unaware that it's stacked for broadside behaviors and doesn't appear to take these things into account.  So I saw my long, skinny warship that was stacked to kill a lot of minor vessels in a couple of volleys, if it used a broadside and forced the enemy to approach it on that arc fly straight at the enemy, and occasionally turn enough to deliver a partial volley (due to range; remember those front guns are quite a few pixels forward) which cost it delta-V and wasn't effective.

4811
Announcements / Re: Starfarer 0.54a (In Development) Patch Notes
« on: September 22, 2012, 12:01:20 PM »
This list is looking great, Alex! Really excited about this next build, it's going to take the game a big step towards feeling like a full-fledged RPG :) 

Any chance we're going to see a Mutablestat that can affect in-system travel speed for fleets yet?  Really want to do that as a System or via character skill, it's one of the few major gripes I've had with the campaign's feel lately :)

4812
Suggestions / Re: Problems with broadside logic
« on: September 22, 2012, 11:55:21 AM »
Strafe speeds aren't the same as forward speeds, and although the velocity caps on ships hide it to some degree, when a ship isn't perfectly facing the opponent, it's using up delta-v on a vector that won't take it nearer to the enemy.  That velocity then has to be corrected for, hence it's a waste of delta-v. 

In kiting situations, wasting delta-v is bad, because it means your enemy can either catch you or that you can't catch them.  What I want to see is an AI behavior that deliberately avoids kiting and just goes for broadsides, when that's where the overwhelming majority of the DPS is :)

4813
Suggestions / Re: Problems with broadside logic
« on: September 22, 2012, 09:15:53 AM »
The weapons were originally designed to be at right angles and to have 120-degree arcs, i.e. nothing on the broadsides faced fully forwards. 

To be remotely efficient, it would have to do circling behavior, not a face-forwards-then-twist behavior, which is what it occasionally tried to do.  This is an edge-case thing, because, in theory, it can do "more damage" by facing the target at an angle, but this screws up the ship's manuevers and makes it waste delta-v, making it considerably less efficient in chasing fights, whereas if it circled, it would not be able to kite, but any enemy entering the circle faces the maximum possible number of guns.

Anyhow, I fixed it the same way I fixed the Conquest, by allowing the arcs to reach full forwards.  Then it starts behaving efficiently, but it's twice as powerful as planned ;)

4814
Suggestions / Problems with broadside logic
« on: September 19, 2012, 10:46:33 PM »
Basically, the ship AI isn't handling long, skinny ships well, and I think it needs a rule change.  If the majority of the weapons are restricted to an arc that's pointed to either + / - 60 to + / - 120 degrees, or if the largest total DPS lies into those areas, the ship needs to use the broadside logic (i.e., attempt to circle the target or cross the T, instead of using strafe).  If both sides are even, it needs to pick a direction to circle and stick with it, probably for the rest of the battle, as if it picks randomly each time the AI picks a new target, it tends to do more harm than good.

That this isn't working right atm was revealed pretty massively when I built this guy:


All those side-arc weapons were Medium Ballistic, with a combined DPS that far-outweighed anything in the forward arc.  The ship didn't perform adequately until I allowed all those turrets to face fully forwards, however, and tried to face forwards regardless.  This problem also plagues the un-modded Conquerer.

4815
Suggestions / NoStrafe, Friction
« on: September 19, 2012, 08:06:39 PM »
NoStrafe would be a Hull value.  If TRUE, the ship may not use strafe motion, but must turn to change vector.  This might be a biggie, in terms of AI.  It'd be cool for stuff that we want to have more realistic behaviors, though.

Friction would bring a ship or weapon shot to a gradual halt over time.  It would have a lot of modding and gameplay uses.

Weapon shots with a friction value would have their initial velocity multiplied by friction.  A value > 1 would cause the shot to speed up over time, and the inverse would be true.  Values < 0 or 0 would result in a shot would have an initial speed of 0 and not accelerate, regardless of the speed of the launching object.

This would be useful for mine-droppers, weapons with accelerating projectiles, weapons with a fixed radius of projection after MIRV-ing, and for modders, it would allow for some simulation mechanics to be explored, such as using it to simulate air resistance and gravity (if somebody wants to do a WWI / WWII TC mod).

Ships would need two friction values; one for lateral acceleration and one for linear acceleration, and would be restricted to values of 0.0 --> 1.0. 

Friction would be applied after thrust was factored into the current velocity vector each gameframe, and would slow the object each gameframe until velocity reaches zero.  It would need some specific rules:

With a linear or lateral friction value, linear friction would only be applied if thrust was not being applied on that vector (or the inverse or either cross).  If a ship's linear Y+ was > 0 and the end-user applied thrust -Y, then friction would be applied to the value until it reached zero, for example. 

It would serve as a form of "brakes" on a ship no longer under thrust, basically.

If NoStrafe was true, then lateral friction would get applied every gameframe.  This would allow for mods that explicitly modeled motion behaviors that weren't envisioned by Starfarer-as-a-space-game, such as ground combat, WWI / WWII ship battles, Freelancer-style space combat, and many other things.

Pages: 1 ... 319 320 [321] 322 323 ... 338