## Week of February 9, 2014

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

Post

### Week of February 9, 2014

#1
Sunday, February 9, 2014

Another day of many focuses, but I'm most excited about working on the constants and balancing math of the game, so I want to talk about it!

Today I started to replace arbitrary constants in the code with combinations of the 'fundamental' constants, which are coming together nicely. These fundamental constants - much like the speed of light, gravitational constant, and charge of an electron in our universe - will define the most basic relationships that will go on to derive most of the other constants in the game, as well as answer most of the questions that involve quantities and relationships. All of my constants are written in terms of something I call a 'resource unit', RU, which is the abstract unit that I use for balancing. From this, we can derive a whole system of units and equivalences with which to perform balancing. For example, we can define a measure of power to be RU / time (much like a Watt in the real world). Already, with these two units, an interesting fundamental constant comes up - I call it the 'temporal ratio,' and it's the answer to the question "how much RU is contained in an object that provides x units of power output?" Answering that question would answer a lot of other questions, such as "how much RU is in a production unit relative to it's RU output?" Perhaps a bit confusingly, although I call it a constant, the way I have framed this question, it could actually be a function! This will be useful for controlling the balance of the world as the player gets more powerful. We could say, for example, instead of f(x) = 10x, which would simply make the RU value of a production unit equal to 10 times the RU / unit time output of that unit, that f(x) = 10x^2, which would mean it takes increasingly more RU (hence, increasingly more raw materials) per unit of power to build production units of higher output. That would be an easy way to model something like technological barriers with respect to fabrication processes.

Another interesting balance question: how much RU is contained in the blueprint of an x-RU object? Again, we could say, for example, f(x) = 100x, which would mean that a blueprint would be roughly 100 times as valuable (in units of raw energy) as the item that it represents. Or, once again, we could get a little fancier, and say f(x) = 100x^2. Then, blueprints would become increasingly more valuable in contrast to the object they represent. That would have interesting implications for research, since a research unit is assumed to produce RU at a constant rate - so if the blueprint-object RU ratio increases as items get more valuable, it means that research slows down non-linearly with valuable items, putting a higher curb than usual on vertical progression. It would also mean that research would fall out of balance with production - in the end game, it would be near-impossible to develop a new technology, but comparatively trivial to produce any existing one. Altering the powers involved in these fundamental constants could change not just the balance of activities, but also the way that the balance changes over time. Cool

Overall, I think there are going to be a lot of really cool possibilities for defining these fundamental constants to provide the optimal balance of challenge and fun. I'm already more excited than I thought I would be at the concept of balancing procedural systems. The result remains to be seen, of course, but so far I feel great about all of it, and feel a whole lot more confident about actually being able to produce some content, since the numbers will be meaningful and not arbitrary
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#2
Monday, February 10, 2014

As much as it pains me, some days I just gotta take a break from coding and attend to LT as a more-than-just-code project. Well, then again, I shouldn't say it pains me, because today was a day of pure auditory bliss. I finally took the time to carefully review and organize all the sounds that our sound design team has produced thus far - which is actually a remarkable amount.

Alright, so this is pretty embarrassing, but I actually haven't even introduced LT's sound design team yet. I keep meaning to put a piece in the monthly update, but then it always comes down to the wire and I don't have time You all know Francois Jolin by now, who is, as I always call him, LT's master composer. I say master because the guy is amazing But! It also turns out that we've had a master sound design team for over half a year, and I've yet to properly introduce them. Hopefully I'll get around to it in this update! Anyway, our 'team' consists of two guys only a tad older than me who are brilliant with sound synthesis. I've been working with them on all sorts of spacey sounds for many months now, and they continue to impress me with the quality of their work, even when I give terribly vague directions ("guys, I really don't know what a research module is supposed to sound like...so...uh...just figure something out" (and yes, when I received the results, I've never heard research conveyed more perfectly :applause: )). I've also not gotten around to properly integrating most of them with the game yet

So finally, manager Josh has gotten all of the sound design in order and ready to be used by the engine. I'm already playing with some of the newest sounds and really loving them. The ice field ambiance loop came through just in time, considering my recent work on ice Man, drifting in an ice field with that ice field ambiance playing while a subtle research unit sound flits about in the background is...pretty sweet. Ambiance was always one of the core focuses of LT, and with the visual and auditory elements finally coming together, I think it's shaping up to be the Freelancer 2 that I always wanted

Believe it or not, sound design is nearing completion. I'll be checking in with Francois soon as well, and I believe music will be nearing completion within a month or two. As for the code? Better crack the whip I suppose But everything's really coming together folks!!

PS ~ Guess what...one of the sound designers is named Josh as well Yep, Limit Theory's got a whole lotta Josh

PPS ~ Last dev log thread is over 10K reads Where the heck are you lurkers coming from!!? But..hi
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#3
Tuesday, February 11, 2014

Dominating. Burning up the keyboard.

Dunno what happened, but I had one of those great waves today of "oh my god, this is my dream game, and I'm the programmer...I can do anything I want!!" That, coupled with the constant whisper of Mr. Caffeine in my ear ("you can do anything bud - long as you got me in your veins, the sky's the limit. Hehehe. Now reach for another diet coke. Go on. Good boy. ) made it a tremendous day, where I started sprinting down several different paths to cool features that I want. And I want them sooner rather than later

I'm really inspired by mining right now. Had some big ideas that tie into both mining and other areas of gameplay as well. Ahhhh. So much fun potential here, but...can I do it? Am I biting off too much? Don't want to say too much yet, because it's a long shot and a lot of extra work to do what I want to do. But it would be super cool. So here's the deal: if I get it done before I pass out today (which would usually be right around now), then it's done. Otherwise, I walk away and no harm done. Success will require a codemiracle. But, given everything that happened today, I'm willing to believe that it's possible Once again, the neurons are aligned, for whatever reason, and I have to take advantage.

As for what actually got done today, well, it was another one of those days where there was too much happening to speak coherently of any particular item, so we must revisit Sir Bulleted List!! :
• Reworked "container" objects to be more lightweight and separated from the physics engine - paving the way for more objects-within-objects. I have big plans for this feature...but don't want to speak of them yet
• Implemented pseudo-transparency for distant object fading (finally! Goodbye asteroid popping! )
• Implemented bezier curve color grading
• Did a fair amount of research on color grading and will be stepping up my post-processing game soon
• Developed some super-secret theory for features which may or may not be implemented within the next however-long-I-can-stay-awake hours
• Figured out how to work roll into the gamepad control layout, so that yaw, pitch, and roll are now all easy with a gamepad
Well then. I have a lot of work to do. So...please close the door on your way out.

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

### Re: Week of February 9, 2014

#4
Wednesday, February 12, 2014

It's new. It's exciting. It's flashy. It's hip. It'll make all your friends say "whaaaaa!!?"

That's right baby, I'm talking about probes. Probes and probe launchers. Get ready for them. Shooting something out of a launcher that becomes a full-blown object in the world. Done.

Yes, I finished them before I went to bed. That is to say, I finished them before a few hours from now, because...ding ding ding!!! I didn't go to be last night I'm sure you'll be so kind as to excuse any ensuing delirium.

Recently, I've been trying to understand how the scanner interacts with mining, and, in particular, how a player is supposed to figure out where to drill with a transfer unit for maximal extraction rate. At first, I thought the scanner would be a good candidate. But after thinking about it a bit more, I realized it'd be tedious to use the scanner for sub-object precision stuff like mining. The next thought really excited me: what if you had to launch probes that attached to the asteroid, took core samples, and then fed information directly into your HUD - basically like a mini-scanner, except via real objects that you have to deploy! That'd be pretty sweet, not only because the concept is fun and immersive, but also because it introduces another "real" minigame: trying to triangulate the high-density pockets of an asteroid with a limited number of probes.

So, that required a few new things. First, the concept of a launcher and a payload. The launcher launches payloads..obviously. But a payload is the interesting thing: it contains an object that gets instantiated under certain circumstances (like hitting something). So taking a core sample is as simple as aiming your tubes at the asteroid and launching a prospecting probe! Upon impact, the payload pod disintegrates and attaches the payload to the colliding object. In this case, we get a prospector probe ready to start taking samples and reporting ore densities back to us.

Mind you, all of this is actually done. Today. Minus the UI that reports the density. Still working on a teensy bit of interface tech that needs to happen before we can get that, but it's not a big task. We're almost there! I've already launched many a probe at many a helpless asteroid. Granted, they're all quite happy that it's not a pulse laser, which is usually what I'm hitting them with

But surely you anticipated already that...probes are for more than just prospecting! Shall we let our imaginations run wild for a moment? A few ideas for other probe types: hacker, tracker, drill, architect.
• Hacker: Launch it at an enemy ship; if you get a hit then there's a chance to disable their computer systems and cut power to their subsystems
• Tracker: Gives you constant awareness of the whereabouts of an object, even when outside of conventional scanner range. Perfect for the budding scout looking to harmlessly track the locations of a few battleships
• Drill: The cousin of the prospector; helps to automate the mining process by...mining autonomously. The only caveat is that it has a rather small hold, so you'll still need to attend to it and grab the ore to make sure it doesn't fill up. The way I see it, the drill is a fantastic way to turn mid-game mining (e.g., you're not a noob but you still only have one ship) into something that's not quite as tedious as manually using a transfer unit. Deploy a few drills in a field and you can play more of a 'caretaker' role, and also attend to other things for a short time while you wait for your drills to fill up.
• Architect: Manages construction of large-scale objects. This is going to tie heavily into the macro-construction theory that will be happening later this week or early next. More on that soon
NOTE: The rest of the dev log was written earlier today. If you're wondering how I had the stamina to write a dev log of this length, that's how. Also, I may sound less delirious in the following paragraphs. One can hope

Anyway, that's all well and good...but what's life without a little off-the-beaten-path graphics pipeline work? Yeah. Nothing. Today I implemented a meshing technique for voxel rendering, in hopes of finally building a mesh representation that's conceptually simple and elegant. I hate polygons. I really do. There are so many complexities in modern model pipelines, it's no wonder that all the 'creative' games these days are using voxels. But voxels come at a high price: the infamous Minecraft Look. Yes, most voxel games are blatantly, in-your-face voxel-based. They don't make any attempt to hide their devious nature. My goal was to develop a technique that uses a volumetric representation through most of the pipeline (hence, affording a very clean and simple mesh representation), but then plays tricks at render-time to avoid looking like a bunch of chunky monkeys (aka, blocks).

For the few hours that I spent on it, I would call this little excursion a serious success!! In a few hours I worked up to a voxel meshing pipeline that looks very close to my current polygonal pipeline in terms of quality. There are still some visible block-ish artifacts here and there, but, by and large, I've now got a pretty nice voxel meshing pipeline. Not to say that I'm super clever or anything, because it's all dead-simple. If you wanted to sound really uptight and fancy, you might call my technique "SSVO" - smooth sparse voxel octrees Ha. Sounds so much fancier than it is The neat thing that I'm realizing is that I've basically re-invented marching cubes for the meshing portion. Or something rather similar. But I've done it within the framework of voxel representation, and now I totally understand it. That's really good! Nothing like the feeling of having a solid grasp of what's going on

Anyway, I won't be using a voxel representation for LT 1.0. But I'm always on the look-out for tech that can help me become a better person (and make LT 2.0 the beast of a game that it deserves to be). Today has definitely made me a better person with respect to simple, elegant geometry pipelines. This work opens up the door for much more dynamicity with assets (in particular, destruction / drilling holes in asteroids / blasting off pieces of your enemy's hull, etc.), easier interiors, fast and natural CSG, and faster, scalable physics (I believe a voxel-based pipeline scales much better with respect to fast, clean physics interactions).

The future shines ever brighter

PS ~ Oh I think I also implemented that thing where the HUD moves subtly in response to acceleration, to make it really feel like you're in a cockpit. But hey, on a day like this, such a "small detail" is hardly worth mentioning

PPS ~ Can I go to bed now??
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#5
Thursday, February 13, 2014

Alright, I'm going to keep today relatively brief since I drained my entire devlog meter and then some in yesterday's ridiculous tome

I worked on the scanner today, getting it ready for frequency-space analysis (which, in a perfect world, will be ready before the end of the month ). I'm also trying to make it less confusing for the that-looks-like-a-radar camp of people Experimenting with linear graph layouts instead of circular yielded several good candidates, but ultimately, the simplicity of the single, linear graph strip along the bottom of the HUD won out. It looks nice, but it's also very informative due to the amount of horizontal real estate it takes up. I must admit, I also like that it gets the graph out of the way of the scene...it's easier to tell what you're looking at without a graph glued to the scanning reticle I'll miss the beautiful symmetry of a radial graph, but in the end, it's hard to argue with the practicality of a traditional one.

Now then, off to regenerate my dev log meter so that we can pack some more excitement into tomorrow

(And yeah, I also slept a lot today. But not long enough to make up for a full lost night of sleep, mind you, so we still came out in the green )
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#6
Friday, February 14, 2014

The cold, dark facade of an asteroid loomed in the distance. It laughed at me. It taunted me. "You'll never know." "You'll never know what I hold inside." What was beneath that dark facade? I glanced at my scanner console, my sweeping cone trained on the arrogant rock. Clearly a signal. A strong one. "Ha, yeah. You know I've got it, but you'll never know where. You'll never know what." The smug little thing scoffed at me.

A day ago, it would have been right. A day ago, I'd have never figured it out. Not in a lifetime. But yesterday was yesterday, and a lot can change in a day. I gently tapped a few circular forms on the console, aimed my targeting sight smack-dab in the middle of that asteroid's face, and pulled the trigger. A gentle pop emanated from below, and I watched as a probe was hurled toward the roid.

"What the..." The asteroid gasped in surprise. The probe landed and immediately clamped onto the jagged face of the rock. "What is this thing...stop that, you can't do that!" It panicked. A bead of sweat rolled down the side of the otherwise-dry thing. "You can't have my treasures!"

We'll see about that, I thought to myself. A moment passed as my probe settled in, and then a new form appeared on my HUD. An empty, holographic ring now encircled my probe. No reading. Nothing there. But I wouldn't be discouraged so easily.

I rolled and pitched and fired my jets a bit, bringing the small scout ship to the other side of my prey. Three more probes sailed through the void, nailing the dark side of the asteroid in a triangular pattern. First probe's data came through. Another miss. Second probe. Nothing. Third probe...noth-wait! The screen flickered and then I saw it: "87% Hargonite". That glorious little text overlaid on the probe. The probe's data widget glowed orange, pulsating gently on my display. I smirked. "Gotcha."

For good measure, and just to see if I could do any better...I let loose another three probes, this time in a tighter pattern around the successful one. 73%. 60%. And the last....99%! What!! 99%??! Lady Luck was smiling on me today. In my mind I could already see the credits pouring out of that little dig site. The asteroid had long since gone silent. It knew this was a new game. No more was it an impenetrable fortress of treasure. This changed everything.

Probes in place, I headed back to the station. I would need to wait on that transfer unit that I ordered a few days ago. Should get here soon. Until then, I'd live with the wondrous knowledge that out there, only ten or twenty kilometers away, I had an access point of 99% Hargonite waiting for me. I would sleep well tonight.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#7
Saturday, February 15, 2014

At this very moment I'm in the midst of what I believe will be the final push to a working research implementation I know I've said similar things plenty of times, but really, I think I'm there. I've simplified the implementation model of research even further today to actually completely eliminate the need to load in those 'metatype defaults' of which I've been speaking. Instead, I'm pushing all of the work into the fundamental constants - which feels a lot more correct (and less arbitrary)

My new model treats any given object as a simple vector, comprising a magnitude and a direction. The magnitude is to be thought of as the intrinsic 'value' or 'quality' of the object, and the direction specifies the particulars of how the properties are configured to produce that value. The trick that I'm going to play here is that I'll push all of the work of balancing the item properties into the global constants. The numeric values of the item type vector will actually be normalized in value space, hence, the 'default' for any item type (e.g., the starting point for all research), is simply the unit vector whose components are all equal! In other words, the item is completely 'balanced,' and the overall value is 1. It is the generating function of that item type that is then responsible for transforming the item's vector out of value space and deriving concrete numbers for the item's stats. What this means is that, for example, setting one of the components of a vector to 2 does not necessarily change the underlying attribute by a factor of two - it only changes the intrinsic value of that attribute by a factor of 2. In this sense, I'm transforming the problem into an inverse-function question.

With this simplified model in place, I'm working my way through all of the item types, preparing them for the final hurrah! Once that's done, the rest of research should be really, really easy - modifiers will now always be operating in value space, so they can be totally oblivious to the underlying item..they can even be oblivious to the properties that they're changing! With this new approach, a modifier knows that multiplying one component of the vector by 1.1 will result in an item that is about 10% 'better.' If it then divides another component by 1.1, it can rest assured that the overall quality of the item will remain about the same (but the properties will have shifted). The actual properties of the underlying object may have changed dramatically - maybe the engine calculated that a 10% increase in the 'value' of the item's range actually required doubling the range. Maybe it calculated that a 10% decrease in the value of it's integrity meant cutting it in half. But we don't care, that's up to the engine to figure out - from our perspective, we've just redistributed things in value space. I'm not claiming that the inverse-value problem is easy. I'm sure it'll take significant tweaking to get right for all items...but at least it's a very conceptually-clear and well-defined problem (e.g.: "if you hold all properties of item X constant except for mass, how much mass does XA have if it's got twice the intrinsic value of XB?"...and from the answer to this question we can figure out how to manipulate the mass of X to achieve the desired change in value space)!

So, after all this time, I believe I've finally reduced the research problem to its minimal form, eliminating all the redundant degrees of freedom. It feels good!

Please keep in mind that when I speak of value, I am speaking of intrinsic utility, not market value. Items do not have a set market value, but in order for the game to reason about them, it must have some notion of how 'good' each item is. That's the value of which I speak.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

### Re: Week of February 9, 2014

#8
Summary of the Week of February 9, 2014
• Started implementing 'fundamental constants' for semi-analytic game balance
• Worked on organizing and integrating the work of the sound designers into the game
• Implemented color grading post-process
• Implemented probes!
• Implemented prospecting probe with mineral readout on HUD!
• Refined research implementation, working on final push to research!
“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 1 guest