Move to GitHub Pages?

[BenjamenMeyer]

This seems like something that would be awesome as a Git Hub page site.
Does that make sense?

[nabaco]

Yes it does, so would probably require moving the documentation into a different format.
The main question is, don't we create a redundancy together with vega-strike.org?
Or, in other words, what is the role of vega-strike.org in all of the project?

[BenjamenMeyer]

GitHub pages support doing custom domains (https://help.github.com/en/github/working-with-github-pages/about-custom-domains-and-github-pages) so we can work with whomever owns vega-strike.org to have a subdomain point (e.g docs.vega-strike.org) at the GitHub pages site.

I can't see anything in the GH information about a cost for using the custom domain. So I assume doing so is free. I haven't tried it on any of my repos yet.

[nabaco]

We need to think about how to host this with the existing site. Maybe placing this as a git submodule? Or on a separate site - vega-strike.org/docs? (GH supports that)

Additionally, to make this relevant - we need to see how we sync it with Assets-Production, so developers making changes there remember to update the documentation here.

I think the best would be to merge this into Assets-Production, and host it from there using gh-pages branch, and every change, just merge the master into the branch. (GH supports that too)

[BenjamenMeyer]

I'm not sure about merging with Asset Productions. In part because we have a second asset repo as well (Asset Masters) and we might add some more:

• a testing asset repo with subsections for different kinds of tests
• a base asset repo with common things that an asset system would need (this would likely come after review and refactor of our existing asset repositories)

Any how...those are the things on my mind regarding assets.
Regarding documentation, we have several areas:

• the game engine itself
• creating assets to use with the game engine
• the games we provide out-of-the-box

It would make sense that the documentation for the games out of the box would live with the assets they are with as they will be closely tied, so documentation here that is relevant to that would probably be good to merge over to Asset Masters and Asset Production as appropriate.

The game engine stuff itself should remain separate from the documentation for the games; it'll be more dev oriented.

The documentation for how to create assets....that'll either need to live with the engine or with a new repository covering the basics of building assets. Probably for now, it should just stay with the engine documentation.

[nabaco]

Hi @BenjamenMeyer, I'm attaching the compiled document from this repo.
From what I see, it mostly contains details about the UtCS world (races, factions, etc). I'm not sure how to categorize this, but I still think it should be in the Assets, as I think it's most relevant there.
VSU.pdf

Either way, I'm planning to transform this into Markdown using Pandoc, and experiment with hosting it on our website.

[nabaco]

I would like to point out something regarding this.
As it seems to me, looking at standard Ubuntu packages, we're going to deliver 3 packages:

1. Vegastrike-common (engine)
2. Vegastrike-data (UtCS)
3. Vegastrike-doc

Just pointing the 3rd one out, as we need to think about it when we decided where the docs are going to be

[BenjamenMeyer]

@nabaco That PDF is pretty exclusively the Game documentation side.

Per packaging, I'd think we'd actually need:

• vegastrike-engine (common engine libraries)
• vegastrike-engine-dev (common engine + headers)
• vegastrike-engine-docs (developer documentation for the engine)
• vegastrike-utcs (UtCS Game Assets)
• vegastrike-utcs-docs (UtCS Docs)

that'll be another issue, but yes we should take it into account here as we think about how things should be split and how they should be presented - both on system and on-line.