Return to “[Archived] Daily Dev Logs, 2012 - 2015”

Post

Week of February 16, 2014

#1
Sunday, February 16, 2014

Finished with preparing items for streamlined research! I'm still trying to get the fundamental constants tweaked correctly so that I can actually play the game again (right now my ship won't move, most likely due to some bad relationships between power generation, power consumption, mass, and thrust ratios... :crazy: ). But the great thing is that when I do get it back to a working state, everything should 'just work.' Since it's automatic :)

I worked a lot on both construction and modular object theory today (note: I didn't just say 'modular station' this time ;) ). Sadly, I wrote a rather lengthy dev log concerning the state of construction theory, which is the large-scale analogue of production units...but, in the process of writing it all up, I started to realize that I don't quite have all of my questions resolved as well as I thought I did on paper. Blast. There are a few more things that I need to consider that may end up changing the final implementation. So...I'll refrain from speaking until I've got it nailed down! I can, however, at least reveal this: the 'construction drone' is well on the way...and building your first station module isn't so far off either :D

Sorry to be a rip-off! Promise I'll divulge the details real, real soon :geek:

:ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#2
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!! :D

=== 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 :D 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 :think: 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 :crazy: Always too much to do. And I wouldn't have it any other way :clap:

=== PART IV : Concluding Question ===

So did I make up for yesterday's rip-off? :shock: :shock: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#3
Tuesday, February 18, 2014

Well, you can't win em all :|

I did get so far as to come up with a simplified geometric representation that's specifically geared towards artificial objects. I call it 'PlateMesh'. Spent quite a while perusing the EVE ship viewer, seeing if I could break each ship down to a platemesh in my mind. It holds up pretty nicely for most of them! This is the best conceptual simplification that I've had so far. I'm very pleased with that...

...sadly, the first step in implementing the details - generating ambient occlusion - is giving me a lot of hassle. Yes, I know how to compute AO. But computing it quickly? Difficult problem. With a scalar field it's so trivial! I almost forgot how nice the fields make that (when I go look back at my blog entry on computing scalar field AO, I'm like...extremely jealous :P ). After reading up on many different techniques and racking my brain to see if I had anything unique to contribute (which it turns out I didn't), I ended up implementing a disk-based approach that's been covered twice in various GPU Gems books. It's intuitive and elegant. But the results are not as great as I would want. At least, so far, my implementation can't achieve anything that compares to the quality of the scalar field mesh AO. It's fast enough, but the quality isn't there. Might seem like a small detail to you, but honestly, baking AO is critical to having good graphics. You would all notice if I turned off the baked AO :| This is one area in which non-procedural guys have it so easy...AO is trivial when computation time doesn't matter - it's just a bunch of raytracing. When you need to generate the mesh in a few seconds, it gets a lot harder (raycasting is basically out of the question) :ghost:

I'm not yet convinced that I won't be able to achieved good AO for arbitrary meshes in a reasonable time. I'm just not sure how many hours it will take. Clearly more than I had available to me today :monkey:

Even more sad is that I never got to texture mapping. PlateMesh is designed to be extremely easy to map, and all I really need to do in this department is implement a bin-packing algorithm to combine all the individual charts of the platemesh pieces into a single texture. That's a whole lot simpler and faster than an LSCM UV unwrap. I think this'll be easy..but I wish it was done right now!! I'm so excited to have legitimate UVs and texture maps. It's going to open up an entirely new realm of visual fidelity for the ships. Previously, I've used triplanar texturing all the way. I've definitely done some clever stuff with it and pushed the technique to the limit, but there is, undoubtedly, a limit. The problem with triplanar texturing is that it knows far too little about the surface geometry. With platemeshes, the texture map will know so much! Most importantly, it'll be mapped in such a way that the texture map will follow the same displacements as the mesh. I honestly think that's a huge factor in making a good-looking ship. If you look at almost any nice ship rendering, you'll see that a lot of the details on the hull are following the contours of the hull, perhaps in a subtle way. But it's always enough to tell your brain "Hey, the surface is aware of it's own geometry! Nice!" When you see an LT ship, on the other hand, your brain says "What? the surface has no idea about the geometry..." Which is, of course, why we see so many YouTubers saying "omgyourshipssuck" :oops: :roll:

Well, I'm not sure what I want to do here. Do I spent another day pushing through to quality ships? Do I interleave some gameplay so as not to invest too much in this route? Maybe I'll go for half-and-half. Maybe a bit of work on construction drones, interleaved with continuing to push toward this platemesh implementation of ships. Sounds good :thumbup:

PS ~ If you're wondering, no, I definitely haven't abandoned scalar fields. It's just that..I think I need something different for ships and stations. Fields are 100% perfect for asteroids, ice, and every other natural occurrence. But I really need a specialized solution for these artificial objects. Someday, when we have infinite computing power, I'll use fields for everything :)

PPS ~ PlateMeshes are particularly well-suited for: procedural destruction, interiors, and fast physics on large objects! Nice :D If this comes through, we may just be looking at gaining an order of magnitude for the scale difference between large ships and small.......man, 1000x scale spread would be so, so nice! :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#4
Wednesday, February 19, 2014

In response to yesterday's opening statement: sure, you can't win them all, but...you can win most of them ;) :cool:

As promised, I split the day between tech and continuing with gameplay. The good news? Success on both fronts. The bad news? Eh...none :)

Through a series of highly-fortuitousness guesses and a bit of luck-based finagling of the math...I managed to get the general ambient occlusion calculator in good shape! Sweet!! I can bake occlusion for arbitrary meshes now :) That's awesome. A world of possibilities...opening up in front of my eyes :D

And research? Well, that's old news. It's done. As in, the engine can finally, after long last, create new technologies / items using the 'modifiers' and 'amplification / suppression' techniques discussed previously! Only bad part: I still don't have a finished research interface. Nor do I have a finished inventory interface. Nor do I have any way of viewing the details of an item in my inventory. So I could be the most technologically-rich person in the world, but it wouldn't really matter, since I have no idea what tech I have :lol:

But that wasn't the end of today's progress. I also worked some more on interface tech (since that's one of the primary gameplay bottlenecks for me at the moment). I'm trying to equip the Node UI with more power :geek: In particular, I've given it better blending control, so that it's no longer just additive. This opened up the door for 'panels,' which are semi-opaque nodes that can occlude the background. Works really nicely for making sure the HUD elements are visible...pretty much exactly the kind of thing you would expect from the HUD. Looks great! As always, the real secret is the soft shadows behind the panel...guess what it uses....right! Exponential falloff ;)

What to do today? Good lord. So many options. Ships, research, construction, interface...gas giants? Mining! ...modular stations. !?!?! Too much gameplay! Too much tech!!! What do I do :shock: :D :clap:

PS ~ I mentioned exponential falloff, but actually, over the past few months I've discovered something even better than exponential falloff: exponential squareroot falloff! :ugeek: Well, not even just squareroot...but any power between 0.5 and 0.75. It looks incredible for most visual purposes. I use it for UI shadows, ambient occlusion calculation, stars, nodes, and probably billions of other things that I'm forgetting. If you thought your eyes liked e^-t...well, they like e^(t^0.5) at least twice as much ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#5
Thursday, February 20, 2014

When you have a thousand different options, which one do you choose? Classic answer: the 1001st :D That's right, I went for a half-website, half-interface day!

On the website front, lots of progress. I've caught up with the dev logs (meaning all the dev logs are available on the new website under the dev log section, in individual posts). I've managed to bring over the forum smileys so that my little ghosts and monkeys and squirrels show up in the dev log section :ghost: I've gotten all the dev updates in posts in the news section, and I think I'm caught up on the press section as well. All that really remains are some FAQ entries and some gameplay descriptions :D Like everything I do, the new website has grown in scope since I initially conceived of it. But it'll be great when it's done!

On the interface front, I'm working on that cargo / inventory screen, so that I can finally see what's in my hold :D I've got a nice grid layout, now using the new panel tech, which looks pretty great IMO. Simple, but great.

With the closing of this day, it's now the final week of February. Absolutely insane how quickly it's come. But I still have hope that I can finish everything that I wanted to. Like all final weeks, this one will be a sprint of grand proportions. Let's do it :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#6
Friday, February 21, 2014

Yesterday's question: when you have a thousand different things to do, which one do you choose? Yesterday's solution: confuse the enemy...choose the 1001st! Today's alternate solution: screw the enemy. Choose them all :ugeek:

The computer tells me only a day has passed since the last dev log. Is that right?? That can't be right. I could have sworn it was a week :think: Yes, I'm quite certain. A week. Let me recount it.

Day 1: "Making Abrams Proud."
In the first day of this week, I went to town on lens flares. Better anamorphic shape...so crisp. Really sets the mood. Some subtle lens dirt as well. And of course the chroma shifting from last month. Put it all together, and you've got one of the prettiest ways to blind someone that I've ever seen :lol: I might have squeezed some chromatic aberration into the last few hours of the first day. That, my friends, is the last time I'm ever going to speak of chromatic aberration. With real cubic lens distortion and radial blurring, we've finally matched CryEngine's quality. Nothing left to be said about that. Day one: complete.

Day 2: "Don't Be Afraid to Dream Big."
The second day saw me happily digging back into the research and cargo interfaces. 'The Grid' layout gets ever more capable. For the research interface, I've chosen a bit of an odd layout: at the top level, we see a grid. One node for every item type. Within each grid cell will be the tree for that line of technology. What this means it that, for the moment, I'm doing away with intermediary technologies. The more I think about it, the more I think sure, it sounds great in theory to have various 'fabrication' techs be a prerequisites for doing research in ships vs. stations vs. ...., having various energy technologies being prerequisites for scanners, power generators, etc...but in practice, when I get my first research unit, is that really going to lead to any interesting gameplay? I don't think so. I'd rather just say that you can research anything you like from the start, but of course, your first pieces of research in any field will always be pretty underwhelming. I like this 'soft' limitation much better than the 'hard' limitation of having arbitrary prerequisite techs :thumbup: Plus, there's the fact that certain technologies are inherently harder to research, and will require more research power to do effectively. Stations, for example, are so high-valued compared to other objects, that you'll need some serious research power to get anywhere. Still, there's nothing stopping you from trying to design a new station type with a single, tiny little research module (I mean, there's nothing stopping me from trying to design my own real-life space shuttle right this very moment...it's just a question of how long it'll take and how lucky I'll need to get :roll: ). Hey, don't be afraid to dream big ;)

Day 3: "What A Drag."
Day number three caught me by surprise. I've been wanting to improve the 'feel' of piloting in LT. There's just something about the piloting in Freelancer that feels so...crisp, yet smooth. I won't say I nailed it yet. I didn't. I've definitely improved LT's flight model today. But the big surprise was when I tried changing drag to quadratic instead of linear. I'm aware that the real world uses quadratic drag forces...but I never gave much thought to the difference. But as I have learned today, I strongly prefer the quadratic drag! It's pretty simple to reason about: with quadratic, the asymptotic ceiling (top speed) is much 'harder' - e.g., it comes up 'faster.' Think of x^2 vs x. x^2 reaches 1.0 much more 'suddenly' than x. For x < 1, x^2 is of course smaller. This means that, for speeds well below the top speed, the drag is comparatively small - meaning it feels 'more Newtonian'! At the top speed, the result is still the same - you will get asymptotically closer to the terminal velocity. But at lower speeds, the result is quite nice: you can drift along for a fairly long time at 50 or 100 m/s, unlike with linear drag, which will bring you to rest rather quickly. To come to a full stop, you'll have to wait quite a long time, or just fire your thrusters, but it's not difficult or distracting because you'll only be drifting along at a small velocity. Love it! :D

Day 4: "The Asteroid's Cold-Hearted Cousin."
#4? Well it had to be ice, of course. Not much to say here...ice looks better :D

Day 5: "Forever A Mystery."
#5: The records of day 5 have been lost to the unrelenting jaws of time.

Day 6: "That's No Shadow...It's Ambient Occlusion!!!"
Number six saw the theory of a new, simplified mechanism for computing occlusion on platemeshes. Faster, higher-quality. Exploiting their geometric nature to avoid having to do any hacks or expensive integration. It's only theory at the moment, but I've a real good feeling about it. Forget the disks.

Day 7: "A Monument Rises."
And finally. The last day. I almost cried as I stood before the largest structure ever seen in Limit Theory. A station, about 10,000 times the size of my little fighter. The crisp, metal countours of the platemesh catching the sun's rays, the bloom aberration splitting a rainbow at the edges of the reflections, the lens flare washing over the scene in true Abrams style. It was overwhelming. To think that someday I'll be able to build a thing like this. To call it my own. To watch my drones work tirelessly, standing back as millions of tons of metal slowly become more than the sum of their parts. To rest inside, to command my empire from within an impenetrable fortress. To live in, and perhaps to die in, a monument to the sheer power of the limitless mind. Someday. Someday soon.

Wonder what next week holds... :roll: :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#7
Saturday, February 22, 2014

I got it. I. Got. It. !!!!!!!!!!!

The one. The only. The mythical 'Freelancer flight feeling.'

It took forever for me to get the secret. But today, I finally cracked it. A beautiful, simple little secret. Now I understand why flight in FL feels so good. There's this incredible perceptual trick that the game plays to emphasize angular velocity. So simple, but so impactful...it makes all the difference in the world. Whoever came up with it was a genius. It makes flying, and especially dogfighting, feel so much more visceral. All because the camera does this slight trick.

Ah. Goodness. Flying a new, platemesh ship through my new station with the new camera...it absolutely feels like Freelancer 2. Absolutely. All I need now is a good bogey with which to dogfight, and the feeling will be complete :geek:

Sure, I did other stuff today. But let's face it. Nothing else really matters :)

:squirrel: :squirrel:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 16, 2014

#8
Summary of the Week of February 16, 2014
  • Developed construction & construction drone gameplay theory
  • Started 'PlateMesh' implementation for ships and stations,
  • Implemented GPU-based AO baking for arbitrary meshes (including PlateMesh)
  • Implemented final form of research!
  • Implemented advanced blending modes for interface
  • Implemented interface panels
  • More work on the mythical 'new website'...
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 2 guests

cron