Разработчика «Factorio» попытались отменить, но не получилось / Компьютерные и мобильные игры / iXBT Live

Разработчика «Factorio» попытались отменить, но не получилось / Компьютерные и мобильные игры / iXBT Live Без рубрики

Factorio — с чего начать? (factorio 0.14.20)

Добрый день, Пикабу! Очень часто я в комментариях под постами с игрой Factorio вижу сообщения типа «Что это за игра?», «Что здесь нужно делать?» и т.д. В данном посте я постараюсь передать вам базовые знания о этой игре для того, чтобы новичкам было легче играть. Для опытных игроков этот гайд будет неинтересен!

Итак, вот мы скачали игру/купили игру/взяли_аккаунт_друга (нужное подчеркнуть) и запустили ее. А что дальше?

Так как вы играете в игру в первый раз, сразу лезем в настройки и ставим все на максимум настраиваем игру под свое железо. Сразу предупрежу, что ближе к концу игры она будет потреблять намного больше ресурсов компа, чем на начальном этапе

Вроде все настроили, пора наконец начать играть! В главном меню тыкаем в пункт «Играть»! Игра предлагает нам несколько вариантов игры: кампания (аналог обучения), свободная игра, сценарии, повторы и сетевые игрища. Первым делом я рекомендую пройти вам обучение, но если «обучение для слабаков», то нам в «Свободную игру»

«Черт! Еще одна менюшка, да сколько можно!!! Я уже играть хочу!!!» при первой игре я советую вам оставить вам все настройки мира по умолчанию, кроме пункта «Мирный режим». Он подойдет тем, кто боится любого звука и не хочет парится создавая оборону своей базы. Вроде все решили, можно жмать «Сгенерировать»!

Ура, мы в игре! Нам говорят, что нашей целью является запуск спутника — шлем лесом, мы сюда играть пришли, а не сообщения читать. Вроде, теперь нам ничего не мешает начать играть! Стойте, а как играть-то? Итак, давайте по порядку. Мы летели на космическом корабле, который потерпел крушение и нам теперь предстоит выживать в это жестоком и холодном мире…

После крушения у нас есть базовый набор ресурсов: немного железных плит для изготовления инструментов, бур, работающий на угле и печка. Итак, теперь нам надо найти рядом с собой такие базовые ресурсы, как железная руда (голубенькие камушки), медная руда (рыженькие камушки) и уголь (черенькие камушки). Железа нам надо много, очень много, так что если рядом с вами его нет или очень мало, то стоит либо немного побегать, либо пересоздать мир. И нет, у этой игры нет такой прекрасной функции, как сохранение при выходе, так что не бойтесь — если вам не понравился ваш мир и вы не хотите засорять список ваших сохранений (далее сейвов), то выходите и не парьтесь. После того как мы нашли оптимальное количество железной руды приступаем к самому важному! Создаем себе первый инструмент: железную кирку. Для этого открываем инвентарь (E) и преходим на вкладку «Производство» и ищем там кирку:

Сразу видно, что для создания одной кирки требуется 4 железа, а у нас его 8! Но не торопимся создавать себе еще одну кирку, т.к. одной вам на первое время хватит. Все, кирка в наших руках, теперь бегом к углю и добываем (зажимаем ПКМ)  10 штук. После того как добыли немного угля ставим бур таким образом. Желтая стрелочка НЕ должна смотреть в сторону железа

Чтобы не терять эту стрелочку (а так же другие, но о них в другой раз) нажимаем (но не держим) левый альт. Именно левый, с правым работать не будет!

Теперь напротив стрелочки ставим печь таким образом, чтобы она была вплотную к буру:

Теперь загружаем в бур и в печь по 5 единиц угля и наслаждаемся тем, как наш бур добывает железную руду, а печка переплавляет ее в железные листы. Но долго наслаждаться нельзя, ибо уголь сгорает довольно быстро и нам необходимо добыть еще немного.

На этом я заканчиваю первую часть гайда, так как рассказал максимум 1% от всей игры! Если вам понравится, то выпущу продолжение

‎factorio calculator

Very easy to use calculator for the Factorio game. Just pick the required item, specify the required rate or the number of factories, and see the factory plan in the app! Draft your factory in one click.

Features of this calculator include:
— Works offline.
— Supports the latest Factorio version.
— Very easy to use, but contains a range variety of settings if required.
— Proper handling of oil products. Obtaining numbers for these recipes can be tricky, as several of the items involved may be produced from multiple recipes.
— Supports the breakdown of the production rates.
— Support for the mining productivity bonus
— Support for «expensive» mode.
— Arbitrary numerical precision. Calculations are performed using large scale rationals, so errors from floating-point calculations should not be an issue.
— May display rates per second, minute, or hour.
— Support for modules, including beacons.
— Support for multiple simultaneous outputs.

Fig. 2 — the manual building

There are several main goals to pursue when you try to make the code cleaner. Removing code duplication is the first and biggest priority. It is reasonably easy to solve when the code isn’t structured well, functions are too long, or names are weird, but if you have 5 versions of the same pile of code with slight changes here and there, it is the worst beast.

Читайте также:  чехол для ipad a1652 на АлиЭкспресс — купить онлайн по выгодной цене

The manual building logic is a monster, because of all the things it supports already:

Then, all of this logic needs to be multiplied by 2 (when you are lazy and copy paste), as you can have normal building and ghost building.

And then, you multiply this whole code abomination by 2 again. Why? Because we also need to do all this logic in the latency hiding mode. Sounds bad already, but it isn’t all of it, since this logic was continually being patched and touched by different people throughout history, the core of the code was a crazy long method with the code looking like the horizon mentioned by Uncle Bob.

Now imagine that you need to change something about this code, especially when you take into consideration, that the code naturally had many corner cases wrong, or fixed only in some variant of the code. This is a great example of how lazy long-term design leads to poor productivity.

Long story short, this was approached like a hobby side project of mine that took weeks to be finished, but in the end, all the duplications were merged, the code is well structured and fully tested. Managing the code requires a small fraction of the time compared to the previous state, because the reader is not required to read a huge pile of code just to get the big picture and to be able to change anything.

This reminds me a quote from Lou after a similar kind of refactoring: «Once we are done with this, it will be actually a pleasure to add stuff to this code.». Isn’t it beautiful? It is not only more efficient and less buggy, it is also more fun to work with, and working on something enjoyable tends to go faster regardless of other aspects.

The only way to go fast is to go well!

Fig. 3 — gui tests

No, we obviously didn’t get to this point without automated tests, and we mentioned them several times already (FFF-29, FFF-62, FFF-288, and more). We try to continuously raise the bar of what code areas are covered by tests, and this lead us to cover yet another area, the GUI.

This aligns with the ever repeating underestimation of the amount of engineering care the GUI needs. Having it not tested at all is part of this underestimation, how many times it happened, that we made a release, and it just crashed on something stupid simple in a GUI, just because we didn’t have a test that would click the buttons. And in the end, it proved to not be hard at all to automate the GUI tests.

We just have a mode in which the testing environment is created with GUI (even when tests are run without graphics). We declared some helper methods, that allow a very simple definition of where we want the cursor to move, or what we want to click, like this:

TEST(ClearQuickbarFilter)
{
  TestScenarioGui scenario;
  scenario.getPlayer()->quickBar[0].setID(ItemFilter("iron-plate"));
  CHECK_EQUAL(scenario.player()->getQuickBar()[0].getFilter(), ItemFilter("iron-plate"));
  scenario.click(scenario.gameView->getQuickBarGui()->getSlot(ItemStackLocation(QuickBar::mainInventoryIndex, 0)),
                 global->controlSettings->toggleFilter);
  CHECK_EQUAL(scenario.player()->getQuickBar()[0].getFilter(), ItemFilter());
}

The clicking method is then calling the low level events of input, so all layers of event processing and GUI logic are tested. This is an example of end-to-end test, which is a controversial topic, because some «schools» of test methodology say, that everything should be tested separately, so in this case, we should theoretically test only, that clicking the button first, which creates an InputAction to be processed, and then, have an independent test of the InputAction working properly.

The only way to go fast is to go well!

Fig. 4 — tdd — test driven development

I have to admit, that I didn’t know what TDD really was until recently. I thought that it is some nonsense, because it sounds really impractical and unrealistic to first write all the tests for some feature (without the ability to try it or even compile it), and then try to implement something that satisfies it.

But that is not TDD, and it had to be shown to me in a «for dummies» way for me to realize how wrong I was.

TDD actually is the constant fast switching between extending the tests and making them pass continuously. So as you write tests, you write code to satisfy them basically at the same time. This allows you to instantly test what you write, and mainly use tests as specification of what the code should actually do, which guides the thought process to make you think about where you are headed to, and to write code that is more structured and testable from the very beginning.

Читайте также:  Подробный обзор iOS 15 — Wylsacom

So after the «AHA» moment of realizing what TDD really is, I started to be instant fan. I’m now putting a lot of effort to try to follow the TDD methodology as much as possible, and to force it on others in the team as well. It feels slower, to write tests even for simple pieces of logic that just bound to be right, but the test proved me wrong several times already, and prevented annoying low-level debugging sessions in the near future.

The only way to go fast is to go well!

Fig. 6 — test coverage

When Boskid joined the team as the QA guy, one of his main roles was making sure that any discovered bug is first covered by a test before it gets actually fixed, and generally improving our code test coverage. This made the releases much more confident, and we had less regression bugs, which directly transitions into long-term efficiency.

Test coverage is an indicator of which parts of the code are executed when the application runs (which usually means running the tests in this context). I never used a tool to measure test coverage before, but since it was one of the topics Uncle Bob talked about, I tried to use it for the first time.

Uncle bob

Now that there are only developers here, I can share my new discovery of Uncle Bob and his really nice explanation of some of the fundamental principles related to programming project management, and more. If you have 8.5 free hours on your hands, I propose you watch it, as there will be some references to what he mentions later on.

My general thought was, that we maintain the quality of the code to be quite high, and we have a reasonably good work methodology. But we were the victims of selective blindness in many places actually. It is interesting, how some pieces code were just good from start and stayed pretty good throughout all the years, even when it was expanded a lot… and some of the code just deteriorated heavily.

And the answer is explained with the metaphor of the wax foundation.

What is a wax foundation and how is it related to programming you might ask? My grandfather was a very enthusiastic bee-keeper. My childhood was spent in our garden, where you had to be careful where you step, where you sit down, and you could never leave anything sweet just laying around, because you would find a big pile of bees on top of it quite soon.

One of the jobs you do around bees, is that when the honey is taken away from the bees, you put the wax foundation in the hive, which looks like this:

Its primary function is that the bees build their tiles evenly and quite fast, as it is just natural to follow the optimised structure that is already there. And this is exactly what happens with code that has a good and expandable design from the start.

On the other hand, there is code that either had a lazy original design, or it was never expected to grow so much in complexity, and each of the changes were just a small addition to the mess. Eventually we got used to the idea that this part of the code is just hell, and that making small changes is annoying.

When I took the Uncle Bob glasses and started looking around, I quickly identified several problematic places like this. It is not a coincidence, that these places were eating away an disproportionately large amount of the dev time, not only because making changes is hard, but because they are full of regression bugs and generally are a never-ending source of problems.

This is the beautiful thing about having a company that isn’t on the stock market. Imagine you have a company that goes slower and slower every quarter, and then you confront the shareholders with the statement, that the way to solve it, is to do absolutely no new features for a quarter or two, refactor the code, learn new methodologies etc.

I doubt that the shareholders would allow that. Luckily, we don’t have any shareholders, and we understand the vital importance of this investment in the long run. Not only in the project, but also in our skill and knowledge, so we do better next time.

This is the timeline of the lines of code in Factorio

Разработчика «factorio» попытались отменить, но не получилось / компьютерные и мобильные игры / ixbt live

18-го июня главный разработчик Factorio, Михал «Kovarex» Коварик, оказался в центре небольшого скандала из-за своего блога разработчика «Friday Facts». Бурную реакцию на Реддите вызвали отнюдь не новости о дальнейшем развитии популярной песочницы, недавно вышедшей в релиз из продолжительного раннего доступа, а лестные отзывы в адрес лекций американского программиста Роберта Сесиля Мартина, известного как Uncle Bob. Среди ужасных преступлений ультраправого программиста называют сексизм и расизм.

Читайте также:  ipad - Перевод на русский - примеры английский | Reverso Context
Разработчика «Factorio» попытались отменить, но не получилось / Компьютерные и мобильные игры / iXBT Live

В Твиттере Uncle Bob публично защищал слово «craftsman» («ремесленник», очевидно сексистский термин) и полицейских, и даже цитировал действующего на тот момент Президента США Дональда Трампа.

Один изпользователей Реддита, предложилКоварику если не вымарать всякие упоминания злодея, то хотя бы добавить сноску, обличающие его преступления, однако вольнодумец-разработчик не внял голосу разума. Напротив, он прямым текстом предложил осторожному обывателю «засунуть в задницу свою культуру отмены», добавив, что не знает и знать ничего не хочет о предполагаемых злодеяниях Мартина, так как они не имеют никакого отношения к лекциям о программировании и управлении проектом, о которых Коварик писал в своём блоге.

После резкой реакции, обвинения посыпались уже в адрес самого Коварика. Разработчик возмутился, что «правым фанатиком» его стали называть лишь за то, что он отказался присоединяться к травле высококлассного специалиста за его политические взгляды, глубоко безразличные самому Коварику: создатель Factorio живёт в Чехии и голосовать за Республиканскую партию США явно не может.

Завязавшуюся дискуссию прекратили модераторы Реддита, которые стёрли её начало, а позже закрыли тред целиком, после чего недовольные активисты попытались перенести её в Стим. Однако настоящая аудитория Factorio, в полном соответствии с ожиданиями, встала на сторону разработчика и принялась высмеивать «отменяторов». Попытка ревью-бомбинга со стороны уязвлённых активистов (Коварика, да и его игру,моментально обвинили в «трансфобии» и ультраправых взглядах) утонула в волне положительных отзывов: против сотни купивших игру активистов вышло больше тысячи пользователей Стима.

Разработчика «Factorio» попытались отменить, но не получилось / Компьютерные и мобильные игры / iXBT Live

В отличие от создателя Five Night’s at Freddy’s Скотта Коутона, восточноевропейские разработчики заняли твёрдую и ехидную позицию, и на поводу у не столь многочисленной толпы идти не собираются. В официальном твиттере игры появилась благодарность за бесплатную рекламу ещё сильнее взбесившая активистов, а количество игроков в Steam вновь подросло, несмотря на отсутствие скидок.

По материалам Райана Персона, nichegamer.com.

Fig. 5 — test dependencies

This is a continuation of the test dependency topic from GUI tests.

If tests should be truly independent, test C, should have some mocks of A and B, so the test of C is independent of the system A B working correctly. The consensus seems to be, that this leads to more independent design etc.

This might be applicable in a lot of cases, but I believe that trying to have this approach everywhere is close to impossible, and it would lead to a lot of clutter and I’m not the only one having problem with this.

For example, lets say that we have a test of electric poles connecting properly on the map. But I can hardly test it when I don’t know that searching for entities on the map works properly.

My conclusion is, that having dependencies like this is fine, as long as the dependencies are also tested, but the problem comes when you break something and a lot of tests start to fail suddenly. When you do small changes the yes/no indication of tests is enough, but it isn’t always an option, especially when you refactor some internal structure, in which case you kind of expect to break a lot of stuff, and you need to have a way to fix them step by step once it can compile again.

If the tests don’t have any special structure, the situation when 100 tests all fail at the same time is very unfortunate, all you are left with is to try to pick some test semi-randomly, and start debugging it. But it is really misleading when some complicated test case fails in the middle, and you spend a long time debugging it, only to realise that it is some very simple low level bug that is causing the failure.

The goal is pretty easy, I want to be given the most simple fail case of my change.

For this, I implemented a simple test dependency system. The tests are executed and listed in a way, that when you get to debug and check a test, you know that all of its dependencies are already working correctly. I tried to search if others use the dependencies as well, and how they do it, and I surprisingly didn’t find anything.

This is an example of a test dependency graph related to electric poles:

I built and used this structure when refactoring away the duplication of ghost/real poles connection logic and it certainly sped up the process of making it work properly, and I’m confident that this is the way to structure test for us in the foreseeable future.

The only way to go fast is to go well!

Conclusion

The only way to go fast is to go well!


If you are moved by this, if your emotion when you read this is, «I wish my boss had these priorities». Consider applying for a job at Wube!

Оцените статью
iPad Мобайл
Добавить комментарий