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


Week of February 2, 2014

Sunday, February 2, 2014

Last month, I started off by dedicating the first work day to planning. In retrospect, I think that was a fantastic idea, and definitely somewhat responsible for the amount of progress made. Naturally, I decided to start this month in the same way!

February is going to be a tough month. On the one hand, I'm going to continue moving forward with both gameplay theory and gameplay implementation, but on the other, I'm also going to be moving forward with AI, picking back up where I left off in December and following up on all that delegation excitement :) At this point in development, I've learned enough to say with confidence that AI is the toughest of the systems (at least, the kind of AI that I'm doing :roll: ), so there will be fried neurons this month...of that we can be sure :ghost:

Despite the rough month ahead, I'm feeling more optimistic than ever :D The systems are really in good shape, and I can feel it. All the signs are there. The conceptual clarity, the clean code, the ease of prototyping new ideas, the high performance, etc. It's all coming's only a matter of time ;)

PS ~ Mini post-its are the best thing ever. They're favorite organizational tool of all time :D

PPS ~ As you may have noticed on the most recent weekly summaries, I've decided to stop with the actual textual summary, and simply document the notable achievements of the week in bulleted form. The text summary has always seemed slightly redundant, what with the "little" daily logs and the "big" monthly summary. I don't know, I don't think we really need anything in the middle. I would prefer just to have the distilled list of weekly highlights. Apologies if you actually enjoyed the text summaries, but...I think I generally say everything that needs to be said in the daily logs ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Monday, February 3, 2014

Ah, feels good to be back with the AI ;)

Truth be told, my focus wasn't exactly on AI today, but rather on getting the fancy new HUD and UI to run externally from the game. I used to have a different application from which I could watch the AI without having to load any of the graphics resources, but it was broken due to the fact that the new UI was tied closely to the other graphics subsystems. Not anymore, though, and the separation came with the added benefit of a lot of code-cutting (as usual) :cool:

One of the issues that I've left unresolved with respect to the AI is the relative value of goals. It seems really quite difficult to get these balanced out, and I'm a bit at a loss for how to derive the numbers. I've mentioned in the past how NPCs value different personal statistics based on their personality. But the relative value of these is a tough problem to crack. For example, how much is it worth to have discovered a new system vs. acquiring one credit? Surely discovering a new system is worth more than a credit, even to an NPC who is not so interested in exploration. But how much, exactly? :think: I believe that this is one of the most fundamental constants in the game. But is there any way to derive it? Not sure, short of gathering data from loads and loads of hours of simulation.

Despite the AI work, I'm really looking forward to pushing the scanner forward. The idea of time-varying signatures is just too great not to explore, and the fact that I didn't already implement them for the video is a bit of a shame (since I wouldn't be catching so much flak for the design of the scanner widget if people could see the purpose of the history buffer.... :problem: ). One idea I had today is that we can allow the player to "capture" a signal, save it to a database within the scanner, and then the scanner can automatically pattern match future signals against the database, and notify the player when a similar signal is detected (e.g. 93% match with 'Rochabite field'). That'd be pretty awesome, and would encourage the player to build up their own little database of signature knowledge. Signature information could also be traded, just like any other information, allowing the player to, for example, "buy" the knowledge of what jump drive X's signature looks like.

Today I'm headed back to research land to tie up the loose ends once and for all. Wish me luck :) :thumbup:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Tuesday, February 4, 2014

All over the place today, but in the end, just wasn't the day I was looking for. My personal life cut a bit more heavily into the workday than I was expecting...I suppose that's just life :|

I tried to let graphics Josh out of the cage today, but not just for the same old boring stuff. Today I wanted to push forward with some new content - new planetary types (including gas giants) and ice :squirrel: Unfortunately, I didn't have enough time to perfect either! :monkey:

I'm having a lot of trouble getting the ice to look right. It's probably just because ice is new to me and this is the first time I've ever tried it. It's pretty darn tricky in the way that it reflects and refracts and...well, my ice just doesn't look like ice yet :oops: Hopefully I'll get some more insights soon :think: I really, really would love to have this month's update video take place in an ice field!! :geek:

Gas giants are seeing a bit better luck, but I'm still not satisfied. The hardest part with them is the scattering - it's hard to get the atmospheric scattering right on a gas giant. Actually, I'm not even totally sure how atmospheric scattering works with respect to a gas giant. Isn't the whole planet big atmosphere? :think: Maybe it should just be a big blob of atmospheric scattering :D Dunno. Weird stuff.

At any rate, I've got a stronger framework in place now for having different planet types, so if nothing else, the day was successful in that respect. I'd say I'm about 50% on both ice and giants. Hope I can get to 100% by the end of this month :)

PS ~ I swear I'm going to get the dev log posting times back into good shape here soon...just..bear with me!! :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Wednesday, February 5, 2014

Huge day of work - just a brute-force, way-too-many-work-hours day :D Today one of the last great problems remaining with respect to the interface falls! I've been struggling with how to handle long lists of information for as long as the node UI has been alive. In particular, trying to figure out how scrolling fits in with the nodal framework. Today I finally had the necessary conceptual breakthroughs! :geek:

I had to change the way I think about the local spaces within an interface. Instead of thinking about the interface as one big structure in 3D space, and then projecting it to the screen with a camera, I needed to think about it as being a web of different spaces, each with their own notion of a view. Under that model, it becomes clear that every node should handle it's own view, and that nodes can have different types of views that can be manipulated in different ways. In particular, list nodes can have scrollable views that change the offset of the list with respect to the camera. Perfect! :thumbup: I really love how this blows away all of the camera logic from the main UI and forces it down into the node level. Clean code and such, you know :)

Believe it or not, the motivating factor for finally getting this done was that...I was trying to finish research!! See, I swear, I was trying! But I couldn't, because the list of types in the engine was so long that I couldn't use the data editor to create the files for research. At that point I finally accepted that I needed to do something about the long-list-of-nodes problem ;)

I briefly tried a little tweak to the nebula algorithm, inspired by some sci-fi concept art, to make the density of nebulas fall off away from the horizon, so that you can actually tell where the horizon is. This is a surprisingly-nice effect and makes a pretty big difference in terms of being able to orient yourself! I'll probably make this another parameter of system generation, so that some systems will have a strong sense of horizon and others not :)

Looking forward to another day of many hours. My goal for February is simple: put in the time. To do so, I've eliminated pretty much everything from my life except eating, sleeping, and Limit Theory :monkey: So far it's going well :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Thursday, February 6, 2014

It always comes back to those blasted constants.

I'm sitting here, in the more-functional-than-ever data editor, looking at the metatype for a production unit. Honestly, it's the simplest thing in the world. All I have to do is fill in a default value for mass, output, and power drain. That's it. The research system will do the rest, flinging forth thousands of unique production units using the modifier mechanism. All I have to do is fill in three numbers. And I just can't do it. I can't make these up. It's not right.

So I turned back to the math :geek:

A great deal of this game is already self-balanced by math. But what about the very root of it all - the metatype defaults. Can we get rid of those too? Can we let the math balance literally every attribute in the game, such that no single item is ever objectively more useful than another, so that no mechanic is ever pointless, so that no weapon is overpowered, no research unit under-appreciated, and so forth? I have to believe so :think:

When it comes right down to it, the LT gameplay is just one giant system of differential equations. But the problem is that they're both recurrent and highly-coupled. This makes it really, really difficult to figure out the way in which any given parameter of gameplay influences the whole, which makes it really difficult to figure out an analytic value for any given variable.

I can come up with fairly good solutions for some of them. 'Dependent variables' are rather easy - production output, research output, transference, damage output, etc. These are all directly proportional to the effectiveness of various elements of gameplay. But the real killer is the 'limiting factors' - the things that aren't really dependent variables, but have a limiting effect on other variables. I find that many of the equations in gameplay are of the form y' = min(f_0 * f_1 * ..., g), where f_i are dependent variables, and g is some limiting factor. A good example is mass. Mass is killing me. How much is the capacity of a ship worth? An off-the-cuff answer might be: the maximal value per unit time that you can make as a trader, multiplied by some 'patience factor' that acts as a conversion between function and rate (this factor would determine, for example, how much you would pay for an extra $1 per hour for the rest of your life).

But that's not even good enough. Capacity is more valuable than that. Trade is probably the only place where capacity is obviously the dependent factor in how much you can rake in. But capacity acts as a limiting factor (the 'g' in the equation above) in lots of different situations. Capacity will limit the rate at which you can mine, the rate at which you can produce items, etc. I don't know how to value those kinds of subtle dependencies yet :think: Capacity / mass isn't the only example either, it's just a particularly prevalent one.

The only really promising solution that I've got in mind for all of this right now is some kind of iterative graph method, where value is propagated back and forth between nodes in a 'gameplay graph,' ultimately determining how much each node is worth compared to the others. Constraints and limiting factors could be taken into account during this process. Something like Bellman-Ford...ish. It's a long shot, but if I can analytically balance all of the game up-front, well...could be pretty useful, don't you think? ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Friday, February 7, 2014

Today I wanted to go a step further with the other day's work on scrolling in the node UI. I wanted to figure out a layout that makes lists more natural. I've been using the 45-degree-twisting-tree layout from update 10's data editor. It's a pretty awesome layout, at least visually, but not such a great thing in practicality, since you have lists going at 8 (well, really only 4) different angles. It's a bit disorienting :crazy:

I've gotta say, today's layout work is pretty great :) This is the first time I'm trying a bilinear layout. I call it bilinear because it's basically just a tree where every node is two vertical lists of elements. The advantages? It's symmetric, it doesn't require rotations, it puts a lot of information on screen at once, and it's space-filling (meaning it can make use of the entire screen). On top of that, I'm now using some classic exponential magic to compress lists into a unit volume, such that even infinite lists have a uniform size. By far the most functional layout yet. Those who said the node UI will not work well for long lists of data and such...prepare to be proven wrong :D

In other news, dedicated a few more hours to ice today. I'm pleased with it for a first iteration :thumbup: Not the prettiest thing in the world, but definitely conveys the feeling of ice - and it's only going to get better with time!

Today: will he ever finish research? Will functional transfer units ever see the light of day? Stay tuned to find out!!! :lol: :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Saturday, February 8, 2014

Lots of random small things today, trying to push forward on multiple fronts at the same time (a strategy that I'll explain at the end) :)

I've generalized the HUD workspaces today so that subsystems are automatically queried to see if they want to expose a workspace, and if so, automatically added to the workspace set for the HUD. This means you'll automatically get new workspaces when you install equipment that provides them. Heck, right now I could even install multiple scanners and get different scanner workspaces with different properties. Neat. I am about to start a research workspace, which is why I implemented this in the first place :)

I'm also trying to decide exactly how I want to treat transfer units in terms of controlling them. In particular, do I want them to have a dedicated workspace, or do I just want them to function like most weapons? I guess I should probably have a workspace to make it fun. But it seems this workspace would also need to tie in with the scanner, as it would be a bit tedious to have to keep switching back and forth between the scanner and transfer unit. Or...maybe scanner and transfer workspace are actually the same? Need to give it a bit more thought :think:

Now, don't hate me, I only sunk two or three hours into it - but I let Graphics Josh out for a very specific purpose today :monkey: I wanted him to write a good SSAO shader to see if there's any chance that I could replace my per-vertex AO, thereby freeing me from the constraint of having highly-decimated meshes. No, I'm not going back on my love for scalar fields, but I'm not particularly loving the way that they're triangulated right now. It's going to really start bugging me when I try to build large stations (you see, this was relevant to station work!!), as triangulation of hard-edged and highly-detailed surfaces is notoriously difficult. The math underneath it all (the fields) is so beautiful...but converting everything into thousands of triangle shards...ugh. Not beautiful. I understand why modern graphics hardware is built around triangles, but that doesn't stop it from sucking. The biggest barrier between me and a different mesh representation is my ambient occlusion, which looks so freaking good I could never abandon it if I didn't have a quality replacement. Well, graphics Josh did a good job. In a few hours he got the best SSAO I've ever been able to get before. It's not Crytek quality, but it's pretty darn good :) Unfortunately, this was enough for me to answer the question: no, it cannot replace my AO. Compared to my current solution, SSAO doesn't even get close. Add to that the fact that it is incredibly slow compared to most other rendering operations, and I just can't stomach it (yeah, I had forgotten how expensive SSAO is..). For now I remain tied to these triangles :think: Ah well. Someday I'll think of something. LT2 perhaps.

Bit of an odd tidbit, but I spent some time thinking critically about development efficiency, work ethic, and all that stuff...trying to get a more thorough handle on it. I wrote down some equations as best I could to try to approximately understand the way that my efficiency works and how it varies with time, with the rate of problem solving, the difficulty of the problem being solved, etc. Basically, what I came to understand is that, at least in my case, a really difficult problem can have the effect of breaking 'flow,' (or 'focus,' 'interest,' 'motivation,' etc.) What this led me to realize is that my way of working is probably wildly inefficient. I have a tendency to not yield to a problem until it's solved. We've seen this happen many times throughout development. No doubt this persistence is part of what makes me a strong problem solver, but maybe also something that gets in my way sometimes - rather than taking a sledgehammer to the same problem over and over and over until it collapses, I should try mixing in some smaller problems to build up my focus, then switch over and give the harder problems a good thwack, then come back for a while, etc.

I think difficult problems pose a serious threat of 'negative feedback' - e.g., they decrease your focus, which leads to lower efficiency, which in turn continues to decrease your focus. Contrast that with a smaller problem, where the opposite is true - you continue to pick up speed as you blow quickly through it. How many times have you heard me say "awesome day of graphics :monkey: "? That's because graphics is so easy compared to all the other problems I face in developing LT...after a day of graphics work, I'm usually on a peak in terms of motivation and focus. Contrast it with some of those AI days way back when, and I think you'll see a really notable difference in tone. Graphics days usually feel like huge wins (despite the fact that they're small in the grand scheme of things), while the harder, conceptual days feel like trudging through an endless swamp of difficulty.

So, from now on I'm going to try to keep more mini-post-its on the monitor at once so that I can have a "working set" of problems between which to switch :) Ideally, I guess this set would include a few small problems and a big one. I'm interested to see if I can tell any difference between this strategy, in terms of how "in the zone" I am :geek:

(Now THAT'S a dev log, folks :shock: :shock: )
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of February 2, 2014

Summary of the Week of February 2, 2014
  • Implemented ice material (ice fields!!)
  • Implemented bilinear layout algorithm for nodal UI
  • Implemented SSAO (but unlikely to be used)
  • Developed working set meta-theory for more effective problem solving
  • Started developing analytic game balance theory
  • Separated HUD / node UI from the game, allowing external usage
“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