Factorioは無限に広がる2D世界に自動化された工場を建設し、次第に複雑になる様々なアイテムを製造するゲームです――想像力を駆使して工場をデザインしましょう。単純な要素を組みあわせ、精巧なラインを作りましょう。そしてあなたを敵視する生物から工場を守りましょう。
最近のレビュー:
圧倒的に好評 (743) - 直近 30 日間のユーザーレビュー 743 件中 96% が好評です。
全てのレビュー:
圧倒的に好評 (28,809) - このゲームのユーザーレビュー 28,809 件中 98% が好評です
リリース日:
2016年2月25日
開発元:
パブリッシャー:

このアイテムをウィッシュリストへの追加、フォロー、興味なしとチェックするには、サインインしてください。

早期アクセスゲーム

今すぐアクセスしてプレイ開始;開発途中のゲームに参加しよう。

注: この早期アクセスゲームは不完全であり、これから変わることも、変わらないこともありえます。現時点でこのゲームをプレイしても満足に遊べない場合は、 ゲームの開発が更に進捗するまで待ってみる必要があるかもしれません。 詳細はこちら

開発者からの注意書き:

早期アクセスにした理由

“私たちは4年以上にわたってFactorioの開発を続けています。 ゲームは非常に安定しており、長期間のゲームプレイや巨大な工場にも高く最適化されています。 私たちのウェブサイト上でのFactorioの販売数は11万本を超えており、より広く意見を聞くのによい時期だと考えています。”

このゲームは大体どのくらいの期間早期アクセスですか?

“私たちのリリース計画は進行を続けており、定期的に新しい要素やコンテンツを追加しています。 ゲームが完成した暁にはフルバージョンをリリースする予定です。現状の予測では、8~12ヶ月後と見込んでいます。”

早期アクセスバージョンと計画されているフルバージョンの違いは?

“フルバージョンでは、洗練されたGUI、マルチプレイヤーマッチングサーバ、プレイヤー・サーバー両面でのMODの調整、その他多くの最終調整を行い、コア・ゲームプレイへさらなる要素の追加を考えています。”

早期アクセスバージョンの現状はどうなっていますか?

“このゲームには魅力的なメカニクスや要素にあふれた、強力なコンテンツ基盤があります。 マルチプレイヤーモードや献身的なMODコミュニティのおかげで、多くのプレイヤーが何百時間プレイしても飽きがこないという声を寄せています。”

早期アクセス期間中と期間後ではゲームの価格は変わりますか?

“アーリーアクセス終了後に、価格を上げる可能性があります。”

どうやって開発プロセスにコミュニティを参加させる予定ですか?

“コミュニティは開発プロセスの重要な一部です。
私たちは計画したすべての要素を事前にアナウンスします。この期間の内にコミュニティから意見やコメントを受け、プレイヤーのもつ様々な視点を取り入れた議論を行います。

コミュニティから出されたアイデアが開発に取り入れられることも多くあります。私たちは個々のプレイヤーがもつ意見を重視しています。”
詳細を見る

Factorio を購入する

このゲーム用のダウンロードコンテンツ

 

最新の更新 全て表示(270)

7月13日

Friday Facts #251 - A Fistful of Frames

Factorio at the National Library of Technology Prague
If you are in Prague this summer, and wanting to satiate your Factorio cravings, you can stop in to the National Library of Technology Prague, where Factorio is loaded onto 150 computers for all to play. Entry is free for all visitors Monday to Friday 08:00 - 22:00 until the 31st of August. The PC's are running Linux (Fedora), loaded with a custom build of the game HanziQ put together, and you can host LAN servers and play with your friends.



On the 23rd of July we will be hosting our own Factorio LAN party at the library starting at 16:00 CEST (Prague time), so you can come along and play with us. It is advised to bring your own set of headphones if you are going to attend.

Rendering optimization
As we started to modernize our rendering backend, the absolute must have was to make it at least as fast as the old one. We had the chance to do things however we wanted, so we were excited about the capabilities newer APIs unlocked for us, and we had lot of ideas how to draw sprites as fast as possible.

But first, there is no need to reinvent the wheel, so let’s see how Allegro makes the magic happen. Allegro utilizes sprite batching, which means it draws multiple sprites that use same texture and rendering state, using a single command sent to the GPU. These draw commands are usually referred to as draw calls. Allegro draws sprites using 6 vertices, and it batches them into a C allocated buffer. Whenever a batch ends, it is passed to the OpenGL or DirectX drawing function that copies it (in order to not stall the CPU) and send the draw call.



That looks pretty reasonable, but we can’t do the exact same thing, because in DirectX 10, there are no functions for drawing from C-arrays directly, and it is mandatory to use vertex buffers. So our first version created vertex buffer to which current batch was always copied for use in a draw call, and we would reallocate a buffer with a larger size if the current batch wouldn’t fit. It was running quite fine, probably not as fast as Allegro version, and it lagged noticeably whenever the vertex buffer would need to be resized.

After reading some articles, for example optimizing rendering in Galactic Civilizations 3 and buffer object streaming on the OpenGL Wiki (which was very helpful), it became clear that the way to go is to have a vertex buffer of fixed size, and keep adding to until it is full. When we finish writing a batch to the buffer, we don't send a draw call right away, we write where this batch starts and ends into a queue, and keep writing into the buffer. When the buffer is full, we unmap it from system memory, and send all the queued draw calls at once. This saves on the expensive operation of mapping and unmapping the vertex buffer for each batch.



As we were trying to figure out how to serve data to the GPU in the most efficient way, we were also experimenting with what kind of data to send to GPU. The less data we send, the better, and Allegro was using 6 vertices per sprite with a total size of 144 bytes. We wanted to do point sprites which would require only 48 bytes per sprite and less overall maths for the CPU to prepare a single sprite. Our first idea was to use instancing, but we quickly changed our mind without even trying, because when researching the method, we stumbled upon this presentation specifically warning against using instancing for objects with low polygon count (like sprites). Out next idea was to implement point sprites using a geometry shader.



We tried it, and it worked great. We got some speedup due CPU needing to prepare less data, but when doing research how different APIs work with geometry shaders, we found out that Metal (and therefore MoltenVK) on macOS doesn’t support geometry shaders at all. After more digging, we found an article called Why Geometry Shaders Are Slow. So we tested using the geometry shader on a range of PCs in the office, and found that while it was faster on PCs with new graphics cards, the older machines took a noticeable performance hit. Due to the lack of support on macOS and the possible slowdown on slower machines, we decided to drop the idea.

It seems the best way to do point sprites is to use a constant buffer or texture buffer to pass point data to a vertex shader, and expand points into quads there. But at this time we already have all the optimizations mentioned in the first part, and the CPU part of rendering is now fast enough that we have put the point sprite idea on ice the for time being. Instead, the CPU will prepare 4 vertices per sprite with a total size of 80 bytes, and we will use a static index buffer to expand them to two triangles.

The following benchmark results are from various computers. The benchmark rendered a single frame at max zoom out (about 25,000 sprites) 600 times as fast as possible without updating the game, and the graph shows the average time to prepare and render the frame. On computers with integrated GPU there was little improvement because those seem to be bottlenecked by the GPU.



We also noticed higher speed-ups on AMD cards compared to nVidia cards. For example in my computer I have a GTX 1060 6GB and Radeon R7 360. In 0.16 rendering was much slower on the Radeon than on the GeForce, but with the new renderer the performance is almost the same (as it should be because GPU finishes its job faster than the CPU can feed it draw commands). Next we need to improve the GPU side of things, mainly excessive usage of video memory (VRAM), but more on that topic in some future Friday Facts...

As always, let us know what you think on our forum.
30 件のコメント 詳細を見る

7月6日

Friday Facts #250 - Dead end conclusion

Mod portal features
Sanqui has been quite effective these last weeks getting stuck in with the mod portal, so we have some interesting additions to talk about.

Mod deprecation
A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc.



Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later.

Collaborators
It is often the case, that a mod author will want someone else to help them maintain and manage their mod, for instance if they are going on holiday when a major release is coming out. The way it has worked in the past, another modder would have to come and upload an updated version of the mod under their own name. Now a modder can set another player as a 'collaborator', which means they can help out will all the maintenance of the mod. Collaborators can do everything the author can do, except add or remove collaborators.



You might also spot the other feature, transferring mod ownership. This lets the author give the mod completely to a collaborator, in the case that they are no longer interested in working on the mod at all.

Discussions notice
Mod authors can now display a notice above their mod page discussions, informing the users of any useful information. For example, an author might prefer you to report bugs on their GitHub page, so the notice will inform users of where they should go. An additional option allows the author to disable the discussions completely, in the case they have their own forum/thread somewhere for discussions.



If you have any ideas for an improvement to the mod portal, please let us know on our Mod portal discussion subforum.

Blueprints - Proposal Zero
I feel that none of the propositions in the previous Friday Facts were really that great. We spent some more time thinking about the blueprints and the blueprint library while going through the player feedback, and we are now agreeing on what I like to call Proposal Zero, because it was the first idea and the first mockup I ever made related to this subject. Put simply, blueprints stay as items, and the blueprint library becomes a regular inventory, like a chest (that is of course accessible across all your saves).

The idea goes together well with the "quickbar is an action bar" idea explained in the FFF-191. The details and mockups for the action bar are taking shape, so expect more about it in a future FFF.

When working on GUIs, I like to create design documents where I try to explain how something works as objectively and as complete as possible. It ends up sounding like a boring legal document, but it helps force me to think of all the corner cases and possibly find problems. I will use this opportunity to also tell you how we usually work on the GUI. Here is what I have written so far:Blueprints and blueprint library Proposition Zero:
  • In the text below, Blueprinting Tool = Blueprint, Blueprint book or deconstruction planner. Library = Blueprint Library. Book = Blueprint Book.
  • Blueprinting Tools stay as items, they interact consistently throughout the game.
  • The blueprint library: One window with one grid of large (or small?) spaces. The grid expands infinitely on a row-by-row basis (if any item is placed in any slot of the last row, a new row is added). This grid act almost identically as a chest. Items can be manually moved there, or fast transferred using any of the shortcuts that work for normal inventories (see comment below). This inventory grid can only hold blueprints, books or deconstruction planners.
  • Special behavior: when picking up a Blueprinting Tool from the blueprint library, it is replaced with a "hand". This means that when pressing Q to drop it, it is not returned to the player inventory, instead, back to that slot in the blueprint library. This is so blueprints can easily be used directly from the library.
  • The functionality of automatic blueprint library sharing in multiplayer is removed. The "shared blueprints" panel is removed. Blueprints and blueprint books in multiplayer will be shared by manually trading the items or by linking them in the chat. Blueprints or books linked in the chat can be clicked to pick up a copy that can be used as a normal item.
  • Every Blueprinting Tool will have a unique identifier, so every blueprint item is unique, even if it has the same contents.
  • The blueprint editing interface (the UI that opens when you right-click a blueprint) will have 2 new buttons:
    • Reassign: assign new contents to this blueprint. This is helpful when you want to update a blueprint and leave it in the same place in the player inventory, blueprint library or action bar.
    • Duplicate: create a new blueprint with a different unique identifier, but the same contents, and place it in the player cursor. This can be useful when players want to take a copy of a blueprint from the library to edit, experiment with or remove buildings from, without changing the original blueprint.
  • Shortcuts to Blueprinting Tools can be created from the player inventory or from the blueprint library to the action bar:
    • Right clicking a shortcut to a Blueprinting Tool will open the blueprint editing interface, as if it was right clicked in its original location.
    • If a Blueprinting Tool is moved between the library and the player inventory, the shortcut in the action bar remains valid and unchanged.
    • If the Blueprinting Tool is moved outside any of these inventories (e.g., placed in a chest, or given to another player), the shortcut will become greyed out and cannot be interacted with, only cleared. If the Blueprinting Tool is placed back in the player inventory or blueprint library, the shortcut becomes valid again.
    • If the Blueprinting Tool is removed (or destroyed) from the library, and a different game is loaded that had a shortcut to that Blueprinting Tool, the shortcut will become greyed out forever, and it can only be cleared. This is to give feedback that there used to be a Blueprinting Tool there.
    • If a Blueprinting Tool is explicitly destroyed using the trash button, the shortcut will become greyed out forever and it can only be cleared. This is to keep consistency with the two rules above.
  • Blueprint books will work very similarly to the library: it will be an inventory which can hold only blueprints (maybe also deconstruction planners?).
  • Blueprint books will have the same sparse grid where you can arrange the contents as you like. 'Shift + Mouse Wheel' will move to the next/previous non-empty slot.
  • Blueprint books will not have any special behavior or interactions while in the library, right clicking them will open the book in a separate window, possibly closing the Library. Clicking them will pick them up to the cursor.
  • Blueprinting Tools are created using buttons in the Library. Blueprint string importing will also be there.
  • Quick Copy pasting will be done using new copy-paste functions that work almost identically to blueprints. Pressing 'Ctrl + C' will place a copy tool, similar to a blueprint in the cursor. You can use this select a number of entities to copy. Pressing 'Ctrl + V' will place a quick paste tool in the cursor, similar to a blueprint with items. You can use this to place as many copies of the things you copied as you like.
  • The quick copy and quick paste tools are not items. Pressing Q will simply clear the cursor and not return anything to the inventory.
  • The quick copy and quick paste buttons will also be shown in the main GUI, next to the action bar. Hovering over the paste button will show a tooltip of the blueprint that is currently in the 'clipboard'.
Comments:
  • Being able to use all the fast transfer shortcuts in the blueprint library makes it very consistent with a chest, but can lead to very nasty situations where one accidental click can transfer all the blueprints and books to your inventory, completely screwing the order and organization you had in the grid. At the same time "transfer everything" can be something some players might use often if they don't have many books.
Other:
  • The blueprint editor GUI should allow you to zoom and pan around to better inspect it. You can add buildings while holding an item or ghost item from the action bar; for convenience a small interface will give you the possibility to place any ghost item in the cursor. This is intended for quick corrections. Things like connecting cables or changing entity settings will not be possible; for bigger changes use the Reassign button.
  • The blueprint library button will be disabled until bots are researched or until any item is added to the library for the first time. This means less GUIs for new players to get lost in, also less of an invitation to use the controversial string importing at the beginning for the game.

Usually I create a very crude and simplified MS Paint mockup of any changed GUIs.


I use all this, the design document and mockup, to present the idea to the other devs, make some changes, and if we all mostly agree with it, all this goes to Albert so he can more thoroughly design the look and arrange all the GUI elements. There is usually a lot of back end forth between us so we can properly tie UI and UX together. After the mockup is finished, one of the programmers, usually Oxyd, Dominik or I(Twinsen) start putting it in game, with the help of kovarex who makes sure AGUI has all the new functionality we need in the back-end. After we have the interaction in the game and we are able to play with it, there is of course further tweaking.

Well, the process I wrote about is the ideal case, in reality every different part of the UI is done slightly differently, especially since we are still at the beginning and we are still trying to figure out the concepts of the GUI, but I hope we will be able to use this pipeline to go though the GUI like butter.

Let us know what you think of the proposed changes to blueprint on our Forum.
19 件のコメント 詳細を見る
全てのスレッドを表示

このゲームの掲示板でバグを報告したりフィードバックを残そう

このゲームについて

Factorio は工場を作り、維持するゲームです。

資源を集め、技術を研究し、施設を建て、生産を自動化し、敵と戦いましょう。

木の伐採も、鉱石の採掘も、ロボットアームやベルトコンベアを作るのも、最初は自分の手で行います。しかしすぐに、広大なソーラーパネルや、石油の精製分解施設、自動生産施設を備え、建築や物流にロボットを駆使する巨大な産業プラントを作るでしょう。

そのような惑星資源の搾取を、原住生物は見逃しません。あなたの作った機械の王国は、自分の手で守らなければなりません。

マルチプレイヤーゲームで他のプレイヤーと協力し、友人と分担して巨大な工場をつくりあげましょう。

MODを導入すれば、さらに楽しさは広がります。ちょっとした調整やヘルパーツールから、ゲーム全体を刷新するものまで、Factorioは最初期からMODをサポートしており、世界中のクリエイターから魅力的で革新的なものが寄せられています。
ゲームはフリープレイを主体としていますが、様々な面白いチャレンジを収録したシナリオパックもあります。これは無料DLCとして入手できます。

もし面白そうなマップやシナリオが見つからなくても、インゲームマップエディタを使って自分で作ることができます。地物や敵を設置し、地形を望むままに書き換えましょう。望むならば自分でカスタムスクリプトを書くこともできます。

安売りはしません: 私たちは予見可能な将来において、セールや値下げを行う考えはありません。

プレイヤーの声


  • No other game in the history of gaming handles the logistics side of management simulator so perfectly. - Reddit

  • I see conveyor belts when I close my eyes. I may have been binging Factorio lately. - Notch, Mojang

  • Factorio is a super duper awesome game where we use conveyor belts to shoot aliens. - Zisteau, Youtube

システム要件

Windows
Mac OS X
SteamOS + Linux
    最低:
    • OS: Windows 10, 8, 7, Vista (64 Bit)
    • プロセッサー: Dual core 3Ghz+
    • メモリー: 4 GB RAM
    • グラフィック: 512MB Video Memory
    • ストレージ: 1 GB 利用可能
    • 追記事項: Low sprite resolution and Low VRAM usage.
    推奨:
    • OS: Windows 10, 8, 7 (64 Bit)
    • プロセッサー: Quad core 3Ghz+
    • メモリー: 8 GB RAM
    • グラフィック: 2GB Video memory
    • ストレージ: 1 GB 利用可能
    最低:
    • OS: macOS High Sierra, Sierra, OSX El Capitan, Yosemite, Mavericks
    • プロセッサー: Dual core 3Ghz+
    • メモリー: 4 GB RAM
    • グラフィック: 512MB Video Memory
    • ストレージ: 1 GB 利用可能
    • 追記事項: Low sprite resolution and Low VRAM usage
    推奨:
    • OS: macOS High Sierra, Sierra, OSX El Capitan, Yosemite, Mavericks
    • プロセッサー: Quad core 3GHz+
    • メモリー: 8 GB RAM
    • グラフィック: 2GB Video memory
    • ストレージ: 1 GB 利用可能
    最低:
    • OS: Linux (tarball installation)
    • プロセッサー: Dual core 3Ghz+
    • メモリー: 4 GB RAM
    • グラフィック: 512MB Video Memory
    • ストレージ: 1 GB 利用可能
    • 追記事項: Low sprite resolution and Low VRAM usage
    推奨:
    • OS: Linux (tarball installation)
    • プロセッサー: Quad core 3GHz+
    • メモリー: 8 GB RAM
    • グラフィック: 2GB Video memory
    • ストレージ: 1 GB 利用可能
カスタマーレビュー
大量のレビューが検出されました:
除外対象  あるいは  表示対象
レビュータイプ


購入タイプ


言語


期間
特定期間内のレビューを表示するには上のグラフをクリック&ドラッグするか、棒グラフをクリックしてください。

グラフを表示



表示:
レビューベータ NEW!
有効にすると、新機能の有用性スコア順にレビューを並び替えます。詳細はブログ記事をご覧ください。
グラフを表示
 
グラフを非表示
 
フィルター
有用性レビューベータが有効になりました
上記のフィルタに当てはまるレビューはこれ以上ありません
他のレビューを見るためにフィルターを調節する
レビューをロード中...