Home

Welcome to the haxeflixel-mechanics wiki!

About

This repo is the development environment for HaxeFlixel-Mechanics, a website tool to demonstrate, explain, and show off individual concepts of the HaxeFlixel library.

Goals

The goals for this project are pretty simple - create a bunch of simple demos and examples with accompanying source code and links to help users of HaxeFlixel learn and understand the mechanics of the library.

Why not stick with the current demos, docs, tutorials, and API?

I feel like it is currently pretty difficult to a newcomer to jump in and start using HaxeFlixel. The current tutorial is good, but is very specific and doesn't do enough to really explain concepts, while the demos and API are just a lot of information - you have to know what you're looking for and/or spend a lot of time digging through code to find out what you want to know - and this can be very daunting for someone trying to figure out how to just get started.

Why a separate repo?

The current state of the HaxeFlixel website, while functional, is sort of a mess behind the scenes and is difficult to work with and make changes to. Also, since this project is sort of meant to be it's own resource, it made sense to start with it as a separate entity so as to prevent it from interfering with the Haxeflixel.com repo (and vice-versa). In the future, this project may end up being merged into the HaxeFlixel website.

Terminology

In an attempt to try and keep everyone on the same page, I've come up with a few terms. We may want to come back and discuss changing these later.

• Concept

• These are the things we're trying to explain in this project. Loosely defined, a Concept is something that HaxeFlixel 'does', such as 'collision', 'particles', 'sound', etc. Concepts will be broken up into smaller Concepts, and Proofs.

• Proof

• A Proof is something that shows off a small element of a Concept. Concepts are broken down into Proofs. For example, the Concept 'Collision' might have several proofs, including '1 to 1 Collision', '1 to Many Collision', 'Many to Many Collision', etc. Proofs should try to be clear, simple, and concise, dealing with only as much as it needs to demonstrate the element it's covering.

• Synopsis

• Each Proof will have a Synopsis, which will be friendly, helpful text which describes the Proof and it's relation to the Concept (and possibly other Proofs).

• Sample

• Each Proof will contain a Sample, this will be one or more small snippets of code that demonstrate the Proof. The sample will be formatted and colored to be easy to read. Ideally, we should find a way to have parts of the code in the Sample link to the API. An example of a Sample might be, in the Proof for '1 to 1 Collision':

  FlxG.collide(sprOne, sprTwo);

  The Sample should NEVER contain any extraneous or superfluous logic.

• Demonstration

• Each Proof will contain a simple SWF that uses the Sample code to demonstrate the Proof in action. Demonstrations will need to adhere to a strict set of guidelines and styles in order to help build familiarity for the readers. Each Demonstration will contain ONLY what is needed to show the Proof in action, and no more.

• Source

• Each Proof will contain the complete Source code for the Demonstration - we might want to just have a link to a GitHub repo or something?

• Tags

• Each Concept and Proof will be able to have Tags assigned to them to help readers search for and locate specific things.

Design

The Concepts and Proofs should be organized from simple to complex, so that someone starting at the top will gradually move through more and more complex Concepts and Proofs. They should build off of each other whenever feasible, allowing someone to watch the progression and evolution of a simple idea into much more complicated ones.