kovarex

kovarex



01 Sep

Comment

Yes, it is a strategy. It has its own twist, but if you want to put it in existing genres, strategy seems like an obvious pick to me.
You gather resources, research, build, upgrade, expand, defend, fight enemies for resources and space and mainly properly time and combine these to get the best result.

Comment

Originally posted by AcherusArchmage

Achievements were added June2016 so anyone who owned the game beforehand and either didn't play again, or always played with achievements disabled (often due to certain world settings or with mods) wouldn't have them obtained no matter how easy they were.

Some other games that have achievements that SHOULD be 100%, such as "start the game" are often at 74-95%, even lower if achievements came in at a later date.

Achievements were added specifically for the steam release, so as long as steam players are involved, achievements were there from the start.
The real reason is, that far from all people play (or even finish) the games they bought.
Check achievement for different kind of games, and it rarely goes over 20% of people.

Comment

Originally posted by Weppet

The main problems with big networks right now are (for me): resources get pulled from all over the base and bots migrate, this results in massive travel time and recharge time. I imagined this would be solved by being able to allocate bots to roboports and with the scheduling change. Sure, some resources might still be exchanged between lines of production but only if it's faster to do so, from what I understand.

Or are you also talking about UPS advantages?

Generally speaking, smaller network is somewhat more ups friendly, because there are less robots and charging places to choose from when doing the logic.We can optimise all we want, but I don't think it is possible to get the complexity to O(1) when choosing a roboport for charging for example, so the bigger network will always have some small penalty.

On the other hand, finding where to pick some specific material from actually has O(1) complexity, as we have a special data structure for that since the beginning, which is very nice, but the limitation of the data structure is, that you find "some" place where to drop the item, not the closest one.

Comment

Originally posted by Weppet

I love it, does this mean that we can do bot megabases with one big network instead of many smaller ones? It seems that the queue system could really get rid of the problems that big networks have.

Lot of the advantages of separating networks still hold.

Comment

Originally posted by Darkhogg

Most of these additions are stuff I have at some point thought about, both problems and possible solutions, so I'm really glad they were addressed!

It would be amazing if bots did do some amount of pathfinding, it would not be that hard or complex (computatially sdpeaking) to implement an algorithm that chooses where to go based on max possible distance before needed to charge to some extent.

But at the very least, the game should make sure bots don't start looking to recharge when the can complete their assignment before running out of battery!!!

It would be possible to make robots pathing, but I personally prefer 10 000 beautiful idiot robot children (Thanks for the phrase r/Nicksaurus) rather then 1 000 smart robots.

I find the design which leaves it to the player to make robots more efficient part of the challange. That is why the change doesn't completely solve the lake problem at the end, as the robots would still get a huge speed penalty when going above a big lake without supporting charging places. So making a "bridge" of roboports for them is still desirable, but at least, this won't completely halt your factory.

Comment

Originally posted by alexbarrett

If I understood everything correctly, actives robots will have properties for estimated idle time & position. Does this mean that:

  1. When a personal robot is constructing an entity: the estimated final position will be at the constructed entity's position.
  2. When a personal robot is bringing an item to the player's inventory: the estimated final position will be the player's position.

I assume also that once a task is added to a robot's queue, it will remain there and not get dynamically reassigned.

Does this mean that if a player stands e.g. very close to a full chest and deconstructs it, the game will assign tasks to empty the chest to the personal robots, and if the player then walks far away from the chest the personal robots would then a very long task queue ahead of them? Would the estimated idle time be updated when the player moves?

I don't think that existing tasks get re-evaluated this way, this is why we stated it is only an estimate (heuristic). We tried to hit the sweet spot of being reasonably precise and useful while also simple enough to not hit the performance.

Comment

Originally posted by DrAndros

An other new feature I've noticed is that in the image with the roboport robot request feature in the inventory the red wire doesn't stack. I think the wires are now permanent, so hopefully there is no need to craft a bunch of them when designing circuits.

And the wires are in two places in the inventory. This can't be filtering, because there would be a blue background behind the slot, so maybe it's changed.

Or the inventory sorting could be turned off entirely, but that wouldn't be exciting.

It will be discussed in more detail in the future, but

  1. It is quite clear, that there were things in the inventory which Scott just didn't want to show yet, so he just pasted the icon over.
  2. One of the FFFs in the future will be about all the improvements of how you can build and configure things remotely. Almost everything is doable remotely already (with more or less hussle), but you can only build wires locally, or by a blueprint trick, which was quite annoying, so you can guess what we did :)
Comment

Originally posted by BraxbroWasTaken

Will those capabilities be available for modders when the expansion is installed, then? (though I’m not sure I like locking down the engine to prevent reimplementation of the expansion; that seems more like something that should be a ToS enforcement on the mod portal than something built into the game, in my opinion; is this the plan just because it’s easier on your limited personnel?)

There are (will be) bunch of switches in the mod json file, which specifies what kind of "special features" is the mod demanding.
If the mod demands the space-platforms feature for example, the related stuff will be usable by the mod, but the mod will require to have the expansion executable.

TL;DR; There can be both expansion/non expansion mods, based on what the mod wants to use.

Comment

Originally posted by I_IblackI_I

Do the things like the robot improvements come as a free update or require the purchase of the expansion?

These changes come as free update.
It would actually be technically harder to make it only for an expansion, as it is change of how the thing is programmed in general.
Generally speaking, expansion stuff is new content (like the space platform, other planets, etc.). Sometimes, new engine capabilities might be expansion only, as there would be way too easy to make mod which just gives you the new expansion content, it will be all nicely explained in the next FFF which will be a good example of such a case.

Comment

Originally posted by Malfuncti0n

I never knew I needed these changes, amazing!

Hope it might come in 1.2 before the expansion, I don't see a reason why not?

The source code (branch) of the the expansion WIP diverged so crazily much from the 1.1, that backporting any non-trivial feature is a lot of work, sometimes almost the same as doing it from scratch.


26 Aug

Comment

Originally posted by iyix

Sorry to hijack your comment, but I am just really wondering about something: did you play Space Exploration for any significant amount of time and how do you like it?

I never played personally, but I got first-hand info about it from Vaclav who finished it twice. So I have some idea about it.

Comment

Originally posted by AmasserOfHobbies

I was also annoyed by that!

Do I detect some usage of past tense? :)

*Poker face*


25 Aug

Comment

Originally posted by Vollgrav

I just imagined a group of developers reassuring each other all the time that wszystko będzie, partly jokingly and party seriously, and it sounds like a nice atmosphere at work :)

Even if some of these thigs arrive many, many years later.

Something like this, yes :)

Comment

Originally posted by Vollgrav

"Wszystko będzie"? I thought you're Czech, not Polish :) Great attitude, by the way!

We are czech, but we have polish friends, and the saying just became somehwat of a meme in the office just before we had to figure out the company name.

Comment

Originally posted by djdan_FTW

my guess is that the challenge mostly comes from making tradeoffs between getting to the destination faster and defending your ship when you have very limited space to work with. I think it's a good idea, since space is almost never a limitation in the base game, but some of the most satisfying moments come from figuring out how to pack a production line as small as possible

Inspired by the boardgame Galaxy Trucker, perhaps... (probably not).

We like that game indeed!

Comment

Originally posted by StickiStickman

But also sounds like it will have less content overall than the mod, which is a bit disappointing.

Also really not a fan of them removing stuff from the base game like artillery and dynamite and locking it behind specific planets. Having stuff you had before removed just to pad the DLC doesn't really seem like it is rewarding.

Obviously, as long as the expansion isn't activated, the techs in vanilla are as they were (apart some balancing tweaks comming with the update).
And the changes are made only by the expansion mod when activated.

I believe that even wouldn't try to lock existing content behind a new DLC gate :)

Comment

Originally posted by ferrofibrous

A very common question/complaint I see here is no train-side logic that lets you stop at a refueling station only when needed.

I was also annoyed by that!

Comment

Originally posted by oForce21o

that feature seems off-putting to me. Whats so important about making the rocket cheaper? can we have the choice to keep prices the same as vanilla and still have a good time in dlc?

The changes are based on actual game testing by people from the team who are quite knowledgeable about Factorio.

Having rockets expensive in vanilla is fine, when it is basically the top-tier most expensive thing in the game, but once it is just a way to get to the further parts of the game, with more than enough ways to spend resources and production, it just felt way too slow with the current setting, where you had to spend tens of rockets just to build a small platform.

It still holds, that the Factory (even just the rocket production), is expected to be quite bigger compared to vanilla eventually.

Comment

Originally posted by lo53n

To not force players to increase production to unreasonable levels on a planet that we will most probably abandon in favour of new places? Having vanilla price is good for normal playthrough, as it is your game goal. In Space Age goal lies somewhere else, there is no point in blocking access to it behind big base and lots of tech - considering they are shuffling tech tree to move techs behind visiting other planets.

The expansion was specifically designed in a way that you never abandon anything, you just grow and expand :)

It would be quite annoying to build all the infrastructure on the first planet with the knowledge that everything is temporary and you are going to abandon it.


10 Jun

Comment

Originally posted by AgileInternet167

I wish we could control units in the mods (but also spidertron) like how you can in an rts like c&c. Click drag to select all, point go there. Now you always have to use the remote. now it feels like the first warcraft.

I agree that the current way of controling them is bad, this is why it was heavily tweaked in our internal version, stay tuned for future news :)