Game content pipeline for Node.js
npm install contentjs
|4||downloads in the last month|
|Version||1.1.1 last updated a year ago|
|Keywords||asset, content, pipeline, game, tool|
A streamlined, minimalistic game content pipeline built on Node.js. The library and tools can be set up to monitor multiple source directory trees for changes, and on command, execute data compilers for each modified file. The intent is to provide rapid iteration for game content while minimizing errors that might result from manually running a series of separate tools.
Currently, the filesystem watching functionality is not implemented. Instead, the core functionality is exposed as a set of command-line tools for compiling resources and then archiving them up into single files for efficient transfer and loading.
npm install -g contentjs
This installs a number of utilities accessible from the command-line.
Content.js is a toolset, not a Node module. When installed, a number of command-line utilities become available:
buildimplements the core content build process.
publishbuilds archives for each resource package.
For each utility you can specify
--help to see the command-line options.
The tools operate on a top-level entity referred to as a content project. This is nothing more than a root directory under which all source content is located. A content project has the following basic directory structure:
project_name/The root content project directory.
database/Stores all generated content database information.
packages/The root directory for all resource packages.
processors/The root directory for all data compilers.
pipeline.jsonThe content pipeline definition file.
platform.jsonThe set of recognized platform names.
publish.jsonConfiguration data for the
Most of the work occurs under the
packages directory. Within the
packages directory, source content packages are defined. Each content package is a directory with a name like
Core.source. The name of the content package is 'Core', and the '.source' identifies it as a source directory. Within the source content directory, you may organize files however you would like. The directory structure helps to define the name of the resource at runtime; for example:
Core.source/The source content package directory.
textures/The root textures directory.
brick.textureThe brick texture for the 'generic' platform.
brick.xbox360.textureThe brick texture for the 'xbox360' platform.
brick.ps3.textureThe brick texture for the 'ps3' platform.
At runtime, the 'Core' package would contain a resource named
textures/brick, which would contain the runtime data for the platform-specific version of the resource.
Resource identifiers consist of three parts, a name, zero or more properties, and a type. This data is all encoded in the file path:
- Name: The name portion is the relative path and filename of the resource, with any extension components removed. The path is relative to the resource package root.
- Properties: The properties are all of the dot-separated extension portions of the filename, not including the final extension component. Properties may be anything you desire and are available at runtime.
- Type: The resource type is taken as the final extension component of the filename.
For example, given a root content project path
/Users/foo/project, with a resource package at
/Users/foo/project/packages/Core.source, and a file within that package at
textures/armor.battered.ps3.texture we have:
- A resource name of
- Two properties,
- A resource type of
Platform identifiers may be any string you wish. Edit the
platform.json file to define your platform identifiers. This JSON file contains a single array of string values, each of which represents a single platform identifier:
[ 'xbox360', 'ps3' ]
These identifiers will then be automatically recognized when they appear as part of the resource filename extension list, for example
Additionally, code is included to manage the downloading of these manifest and package files. The HTML5 IndexedDB API is used to cache downloaded packages on the client, speeding load times and allowing offline access while still allowing for content updates.
The following items remain TBD or fixed:
- Need to implement the clean tool to delete all target packages.
This is free and unencumbered software released into the public domain.
Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.
In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
For more information, please refer to http://unlicense.org/