Additional Information/The File System

ファイルシステムThe File System

GameMaker Studio 2でファイルシステム機能またはインクルードファイルを使用するとき、すべてがどのように機能するのか、そして舞台裏でどんなことが起こっているのかを正確に知ることが極めて重要です。そのために、このセクションでは、物の保管方法、保管場所、およびこのシステムに対する可能性のある制限または回避策について、正確に説明および明確化することを目的としています。

The Sandbox

ファイル関数に関して注意すべき最初で最も重要なことは、一般に、それらがサンドボックスに限られているということです。つまり、GameMaker Studio 2は、ユーザーからの明示的な入力がないと、ゲームバンドルやデバイスのローカルストレージの一部ではない場所からファイルを保存またはロードすることはできず、その場合でもこの入力のターゲットプラットフォームはWindowsおよびMacのみに制限されます。

まず最初にサンドボックスを理解するには、ファイルには2つの異なる領域があることを理解する必要があります。

ファイルバンドル（The File Bundle） - GameMaker Studio 2 IDEの[含むファイル]リソースリストに追加したファイル（パッケージに含める外部ファイル）を含む、実行可能ゲームにパッケージされているすべてのファイルが保存されている場所です。ゲーム）。
The File Bundle - this is where all the files that are packaged with the executable game are stored, including the files that you have added to the Included Files resource list from the GameMaker Studio 2 IDE (which are the external files that you want packaged with the game).

保存領域（The Save Area ） - これはゲームによって安全に書き込まれることができるデバイスストレージの領域であり、ゲームはこれが書き込み可能な領域であることが保証されています。
次の図は、これを視覚化するのに役立ちます。

注：ファイルバンドルディレクトリに書き込むことはできません。

ファイル関数の使用　Using the File Functions

2つのターゲット領域（バンドルディレクトリとローカルストレージ領域）は、各ターゲットプラットフォームで使用できますが、それぞれの動作は多少異なります。ただし、GameMaker Studio 2では、できることとできないことの主な本質が抽象化されているため、ゲームを複数の環境にターゲット変更するのが簡単になります。

まず最初に、working_directoryについて話すときに何が意味されるのかを理解する必要があります。これは2つの保存可能な場所（上の図で示されているように）の同義語であり、そのディレクトリを使用するとき、読み書きしているかどうか、そして（変更されたか、変更されていない）ファイルが読み込んでいるいるかによって異なります。

• 読み取り操作 - working_directoryは、最初に保存領域を調べて、アクセスされているファイルがそこにあるかどうか、またそれを使用しているかどうかを調べます。ただし、ファイルが保存領域に存在しない場合は、ファイルバンドル領域を確認してそれを使用します（探しているファイルがゲームに含まれるファイルである場合）。
   
• 書き込み操作 - これは保存領域でのみ発生する事ができます。
  注：一般に、GameMaker Studio 2がこれらすべてを処理するので、組み込みの変数working_directoryを使用する必要はほとんどありません。
  これら2つの単純な規則を使用して、次の関数がどのように機能するかを確認できます（これらは、使用可能なさまざまな関数のプロセスを視覚化するのに役立つ例です）。
   
• directory_create（およびその他のディレクトリ関数）は保存領域でのみ機能します。
   
• ファイルシステム関数は、ファイルバンドルと保存領域の両方からファイルに関する情報を返しますが、保存領域にのみ書き込みます。
   
• テキスト、バイナリ、またはINIファイルを書き込むための関数は、存在しない場合は保存領域に新しいファイルを作成し、ゲームバンドルに含まれる元のファイルから情報をコピーします。元のファイルは保存ディレクトリの読み取り専用部分に残ったままですが、保存領域の読み取り/書き込みセクションにバージョンが存在する限り参照されません。

• the functions for writing text, binary or INI files will create a new file in the save area if one does not already exist, copying over any information from the original files included with the game bundle should they exist. Note that the original files will still remain in the read-only part of the save directory, but they won't be referenced as long as a version exists in the read/write section of the save area.
   

Saving And Loading Outside The Sandbox

WindowsおよびMac OSプラットフォームでは、サンドボックスの外部からファイルを保存およびロードする方法が1つあります。それは、関数 get_open_filename および get_save_filename を使用することです。これらの機能はどちらもユーザーが読み込みと保存のために領域を選択することを必要とし、そして戻り文字列はサンドボックスを迂回するために残りのファイル機能で使用することができます。詳細については、マニュアルのスクリプト作成セクションにある機能の説明を参照してください。

HTML5では、サーバーからサンドボックスの外側からファイルをロードすることも可能ですが、ほとんどのブラウザでは同期的にロードすることは推奨されなくなり、最終的には廃止されるため、これは関数 buffer_load_async() を使用してのみ行われるべきです。つまり、この方法でロードされているファイルはバイナリファイルとして保存する必要があります。
たとえば、*。iniを文字列として保存し（詳細は ini_close を参照）、非同期関数を使用して、保存もしくは読み込まれたバッファにそれを書き込めます。もしあなたが sprite_add を使用して画像をロードしている場合、これらは既に非同期的に処理されています。
br

プラットフォーム固有の保存/読み込み

GameMaker Studio 2で作業するとき、あなたはそれぞれのターゲットプラットフォームがファイルとディレクトリが読み書きされることができるそれ自身のセーブエリアを持っていることを知っているべきです。以下は、各ターゲットのそれらの領域のリストです。

• Windows and Windows UWP- Windowsはすべてのファイルを %localappdata%\<Game Name> ディレクトリに持っています（Windows 7ではこれは /Users/<User Name>/AppData/Local/<Game Name> ディレクトリです）。
   
• HTML5 - すべてがローカルストレージを介して行われます。
   
• Mac OS - ストレージは、アプリケーションがサンドボックス化されているかどうかによって異なります（通常、パスは ~/Library/Application Support/<Game Name> のパスを使用します).
   
• Ubuntu (Linux) - Files are stored in the Home/.config/gamename where "Home" is the users home directory - /home/<username>
   
• iOS - ストレージは標準の場所です（iTunesから見た場合）。
   
• Android - ファイルは標準の場所にあります（デバイスがルートになっていない限り表示されません） /data/<package name>.
   
  HTML5のターゲットモジュールはローカルストレージに制限があることに注意する必要があります（ブラウザによっては1MBから5MBの間です）。大きなスプライトやスクリーンショットなどを保存することは許可されません。
   
   
  Back: Additional Information Index
  Next: Using Buffers

The File System

When using the file system functions or included files with GameMaker Studio 2 it is vitally important to know exactly how everything works and what things are going on behind the scenes. To that end, this section is designed to explain and clarify exactly how things are stored, where they are stored and what possible limits or workarounds there may be to this system.

The Sandbox

The first and most important thing to note about the file functions is that they are limited - in general - to the sandbox. What this means is that GameMaker Studio 2 cannot save or load files from anywhere that is not part of the game bundle or the local storage for the device without explicit input from the user, and even then this input is limited to only Windows and Mac target platforms.

To understand the sandbox first of all you need to understand that there are two distinct areas for files:

The File Bundle - this is where all the files that are packaged with the executable game are stored, including the files that you have added to the Included Files resource list from the GameMaker Studio 2 IDE (which are the external files that you want packaged with the game).

The Save Area - this is an area of device storage that can be safely written to by the game and the game is guaranteed that this is a writeable area.
The following diagram may help you to visualise this better: File System Save Areas

NOTE: You can never write to the File Bundle directory.

Using the File Functions

The two target areas - the bundle directory and the local storage area - are available on each target platform, but on each one they will work slightly differently. However GameMaker Studio 2 has abstracted out the main essence of what can and can't be done, making it easier to re-target games to multiple environments.

To start with, you should understand what is meant when we talk of the working_directory. This is a synonym for the two possible save locations (as illustrated by the diagram above) and when you use that directory it will do one of two things depending on whether you are reading or writing, and whether the file you are reading from has been changed or not:

• Reading Operations - working_directory will first check the save area to see if the file being accessed is there, and if it is uses that. However if the file does not exists in the save area, it then checks the file bundle area and uses that (if the file being looked for is an included file with your game).
   
• Writing Operations - This can only happen in the save area.
  NOTE: in general GameMaker Studio 2 will handle all this for you and you rarely need to use the working_directory built in variable.
  Using these two simple rules we can now see how the following functions work (these are examples to help you to visualise the process for the different functions available):
   
• directory_create (and the other directory functions) will only work in the save area.
   
• the file system functions will return information on files from both the bundle and the save area, but will only write to the save area.
   
• the functions for writing text, binary or INI files will create a new file in the save area if one does not already exist, copying over any information from the original files included with the game bundle should they exist. Note that the original files will still remain in the read-only part of the save directory, but they won't be referenced as long as a version exists in the read/write section of the save area.
   

Saving And Loading Outside The Sandbox

On the Windows and Mac OS platforms there is one way to save and load files from outside of the sandbox and that is using the functions get_open_filename and get_save_filename. Both of these functions will require that the user select an area for loading and saving and the return string can then be used in the rest of the file functions to bypass the sandbox. See the function descriptions in the scripting section of the manual for more details.

On HTML5 it is also possible to load files from outside the sandbox from a server, however this should only be done using the function buffer_load_async() as loading synchronously has been deprecated on most browsers and will eventually be obsoleted. This means that files being loaded in this way should be saved as binary files - for example, you can save an *.ini as a string (see ini_close for details) and then write that into a buffer which can then be saved and loaded using the async functions. Note that if you are loading images using sprite_add then these are already dealt with asynchronously.

Platform Specific Saving/Loading

When working with GameMaker Studio 2, you should know that each target platform has its own save area where files and directories can be written to and read from. Below is a list of those areas for each target:

• Windows and Windows UWP- Windows has all files in the %localappdata%\<Game Name> directory (on Windows 7 this is the /Users/<User Name>/AppData/Local/<Game Name> directory).
   
• HTML5 - Everything is done through the local storage.
   
• Mac OS - Storage will depend on whether the application is sandboxed or not (following Apples rules, with the path usually being ~/Library/Application Support/<Game Name>).
   
• Ubuntu (Linux) - Files are stored in the Home/.config/gamename where "Home" is the users home directory - /home/<username>
   
• iOS - Storage is the standard location (as viewed through iTunes).
   
• Android - Files are in the standard location (which is invisible unless the device is rooted) /data/<package name>.
   
  It is worth noting that the HTML5 target module has a limit on local storage (which can be between 1MB and 5MB depending on the browser) meaning that you will not be permitted to save large sprites, screenshots etc...
   
   
  Back: Additional Information Index
  Next: Using Buffers
  © Copyright YoYo Games Ltd. 2018 All Rights Reserved