Publish game features

[Josh]

This is the interface for the standalone publishing option for Leadwerks:

We have not talked in much detail about what features the Ultra publishing system should support. I plan to use encrypted zip files, and some people have requested splitting the zip archives up into multiple segments, or zipping each folder up separately.

What are your ideas?

[SpiderPig]

1 minute ago, Josh said:

some people have requested splitting the zip archives up into multiple segments, or zipping each folder up separately.

I've found this is needed for uploading to Steam.  When you encrypt / compress one large zip file and change only a small file in that zip, the zipping algorithm must be changing all the bytes of the zip file, because the Steam uploader will upload the entire zip again, no matter the size.  It makes creating small updates for your game impossible.

[Josh]

I think the safest way around this would be to put files in multiple zip archives with a fixed size limit, like data1.zip, data2.xip, etc., with a user-adjustable size limit. If we make a spanned archive, it would probably have the same problem as a single archive, where all the bytes change and the whole thing has to be uploaded.

[SpiderPig]

Another option for the publisher would be to exclude certain files.  Like "exe" should be included but "_d.exe" should be excluded.  Sometimes we might want to publish the debug stuff and other times not.  Even being able to save certain publish configurations would be nice.  We could change between a debug publish config and a release publish config.

[reepblue]

I would like to have the publisher to be an extension or an open-source application.  If it's an application separate from the editor, people can make builds of their games without launching the editor by running it through a command line. 

Different people have different needs. I recommend making a generic packager and allowing end-users to modify if needed. One thing I'm liking about Ultra Engine over Leadwerks is that the editor is more configurable. Please keep going with this! 

[Josh]

The only part that really needs to be done in C++ (for speed) is the file scanning. In Leadwerks, this starts with scene files, then checks scene files and find materials and models, then checks those models and finds more material files, then checks the material files and finds texture files. A function could be added in the editor API, something like ScanProjectFiles(), and that could return an array of file names.

CreatePackage, Package:AddFile, and Package:Close are exposed right now in the Lua API, although I have not tested these commands extensively.

[Josh]

First pass at this:

 

[Alienhead]

Will this system eventually omit files not in use ? ( ala leadwerks ) 

[Josh]

Yeah, that is the idea. It's a little tricky because Ultra can have extended support for new file formats the publishing system doesn't know how to handle. I am trying to implement the whole scanning system in Lua now so that it can be modified if needed...