原文：https://forums.unrealengine.com/showthread.php?54448-Best-Practices-For-Running-On-The-PS4
Hey guys,
Since there are multiple ways to run your game on PS4 there's been some questions about best practices. Also a bit of confusion about how everything works. I wanted to write up a definitive post to lay out all the options, how stuff works, and my recommendations.
If there are any questions or something isn't clear, please let me know and I'll update the post.
Before I start I want to define a few terms:
- Cooking : The process of turning cross-platform editor assets into platform-specific runtime assets.
- Staging : The process of creating a directory on the PC which holds the runtime filesystem for your game. Necessary for packaging or deployment. When using UAT it is specified with -stage
- Packaging : The process of creating a .pkg for installation on the PS4/device. When using UAT it is specified with -package
- StageDir : This is the directory on your PC where the filesystem for your game is copied (staged) prior to packaging or deployment. It will be located under /YourProject/Saved/StagedBuilds/PS4
- Deploy : The process of copying the StageDir to the device. (to /data/). Note that this is very different from installing a .pkg. Deployment simply copies files to /data/ for faster reading, it will not create a runnable application in the PS4 frontend.
- UAT : "Unreal Automation Tool". The project in Visual Studios is just listed as 'Automation Tool'. This tool has many uses and is the supported method to create cooked builds for packaging or deployment.
- /data : /data refers to the development-only data directory on the PS4's local harddrive. When passing paths to OS file functions (sceFios*) paths rooted at /data/ will read/write to the local device. See SCE/Orbis/documentation/pdf/en/SDK_doc/1st_read/Programming_Startup_Guide.pdf for more info.
- /app0 : /app0 is the root path for reading files in shipping titles. However, in development it refers to the 'Working Directory' that you can set in Visual Studio, or in PS4 Neighborhood when launching from there. Not that this is NOT the same as 'File Serving Directory'. In an installed .pkg /app0 is the .pkg root. Again see the Startup_Guide for more info.
- O drive : The PS4 SDK maps PS4 harddrives as O:/SomeIP/data/. You can access deployed files, or logs/screenshots written locally at runtime from here.
- UFE : "Unreal FrontEnd". A work-in-progress tool to make launching games simpler. GUI application that helps avoid everyone having to deal with commandline tools.
With that out of the way, let's go over the various methods of running a game.
1. Deploy and Launch from the Editor
Also known as 'LaunchOn'. To do this you simply click the dropdown on the 'Launch' button in the editor and select your PS4.
What it does:
This method is the simplest, but currently the slowest for iteration. This process will use UAT to cook, stage, and deploy your game. It will then launch it for you with a commandline to load to the map you currently have open in the editor. This method was GREATLY improved in 4.7. The deploy is now 'iterative' so subsequent launches should only deploy modified data and be much much faster.
Internally it uses the SDK application orbis-run to launch the game. The working directory is set to YourProject/Build/PS4 so the OS can find any Trophy or Save data config files you may have.
Advantages:
- Simple.
- Guarantees that content changes are in your build. Good for content creators in this way.
Disadvantages:
- Possibly still too slow for iteration on very large projects.
Recommended Use:
- Content Creators on small to medium sized projects.
2. CookOnTheFly Server
What it does
Rather than cooking all of your content up front and staging/deploying it, you can run a server which the game will connect to and request files as needed. To launch such a server you must build your project under the 'Development Editor / x64' configuration.
The server can be started by running UE4Editor.exe with a commandline to set up cookonthefly.
e.g. "UE4Editor.exe "C:UsersMarcus.WassmerDocumentsUnreal ProjectsUDNParticlesUDNParticles.uproject" -run=cook -targetplatform=PS4 -cookonthefly -log"
The server will start up and then simply wait for connections. As requests come in, it will cook requested files as necessary and serve them to the target.
When launching the game executable you must pass -filehostip=YourPCsIP as one of the parameters. This has several effects on the game runtime.
- Files loaded by the engine go through the file server and are cached locally on /data/
- Files will only be read by the engine from /data/ never /app0. The network file system simply copies files over the network to /data/ where they are finally read by the filesystem.
- Cached files will be reused if possible on subsequent runs, saving you network copy time.
- The OS will still automatically read certain system files (like trophy files) from /app0. These can't be served by the COTF server, so it's important to still have a valid Working Directory set if your title has implemented trophy support. The generated Visual Studio project will automatically set the WorkingDirectory to YourProject/Build/PS4. System files should go here. See ShooterGame for an example.
You can use CookOnTheFly when launching from Visual Studio, from PS4 Neighborhood, or from UFE.
Advantages:
- Initial launch time is faster than LaunchOn because you're only dealing with data you currently need.
- If you leave the COTF Server running then all files will remain cached on /data/ and subsequent runs will simply read from local files.
Disadvantages:
- Content changes require a restart of the COTF Server. If you do not pass -iterate when starting the server, the entire Cooked directory will be wiped and regenerated. However, -iterate does not have perfect dependency checking and can miss changes in some cases. -iterate is still being improved. If your content changes do not show up, try running the cooker again without -iterate
- At boot there is time spent communicating with the server to clear any out of date files from the /data/ cache. This time scales with the size of the project.
- Not available for Shipping/Test Builds.
Future Work
- -iterate will be made reliable
- The regular editor will be an active COTF server, so in the future you will not have to start a separate process for it.
Recommended Use:
- Programmers on large projects that need to do targeted testing and don't want to wait for the whole project to cook.
- Content Creators (using UFE to actually manage launching everything)
3. Reading from a Staged Directory
What it does:
This method requires the most manual setup, but is probably the second best for programmer iteration at the moment. The first step is to generate a StagedDir for you game that has a valid runtime filesystem. There are various ways to do this (packaging the project from the editor, using UFE) but they all simply run a UAT command for you. You can use UAT to stage a build for you like this:
"D:devUE4EngineBuildBatchFiles>RunUAT BuildCookRun -project="D:WorkingUE4SamplesGamesShooterGameShooterGame.uproject" -ps4 -cook -stage -pak -cmdline=ShooterEntry -clientconfig=Development"
Such a command would generate ShooterGame/Saved/StagedBuilds/PS4/... with all the necessary files to run.
You can then set the Working Directory in the Visual Studio debugging params to this directory. The game will then treat this directory as /app0 and it should run without any other fuss. However, there is one gotcha here. The existence of a ue4commandline.txt file in the root of /app0 is used to decide to use /app0 as the file root. (See PS4Launch.cpp), so always add a -cmdline=yourstartupmap to your UAT command to generate one. (Or you can simply place a blank one in the directory yourself). This process will be improved in the future.
Again, you use either Visual Studio or PS4 Neighborhood to launch your game like this, you simply must set the Working Directory appropriately after UAT completes staging.
Advantages:
- Very fast iteration if you aren't changing content.
- No startup time penalty from talking to cookserver / checking cached files.
Disadvantages:
- Very manual setup.
- Slower load times than reading from data deployed to the O: directly because you're reading over the network.
- Easy to run with out of date content if you forget to re-stage your build.
Recommended Use:
- Programmers iterating on large projects with infrequent local content changes that are willing to trade longer load times to avoid an initial deployment period.
4. Reading only from Deployed Data
What it does:
This method is only for programmers. You must first get your data deployed onto the O: of the PS4. This can be done by using LaunchOn, running once with CookOnTheFly until you have cached all necessary data, or using a UAT commandline such as:
"D:devUE4EngineBuildBatchFiles>RunUAT BuildCookRun -project="D:WorkingUE4SamplesGamesShooterGameShooterGame.uproject" -ps4 -cook -stage -pak -deploy -device=YourPS4Name -cmdline=ShooterEntry -clientconfig=Development"
Once the data has been deployed, when you run your game from VisualStudio simply pass -deployedbuild as a commandline argument to the game. The engine will now ONLY load data from the PS4 harddrive's /data directory. There is NO initial cost from talking to a cookserver, and there is no cost from reading files over the network. This will give you the fastest iteration times if your content is not changing. Be aware if you use cookonthefly for your initial deployment that you will ONLY be able to load content that you loaded during your COTF session. For example, if you use COTF and load Level1, then do a -deployedbuild run you will not be able to load Level2.
Advantages:
- Very fast iteration if you aren't changing content.
- No startup time penalty from talking to cookserver / checking cached files.
- No penalty for reading files from the hostpc.
Disadvantages:
- Easy to miss data you will want later if you use CookOnTheFly to cache the data.
- Initial deployment time to copy all files to the PS4.
- Easy to run with out of date content if you forget to re-deploy.
Recommended Use:
- Programmers iterating on any project with infrequent local content changes.
Conclusion
TLDR:
- Content Creators: LaunchOn for small projects, for larger projects Use UnrealFrontEnd to do CookOnTheFly.
- Programmers: Use COTF or Deployed Data directly.