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

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

早期アクセスゲーム

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

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

開発者からの注意書き:

早期アクセスにした理由

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

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

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

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

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

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

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

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

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

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

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

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

Factorio を購入する

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

 

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

7月20日

Friday Facts #252 - Sound design & Map editor

New sound design
Val: Do you remember the smell of the fresh air near the seashore? Can you describe, a forest that rumbles its trees after a summer rain? All that you hear and see goes right into your mind. All of our senses are connected with each other in our memories. When we feel at least one of them, our imagination brings the others. Sometimes, and even often, we can't see the object, but we can hear it! You can't see the wind, but you feel it and hear it! The bird is singing. You can't see it hiding in a bush, but you hear a beautiful song and can define the direction it comes from.

The forest, the sea, the desert... Night and day. Clanking of a loading cannon and snoring of unseen monsters. That is what we are planning to do. To put the unseen colors of sound and add some feeling of life to the planet of Factorio. Even the emptiness has it's own voice...

Albert: As you probably know, we are in a stage of polishing all the possible aspects of the game.

Last week we were cooperating with Val, our new sound designer, and we spent the entire week defining new concepts for environmental sounds and sound effects. Also we were working on the sound of the biter nests and the artillery cannon. This is definitely a huge subject full of details that can really improve the play experience of Factorio. Here I can show you a work in progress of the artillery cannon:

https://us2.factorio.com/assets/img/blog/fff-252-artillery-cannon.mp4

We have to tweak some behaviour of the entity in order to make it act more mechanical, but overall, the possibilities that sound design can bring to the game are really interesting. Compare the simple shooting of the cannon in the actual version with this proof of concept with all those details in rotation and loading. Of course this level of detail complicates the work a little bit, but I'm convinced it's worth it.

Spawners redesign in HR
We are also working in parallel with Ernestas, who is improving the look of the enemies. Right now we can show a sneak peek of how the new spawners look in HR. Together with TOGoS, we are working in a more specific map generation in order to improve the composition of the nests. The intention is to generate a special ambience for those areas that makes you feel like you are in enemy territory.



Everything here is a work in progress, let us see how we end up with all those plans. Soon I'd like to show how the nests look with the animations, the ambience, and all the biters and worms around.

Nobody uses the Map editor
Factorio has had a Map Editor since the early stages of development. It was initially used to create the current campaigns and scenarios, and from time to time we would use it to help diagnose desyncs. However, as development continued the Map Editor seemed to have been forgotten.

Inside the Factorio engine, almost every game GUI/action is associated with the player that is looking at the GUI and doing the action. This makes sense because when the game is running everything is done by a specific player, and GUIs need to know stuff about that player. When actions are processed the game applies them to a specific player in the world, and handles stuff like multiplayer syncing of actions done by different players. In the Map Editor there is no "player" - there is just the editor - and this has caused a massive divide in what the editor can do compared to the main game.

Because the Map Editor has no 'player' it can't use any of the action processing logic the normal game uses, and instead uses a large copy-paste of the action processing and attempts to apply it to the map knowing there's no player associated. This 'works' for the most part, but some actions are inherently tied to a player and simply don't work in this disassociated context. Having this split of 'game' and 'editor' means we had to essentially write any action processing logic twice: once for the game, and once for the editor. Most people skipped the second part and so the editor fell behind. From time to time someone would report a problem with it, or ask if we could add some new functionality (or even if it could just do what the normal game could do). The internal joke was always "Nobody uses the Map Editor" to explain-away why it was so lacking.

When 0.17 tasks where being assigned, the topic of the Map Editor was brought up and I (Rseding) indicated I would be interested in working on it. Knowing what the problems where and how I wanted to go about fixing them I started. Several months of work (and several false-starts) later, I now have a 90%-there new Map Editor.

The new Map Editor has several key differences over the old one:
  • I removed the separation of 'normal game' and 'map editor'. The Map Editor is built right into the standard game logic. Anything the normal game can do it can do automatically. For those familiar with Factorio's modding: it's a new controller like the 'god controller', called 'editor controller'.
  • The standard interaction mechanics of the normal game 'just work' in the Map Editor (Hotkeys, QoL shortcuts, Pipette tool, etc.).
  • The Map Editor can be toggled on and off while playing any game. You no longer need to save, exit the game, go to the map editor, convert-save-to-scenario, and then finally load-in-map-editor. You can just be playing the game and switch to the editor (and back).
  • The Map Editor is multiplayer compatible: It doesn't make any distinction between singleplayer and multiplayer - it just works for both.
  • The Map Editor can pause/unpause the normal entity update but still interact (in multiplayer as well). Non-map-editor players are frozen in place but can still talk, switch to/from the editor, connect, and disconnect from the game.
  • The Map Editor is King. Anything you want to do, it lets you do (if I thought of it), at no point during development did I decide "No, you just can't do that with the editor - it would be too powerful". The point of it is to be powerful.

https://us2.factorio.com/assets/img/blog/fff-252-editor-switch.mp4

After replicating the functionality of the old editor, I started working on new features that have been requested by community and other team members:
  • A new cloning tool to copy entities/decoratives/tiles in any combination from one area (and surface) to another. This copies almost everything about the entity - items, recipes, variations and so on:

https://us2.factorio.com/assets/img/blog/fff-252-copy-paste.mp4

  • A paint-bucket tool for painting tiles that would paint-bucket replace all tiles of a specific type under the mouse:

https://us2.factorio.com/assets/img/blog/fff-252-paint-bucket.mp4

  • Extending the force-editor to create/remove/edit forces fully.
  • Extending the entity-editor to let you place entities on other forces than the defaults.
  • Extending the decorative editor to have more fine-grain control of placing/removing without needing to know the exact decorative you're looking at.
  • Controlling the simulation rate and controlling tick execution.

https://us2.factorio.com/assets/img/blog/fff-252-time-control.mp4

Finally what I see as the ultimate request: "Ability to Copy & Paste an area from 1 map to another, transferring tiles/doodads/biters/trees/entities/items/...". The key part being "from 1 map to another" meaning "let me import stuff from other save files". I have a plan to make this work, but it will be restricted to single-player only. Still, I can see it being incredibly powerful when finished.

In summary: there is still more work to be done but the new Map Editor is coming together amazingly. I'm looking forward to what people will create/do with the new power the new Map Editor will bring. For us it will greatly speed up the work on the new campaign maps.

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

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.
36 件のコメント 詳細を見る
全てのスレッドを表示

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

このゲームについて

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