Monday, February 17, 2014
=== PART 0: TL;DR ===
Construction is done via construction drones. It is super cool and affords loads of gameplay potential. I like it.
=== PART I : Real Men Build Their Own Castles===
"So ye got big dreams, do ya kid? Feel like ye might just want to build yerself a big chunk of metal to call yer own? Little stuff not cutting it for ye, eh? Fine. Time to become a man. Grab yerself a construction drone or two. Ye already know how to build somethin I take it? Good. Let's head out."
Here's how it goes. You head out into the Great Sea of Stars. You find yourself a nice little corner of empty space, open up your drone bay, and deploy a few construction drones (by the way, 'probes' are now 'drones' and 'launchers' are now 'drone bays'
). As they buzz around the empty space in front of you, a widget overlays on each, and you expand the widget for one. You load in a station blueprint and hit confirm. A holographic overlay of the station flickers onto the HUD, with a node in the center. "Build Site: 0%" it says. You grab the node to re-position the outpost as you like (remember me throwing around stations in the last video?
). Once you're satisfied, you select both drones and assign them to the site. They flit back to your bay, grab some of the alloys that you had stocked in your hold, and dance back to the construction site. The bright green light of transfer beams washes over your ship and the nearby asteroids. Ah, a lovely sight. Something of my own. Truly, my own. "Build Site: 1%". Bah. You haven't all day to watch this. So you jettison a compression pod of resources - it should be enough to finish the job - and inform your drones that they are to draw their resources from the pod. You turn back and head off, excited to be the king of a brand new outpost when you return.
As always, it's a fairly simple theory that, nonetheless, affords a lot of good gameplay potential. I considered a lot of different angles on construction, but ultimately landed on this for a lot of reasons:
- The question of "where do the raw materials come from" is answered in a realistic and understandable way. They can come from your ship, an ejected pod of resources, or any accessible container.
- Remote construction is possible even without help from an NPC.
- Construction is scalable: the speed is proportional to both the number and quality of construction drones on-site. This means collective construction is also possible - multiple ships can work together on the same site.
- Construction is improvable in the sense that you can buy or research better drones to work more quickly, affording yet another aspect in which you can specialize!
- Construction is progressive: you needn't build all in one go. Like the idea of slowly working up to something grand? Don't quite have the resources for it? Then just plop it down with a construction drone, water it with resources like a plant every now and then when you pass by. It's like a big, floating IRA. By the time you retire from mining you may just have saved up a whole station's worth. Literally.
- Construction is interruptible, but interruptible in such a way that resource loss is proportional to completion. If your construction site gets destroyed, you lose whatever had already been put into construction, nothing more. Unless you leave a great big crate of resources floating nearby for your drone. But of course you're not going to leave a construction site unattended in a lawless system...right?
- Construction makes sense for all objects. Why not allow small ships to build bigger ones? If you've got a drone of high enough quality and the patience, there's no reason why you can't make yourself something bigger and scarier than that scrawny little sub-capital of yours.
- Large objects naturally have a greater capacity for construction since they can hold more drones. Stations could potentially have hundreds of drones housed, making them extremely effective at building capital ships.
All theory at this point. But good theory has a tendency to turn into implementation when it comes to Limit Theory
I'm really excited for construction!!
=== PART II : Bring More Guns, Not a Friend ===
(
Once again, this part written earlier in the day, and totally unrelated to Part I.)
Balancing the fundamental constants led me to some interesting math today that relates to RTSs in a way that I've never thought of before. In fact, I was surprised that I had never realized this simple but easy-to-show mathematical fact: all other things held constant, one unit of strength
n is always better than
n units of strength one. Maybe it's common sense to the RTS players among you...heck, maybe it's common sense to everyone. But I had never taken the time to work it out before. So here's an interesting question: exactly how good is a unit of strength
n compared to
n units of strength 1? Well, it turns out that, in the limit as n gets large, the answer is: twice as good. Let me work it out:
Consider a battle between n small units of strength 1 and 1 big unit of strength n. For simplicity, we'll say that 'strength' means both dps and health (so a unit of strength 1 will have 1 damage/second and 1 unit of health). Consider a really simply case: two 1s v. one 2. They have at it. At time t=0.5s, the big one has now destroyed one of the little guys, and has taken 2 * 1dps * 0.5s = 1 damage. By time t=1.0s, both little units are destroyed and the big one has suffered 1 * 1 dps * 0.5s = 0.5 additional damage, leaving it with 0.5 out of 2.0 health. The big guy wins with 25% health. Obviously, the reason the big guy won is that he actually
lowered the enemy's dps halfway through the battle. Now consider the general case. A little unit will always be destroyed in 1/n time, because the big unit maintains constant dps. Let
i be the 'round' that we're currently on (starting with 0), then the little units do (n - i) * (1/n) damage. The n - i comes from the fact that i little guys have been lost by round i. 1/n comes from the fact that each round takes 1/n seconds. So, the
total damage inflicted by the little guys over
n rounds (after which they are all dead), is simply sum from 0 to n of (n - i) / n. This is an easy sum and evals to n * (n + 1) / 2n = (n + 1) / 2. So at the end of the fight, the big unit has lost (n + 1) / 2 health out of n. You can easily see that, in the limit as n becomes large, the big unit has lost 50% of his health. Obviously I am leaving out all sorts of minor issues like how quickly the big unit can lock on to a new target, how the size of a unit impacts accuracy, etc. This is a basic, basic model of a battle, but it gets the point across: in a mathematically-ideal battle, size does matter
That's good, because it gives you an incentive for progressing to bigger units. It's also good since we could definitely argue that the small units have the tactical flexibility of being able to split up. But that same flexibility is exactly what causes them to be at a disadvantage in a straight-up brawl against a big unit.
Just figured I'd share that interesting thought
=== PART III : The War Ahead ===
Now. I've got big plans for tomorrow. I want to work on ships. But I really think that I need some kind of new meshing tech to break through to the next level of ship generating. I also need a legitimate UV unwrap. But as of today, I have a few triangle-shaped ideas and a cute little bin-packing technique that might just do the trick
On the other hand, I'm super-eager to dig into construction drone implementation - but that's going to require a decent cargo interface, which requires a good grid layout, which...ah, you get the idea
Always too much to do. And I wouldn't have it any other way
=== PART IV : Concluding Question ===
So did I make up for yesterday's rip-off?