Switch to a JSON-based format for .ssproj

[fatcerberus]

The implementation, as it is now, is simply a surrogate for the game.sgm file. The SGM is generated from the project automatically when the user clicks the Test Game button or makes an .spk package.

An .ssproj file is stored in true INI format:

[Animals]
maggie=hippo
Fattesty=cow
Machel=ape
FTG=hunger-pig

[WhatAreTheyDoing]
What=Preyin' on you
When=Tonight
How=Hunt you down
How2=Eat you alive

This makes the file easy to manipulate by the user while still providing some flexibility for organization. I have some questions, however:

• How are we handling directory structure? VS allows a project to be stored anywhere and reference files in any arbitrary directory, either relative or absolute. This is probably more flexibility than we need, but we do probably still need a standard for what is considered part of the project and what's not. So how should inclusion be specified in the .ssproj?
• Where is the project built? Currently game.sgm is generated alongside the .ssproj and everything else is identical to a normal Sphere game structure. This is probably not adequate for pipelining though, since project files will end up being included with the game that aren't actually part of it. I think you suggested dist/?
• How to track incremental builds. For a multi-megabyte game (think 50+ MB), copying all the files into the build wholesale every time the user clicks Test Game will get very inefficient. So a way to detect only those files that changed is needed. Maybe store the last build time in the .ssuser file and ignore any files older than that when building?

And... that's all my questions for now.

[Radnen]

So, the folder structure is like this:

\src
\src\images
\src\maps
\src\spritesets
\dist
\dist\images
\dist\maps
\dist\spritesets
\other
.ssproj

.ssproj reads /src as the development directory (it can be changed in the editor, the default is /src) the files in /src can be included in a repository along with .ssproj and the /other folder or anything else. /dist is created in the build (it can also be set in the .ssproj). Yes, the editor will copy the stuff from /src, but this is what many game editors already do. The reason for this is the pipeline. You might convert a font from a text-based file to an image-based file. Imagine only committing a font like this to the repo:

[font]
name=arial
size=16pt
stroke=True
color=#ffffff

Then it turns it into the binary data (.rfn or any other type) based on the processor. This technically means the editor is Sphere-agnostic. You could develop XNA games in it, allegro, whatever.

Ok, the decision to use INI will make it hard to track changes because it is flat. XML or JSON is better at organizing this. I lean toward JSON.

There are 4 states you can set a file in the editor.

1. Copy newest (uses date).
2. Copy always.
3. Copy never.

When you run that font.ini -> font.rfn processor as I outlined above, there must be a way to not re-run it each time. So if the original .ini file has never been modified, it shouldn't run it. If it has, go ahead and run the processors in the build.

So a file - every file - has these properties (so JSON would REALLY help here):

{
    "path": "/fonts/font.ini",
    "state": 1,
    "processor": "/other/font-proc.js",
    "date": "2015-7-18T10:20:15Z"
}

There might be more to it than that, so a filetype like JSON allows these to be "incomplete". Notice processor above, it's a filepath to a JS based processor, or it can be a string of the name of a processor registered to in the editor. It can be a plugin that introduces this processor. I want plugins to be everything for the editor even if they are as simple as editing a very basic C#-based processor. The state is 1 so, check new changes. And the date is stored in a clean ISO/UTC format.

[fatcerberus]

Ideally I'd also want an option to build in ~/Sphere Games, since that's where minisphere (as of 1.5.3) looks for games when GetGameList() is called.

[fatcerberus]

I definitely think we should switch to a JSON-based project system, but that's something for 2.0 I'd say. For now we should stick to the INI format as that's what's been used for a few minisphere bundles, breaking compatibility in a minor release probably isn't a good idea.

[fatcerberus]

Sphere Studio now has a dependency on Json.NET because it's required for source map support. Now would be a good time to implement this, I think.