JoshParnell wrote:Well, given the recent reversal on this issue, what do you guys think?

Is it acceptable to have both blueprints AND tech as part of the game?

Yes.
To me it makes more sense. Technology is the theory, a blueprint is what you do with it.

JoshParnell wrote:Well, given the recent reversal on this issue, what do you guys think?

Is it acceptable to have both blueprints AND tech as part of the game?

I like it.

One nice thing that another favorite game of mine does related to this is the following:

Research modules = Generating research points.
Each level of technology requires twice as many research points to unlock as the previous for a 10-20% improvement in what ever performance field it increases:

For example Laser wavelength (range)
Infrared (Level 1) = 100%
Visible (Level 2) = 115%
Ultraviolet (Level 3) = 130%

To research/generate a blueprint you actually also need to spend research points, worth about 10-20% as many points as the average value of parent technologies.

To generate the name for the blueprint you use the parent technologies:

For example: 10mm Ultraviolet 15GW Laser (caliber + wavelength + capacitor + weapontype).
Then a procedurally generated flavour name can ofcourse also be pasted on top.

I'm OK with techs + blueprints.

In my head, I was sort of thinking of techs as "proto-blueprints," where they have both a theoretical (research) and practical (production) function -- which output you get depends on how you use it. Splitting those functions will, I suspect, actually make the economy more interesting.

My one gripe about blueprints is when they're implemented such that 1 blueprint + a cargo pod of nothing but raw ore = a highly complex technical thingie. This has the obvious advantage of being bulletproof; as long as players have the blueprint and the raw materials, they can't hose themselves. (It has the less obvious but maybe more important advantage of being relatively simple to code and test.)

The alternative is to allow complex systems to be composed of multiple subsystems, which themselves may be composed of subsystems. Clearly that way is the path of madness for developers and players alike if taken to extremes, so some reasonable limit (sorry, there's that word!) on nesting is required. I'd be OK with (let's say) four levels for the most complicated craftable things, or maybe even three if persuaded nicely.

Something to note is that this design has a couple of useful gameplay effects for different kinds of players. For the creative types, componentized blueprints makes researching new kinds of physical products vastly more interesting, since the particular internal structure of a new thing's components can have an impact on the the form and functions of that thing when someone creates it. And for the would-be manufacturing baron, building things from pieces instantly creates business specialization opportunities for making lots of the core components for more complex objects.

What do my fellow Limitians think about this?

On a related note: given my comments earlier in this thread about player styles and how those might work in a game like Limit Theory, I am obviously pretty pleased with Josh's notes from today's (June 24, 2013) dev log that he's giving some thought to letting players work to generate new technologies as R&D specialists and/or new blueprints as manufacturing wizards. You made a game design geek's day, Josh! Obviously none of this is set in stone and anything is liable to change, but it's nice to hear about for now.

Flatfingers wrote:I'm OK with techs + blueprints.

In my head, I was sort of thinking of techs as "proto-blueprints," where they have both a theoretical (research) and practical (production) function -- which output you get depends on how you use it. Splitting those functions will, I suspect, actually make the economy more interesting.

My one gripe about blueprints is when they're implemented such that 1 blueprint + a cargo pod of nothing but raw ore = a highly complex technical thingie. This has the obvious advantage of being bulletproof; as long as players have the blueprint and the raw materials, they can't hose themselves. (It has the less obvious but maybe more important advantage of being relatively simple to code and test.)

The alternative is to allow complex systems to be composed of multiple subsystems, which themselves may be composed of subsystems. Clearly that way is the path of madness for developers and players alike if taken to extremes, so some reasonable limit (sorry, there's that word!) on nesting is required. I'd be OK with (let's say) four levels for the most complicated craftable things, or maybe even three if persuaded nicely.

Something to note is that this design has a couple of useful gameplay effects for different kinds of players. For the creative types, componentized blueprints makes researching new kinds of physical products vastly more interesting, since the particular internal structure of a new thing's components can have an impact on the the form and functions of that thing when someone creates it. And for the would-be manufacturing baron, building things from pieces instantly creates business specialization opportunities for making lots of the core components for more complex objects.

What do my fellow Limitians think about this?

On a related note: given my comments earlier in this thread about player styles and how those might work in a game like Limit Theory, I am obviously pretty pleased with Josh's notes from today's (June 24, 2013) dev log that he's giving some thought to letting players work to generate new technologies as R&D specialists and/or new blueprints as manufacturing wizards. You made a game design geek's day, Josh! Obviously none of this is set in stone and anything is liable to change, but it's nice to hear about for now.

Oh, I don't think anyone said it would be just a blueprint + raw ore (wait, did I say that? If so, I didn't mean it...). There will definitely be intermediaries. Exactly how many stages of intermediaries is yet to be determined.

At the very minimum, you will need to go one step past raw materials.

And glad you're happy with this system! Personally I am just trying to find the "least arbitrary" system, as always, because this helps me to implement it. I just wish generating all of these things didn't involve so many arbitrary choices

Structure is so beautiful...specifics, meh

JoshParnell wrote: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 form 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.

I'm not so sure about the need for blueprints.

If we go with tech requirements only, then
tech + material components = item

You don't need a "saved reference" to an item to be able to select it for building.
The items you have available for building are a virtual database... which is not a database at all but procedurally generated item links based on the tech you know.

If you search for items with the "Point Defense" property, the game generates all items you currently have the tech for and displays those that match the filter.
In SQL terms your "select item list" would be a generated report which is based on a database (tech levels) but modified six ways to Sunday with JOINs, SUMs, and whatnot. It does not display what is inside the database but what was calculated from these values.

You then select this particular item for production, generating an item without ever having had a blueprint for it.

Ok, how about keeping a list of all objects the player has ever seen and allowing them to select from this list.

Nope.
If you want the item, you have to dismantle it, possibly gaining tech from that, or a research bonus, or well... something that gets you closer to the tech levels required to generate this item.

That means you can still "steal" your technology by either stealing the items directly (and using them) or stealing them to reverse engineer and get to the tech required to build them.


You can also grant "local" tech levels to a particular research / engineering station after this station has successfully dismantled the Meson Leaf Sublimator.
On this station you can then build the Meson Leaf Sublimator because only this one station has the required "bonus tech".

Research can be completely separate from salvage / copy.

Again. No blueprint involved either way.


The only side-effect would be that this station would be able to generate all items that share this exact combination of tech levels.
That would not be a major issue if the item generation formula would only ever generate a single item for each combination of tech levels.

Solution: The bonus techs a station acquires are saved as sets of tech, with each set leading only to this single item.
The techs are not thrown into the station's tech pool, where they would be able to generate 50 different items including this particular tech.
Still no blueprints.

JoshParnell wrote:Is it acceptable to have both blueprints AND tech as part of the game? :)

It is not neat and requires saving an old-school "item database" but if you insist... =P

Gazz wrote:

JoshParnell wrote: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 form 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.

I'm not so sure about the need for blueprints.

If we go with tech requirements only, then
tech + material components = item

You don't need a "saved reference" to an item to be able to select it for building.
The items you have available for building are a virtual database... which is not a database at all but procedurally generated item links based on the tech you know.

If you search for items with the "Point Defense" property, the game generates all items you currently have the tech for and displays those that match the filter.
In SQL terms your "select item list" would be a generated report which is based on a database (tech levels) but modified six ways to Sunday with JOINs, SUMs, and whatnot. It does not display what is inside the database but what was calculated from these values.

You then select this particular item for production, generating an item without ever having had a blueprint for it.

Ok, how about keeping a list of all objects the player has ever seen and allowing them to select from this list.

Nope.
If you want the item, you have to dismantle it, possibly gaining tech from that, or a research bonus, or well... something that gets you closer to the tech levels required to generate this item.

That means you can still "steal" your technology by either stealing the items directly (and using them) or stealing them to reverse engineer and get to the tech required to build them.


You can also grant "local" tech levels to a particular research / engineering station after this station has successfully dismantled the Meson Leaf Sublimator.
On this station you can then build the Meson Leaf Sublimator because only this one station has the required "bonus tech".

Research can be completely separate from salvage / copy.

Again. No blueprint involved either way.


The only side-effect would be that this station would be able to generate all items that share this exact combination of tech levels.
That would not be a major issue if the item generation formula would only ever generate a single item for each combination of tech levels.

Solution: The bonus techs a station acquires are saved as sets of tech, with each set leading only to this single item.
The techs are not thrown into the station's tech pool, where they would be able to generate 50 different items including this particular tech.
Still no blueprints.

JoshParnell wrote:Is it acceptable to have both blueprints AND tech as part of the game?

It is not neat and requires saving an old-school "item database" but if you insist... =P

Just wrote a very long response to this, browser decided to close, now I simply ragequit.

Short version: can't query an infinite database, it's infinite no matter how you slice it, even if you impose certain restrictions on technologies. Techs are one-to-many mappings, simply impossible to get the game to list items that you can build with current tech. Either the list is infinite or you must impose restrictions (like regional items require regional tech) which will break necessary memory guarantees (like the game may never access a region that is X units away from the player).

Need a way to specify which item you want to build that doesn't require a query, this is what a blueprint does for you. I see no other solution!

At first i would like to say that Tech + blueprint system seems much better then just tech.

Also, what about how you get different Tech's? It would be awesome to buy/steal it from other factions or just find them on abondoned research stations far in deep space etc. Will much more encorouge exploration for me.

JoshParnell wrote:
Oh, I don't think anyone said it would be just a blueprint + raw ore (wait, did I say that? If so, I didn't mean it...). There will definitely be intermediaries. Exactly how many stages of intermediaries is yet to be determined.

At the very minimum, you will need to go one step past raw materials.

As for steps of producing ship hulls. I think that the bigger the ship, the more steps it has to go through (or if ship is highly advenced). Lets say fighters/bombers are built directly on the construction plant; huge Battleship is constructed from many (5-10) smaller hull components on the orbital drydock, that makes sence. This system will also bring more differences between build/buy ships. Byuing will be more expensive, but will free you from all that management.

JoshParnell wrote:Short version: can't query an infinite database, it's infinite no matter how you slice it, even if you impose certain restrictions on technologies.

The technologies known to a faction or the player are not infinite.

You are not filtering an infinite number of items down to the known technologies.
The technologies generate the items.
Item = f(tech levels)

This could still generate a lot of items when you know a bunch of tech levels so you could cut it down with dependencies.
The "Altair Weapons Tech" ties into only 2 common and 1 rare tech.

Item / hardpoint size could be a free tech but further limit the items down to something the player is looking for.

JoshParnell wrote:Need a way to specify which item you want to build that doesn't require a query, this is what a blueprint does for you. I see no other solution!

Well, it's not a query. The items do not exist in any kind of database - they are generated.

What you can do to deal with the infinity issue is to not generate items if that's not doable.
When the player filters for his "known" items, he gets told that "9283475 items are selected".
You have to filter down to whatever number becomes manageable to display in full... or be happy with a random selection.



I just don't see the "infinity issue"!
If might play a role if you had blueprints because then every possible item would have to "exist" as a blueprint.

If the tech levels generate items then you're selecting from a decidedly non-infinite pool and you can tell how many items are available before generating a selection.

JoshParnell wrote:Well, given the recent reversal on this issue, what do you guys think?

Is it acceptable to have both blueprints AND tech as part of the game?

Just to muddy your water a little more, why not think of technology as being a form of base-line requirement (either for utilizing a given piece of hardware, but also for constructing it), while Blueprints are limited specifics (sort of like a partial seed) of a given item. All a blueprint enables is giving the item generation system a 'starting point' for what is being produced and a specific name-property for the end product. That is, of course, assuming that the item generation system is designed in such a way that it can be given parameters to control the end-product.

Example:

Blueprint
Krenum Ion Fusion Torpedo

Required Technology:
Ion Weaponization
Advanced Ion Generation
Weaponized Fusion Systems
Krenum Ion Weaponry

Materials Required:
Stuff
More Stuff
Yet More Stuff

Produced Item Grade: 5

A lot of discussion on this topic already in the thread: viewtopic.php?f=2&t=1204&start=20#p13031

Leaving aside details of the technical implementation, I've been mulling over this pretty much all day. Josh writes his dev logs just as I'm having breakfast, which means I get to think over it at work.

The tech + blueprint decision sounds like a pretty decent way forward. It also sounds potentially extremely complicated, which I think Josh alluded to in his "can I do it all in a year?" finishing thought. To that end I gave some consideration to how it could be practically implemented. Here are my thoughts:

• Research budget - All factions should have a total research budget governed by the number of research modules they are currently operating. Josh seemed to casually throw the idea of these modules out there, but I think it could work reasonably well. Each module should be a drain, so that supporting a large number of research modules requires a robust faction economy (i.e. revenue stream).

• Tech vs. Blueprints - The research budget should be spendable on either techs or blueprints. This would simply be a slider that sends more research one way or the other.

• Tech: Evolve vs. New - Research spent on tech can be spent on the evolution of existing tech, or the development of new tech - but not both.

• Tech: Directing New Tech Research - Josh's idea seems pretty good here. You should be able to suggest tech on which you can base research. In this regard I'm imagining that different techs will have different characteristics (procedurally generated of course!). Thus if you have access to a high rate of fire tech and a high damage per projectile tech you may specify research based on both in the hope of getting a high rate of fire weapon that also does serious damage per round. At this point I'd recommend bringing in the idea I've been going on about over the last few posts in this thread: that "regional", faction-specific, tech becomes "universal" tech after a set period of in-game time. That means that you can utilise older tech from other factions that may still be better in some areas than the tech you have access to.

• Tech: Measuring Progress - The conventional method of determining research progress is to have a fixed target against which you work until the tech is "unlocked". I propose instead that development progress, whether it be towards a new tech or the evolution of and existing one, be measured in terms of estimated improvement over the existing best tech. The player (or AI) can decide when to call a tech "complete" based on the incremental improvement. Thus for the evolution path you can quickly ramp up the tech level with a rapid set of small improvements, or wait it out until the improvement is significant. For a new tech, the initial incremental improvement should be negative, such that it takes a long time to reach parity with existing mature tech, BUT the expected ultimate benefit ceiling should be higher (otherwise you wouldn't bother!).

• Blueprints: Evolve vs. New - Just like tech, you should be able to direct blueprint development towards brand new items or evolution of existing items. If you have the tech behind any blueprint, this could also allow the improvement of another factions' blueprint, with suitable delay in the incremental improvement progress to reflect the reverse engineering required.

• Blueprints: guns vs. missiles vs. armour etc - Kind of self-evident, but you should be able to guide the research towards the kind of blueprints you want to develop. I have no idea what Josh is thinking here, but I would imagine a list consisting of at least: guns, missiles, armour, shields, hull design, navigation, communications, prospecting/scanning, sensors and AI.

I reckon this would be a reasonable way to limit the complexities whilst still giving the user enough control to keep things interesting. There are one or two refinements that can be considered optional

Firstly is the idea of "research centres". This is to allow you to research multiple new techs and blueprints at the same time. This could be made interesting by limiting the efficacy of adding new modules to a research centre if the modules are in physically different locations. Thus once you've maxed out the module space on a planet you can add more modules to the research centre by buying another planet and adding more modules but an efficiency cost. Tech advances in communications can then reduce the impact of physical separation to allow research centres to span large distances (i.e. multiple systems).

Secondly there is the concept of "research directions". This is where, shortly after starting research towards a new tech the player is presented with the initial directions that the research could take. This would allow the choice between a tech with that, for example, will have applications to weapons only versus one that has many more potential applications but a correspondingly longer duration until positive incremental benefits are realised. Alternatively, the trade off could be research duration versus potential ceiling on damage/shields/whatever when the tech reaches maturity.

Thoughts?

Have a look at pic for LT the Materials wodd be what is in LT as for skills mack that technologies.

Q can the player of day one with limit cash mack all/bigist ship and items in LT

Gazz wrote:

JoshParnell wrote:Short version: can't query an infinite database, it's infinite no matter how you slice it, even if you impose certain restrictions on technologies.

The technologies known to a faction or the player are not infinite.

You are not filtering an infinite number of items down to the known technologies.
The technologies generate the items.
Item = f(tech levels)

That might be doable for equipment. Actually research in Civilization (the strategy game) works like that. Once your civilization discovers gunpowder, you automatically gain the ability to build musketeers.

But what about player-designed stuff?
Josh has announced plans for a ship designer. Each player-designed ship needs to have its building plans stored, which are a sort of blueprint. So you will have blueprints for part of the game anyway. And need a system to handle them. Avoiding blueprints for equipment will make your blueprint lists smaller, but won't remove the need for some kind of blueprint catalogue system.

Thanks. Not sure how I missed that.