Home

Welcome to the snippets.haxeflixel.com wiki!

About

This repo is the development environment for HaxeFlixel-Snippets, a website tool to demonstrate, explain, and show off individual concepts of the HaxeFlixel library. If you want to jump in and start contributing, here's what you need to know: Contributing

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 concepts 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.

Each Proof and Demonstration should be as simple and verbose as possible. Exactly enough to explain and demonstrate the Proof, and no more. We don't want to fall into the problem of 'flixel-demos' where when trying to explain collision we also have emitters, and tilemaps, and sounds, etc.

Every Demonstration needs to adhere to the (not yet) defined style guide, and, again, should be as simple as possible to convey the message. The style guide will define which colors, images, styles, fonts, sounds, and sizing, etc to use for Demonstrations, and should only be 'broken' when necessary to properly explain a Proof.