There are a couple of ways you can contribute to this project.

If you just have a suggestion for a demo, or something that think should be changed or added, add a New Issue describing your suggestion, and we can discuss it and/or implement it, if it makes sense.

I have tried to make working with this site as simple as possible.

At the bare minimum, you need to have Ruby 2.7 + Dev Kit, and Bundler installed to begin working with the repo.

In order to build the demos, you will need to have Haxe installed. You will also need the lime, openfl haxe libraries, as well as flixel, flixel-addons, and flixel-tools.

Run bundle exec rake serve to start serving the site locally. The script will build all of the demos, and then serve the site at http://localhost:4000. Any change you make while the site is being served will automatically update.

If you change a demo's code, you need to rebuild that demo to get it's swf to update on your locally served site.

Use bundle exec rake html_proof to validate the site's HTML (must be done after serve or deploy)

Use bundle exec rake deploy to rebuild all of the demos, rebuild the site, and check the site's HTML.

• Everything in the site should be sorted by complexity, whenever possible, with the simplest items at the top, and more complex items further down.
• Files should be places in their appropriate folders ('_concepts' for Concepts, '_proofs' for Proofs), and their filename should be the page's title, slugified, with '.md' as the extension.
• Example: _proofs/1-to-1-collision.md
• Concepts and Proofs use Front Matter to be rendered properly. Each file must contain the following front-matter at the top of the file:

---
title: Title        # The pages title
order: 1            # {the position in the list it should show up}
tags: [tag1, tag2]  # tags that this page should be grouped under
complexity: 1       # 1 (Beginner), 2 (Medium), or 3 (Advanced) for how complex this item is 
---

• Although we strongly encourage using Markdown for your pages, you can use HTML if it is absolutely necessary.
• To add a code block, use 3 backticks ('`').
• Example:

    ```haxe
    FlxG.collide(objectA, objectB, callback);
    ```

• You may use Jekyll's Liquid Tags in your pages.
• When mentioning a HaxeFlixel API term, you should use the "api" tag, which will format the term and add a tooltip and link to the HaxeFlixel API

If you would like to add your own content to the site, we have tried to make the process as easy as possible, but there are some guidelines that must be followed.

Concepts are high-level 'ideas' that can be broken down into a few, smaller proofs. Before adding a new Concept, ask yourself if it is appropriate. Concepts should never be too broad ("Game"), or too specific ("Camera Flash"). There should never be any duplicates. If in doubt, create an issue and discuss it, first.

The Concept's page itself should give a brief synopsis of the Concept. Example

Proofs are specific, detailed examples of one element of the Concept. Each proof must also contain the Front Matter variable, concept, which should match the parent Concept. You may also, optionally, include the seealso variable, if you wish, to add a list of links to other pages. The sourcefiles defaults to 'source/PlayState.hx' for every proof, if you want to include other source code files, add them here, with a space between each one.

---
title: Title         # the Title of this Proof
concept: Concept     # the Title of the parent Concept, for example "Movement"
order: 1             # the position of this Proof
tags: [tag1, tag2]   # which tags to group this Proof under
complexity: 1        # the complexity of this Proof: 1 (Beginner), 2 (Medium), 3 (Advanced)
seealso: [Concept/Proof, Concept2]
sourcefiles: source/PlayState.hx source/OtherState.hx
---

Each Proof should start with a synopsis of what it is meant to be explaining, and then must have at least one block of simple, sample code, demonstrating the proof. It may have more, if necessary (but you should consider breaking it up into multiple Proofs). The sample code(s) should be very, very basic, only showing the absolute bare minimum to explain how the Proof works.

Each Proof must have 1 (and only 1) Demo associated with it.

They should be created and added to the 'demos' folder, under a sub-folder named the same as the Concept, slugified. You can easily do this by using flixel-tools with the command: flixel tpl -n "demo-name"

Demos should be given a name that matches the Proof's name, slugified.

The demo for Movement/Angular Velocity would be something like: 'demos/movement/angular-velocity/angular-velocity.hxproj', as an example.

The following guidelines should be followed for every Demo, unless the specific Demo demands something be changed to work.

• 320x240
• 1x zoom
• Build in Release for Flash
• No Splash Screen
• Set FLX_NO_MOUSE, FLX_NO_KEYBOARD, FLX_NO_TOUCH, FLX_NO_GAMEPAD unless the demo requires input.
• Set FLX_NO_FOCUS_LOST_SCREEN
• Build with a transparent background (in the Project.xml, remove background= from the <window> tag, and use bgColor = 0 in your FlxState(s))
• We've found that setting FlxG.camera.pixelPerfectRender = false works nicely.

Demos should utilize the assets prepared for this site. They can be found in demos/demo-assets. The simplest way to use them is to change your Project.xml to say <assets path="../../demo-assets" />, and you may want to change your AssetPaths.hx file, as well.

If your Demo needs an asset that does not yet exist, add it to the demos/demo-assets folder, but try to make it fit with the other assets.

A template can be found here which adheres to all of these guidelines.

Feel free to Fork this repo and submit Pull Requests for changes to the overall site. If you want to build the site locally, you will need to install Jekyll, but it should be pretty straightforward to do so.

Once you've got everything installed and working, run bundle exec jekyll serve from the command line to build and serve a local, auto-updating version of the site that you can access at http://localhost:4000.

When making site changes, try to adhere to the theme of the site. It should be simple, clean, and uncluttered. Easy for someone to navigate and find what they are looking for.