Return to “Announcements”

Post

Re: Development Logs

#46
JoshParnell wrote: Scouting is definitely going to be a real job, as desired. Buying information is going to be a practical thing, and there are a lot of different ways that it could help - if you're a miner, you can buy information about ore-rich asteroids, whereas if you're a pirate, you can buy scan information about nearby conveys. Similarly, selling information will be possible - and potentially lucrative.
Fantastic to see this getting implemented!

Scout/Explorer is one of my favourite things to do in space sims, and I'm glad to see it will be a viable gameplay strategy.

Most other games seem to ignore the concept, or implement it poorly. Happily, Limit Theory seems to be shaping up to be the exception to this.

Hooray!
- The Snark Knight

"Look upward, and share the wonders I've seen."
Post

Re: Development Logs

#47
Re: Wednesday, March 6, 2013

I'm fascinated by the latest ideas on combat, e.g. the manoeuvre sphere of optimal attack.

It strikes me that coming up with an idea of optimal attack will lead to a counter-idea of optimal defence for such an attack, and that the weapon loadouts will reflect such strategies. In some ways, there should be an arms race until a point of maturity (so the AI will know what best to do), and maybe we need to walk through that arms race to work out what that maturity involves.

For example; if I have a cap ship, I know that it will be attacked by fighters moving around their optimal sphere, throwing in ordnance. I need to do two things; 1) kill that incoming ordnance, and 2) attrit the fighters at that range. That means enough point defence and shields to deal with whatever they throw, and enough ordnance that can kill fighters moving on that sphere. That offensive weaponry would be energy if close enough, or else missiles.

Now, if I commanded a fighter force and knew the cap had such weaponry for that, I'd likely aim at one of two strategies; 1) increase the sphere radius to a safe range and use longer range weapons, or 2) swarm the cap to overwhelm the defences, accepting a high attrit rate. 1) would make life easier for the cap, as there's more time to intercept incoming, and 2) means it would need its own fighter screen.

Now, I decide to form small groups consisting of a torpedo boat and several screen fighters, and rush these groups at the cap. I also form several decoy groups consisting of fighters only, and form linear meta-formations assuming those at the back survive. Now the cap has a problem because the attrit kills many fighters, but there's a good chance some torpedoes get through. Again, the cap counters by trying to have enough fighters to screen that. So far it looks like most strategies will be very sore on fighters! That may mean using cheap, sacrificial drones to replace most fighters, as individual skill is less important than weight of numbers.

in any case, the main point of combat would be to gain/control/deny valuable assets, so the types of assets would need to be factored in, e.g. capturing a station or JG, or just a valuable cargo in a freighter, assuming it will surrender before destroyed. What types of ships and ordnance would be best used to do so, using what strategies?

Anyway, is it worth having a strategy/counter-strategy thread to work this out, befoe the AI is decided on?
Post

Re: Development Logs

#48
Factor in subcomponents too! ;)

Against capships:
The first thing I'd do is hit the sensor array, then go after the weapons in the weakest defended quadrant. After that, probably the engines to stop the thing from moving. If there's such a thing as a communication array, that would actually be the very first one I try to destroy. Destroying these subsystems would create an extremely advantageous position for my wingmen to attack the capship.

However, fighters need to get close to a capship first before they can take out any subsystems. A sneak attack on a neutral party might only happen once in a while. Now it depends how smart the turrets are. If they prioritize ships that head straight for the cap, you can't do anything but circle your way closer in, or close the distance in a blind spot.
With procedurally generated ships, this blindspot will change a lot. Perhaps newer generations of the AI ships would even add extra defence where their blind spots were. I usually have difficulties detecting the blind spots, so I'm hoping LT will assist me a little. I'm sure the AI will have a huge advantage here.
Circling your way in makes the journey a lot longer and will be probably as dangerous as heading straight for the ship.

So, you're going to get hit... Now I see two options... Fast and agile to try and keep the capship from tracking you or slower and heavily armed to soak up the damage. Personally I think evasion is the better choice here, but it kinda depends on the weapons of the capship. Should it have fast tracking anti-fighter turrets with fast bullets, agility is probably not helping you too much.
Many lives could be lost before you find out the weakness of an enemy capship. Unless there's sensor technology that can help you with this.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: Development Logs

#49
I agree, once you start taking down the cap's sensors, that will limit it's ability to detect and engage targets. However, getting to that stage may be vey difficult, and the best that might be hoped for is some heavy ordnance getting through and causing increasing random damage.

A cap should have no blind spots, otherwise that's a major flaw. Point defence turrets could be mounted on pylons away from the hull, thus giving excellent arcs of fire. Assuming enough turrets, there would be no blind spots except perhaps close in if you can get amongst the superstructure. Which means surviving that far.

While constant ang velocity would cope with targets tracking around a sphere, rapid charges would need variable ang velocity to cope with the flyby. I'd dare suggest that point defence would only be used for imminent threats, such as incoming missiles or charging fighters, and would likely be short range only. Shotguns and disruptors. Heavier turrets would indeed be used for hitting threats at longer range, where ang velocity would not be high. I'd guess missiles would be the best long range weapons, though there'd be a limited stock. Also, decoys and countermeasures may play a prominent role; think of aircraft using flares and chaff.

At this stage I'm starting to think that the best way to kill a cap is using your own cap, assuming they have large ordnance for bombardment, or some sort of powerful beam weapon. Such a beam weapon would likely be built into the hull so could only be aimed by pointing the ship. No good for manoeuvrable fighters, but deadly to other caps and stations.

Also, different caps would have different roles; some would be for bombardment, some for sensing and scanning, others would be carriers which can provide a swarm of defensive fighters & drones. A bombardment cap may be able to kill large targets at long range, but struggles to defend itself so needs an escort. A carrier also avoids direct combat, but its swarm is deadly. Indeed, to neutralise a cap you don't need to kill it, just take out enough escorts whereby it has to withdraw. So, escort killing may be a higher priority than hitting the cap itself. Any fleet would likely have a number of high-value ships that avoid direct combat (apart from long range), and it's the escort's job to tackle any threat. Without an escort they run away!

This brings up the question - what would a fleet consist of and why? I reckon the ultimate goal would be the capture or destruction of assets, otherwise what's the point in having them at all? Thus there must be some means to capture stations, factories, JGs, etc, and the fleet mix will include that. I think we're talking assault ships - some means of putting "boots on ground", even if only in an abstract way.

Should this go to another thread?
Post

Re: Development Logs

#50
I'm intrigued by the internal linked list which seems a clever way to go, but I'm wondering why the object can't be used in multiple lists too, assuming you inherit (or even contain, at an extra step cost) more than one element class? I've used multiple lists before where rapid traversal was more important than the extra memory overhead, the alternative being several slower filtered searches/sorts on a single list. It means that any one object can exist in several optimally sorted lists used for different purposes, e.g. for separate x, y and z position order. Or else I've picked up the wrong end of the stick with this!
Post

Re: Development Logs

#51
JabbleWok wrote:I'm intrigued by the internal linked list which seems a clever way to go, but I'm wondering why the object can't be used in multiple lists too, assuming you inherit (or even contain, at an extra step cost) more than one element class? I've used multiple lists before where rapid traversal was more important than the extra memory overhead, the alternative being several slower filtered searches/sorts on a single list. It means that any one object can exist in several optimally sorted lists used for different purposes, e.g. for separate x, y and z position order. Or else I've picked up the wrong end of the stick with this!
Well you're right, it can be used in multiple, but you need an internal element for however many lists you can be in at the same time. I.e., if you can be a part of up to three different lists, you need three internal elements, which I think is what you were saying.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Development Logs

#52
JoshParnell wrote:Well you're right, it can be used in multiple, but you need an internal element for however many lists you can be in at the same time. I.e., if you can be a part of up to three different lists, you need three internal elements, which I think is what you were saying.
Yup, exactly so! The object has to be list-aware of all lists it's a member of. The usual trade-off pros & cons of performance vs. memory/storage.

I think I have a slight obsession; I learned assembler when my available program space was often 256 bytes or so :o , so those sorts of tradeoffs are burned deep into the geek part of my brain 8-)
Post

Re: Development Logs

#53
As I'm replying to my own post (!), this one is for the Monday, March 18, 2013 dev log.

As universe generation is a once-per-game affair, I don't think the time taken matters that much. By all means optimise as faster is still better, but then feel free to use that saved time to include more time-consuming detail generation if you feel it needs any. Maybe the player could choose options and slide sliders which will enable more/less detail vs. slower/faster processing.

I'm still not sure what shape(s) the universe will have; will there be separate galaxies? Is it all one big galaxy? Or something else entirely? Or is all that still to be worked out? I'm curious! :)
Post

Re: Development Logs

#54
JabbleWok wrote:As universe generation is a once-per-game affair, I don't think the time taken matters that much.
Not quite. In the Dev Log Josh talks about system backdrop generation as well. And this of course needs to be done each time you jump from one system to another. And as there is nothing to prevent you from exiting out of a jumpgate, turning around, and re-entering en-route to the next system, a new system (including its backdrop) may need to be generated every couple of seconds.
Post

Re: Development Logs

#55
Commander McLane wrote:Not quite. In the Dev Log Josh talks about system backdrop generation as well. And this of course needs to be done each time you jump from one system to another. And as there is nothing to prevent you from exiting out of a jumpgate, turning around, and re-entering en-route to the next system, a new system (including its backdrop) may need to be generated every couple of seconds.
In terms of the new systems themselves, that will be a much smaller task than generating the whole BoI. In terms of backdrop, I agree, that is a per-jump issue. However, even that I don't see as a major issue if we're assuming that jumping should take appreciable game time (even with accelerated play time). Maybe impressive FTL-hurtling animations while the backdrop is being generated, to keep you distracted. If you're travelling by ferry, you could have access to a full menu-driven service area which will keep you busy for some time. I think the "time taken" aspect of jumping and consequent generation could be used to good effect, gamewise. I'm just of the opinion that "do it well" should take precedence over "do it quickly".

Nevertheless, faster is better, I agree!
Post

Re: Development Logs

#56
In this case I would also advocate caching. It's easy to regenerate something each time using the procedural formulae, but it wouldn't hurt to set a gig or two of harddisk space aside for cpu intensive stuff.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: Development Logs

#57
For the Tuesday, March 19, 2013 dev log , the exponential growth / improvement / cost factor could be e^kx where k is small (edit: k < 1) and unique for each circumstance. It's still exponential, but kept manageable and configurable. Or negative for any decline: an exponential tail-off :D

As for buy/sell and import/export via an interface, I'd always suggest keeping it transaction based, i.e. set up all changes before hitting a final "commit". It also means the ability to change your mind prior to that last step. If market force-based price changes apply, transacting a large amount all at once will have a different effect than lots of single-unit ones.
Last edited by JabbleWok on Wed Mar 20, 2013 5:36 am, edited 1 time in total.
Post

Re: Development Logs

#60
JabbleWok wrote:
Katorone wrote:For buying and selling, I dislike having to drag and drop everything. Personally, I love the shift+click combination.
Or just type a number and click "add to trolley" :D
Personally, I'd like to use the mouse as little as possible.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.

Online Now

Users browsing this forum: No registered users and 16 guests

cron