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

Post

Week of June 23, 2013

#1
Sunday, June 23, 2013

Summary

As the hours tell, I spent the majority of my day getting cozy with my notebook. The item generation just keeps making me flip-flop on my approach, and I've decided it's probably best if I stop trying to code it without having a clear picture of the solution. Ah, a lesson I will apparently never learn - think it through fully before coding! :oops: I'm making strong conceptual progress, at the very least. Without much code progress to talk about, I suppose I'll just dump some of my thoughts from the day.

There are two types of items in the universe: those provided by the universe, and those created artificially. The first is by far the easiest to generate: raw resources should be mostly tied to the topmost universe level, with perhaps the occasional regional resources. The distributions thereof are subject to standard mathematical trickery, with no fanciness needed for any particular coherence (other than smoothly varying probability distributions).

Then, there are artificial items. These are harder. The reason they're harder is that, if you really wanted to generate these items properly, you would need to run a simulation and allow the AI to just "invent" these items. This would produce an extremely realistic level of coherence and significance behind the items. "Magmapulse Mk III was the gun that turned the tides of the great Squirrelian-Borg war. The Squirrelian scientists made some major improvements to the Mk II just in time to deliver a new level of firepower to the Royal Nut Fleet, allowing them to overpower the cubes at the last moment." Obviously an overboard example, but it's nice to dream about this level of realism :D On the other end of the spectrum, there's LTP, with 100% random and incoherent items! Don't worry, we'll fix that :geek:

One of the keys to coherence is "series," i.e., having several pieces of equipment that span a certain gamut of value, but share similar properties. The Magmapulse Mk I is suitable for a fighter, while the Mk V is suitable for a battleship. Both of them share the trait that they are generally slow-to-fire, but do absurd amounts of damage at short ranges. This all sounds like common sense and you're probably asking why I haven't already coded this up. But there are more questions to ask! Does this reasoning apply to all "types"? Do shields have series? Sure. Sensors? Probably...? What about armor? Err...I guess? What about ship types? ...? Place types? ...!? Docking Bay Mk IV... :P So clearly there should be a general solution to series generation. But how general is it, exactly? To what subset of types does it extend? Is this subset an arbitrary one, or does it have some significance? And while we're at it, how does technology play into all this? What about factions? And the bit-depth of the Mersenne Twister seed?? :monkey:

Luckily, I did actually manage to do more than just ask questions all day! I answered some of them! Here goes: any subsystem that can be mounted to a ship should be considered to be a "relative" subsystem, and should be eligible to be part of a series. Ships naturally have a certain "level" associated with them, so anything you can mount on a ship should be no different. Technology can be thought of as the source that generates a piece of equipment. Equipment derives its properties from the properties of a given technology. Factions are the source of technology, so the order of generation can be thought of as faction->tech->item. Still, for the sake of the game there should be some "universal" technologies. All of this creates coherence that the player can learn to recognize. "Meson"-based guns are typically red and have an unusually long range, but are easily defeated with a lot of plating. A meson gun may or may not have the name "meson" in it, but the player would be able to see that "Meson Engineering Mk .." is a prerequisite for construction. And as for the Mersenne Twister, it should be seeded hierarchically, starting at the universe seed, then appending every regional seed recursively, and finally, a seed for the item being generated. This means that literally every item you ever see in LT will be 100% unique. Way more than 4 billion (that would be 32-bit random). More like...err, a novemvigintillion? (Seriously, it's a real word :shock:) On a side note, I have literally zero clue what a meson is, so I should probably go look it up and learn a bit of physics before I start tossing random tech trees around.

It goes without saying that not all ship equipment would be generated as part of a series, there would also be some propbability of a "unique" piece that stands alone.

Slowly but surely, I am solidifying the conceptual glue of the LT universe. Everything just takes time and thought. No magic, no brilliance. Just time and thought :)

[ 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 June 23, 2013

#2
Monday, June 24, 2013

Summary

I'm working on a new concept for a hardpoint/subsystem control interface. I want something that can unify all of the subsystem-related configuration operations that one might need to perform. Selecting the task of a construction module, configuring the phase of a weapon to produce a certain firing pattern, installing a particular kind of missile in a launcher...I think they should all be accomplished via a unified subsystem interface. Every subsystem creates its own custom widget that exposes any configuration options specific to the particular subsystem. Not exactly groundbreaking, but certainly more advanced than what I have now (no real per-hardpoint configuration options, other than power, which is treated as a special case). This would allow me to introduce whatever customizations I wanted at the subsystem level, and have the interface automatically adapt. I started re-working the "ship viewer" interface today in anticipation of these changes. I moved everything into accordion-like side-expanding groups. This gives you the freedom to view whichever panels you like at the same time, instead of being constrained to seeing only cargo / power / the 3D ship view at once, and always seeing hardpoints. Now you can specifically expand whichever interfaces you need. I think this makes more sense :)

A bit of bad news about blueprints / technology today, I'm afraid :( As I was going to bed last night, for some reason I suddenly remembered why blueprints were necessary in the first place. We actually do need them...otherwise, how else will you specify which object you want to construct? Sure, a stupid question at first. But look deeper. It's actually not a stupid question. Will you have the player type in the name of an item? And what? Match it against a database of objects? ....an infinite database? The objects in the game cannot be enumerated, because they are unbounded. Selecting via matching a name is automatically ruled out. What about matching against all objects in the universal / regional level? Too much of a special case. What about when the player wants to construct a regional object in a region other than the native one? He is out of luck? Ok, how about keeping a list of all objects the player has ever seen and allowing them to select from this list. But that would completely defeat the entire sparse item system. It would require every object the player has ever seen to remain resident in memory, because it would require holding a reference to it. How about allowing the player to select from an item in their inventory / fleet? Ok, so when their last Death Star gets blown up, they automatically lose any ability to construct it, despite ambitions to build it again without that #$^& two-meter-wide vulnerability?? Not fair. The truth is, there is no good solution. A blueprint is the best solution: it is an identifier that allows you to specify an item to construct. A blueprint is a smart reference.

So. Sorry for being stupid. But we need blueprints :oops: However...I still think technology should be part of the equation! I was never really planning to go this deep with the crafting scheme in LT, but...why not :) Let's have technology be the source of blueprints, and blueprints be the source of objects. You can make a living off of either one. You could scour the galaxy for blueprints, acquiring the know-how to make any object that anyone desires (note: you do NOT need technology to create an item, only the blueprint. I.e., if you follow the instructions carefully enough, you do not really need to know that much about the underlying principles in order to build something :) ). Or, you could be a galactic think-tank, using technology to research blueprints and producing these instructions for the less intellectual lifeforms to construct.

A few thoughts on research. Again, something I was never planning for LT. But it is too enticing. I'm thinking we have "research modules," which are an abstraction for scientific labs and a crew (remember that all crew is abstracted in LT since there is no concept of crew). You can use research modules for a few purposes: first, directed research. Put in a few technologies, then allow the module to simply churn ideas and try to produce a blueprint related to the technologies. This would essentially be "crafting" of new items! I think this is a super cool concept. You could actually guide your research AI to new items. If you like hadron-based rail guns, then you should use "Hadron Engineering" and "Heavy Rail-Gun Construction" as inputs to your research module. Presumably, you will be able to "lead" it to a new blueprint that incorporates these new technologies! Then there's improvement. You have a "Gamma Hadron Accelerator" blueprint, but you also have the technology that governs it. You can use this technology along with the blueprint as an input to the research module, in hopes that it will be able to "improve" this existing technology and come up with a "Gamma Hadron Accelerator Mk. II" Finally, there's reverse-engineering. If you don't know how to build a Gamma Hadron Accelerator, but you have one, and you also have the technologies that govern it, then you could try to research the object itself in order to get a blueprint so you could start manufacturing it.

This answers a whole lot of questions about crafting in LT. The only question that it really leaves open is - where does technology come from? Maybe there's a fourth mode for research module that is "free-form research," where you give no inputs to the module and it simply has a chance of coming up with a new technology.

Well, this is all very cool...I'm excited about all of the possibilities in these systems. Again, it's a bit deeper than I ever expected to go...but once you're at this point, you can't just stop ;) And personally I think I would really enjoy trying to become a galactic think-tank, churning out technologies and blueprints.

Now...can we reasonably implement all of this in under a year? Good question :) Maybe I should stop thinking up ideas now and get back to the code... :geek:

[ 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 June 23, 2013

#3
Tuesday, June 25, 2013

TL;DR

OMGYES awesome conceptual breakthrough on AI, simulation, item generation.

Full Summary

A run-of-the-mill-day. Or was it? ..

Eh, you know. Upgrading the context-free grammar parser to include probability distributions, making it more expressive. Factoring out general probability distributions into their own object / code, yada yada.

Some run-of-the-mill thinking. Generating items? Meh. Too many arbitrary choices. Hold on though...if we need to allow the AI to use research modules (which we do), then we need OOS simulation capability for research modules. This means we need an abstract simulation that produces new technology and items. So...we're already going to have to do that, why not just go the simulation route for everything after all? It certainly removes a lot of the arbitrary choices. Makes everything clean. I like the sound of that. Generate items via a simulation. Sure, I'm sold.

Too bad it brings up billions of questions. If we want to simulate any impressive length of time for this "history" phase of a region, we need to move to a really abstract level. More abstract than your typical that-guy-is-in-the-next-system-over-so-we-won't-do-collision-checks simulation. Wayyy more abstract. I started thinking about it like a turn-based, purely-numbers game. Faction A has 1000 wealth, 200 research points, 500 military points, etc. Let's say we simulate in increments of 1 year. Each year we'll go around and give each faction a chance to do something with their points. Perform research to earn more tech points and possibly generate new tech, spend wealth to acquire more military assets, use military points to potentially overthrow another faction and steal their points, etc. One could imagine simulating centuries without any problem at this level of detail, where everything is just ultra-abstract numbers. This would generate a history consisting of real wars, real strip-mining, real technological developments fueled by real factions (and all of these would reflect the personalities of the factions, so the regional history would be vastly different if most of the inhabitants were "peaceful" vs "aggressive"). At the end of it all, we're left with these numbers, but it's pretty easy to build a concrete world that reflects them. Abstract to concrete is algorithmically mundane.

Alright, alright. This is all well and good. But are we really going to write multiple levels of simulation for *everything*?? Isn't there a way to unify this with OOS simulation and AI reasoning? Yes, there is. I'll spare you all the details, but a new technique called "folding" promises to make the universe incrementally easier to simulate at whatever granularity you like! Very cool, and the day started to get significantly less run-of-the-mill. Folding is a beautiful way to think of incremental universe LOD. Of course, like everything, it brings its own set of problems. It really gets back to the same old set of problems time and time again - what does it mean to simulate an action at varying degrees of granularity? How can it be that a concrete AI is initiating an action on an abstract world? How does time play in? What if an abstract action is "interrupted" and forced to become concrete??

But then. There was light. And now I see!!!!!!!

Events. Events are the key. Stop thinking of the world as being driven by actors and actions. It may be true but it's ugly and intractable. Think of the world as being driven by events. Events are objects, just like everything else. They are simulated, just like everything else - the notion of time is handled just like it would be for any other object. An event may or may not be tied to an AI. Maybe multiple AI. Maybe abstract objects, maybe concrete objects. But the event. Can. Solve. EVERYTHING!!!

The event can handle the translation layer from abstract to concrete (no one else needs to know that it even exists!) The event can handle time and interruptability (it knows how to interpolate the world state differential that it is in the process of producing). The event automatically writes history. The event has a magnitude and can be filtered by magnitude (history = set of all regional events with magnitude >= bignumber). The event automatically handles the notion of detection. Police saving you from pirate attacks? Angry faction leaders telling you to stop mining in their asteroid fields? Friends joining up to attack an enemy together? The event solves them all.

I am telling you all...the event will tuck you in at night. It will make your bed for you when you wake up in the morning, pour your coffee, and butter your toast. The event will hang out with you on the couch and later do your laundry while you play Limit Theory. It will mow the grass, walk the dog, and babysit your children. The event is the answer.

To everything.

Ever.

PS ~ I may have exaggerated a teeeensy bit, but I'm seriously very excited, this is one of the top conceptual breakthroughs in a long time!!

PPS ~ Is it me or are the dev logs getting longer?? I apologize to the poor souls who still read :shock: In the future I will be providing tl;drs for particularly taxing logs :thumbup:

[ 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 June 23, 2013

#4
Wednesday, June 26, 2013

Summary

Jeez, Tuesday June 25, 2013....you're a tough act to follow :shock: Since there wasn't much conceptual excitement today, and I have no new abstract ideas that are ready to do household chores for you, I guess I'll keep it "short" :roll:

I would really like to be able to show some basic production for the monthly update. Since a big part of this month's work has been conceptual, I don't have much shiny new stuff to show, and I fear that roaming around shooting asteroids may be getting a little boring for some people :oops: It'd be great to be able to demonstrate a rough version of "crafting" in LT, especially since people who don't read the logs or peruse the forums frequently probably have no idea what it will be like. With all this new simulation and event nonsense, item generation looks to be a ways off. Still, I could rig up a few prefab items just to play around with the process. Getting a construction module up and running on a battleship could be a cool experience :) Actually, what I was thinking is...it would be pretty sweet to show a missile-based battleship that produces it's own ammunition. I don't think I can have mining ready in time to show the process from A to Z (mining, refining, etc...all the way to finished missiles), but it could be cool just to see the process of churning out some missiles from pre-existing raw materials using construction equipment. I'd also really like to show guided missiles! Everything has been dumbfire until now. Guided missiles shouldn't take very long to implement.

So, today I spent a lot of time on the hardpoint interface, getting it ready for the new modular system. Every hardpoint is more of a full-blown "widget" now, and hardpoints that can be configured have a drop-down panel that displays configuration options. For a construction module, I imagine this would include droppable item boxes for specifying a blueprint, and maybe a few parameters to control the construction, like quantity / looping, perhaps even a slider that allows faster construction at the cost of more resources / energy.

Dropped a few more hours into the chromatic aberration shader, making it a bit smoother but less blurry at the same time. I'm still missing the simplicity in it. I mean, my method is simple, but...there are still a few awkward lines of math that just feel like they could be replaced with something beautiful. Keep searching :geek:

I'd love to get some fancier explosions going on, so that I could end everything with a "bang," using my missiles to destroy something! We all know explosions in LTP are pathetic. Looking at the explosion and particle system code today, though, there's just a lot that needs to be done. Loads of generalization and power need to be added, and I'm not sure how quickly I can figure out a good architecture for this. Sooner or later, though, we will have better explosions...of this I have no doubt!

[ 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 June 23, 2013

#5
Thursday, June 27, 2013

Summary

Well, not as big of a day as I wanted it to be :think:

I did get around to implementing tracking missiles. To be fair, this is hardly an accomplishment. Tracking vs dumbfire is about two lines of code of a difference. Still, those two lines make a pretty sweet difference! Watching my battleship's missiles close in on a pesky fighter that thinks it can outmaneuver me is...surprisingly gratifying 8-) A bit of progress on explosions, but still haven't given the particle engine the love that it needs to ascend to the next level.

Construction modules are on the way! I hope to have them operational and kicking out finished goods by this weekend.

Overall, not a whole lot to talk about today. Oh well...let's hope for a big Friday :ugeek:

[ 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 June 23, 2013

#6
Friday, June 28, 2013

Summary

Solid progress today, continuing to tie up all the loose ends for the monthly demo. Working on UI touching-up, explosion touching-up, homing missile improvements, and so on :) Homing missiles are really just too cool. And perhaps a bit overpowered...but oh well ;)

A bit of exciting news for me today: I spent some time attempting to repair my old laptop - the one on which LT was born! Much to my excitement, it now works! I was able to get everything set up again on this puppy. It's a 3-year-old laptop and definitely was never intended for gaming, but it's the reason why I was so confident in the first place that LT would run on low-spec machines. Ever since it kicked the bucket a while back, I've been concerned about not having a truly low-spec machine to test on. Well, today I was finally able to revisit LT on the "original dev machine" :) Unfortunately, it seems that I've really let the performance get out of hand, because the old laptop could hardly handle 15 FPS. Granted, the graphics have improved a whole lot since I last ran it on that thing. Still, I'm sure some of the poor performance can be attributed to me having developed on too powerful hardware since it died. With my original laptop in hand, I think I'll be able to really push the performance of LT again! If I can get it running at 60 fps on that...then anyone should be able to run at 60 fps ;)

Continued some heavy conceptual work on simulation LOD today. I'm absolutely torn between two different architectures. Events are the glue that would hold either together...but should I insert the abstraction layer at the "world" level or at the "object" level? Very difficult decision. Previously I was thinking world level. The world is an abstract or concrete object that answers queries. Now I'm starting to believe that it could be even more powerful to do it at the object level. In other words, when you deal with an object, you don't really know whether you're dealing with a real object or an abstract one. I was thinking, this could really bring about some beautiful possibilities. Imagine if you called AddItem on an object. Maybe you're actually adding a physical item to someone's inventory. OR, if the object is an abstraction layer, maybe you're just incrementing the military "point" value of a faction, because you gave them another weapon! Very beautiful solution. The same game code could drive the simulation at all LODs. I think object-level virtualization may be the way to go...but this could take a lot of code.

Also, gotta admit, RSI's new site is pretty...sleek :) Wish we had a site like that. Oh well :(

Still hoping to have a production pipeline set up for the end of the month..wish me luck :ugeek:

[ 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 June 23, 2013

#7
Saturday, June 29, 2013

Summary

Lots to do, lots to do! Not much time for a dev log!

Worked all day on preparing for the demo. Making the new hardpoint interface prettier, implementing construction modules, improving the overall UI graphics, and generally being a good little codemonkey :monkey:

Construction modules are now the first hardpoint-mountable objects to make use of the "specialized" hardpoint widget system. They display a rudimentary construction interface that lets you drop a blueprint in to specify an item to construct, then gives some information about material requirements and construction time. And of course, there's a big old button for starting the process! Not very fancy yet, but it works!

After "magically" acquiring several nice loads of tritium and carbon composites, a blueprint for some "Firefly" missile, and a shiny new construction module, I was able to produce my very own batch of missiles, all without leaving the comfort of my lumbering battleship!

Next step is to be able to equip the missiles. This is new to the engine, and will require missile-based weapons to expose a specialized widget for selecting the munition type. After I finish that...I hope to be blasting passersby (and of course, asteroids) with my very own, home-grown explosives :D

Well, that munitions interface isn't going to build itself...

: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 June 23, 2013

#8
Week Summary

General Sentiment

Bit of a scattered week. I guess I'm most excited about "events," as cryptic as I've been about this development, it has totally changed the way that I am looking at the simulation and AI architecture, and I'm feeling more comfortable about it by the minute. It's still going to be a while before everything is solidified, but once I figure out the right architecture for all of that...well, that's basically the biggest challenge in the entire game, I think!

Major Accomplishments
  • Implemented soft-switchable munitions for missile weapons
  • Implemented construction modules
  • Implemented guided missiles
  • Improved UI graphics (again)
  • Improved / expanded hardpoint interface
  • "Events" simulation / AI conceptual breakthrough
“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