Return to “Announcements”

Post

Re: Development Update #16: April 2014

#49
Feedback:

1. there is a dim blue light opposite the sun lighting up the asteroids. Earlier in this thread you might have said this is from the mining beams, but this is a good ambient light effect. It was so good I assumed it was intentional and not the beams doing it. I think in film/art this is called a back-light(?). It gives more visual appeal than objects having pure dark on one side (especially for a dark object on a dark background).

2. love the new station, asteroid shape tweaks.

3. what black magic allows one person to outdo Eve Online? :shock:
Post

Re: Development Update #16: April 2014

#50
JoshParnell wrote:
ThymineC wrote:
JoshParnell wrote:"Matched together" suggests that you either want to perform multiple actions in parallel with different units (which is equivalent to what already exists), or perform multiple actions in serial. Does it really make sense to do the latter, though?
I hope we can still serially chain relatively low-level actions, though, as in Command Stacking. This would be necessary if, as Flatfingers proposes, I wasn't able to maintain instantaneous communication with my subordinates, or if I wanted them to pull off some complex task without me having to constantly monitor them.
Yes, absolutely. But I consider this different from a project allocation - it is not a continuous high-level task, just a traditional series of commands. Definitely still something you can do :)
Can we do this as an infinite loop? As in
1) Mine mineral X (until cargo hold is full)
2) Transport (to...)
3) Give cargo to entity Y
4) GOTO 1)

That may be what ThymineC meant :think: .
In effect, it would be a somewhat more narrowly defined form of project:
The NPCs under your command would not just mine anything and sell it anywhere, but look for a specific resource and deliver the proceeds to a specific location (maybe one of your factories?). But they might still have some autonomy in finding the best asteroid field and the safest route.
Post

Re: Development Update #16: April 2014

#51
In an interface, that could be done with a simple "mine" command:

"Mine from [locationX] and carry contents to [locationY]", with a default of "whatever's best" for both. I'd hope that's how it would work anyway.

What would be more complex is "Mine from [locationX] and carry contents to [locationY], while attacking any [shipTypeA] that come within [DistanceB], if [combatRatingA] is less than [[combatRatingA] / [personalCombatRating]].

Or perhaps "Mine from [locationX] and carry contents to [locationY], while acting as a [patrolShipType] on the journey to (locationX)".

OR, perhaps "Mine from [locationX] and carry contents to [locationY], while sabotaging any ships of [FactionA] that are larger than [MassB] if [cargoFullnessPercentageC] is less than [cargoQuantityD]".

The list could go on for a while, and everything would have a useful situation where the default command just wouldn't cut it quite as well. Commands could potentially get ridiculously complex to the point that the player could feel like they're programming their own AI. The real question is, how complex do we want to go?
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Development Update #16: April 2014

#52
I think the "mine" command needs at least three parameters to fill all obvious applications:
Mine [mineral X] from [location Y], carry contents to [location Z], with the prerequisite that [player corporation] has storage capacity in [location Z].
[Mineral X] and [location Y] could be replaced by "any", and [location Z] could be omitted, in which case the ship would just fill up its cargo hold with ore and wait for new commands.

That's already semi-complicated for a fairly simple task. For more complex tasks, the parameter list may become a bit unwieldy. That's why ThymineC and me suggested chaining commands. Which may feel like programming one's own AI, but work instructions in real life can be just as complex. Hmm, how do we avoid writing ten-page work instructions in LT? :think:
Post

Re: Development Update #16: April 2014

#54
I like the pipeline idea, and it is not so much different from X3 factory complexes. Only that pipelines can be distributed over space where the factories in a X3 complex must all be directly connected. Nice abstraction of goods transport here :) .
Cornflakes also suggested some upper and lower bounds for selling to and buying from 3rd parties. I approve of that, a detail that is missing in X3 :thumbup:
Post

Re: Development Update #16: April 2014

#58
Shiny and interesting update. Like others noted, I'm finding the rapid going through the menus distracting, and not only in this month's update, but in the last few updates as well. I can't follow it, and a lot seems to be just going back and forth through the menu structure purely for the heck of it, serving no purpose whatsoever. It looks more like a nervous tic than like presenting a feature. I'd be glad if you could tone it down drastically for the following updates.

And I have one question. If you've explained it in the video I must have missed it: what are the green/red bars that are plotted above the ships? Please, please don't let them be "NPC life energy bars". I hate those with a passion. They're screaming ARCADE GAME in my face, and nothing of the sort should have a place in a space sim. So I really, really hope that they're just a debugging feature that will be removed by default from the final game.
Post

Re: Development Update #16: April 2014

#59
Commander McLane wrote:=And I have one question. If you've explained it in the video I must have missed it: what are the green/red bars that are plotted above the ships? Please, please don't let them be "NPC life energy bars". I hate those with a passion. They're screaming ARCADE GAME in my face, and nothing of the sort should have a place in a space sim. So I really, really hope that they're just a debugging feature that will be removed by default from the final game.
I have a feeling you won't be pleased about it, but I'm almost positive they're HP bars. You can see some of them begin to turn red when the associated ships take damage.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Development Update #16: April 2014

#60
I liked how the Limit Theory Prototype (LTP) handled this.

It could be a little hard to see unless you knew to look for it, but my recollection is that in the LTP "ship health" info was a circle on the HUD projected around the targeted ship that turned dark as the target ship took damage.

Bearing in mind that it's useful to a human player to see how much damage is being done to a target ship's shields and armor, would changing the display to look more like LTP's style make this any more palatable? Or is a less game-y and more diegetic representation of damage (such as increasingly violent explosion graphics) required?

How should NPCs know when their targeted ship is being damaged?

Online Now

Users browsing this forum: No registered users and 8 guests

cron