Project, Versioning, Releases

Structure

File Structure

• Foldernames must be PascalCase
• For filenames see the Coding Style
• Top-level folders are reserved for FUDGE modules and documentation. There is another folder "Miscellaneous" on this level that holds everything else.
• Everything that is supposed to be bundled into a single .js file (e.g. everything inside one namespace) is to be put into the same top-level folder. Inside a top-level folder with FUDGE sourcecode, there should be the folders Build and Source.
  • Source holds the source code (.ts files), organised using sensible folder structures.
  • Build holds solely generated files like the compiled .js, .d.ts as well as .js.map file
• There can be more folders used if needed.

Special folders

• Test contains FUDGE tests, that check different aspects of the engine in an isolated environment. Check all of these before creating a release.
• Documentation contains everything that is part of the documentation, including the Reference generated from jdoc, Tutorials with accompanying Examples for users to work with and learn how to use FUDGE.
• Miscellaneous contains everything that doesn't belong into any of the other folders, such as log files, logos, isolated experiments that aren't reliable on FUDGE code directly, etc. May be deleted in the future!

FUDGE
├ Core
│  ├ Build
│  ├ Source
│  │  ├ Component
│  │  │  ├ ComponentAnimator.ts
│  │  │  ├ ComponentTransform.ts
│  │  │  └ ...
│  │  └ ...
│  └ ...
├ UserInterface
│  ├ Build
│  ├ Source
│  └ ...
├ Network
│  ├ Build
│  ├ Source
│  └ ...
├ Editor
│  ├ Build
│  ├ Source
│  │  ├ ViewNode
│  │  ├ ViewAnimation
│  │  └ ViewSketch
│  ├ Themes
│  │  ├ Dark
│  │  │  ├ Css
│  │  │  └ Images
│  │  ├ Light
│  │  └ ...
│  └ Html
├ Test
├ Documentation
│  ├ Reference
│  ├ Tutorials
│  ├ Examples
│  ├ Design
│  └ ...
└ Miscellaneous
   ├ Experiments
   └ ...

Namespaces

FudgeCore

The core mechanics, everything the average basic game needs. Includes, but is not limited to: Engine, Node, Render, Animation, Component, Light, Mesh, Shader, Texture, Transfer.
Needs to be included in the exported game for it to work.

FudgeNetwork

Networking Code. Needs to be included in the exported game if used.

FudgeUserInterface

Components for building an HTML-based user interface. Used by the editors and may be used in a game. Needs to be included in the exported game if used.

Fudge

The Editor that makes FUDGE an actual Editor and not only a library. Is a composition of different views into a FUDGE-project and its parts. Each view resides in its own folder within the source-folder of the Editor.
Is not needed in a finished game, only for the creation.

Fudge.ViewProject

Displays the resources that comprise the project and offers means of manipulation and configuration.

Fudge.ViewNode

Displays a Node with its children and components attached and offers a user interface for manipulation.

Fudge.ViewAnimation

Displays an animation and the objects it may manipulate and offers a user interface for editing.

Fudge.ViewSketch

Displays a vectorgrafic sketch that generates a texture and provides tools for sketching.

Fudge.ViewMesh

Displays a Mesh and provides tools for simple modelling.

Versioning and Releases

Once the first version is released, the master branch solely keeps the latest stable release! Work in branches on the next versions

If the user wants to use an older version of FUDGE, there will be a Webservice which will enable them to look for older FUDGE versions and provide them with the matching data. Every released version of FUDGE can be used to create games, but it is always recommended to use the latest version since it is probably the most stable.

Update for user projects

Each new version of FUDGE must be able to load a user project saved by a previous version and save in the current format. Thus, a an old project can be updated by sending it through a cascade of the later versions of FUDGE. There should be a webservice that does this, users can upload their projects to and download a desired version.

Packaging

A FUDGE user is provided with different ways to integrate the FUDGE package into their game

• A user can choose to include FUDGE directly from a local repository
• You can also use an online reference to FUDGE

FUDGE also supports the use of games as a progressive Webapps.

Development Branch

Use different branches for developing/changing different aspects of the editor instead and merge and test on the development branch. Patch candidates may be released as an unstable version if necessary. It should be named vX.Y.Z-pre1 etc. These unstable releases are to be used sparingly.
Use pull requests to request a merge into the development branch. If the admins approve of your change, it will be merged.

Release

Releases are to be performed exclusively by admins!

If you're not familiar with MAJOR.MINOR.PATCH versioning, please read this first. FUDGE Versions are to be annotated with a leading v.

On how to create a release, refer to this. Don't use git tags in this project, except for the automatically generated ones when creating a release.

step by step

1. Make sure the version on the development branch is (as) bug free (as possible) and can be considered stable. Also see the Test folder.
2. If something in the structure of the json files has changed, write a converter for the coming version from the currently latest version and add it to the webservice.
3. Create an electron build of the new version and test that again (don't commit).
4. If it's still stable and builds without problems, merge it into the master branch.
5. Use the just merged commit to build a new electron app (don't commit!). Remember that there are other OS than just your own.
6. Test that electron app again, just in case.
7. Create a release as described here. Use the X.Y.Z Versioning. Version numbers are to be written with a leading v, e.g. v1.0.4. The name field is to be used to mirror the version name if no other name is applicable. The longer information field should be used to:
   1. Link to newly compiled javascript files, including d.ts files.
   2. Link to release-specific documentation
   3. Provide changelogs
   4. List fixed bugs
8. Add the electron standalone build(s) as a downloadable file to the release and publish the release.