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

Post

Week of October 20, 2013

#1
Sunday, October 20, 2013

TL;DR

Research will be easy, approachable, and deep...all at the same time. It will encourage - no, force - exploration, reward specialization, but won't require liters of brain juice to understand or use ;) Researching is as simple as selecting a node in your tech tree. That's literally all there is to it :)

"Summary" (...if you can call it that...)

Clarity! :D :D :D

Alright, brace yourself. I'm going to describe the new concept for LT's research, and if you're not interested in "technical gameplay" details (aka Gazzisms), you might want to just read the TL;DR. You've been warned :roll:

Ready? Ok! Here we go! :squirrel:

The act of researching is incredibly simple. At first glance, it looks too simple. But bear with me as we explore the full consequences of this "simple" idea. Here's what you do: select a research node. That's all. Ever. :shock:

The core idea underlying my whole research system is: research is discovery.

When you select a research node, you're not "leveling" that technology. Levels are both boring and problematic due to scaling. What you're doing is saying, "let's focus on creating new technology based around this idea." Translation: search for nodes in the tech tree that are connected to the selected one.

After some amount of time, you will make a discovery which will add a new node to your tech tree. The discovery is always connected to the node that you were researching. Depending on where you are in the tech tree, the discovery may be a fixed node or it may be a procedural node. A fixed node is built into the game, and will usually encode the notion of a broad field of research (such as weapons, propulsion, etc). A procedural node is generated randomly, and applies a modifier on top of another node. Most of your research will consist of exploring procedural nodes to find the perfect modifiers for your tastes.

When you unlock a new node in the tree that looks promising (i.e., a procedural node that has a modifier you like), you will select this new node. Now, keeping in mind that the next node you unlock will be a modifier on top of your current node, the natural result is that you continue to develop more and more sophisticated / specialized technologies, by stacking.

But what about overpowering? Doesn't the continued stacking of modifiers allow us to keep piling more "bonuses" on top of a tech and arrive at an ubertechnology? No, because a modifier by itself is neutral in the value it produces for you. A modifier is a trade-off, not a boost. You will see things like a "heavy" modifier which will grant +20% integrity, but comes at a price of +20% mass. One of those effects is helpful, the other detrimental. By itself, the heavy modifier is neither good nor bad, simply a matter of taste. Similarly, you might have an "advanced" modifier for ships which adds +2 hardpoints, but cuts cargo capacity in half. Again, not clearly good or bad, simply a trade-off.

Ok, so we just get to keep making trade-offs but never actually get any better? Luckily no, that's not the case. When you research a procedural node, there are a few options for how the tech tree can unfold from that node. The first is, obviously, by adding another new modifier - you can think of this as lateral progression. The second is amplification of a positive modifier, and the third is suppression of a negative modifier. The latter two are where vertical progression happens, where you actually "get better". For example, if I've already researched my "heavy fighter" with +20% integrity and +20% mass, continued research in the heavy fighter node might yield a "modified heavy fighter," which will have +30% integrity and +20% mass (amplification of positive). Or, it could yield a heavy fighter with +20% integrity and +10% mass (suppression of negative). Now I've actually achieved an objectively "better" tech.

The beautiful simplicity behind this scheme is that you customize and specialize your technology simply by accepting or rejecting to further explore the procedural nodes that open up. If the node looks like it's taking your technology in a direction that you like, you follow it and continue branching from it. Otherwise, you leave it be (perhaps even delete it so that it doesn't clutter the tree). I love how simple this is. But more than anything, I love how this strikes a beautiful balance between control and unpredictability. Yes, you can guide your fate and, ultimately, you can become a master of whatever you want. But, your path to that mastery will be lined with unpredictable, alternate paths, making each game vastly different. You are guiding your research, but it is also guiding you at the same time. That simple yet profound idea is a reflection of how research really works.

There's a final bit to the system that I want to quickly go over, and it's the bit that rewards specialization and prevents jacks-of-all-trades. It's also quite cool :D Over time, the procedural unfolding of your tech tree becomes more and more biased towards your previous choices. In other words, if I have historically only spent time researching technologies that are modified with the "heavy" modifier, then future exploration is biased towards unfolding this same modifier. I.e., if I've explored heavy thrusters, heavy weapons, etc. then it's more likely that pressing into the ship fabrication side of the tree will reveal "heavy fighter," "heavy corvette," etc. So this means that your choices not only influence your view of the tree, but also how the tree will unfold in the future. This is basically a super-cool, implicit way of encoding the idea of researching a specific bonus, except that it's so much more intuitive ;) Instead of spending time researching the "heavy fabrication" technology, you simply spend time researching techs that have that property, and the implication is that you get better at it automatically. Elegant. Also, again, a reflection of how things really work!!

To close, just so you can get a better sense of how this works in practice, let's look at a hypothetical research scenario.
  • Begin game. I have only one node available - Engineering - the root of the tech tree. I select Engineering.
    Engineering -> Propulsion unlocks. I ignore the discovery and carry on researching engineering, since I'm not interested in propulsion tech at the moment.
    Engineering -> Ship Fabrication unlocks. Now we're cooking. I want to build some ships! I switch my research to this node.
    Ship Fabrication -> Fighter Fabrication unlocks. I switch my research to fighter fab. At this point, I can design a blueprint based on the "Fighter Fabrication" tech. It will be a vanilla, no-frills fighter. We'll talk about blueprint design later :)
    Fighter Fabrication -> Light Fighter unlocks. -25% mass, -25% integrity. Might be good for a scout ship but I'm not interested in that right now. Keep researching fighter fab.
    Fighter Fabrication -> Bomber Fabrication unlocks. Nice! I've figured out how to scale my ships up and, at this point, can design a blueprint for a basic bomber. Still not interested though...what I really want is a powerful fighter. Keep researching fighter fab.
    Fighter Fabrication -> Specialized Fighter unlocks. +50% power generation, -1 hardpoint. Yes! Here's what I want. I'm gonna rig this puppy with high-powered energy weapons.
    Specialized Fighter -> Heavy Specialized Fighter unlocks. +50% power generation, -1 hardpoint, +25% mass, +25% integrity. Wow, that could really be a tank, but I don't think it's where I want to go for now.
    Specialized Fighter -> Specialized Fighter Mk. II unlocks. +60% power generation, -1 hardpoint. Yes! They'll never know what hit them when I rain down the pulse lasers. Heck, a bit more and I might even be able to load a small beam cannon onto that :squirrel:
    ...
    ...
I hope that gives you an idea of how you'll be able to "craft" what you want in an interesting way! It goes without saying that I got a bit "too lucky" in that scenario, but this post has gone long enough already :shock:

Now then. That was far too much text. And I probably have only scratched the surface of this system...but I'm super excited. It's so simple and clean, but it's going to yield so many interesting possibilities :)

And...as always...the debate floor is open ;) 8-)

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#2
Monday, October 21, 2013

Ridiculous and draining dev log yesterday means a respite from it today :D Both for your sake....and for mine ;)

I'm working on the tech tree widget and it looks pretty slick, even though all I've done is a 2D mockup. I've made it self-laying-out using a classic point repulsion model, so it's pretty neat to watch the tree move itself into a nice configuration. I really love watching how the structure evolves as you branch off of nodes...it can get pretty cool :) I'm sure we'll see a demo of this in the dev update. The spatial thinker in me really loves how the scheme proposed yesterday is, essentially, all about crafting the structure of your tech tree...and it's going to lead to interesting new structures for each game.

Other than that, I'm working towards implementing the system described yesterday. Woo :)

Ah, wasn't that a nice short one :wave:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#3
Tuesday, October 22, 2013

Continuing to work on research implementation...starting to look good! I'm close to being able to get an AI research test up and running. That's really what I want to see...once AI is hooked into research...the fun will really begin :D

I feel the need to express that I was suddenly and inexplicably posessed today by a new idea that I think is going to infect my mind until I try it. Throughout this experience of coding LT, I've written a lot of code and gone through so many changes in how I think about code, the patterns and paradigms that I use to express certain things in code, etc. I've started to see things that make me uncomfortable and make me feel as though I'm working too hard. Those things have led me to flirt with template metaprogramming and now codegen-based metaprogramming. But today I think I am finally starting to understand what I really want. I don't want to write code anymore :shock: The more I do it, the more I feel that it's absurd, wrong, and generally a terrible way of going about things.

Code and programs are such structured, beautiful things. But we write them using these unstructured sequences of characters in a text file. Then we write programs to interpret and create structure from these sequences. A bit perverse, isn't it?? We have this idea of some logical, structured piece of functionality that we want to create. And then we break it down into this horrendous, text-only language. We then suffer through typos, compiler errors, and all manners of bugs because of the fact that we're trying to communicate this elegant thing in an incongruent medium, and hoping that it comes out elegant on the other side after it's gone through the compiler (which is struggling just to make sense of it all). I'm really starting to think that it's all a bit crazy :shock:

What I really want to do is make a tool where code is built visually and structurally. Something like node-based code, where code becomes this simple, beautiful web of structure. Function and data would be the same thing - just nodes, and structure would be created visually rather than syntactically. Imagine a programming language where you never made typos, never had compiler errors, and seldom introduced bugs. I think that's totally possible if we re-frame the problem of building a program to properly reflect how simple and structured that task really is. Don't worry, I won't work on this until after LT, but I think I've found my next project after this one :D I'm thinking the ultimate test would be to write LT2 purely in that format, and see how simple I could get it to look if I really tried as hard as possible to express everything in purest, simplified form, unhindered by the restrictions of a text-based programming language.

Well, it feels better to get that off my chest at least :D Sorry for the off-topic dev log :oops:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#4
Wednesday, October 23, 2013

Good day, albeit a bit more technical than I was looking for! :geek:

The biggest accomplishment (which is pretty big) was totally eliminating the old serialization (saving/loading) system. Thanks to the recent implementation of awesome reflection capabilities, I can safely remove all of my old code and still serialize by leveraging reflection. The result is many, many, many lines of code removed, and a lot of boilerplate eliminated! I went ahead and re-wrote the serializer using reflection, and it's already working! That's a nice step forward for saving and loading, which was, at one point, totally working (obviously - LTP). But it was a system that was going to require a lot of maintenance going forward, and that's why it's been broken for some time. No longer! At first I had performance concerns about using reflection for serialization (in theory it's not quite as fast as my old system), but after some testing today, I find that it's plenty performant, and I haven't even optimized yet!

Not only does this upgrade kill off a few solid pounds of code, but it'll also make saving/loading easier to debug. Since saving/loading both use the reflection engine, I can use my reflection widgets to see the engine data in exactly the same form that the serializer will see. So if something isn't saving or loading correctly, I'll be able to see the problem visually with my widgets! :thumbup: Previously, debugging improper saving/loading was quite a pain.

I'll admit, It's a bit sad that I had to end up removing all of that old work, especially when I think back to the long hours that I put into getting it up and running. But, that's progress for you. Better to acknowledge the progress and move forward with the easier, better solution than to stand by a sub-optimal system out of some misguided sense of loyalty or pride. I am learning, I swear :monkey: Slowly, perhaps :oops:

Other than that, I've implemented modifiers and a general function that can take a "meta type," find a random modifier that's relevant to the type (again, using reflection), and apply it. All that's left to do is define the other two operations (amplification of positive, suppression of negative), and then start writing modifiers! The latter will be something that I'll want to do in UDF so that it can be modded (heh, modding the modifiers :shock:).

Oh! And I've been working on the ship algorithm a bit over the past few days. Nothing too serious yet - when it gets serious it's going to get real serious. But for the time being I'm collecting my ideas and starting to play around with a few new approaches that I've gathered over the months. I'm making progress - both conceptually and in implementation. But the day of reckoning has yet to arrive. As I said a while back, the ship and station algorithms will probably be some of the last things that I write, just because I need to level up as many times as possible before then :D It's like the final boss fight :cool:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#5
Thursday, October 24, 2013

Rawrgoblargarogonus. That's how I feel about today! It's neither good nor bad, simply rawrgoblargarogonus. (Warning: Too much work and very little sleep today. Strange behavior ahead! :crazy: :ghost:)

Today I worked on factoring the creation algorithms for all of the items in the game so that they use the format required by modifiers. This amounts to pulling out the useful parameters (the things that can be "modified"), and isolating them from the rest of the algorithm, them making sure that they have a sensible and proper influence on the item that's created. No, you're right. You're quite right. This work isn't glamorous. But someone has to do it. And as much as I wish the half-eaten snack bar laying on my desk would jump up, take charge of my keyboard, and swiftly finish this job, somehow, I think I'd just be setting myself up for disappointment if I were to count on that happening :think:

Now onto more exciting things. So...I noticed a little bit of floating-point wiggle today while I was scouting around the outskirts of a (now 10x bigger) system. Argh. I guess I may have been a tad hasty in concluding that I didn't need to finish the upgrade to double precision. Bad Josh :monkey: Do the job and do it right. No shortcuts! :oops: Well, I went ahead with the final phase today: doing the actual move to double precision coordinates! The engine is now officially equipped to handle most of the coordinate-related math at higher precision. Woohoo ;) The result is silky smoothness, even at billions of kilometers from the origin!! Well, in theory that's the result. When I finish. I've already got silky smoothness in some areas, but converting all of the coordinate-based math will take a while. Another thing that I wish the snack bar would do for me. But that's ok!

Well, when this is done I'll be able to push the scales as much as I want. I guess, since that stuff will be moddable, we might even see "realistic scale" mods for LT! I think in theory the engine can now support them. Woohoo? :thumbup:

Bedtime. Yes. Bedtime. :)

:wave:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#6
Friday, October 25, 2013

As I started, once more, to build the tech tree and modifiers in UDF files today, I felt a definite lingering unease at writing UDF. At that moment, a lot of things sort of clicked in my head and I found myself saying "wait, I was just talking the other day about how stupid it is to specify structural things in text...and here I go, about to do exactly that." Why the heck would I write data in text when I could easily build a simple editor for it??? :D

And thus, today was born the first iteration of the LT node editor. The idea is to have a generic, visual editor for any of the in-game data, combining ideas from both UDF and the recent "coding in text is dumb" rant :clap:

Not only is this going to turn out to be an awesome dev tool for so many reasons (accuracy and ease of editing the game, real-time visual editing of memory while the engine is running, visual in-engine debugging, etc....), but it's also going to function as a mod editor! It's a far cry away from the TES construction kit, but at least it's better than text files, right? The great thing about a structure-aware editor is that you're never going to "break" the game (i.e., write an "invalid" mod file). It's simply not possible when you have an editor that knows the constraints of the data (in much the same way that a structural coding language would never yield compiler errors, as I mentioned the other day).

The first prototype of this editor already feels really good. It's just...one of those ideas that feels right :) I actually took inspiration from Vim, so right now you navigate the graph with hjkl (don't worry, key bindings will be re-mappable :roll:), and then just hit enter to edit the data in a node. Even this simple scheme feels good and allows for fast navigation of a data graph. The next big step is to be able to edit base class pointer nodes - the editor for these should show a list of possible derived types instead of just a text field like raw data nodes.

I'm very excited about this tool and I have to say, it feels good to get this idea of non-text editing off my chest in a way that's very much relevant to LT :thumbup: I feel that this tool is going to be something that I'll keep refining and improving for...probably my whole life :D :monkey:

PS ~ Sorry for the late log! :( Once again, blame it on an overlapping sleep schedule :oops:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#7
Saturday, October 26, 2013

Great day! I worked all day on the data editor, and it's feeling more and more like the right thing :squirrel:

In one day I've implemented a lot of the major functionality. I've got the ability to traverse arbitrary, structured data (using key bindings or the mouse), automatic layout algorithms that make the data graph look pretty as it unfolds, the ability to edit primitive pieces of data, intelligent / automatic zooming to focus on the "active" part of the graph, nice color coordination to indicate children / siblings / parent relationship to the current node (which makes traversing much, much quicker), intelligent fading out to keep clutter to a minimum and keep your focus on the active part of the graph, and even a basic search function for quickly jumping to another node. I've only just scratched the surface, and I can tell there's going to be an immense amount of functionality that could be packed into this kind of editor, but I think one more day should give me all I need for a first version.

I still lack the ability to edit pointers and vectors. Once those two are in place (and I think I can finish them today), I should have all I need to build the tech tree (and a lot of other things too...)!

It was a pretty awesome experience today when I used the editor for real-time memory editing for the first time. All I did was bring up the graph of my ship, navigate down to the position, and modify it to move my ship around...but it was a darn cool thing to watch :D Manipulating my ship from a raw data perspective, without ever having written any facilities to specifically do so...only a generic data editor. Love it :)

So, have I been derailed, you might ask? No, not at all. With this editor I will build the tech tree (and allow it to be easily modded), with the tech tree I will finish research mechanics, with finished research mechanics I will instruct the AI to build a universe! See, it all fits together :thumbup: :monkey:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of October 20, 2013

#8
Week Summary

General Sentiment

Breakthrough! That's always a good feeling :) We're finally past that little conceptual roadblock on the research highway. Unfortunately, the next step, building the tech tree, has got me all caught up in my obsession with elegance and finding the right solution. UDF seemed like a great idea, and it is...for text. But now I'm envisioning something even better for editing the tech tree (and other pieces of critical game data). Work on the visual data editor has begun, and I feel that it may just be the start of something that will come to play a huge role in the remainder of the LT dev process. Only time will tell :D

In other news..um...a real double precision engine!!! Oh yeah, you know, no big deal...!! ;) :cool:

Major Accomplishments
  • Developed an extensive new concept for research!
  • Implemented tech tree viewer mock-up
  • Implemented technological modifiers
  • Upgraded the engine to "real" double precision!
  • Ripped out the old serialization engine (lots of code eliminated)
  • Started work on a structural, unified data editor for both debugging and modding purposes
“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 6 guests

cron