A brain-dump of my ideas file:
## Characters
* Bob/Böb: novice game maker, floating head guy
* The Wizard: wise, Merlin-style wizard, teaching B[oö]b and the children how to make games
* Pete the Snake: bad guy, main cause of conflict.
## Language
Multiple. Other languages are “forks” of English.
## For Teachers
-> link at the top of the page, leading to a page for teachers, explaining benefits and giving examples of educative uses.
## Style
### Graphics style
LÖVE-like, but less childish. Children with the targeting age will not like anything deemed to childish.
### Language style
Accessible, joking, but not punny. A poop joke once in a while is OK, but caution must be excersized if we want adults to allow their children/pupils to use it.
There should be a central theme to each course, and it all has to fit inside the main story line.
Note that no knowledge can be assumed, not even what we would call basic computer knowledge.
### Code style
Clear, well-commented (thus have to be i18ned, variable names etc as well).
Efficiency is always sacrificed for readability.
Indentation, variable naming and other “smaller” aspects of code need to be completely concistent, even across different .lua files and languages.
Every code file ends with a few commented questions for the pupil, to explain how function x works, how function y could be expanded to change the background color when the player clicks inside the window.
### Page style
Every page should have a large, readable font (and only one for the whole site). Color scheme is also consistent site-wide. CSS > HTML for this purpose.
## Teaching strategy
Theoretical things meshed with practical things.
### Theory
Explain by analogy: a program is like a receipe, an array is a train, etc.
They are illustrated by images (see “Graphics style”) and .loves (see “Code style”).
Understanding of theory is tested by short pop quiz, using multiple choice whenever possible, to ensure no human intervention is needed. Not unlike a Towlr, the pupil is rewarded by praise upon succes. Upon failure to answer all questions correctly, the pupil is encouraged by the page to start learning the course again.
### Practice
Small, modular assignments. A “possible solution” file should always be included.
Assets (images, sounds...) are included, if needed. Assets should _not_ include language, to reduce the amount of translating (which can be rather difficult for assets, unlike text).
Machinated checking is virtually impossible here.
## Access
All pages should be accessible by anyone at all times. However, kids could register, to be able to keep progress. When logged in and viewing a page that is too advanced, the page should display a non-intrusive warning at the beginning of the page.
## Levels
By completing courses, children increase their Level. This gives them a chance to boast, and look foreward to learning more skills.
## Story Organisation
The courses are primarily organized in Chapters. Chapters are story-driven, and each one ends with a small cliffhanger. Chapters are subdivided into Slices, which are ordered per theme. Each Slice contains several courses.
Commentary requested.
Note: I think this project needs mostly artists and writers. Any volunteers? (Nothing “binding” or anything, just a quick gauge of the community.)
