Return to “Suggestions”

Post

Re: Refining Gameplay Ideas Mined

#18
McDuff wrote:How do you *make* a schema though?

What do you actually, physically, *do* to get one?

That's the part I'm not really following along here.
Schemas are programs. You program them. If you buy or otherwise obtain a schema from someone else, you can see their schema represented as a program and tweak it, like you'd tweak another person's code to see if you could improve it in some way.
Last edited by ThymineC on Sat Mar 29, 2014 8:45 pm, edited 1 time in total.
Post

Re: Refining Gameplay Ideas Mined

#21
Creating schemas doesn't have to be as complex as programming. It could be as simple as selecting processes from a drop-down list, putting the selected processes in a sequence, and seeing whether a selected output mode (yield, purity, processing time) is improved as a result. Again: it's an optimization game.
ThymineC wrote:
McDuff wrote:So this is very definitely a "maybe we'll see it in LT2" suggestion then!
Yep.
Is it?

A question, asked not as a desperate attempt to protect an idea but to get some assumptions spelled out: why does mining get to be in LT 1.0 but refining doesn't?

That's actually the simple version of a more general question. What is special about mining that it merits Josh's development time, compared to other parts of the Production game? What are the rules that determine whether one Production sub-game gets implemented with active gameplay features but another doesn't?

To put it another way: how could ore refining gameplay be implemented -- whether that's like what was originally proposed here or not -- so that it makes the cut for LT 1.0?
Post

Re: Refining Gameplay Ideas Mined

#22
Well what I mean is, if it requires an implementation of Thymine's LT programming language, we know that has been gentle maneuvered into the "would be nice, may show up in LT2" pile.

If it doesn't need that dependency, it doesn't have to be. But if it does, it won't be in the game this time round. And if it doesn't need it, there's still the matter of the question I asked. What does the player, the human being sat in the chair holding the mouse, actually do to create and manipulate a schema?
Post

Re: Refining Gameplay Ideas Mined

#23
McDuff wrote:What does the player, the human being sat in the chair holding the mouse, actually do to create and manipulate a schema?
Is there some part of this question that my previous comment doesn't address?
Flatfingers wrote:It could be as simple as selecting processes from a drop-down list, putting the selected processes in a sequence, and seeing whether a selected output mode (yield, purity, processing time) is improved as a result.
The mechanics could be that simple, though I assume the interface would be appropriately node-ified.

The gameplay part is in deciding which processes, and which order of processes, deliver the best result for a particular ore concentration. In theory a player could methodically plod through every possible combination to find the best one. But in practice there'd be enough manipulation processes, and enough varieties of ore, that some amount of creative thought would be necessary to find a satisfactorily good schema within several minutes.

One other way this stays interesting even after you've designed a number of high-efficiency schemas is to allow asteroids to contain multiple veins of different kinds of ores.

Currently when you fire off a mining drone, it reports back on exactly one kind of ore, and only reports if there's some reasonable quantity of that ore at the impact site.

What if, instead, no matter where a drone hit an asteroid, it returned multiple forms of ore? (Better drones would sort the ores they find by percentages, or even molecular weights.) In a lot of cases you'd get back mostly junk ore types like various kinds of silicon dioxide rocks, with perhaps some minor concentrations of good stuff. But every now and then -- infrequently, but still often enough to support production operations -- you'd strike a good concentration of a reasonably valuable element in ore form.

For example, a random mining drone report might be something like:

32% - Pyroxene - Ferrosilite: FeSiO3
16% - Pyroxene - Diopside: CaMgSi2O6
14% - Olivine - Spessartine: Mn3Al2(SiO4)3
11% - Olivine - Forsterite: Mg2SiO4
7% - Dolomite: CaMg(CO3)2
7% - Siderite: Fe+2CO3
4% - Ice: H2O
3% - Brucite: Mg(OH)2
3% - Ilmenite: FeTiO3
2% - Geikielite: MgTiO3
1% - Thorite: ThSiO4

In a case like this, you might notice that there seems to be a fair amount of iron and magnesium at this site. You might grab a cargo hold full of this stuff, then find a refiner who's got a good schema for iron or magnesium refining. Or maybe you've seen a contract with a great offer for Thorium, so that 1% of Thorite is worth optimizing for.

The point is that, in this version of mining/refining (which is different from what Josh showed in the #14 February 2014 video update), most of the material mined from an asteroid would normally contain a mix of things, any one of which could be emphasized through the refining process, but in variable proportions for most loads. So a refiner would frequently need to adjust an otherwise applicable schema to optimize the yield of the target material from the total collected ore.

(Again, I'm using real-world mineral types for my example, but that's not required. Josh could easily make up his own mineral types.)

Mechanically, though, the gameplay is still just selecting processes and putting them in a desired order.
Post

Re: Refining Gameplay Ideas Mined

#24
Another point, that might be worth getting into is researching new Refining steps and
having increased prices for better Hardware, that copuld add an additional layer of strategy even if the process would be simplefied to maybe 4 steps per ore, with diffrent types of byproducts. One could even try to optimise getting more than one type of metal from the process.

On a different note , wouldn't most material in a SciFi setting be Ceramic composite materials?
Other refining could include enriching the metal properties with nano particles , though that might be considered alloy.

That might lead to some byproducts, that would be considered junk early game, might gain some value as overall tech lvl inreases.
Damn it Brain .. why?
Post

Re: Refining Gameplay Ideas Mined

#25
McDuff wrote:Well what I mean is, if it requires an implementation of Thymine's LT programming language, we know that has been gentle maneuvered into the "would be nice, may show up in LT2" pile.
Yeah, I was talking about it being an LT 2.0 thing if you went my way with it (however, Josh is nonetheless planning to develop a programming language for LT 1.0: source). A simpler system for refining could very well make the cut for LT 1.0.
Flatfingers wrote:
McDuff wrote:What does the player, the human being sat in the chair holding the mouse, actually do to create and manipulate a schema?
Is there some part of this question that my previous comment doesn't address?
Flatfingers wrote:It could be as simple as selecting processes from a drop-down list, putting the selected processes in a sequence, and seeing whether a selected output mode (yield, purity, processing time) is improved as a result.
Dropdown boxes would be quite simple to implement, yeah. However, there's a few things that need to be pointed out for this:

1) Selecting options from a set of dropdown menus doesn't sound like terribly fun gameplay. It sounds a bit like office work, actually. Maybe with a cool nodified style this can be mitigated. Coding stuff seems like it would be more fun, though.

2) A dropdown-based approach is inherently less powerful than a programming-based approach. With a programming-based approach, the player and NPCs can utilise code structures like loops and conditionals within their schemas. For instance, a while loop can be very useful inside a schema if we assume that refining processes are stochastic (i.e. not deterministic) and may not be sufficient if only used once, and therefore you might want to keep repeating a process an indefinite number of times until a condition (perhaps based on metal purity) is satisfied. An example of this for extracting copper from copper sulphide is shown below in ViTheory:
Image (Direct link)

3) With a programming-based approach, the balance between purity, production rate, etc. all arise naturally out of the code you write. For instance, in the above example with copper sulphide, I equated the variable "Purity Threshold" with 99.5, standing for 99.5%. This value will determine the number of iterations that I have to cycle through in my while loop in order to satisfy the while loop condition. The higher I set this value, the more iterations the loop goes through (meaning the whole process takes longer), but the higher the purity of the copper I get at the end of it. I prefer this approach to playing around with an abstracted set of sliders. In addition to this, I propose that you don't actually know what the yield/time requirements of a schema are unless you can either figure it out from the code (I can guarantee that the example schema I show above will yield copper with 99.5% purity, though I cannot judge the yield or the time taken in the same way), or by doing a set of test runs and averaging the results. This is quite nice because it limits the rate at which I can try out different schemas - although you could still use a similar system with the dropdown approach, I guess.

4) With the programming-based approach, the refining system will nicely integrate with a lot of other potential gameplay that could be based on programming, as I've talked about elsewhere. Unless there's scope for dropdown-based systems being implemented elsewhere, the proposed dropdown mechanics seem like they'd be isolated for just refining gameplay.

5) On the other hand, it will be easier for players to learn how to use a system based on dropdown menus and sliders than one that forces them to learn to program in a particular language (albeit one that should be very fast to pick up if you're already familiar with general procedural programming, based on my experiences with LabVIEW).
Last edited by ThymineC on Sun Mar 30, 2014 11:34 am, edited 2 times in total.
Post

Re: Refining Gameplay Ideas Mined

#26
I'm... I'm just not sure I see a game involving picking things from multiple drop downs, hitting "experiment" and repeating to be that compelling. It feels slightly like bringing a spreadsheet into the game as a mechanic. And while I do love spreadsheets, I don't want to play with them in my space game. I want someone else to have played with them first to work out the right ranges for the procedural mechanics that they then plug into their not-like-a-spreadsheet gameplay.

I think this is the sort of thing I'd be more inclined to leave to the research mechanic. Something like it could be modelled, yeah, at some level of abstraction, but black boxed to a certain extent so that the game could fudge where it needed to.
Post

Re: Refining Gameplay Ideas Mined

#27
McDuff wrote:I'm... I'm just not sure I see a game involving picking things from multiple drop downs, hitting "experiment" and repeating to be that compelling. It feels slightly like bringing a spreadsheet into the game as a mechanic. And while I do love spreadsheets, I don't want to play with them in my space game. I want someone else to have played with them first to work out the right ranges for the procedural mechanics that they then plug into their not-like-a-spreadsheet gameplay.
Fair enough. I'm trying to respond to both the "it's too complicated" and "it's not interesting enough" objections. Once more: this is an optimization game. It sort of has to be about rearranging internal elements to try to maximize or minimize an output. If there is no intersection between "interesting enough" and "not too complicated" that will ever be acceptable for that kind of gameplay, I can probably find something else to do with my time. ;)

I will say that interface objections seem easily addressed. Schema crafting doesn't have to be drop-downs; that suggestion was purely to point out how simple the interface could be. I'd personally rather see something more like node-dragging, which I assume would be a much closer fit for Josh's node-based UI. Nor does there have to be an "Experiment!" button -- there's no reason not to display outputs continuously as you choose different processes and change their ordering.

If the real objection is to the inclusion of an optimization game in any form at all as part of the Production/Economic game in LT, well, OK, duly noted. Those who do think a refining game might be fun are free to continue to discuss ideas here for how that might be implemented.

One thing that might make this conversation more useful is getting some idea of what Josh is thinking of for the actual manufacturing part of playing Limit Theory. If making stuff is pretty much just pushing a button, then a refining game (even a relatively simple one) is probably too much. If there is a manufacturing game of about the same depth as the prospecting/mining game, though, then I think there's room for some form of refining game in between mining and manufacturing.
Post

Re: Refining Gameplay Ideas Mined

#28
I get the impression that the bits I've been calling General Transformation Processes - Construction/Production/[refining?] - are basically black box processes, at least at this stage. You generate a blueprint from the research mechanic; the blueprint specifies some inputs and outputs; you give all these items to the correct lab or module and wait a given amount of time, and the output happens.

I'm not saying that's necessarily the final way it's going to be, or that other ways aren't possible. Just that this is how it seems to me to be up to this point. Given that research is pretty well established (I think) as a semi-random black box task, and the link between research and blueprints is pretty solid, and making materials is something Josh told me in IRC would need blueprints, I don't think he'll break any of those links at this stage.

But a) I could be wrong on this and b) there's no harm in talking about possible alternatives anyway. Something magnificent and elegant could well make Josh change his mind about something, if it was cool enough.

At some point you have to have a minimum level of detail, though. Somewhere you need to just say "and then a thing happens" without engaging the player or the computer in too much mucking about. Otherwise you end up spiralling down a rabbit hole of detail and never getting out.

If these things are GTPs/black boxes, then the gameplay becomes one of linking them together. Of making sure that inputs and outputs have the right connections, that the refineries have a steady supply of raw materials and acids and other side products, that your manufactories and repair bays have a steady supply of the correct alloys, that your fleets have adequate supplies. All the logistics stuff that has been talked about over long time here. Personally I still think there's an awful lot of game to be had there, whether it's in building up these system-spanning links or infiltrating and destroying them. One additional advantage of that, from a "it's a space game" point of view, also, is that it discourages too much sitting and clicking in one system and encourages more flying around trying to set things up.

Every black box node within this web can in theory be opened and poked inside, be it factories or planets or refineries. But I am not sure whether Josh will be up for that this time around. It seems more likely that the first pass will be making all the links work with black box mechanics and getting a game out of that, and then later, if there's time, exploring whether more detail can be added to black boxes.

I'm definitely not against opening up those black boxes and adding more depth. I'd really like a "colony management" mechanic that opens up the planets, for example: not happening this time either.

And I'm definitely not against expanding the research mechanic that generates the blueprints, or of "optimisation." In fact, one idea I've been mulling but haven't yet posted has been the introduction of things like "efficiency" to the various stages, including the blueprints.

Online Now

Users browsing this forum: Google [Bot] and 5 guests

cron