PAK files are compressed archive files, very similar to .zip archive files. The PAK file format is used to compress large files or volumes of files into a single archive folder.; this makes it easier to distribute the files or download the files from the internet.
For example, if you have fifteen different files that you would like to send to someone, you can send them in a PAK file archive rather than email the files as fifteen different attachments.
The PAK file format is commonly used for video games, like the Quake and Half-Life computer gaming applications. These game file archives contain the graphics, sounds, objects, textures and other game details that are needed to run the game on the computer.
- Initial download of builds is relatively faster when in PAK format.
- All (necessary) assets are available in one place.
- A fully working project is obtained (projects can also be flagged as "not working", "stable", etc.).
- Can be tricky to identify which files are present inside the PAK file, and perform copy/pastes, renames, etc.
- Not easy to submit PAK files to a version control system.
Working with PAK Files
Crytek uses a combination of Python scripts running into our Continuous Integration (CI) system with the Resource Compiler in order to generate PAK files. This allows us to easily manage the content and configuration of a PAK file using an XML file
- To generate PAK files, you need to run the Resource Compiler (Tools/rc/rc.exe in your CRYENGINE project) and pass a few arguments.
- An example config XML file is game_assets.xml (../Tools/CryVersionSelector/rc_jobs/game_assets.xml), which specifies the assets and how they are packaged.
Here is an example python script, buildAssets.py, which contains multiple arguments and serves as the first step in building assets and generating a PAK file:
Next is a real sample from the rc.exe command line where:
- The first argument passed is the path of Resource Compiler;
/jobargument passes the XML file for configuration;
/trgspecify the source of the original assets and the destination of the packaged assets respectively, followed by other arguments for configuration.
And finally an example build function from source code that:
- Calls the Resource Compiler;
- Checks the Version Control System and syncs the code;
- Checks if you use CMake or WAF as a build system, calling the corresponding script to run the build;
- Packages the 'code' and 'asset' targets, and runs the necessary scripts to include them in the correct directories.
How to Build a CRYENGINE Game?
The following chart shows the Jenkins build pipeline used for The Climb:
The main steps in this pipeline are:
- Kick: Project Configuration;
- Build: Divided into four sub-steps for building assets, shaders, and the code for the target system (PC in this example);
- Complete: This is where we check if everything was compiled correctly, before they are uploaded to the correct location on the network.
In Crytek we work with the following types of builds:
- Local Development Build
Local Development builds are generally used while developing features, to make sure the current implementation is working.
They simplify the workflow for developers that have to compile and run the code without needing the CI system, usually for tests or validation purposes; this is done using the Integrated Development Environment (IDE) or Command Line Interface (CLI) tools on the developer's machine, or on a remote machine which isn't a distributed system.
- Debug/Profile Build
Debug/Profile builds are slower builds with symbols that help the developer identify errors, attach breakpoints where necessary, debug on a PC or a console, analyze performance and have a better understanding of what is happening within the code. This is usually considered as a a performance/reliability build.
A Release build is a fully featured binary that is ready for distribution. It contains no symbols and debug or breakpoint information, but might include obfuscation, encryption and even compression.
Release builds are a reliable measure of performance; since they depend on optimized settings, i.e., the defined settings/configuration, you can achieve an optimized build that will run on the target platform with the best performance possible.See this documentation by Microsoft about optimization for a better understanding on the subject.
For every code submission into our Version Control System (VCS), we run a "lightweight" build to check if everything works as expected and to confirm that the code change did not introduce new problems.
- [Extra] Nightly Builds
A full build of our engine and/or the game that runs during the night. This one is heavily used by our QA team in order to test the current status of the product.
One of the biggest reasons to automate the build and deploy process is to speed up your development workflow and to reduce the number of possible failures. Below are some recommendations for your environment in order to have a healthy build system:
- Use a CI system like Jenkins.
- Do Test Driven Development (TDD) as much as possible and run the tests in parallel with your builds.
- Use your CI to deploy your game.
- Have a development, a stage and a production environment.
- Use cloud services if possible; host your infrastructure if needed.
- Containers are nice; ask your DevOps Team.
- Avoid Python 2.x and use Python 3.x. It is a good language for automation that we use in our production workflow.
Below you can find a simple example of our pipeline code that can be used as reference.
- The pipeline.groovy script is the starting point of the CI job:
- The jk.groovy script contains common functions that you can load into other scripts:
- The following Python script is where we have the heavy logic required for our builds.
Also in this example, jk.groovy and build_script.py are imported into the pipeline.groovy script and used in there.
Table of Contents
- No labels