Childsplay Manifesto
Stas Z
E-mail: childsplay@users.sourceforge.netRelease 0.66
May 10, 2003
Childsplay manifesto.
This document is the place for some vague ideas and some strong opinions about childsplay. Don't expect program details here.
What is childsplay? The aim of childsplay is to provide a collection(suite) of educational games for children. The games should be suitable for children of all ages, so games with violence, monsters or the idea that shooting people and animals is fun would never become part of childsplay.
Childsplay is intended to be used in schools and aimed at children from 3-10 years old. The priority is in school use so the ability to be used in a network of thin clients and/or old computers as well as handling multiple users is very important. Also the games should be simple to use without all sorts of questions or options, the aim is that children can play these games without supervision.
Why a project like childsplay? I've started childsplay because i only do Linux and there' not much software for children, besides gcompris and a few games like lletters. II wanted something educational like lletters with the 'suite' concept of gcompris and the RAD of Python. The benefits are:
- I'm getting the software for my own children.
- It could be a much needed addition to some 'Linux-for-schools' projects.
- It's a nice way to give something back to the open-source community.
- It's just fun to create something which gives children the opportunity to do something useful with a computer.
- I just like to code.
Basic design of childsplay.
Controller: The controller provides the basic framework like the SDL screen,help text, menu's etc. The controller will load and start a game while the game can communicate with the controller by using different return values in the eventloop.
Plugins: These are the actual games. The games can be added or removed from the suite to get a games suite with only the plugins one likes. The plugins should be organised in packages like a package for young children, one for school use, one only for fun etc. Other modules used in childsplay should also be designed like the game plugins.
Misc utility's: This module is used to store all kinds of classes and functions which can be used by different parts of childsplay. These utility's should be coded in a way that they never break the program, thus every exception should be caught and probably raise a standard exception which can be caught by the controller. Everything in a module that can be used by some other module should be placed in this utils.py module.
Design considerations.
- The controller is always in charge of the events and plugins should only raise exceptions which the controller can except, and use eventloop-return-values to interact with the controller.
- Never should a plugin call methods or functions of the controller module.
- Plugins never raise a system exit exception.
- Every plugin option or configuration possibility must be consistent with the overall 'look and feel' of childsplay or the package it belongs to.
- Chidsplay nor any of the plugins should depend on some desktop environment. It should only depend on X, SDL and ogg, basically it must be able to run on every standard Linux system.
- Nothing in childsplay should depend on root privileges.
- Games are able to record the state there in when a user quits the game and can restore this state later.
- Games must record the users progress and/or results and presents these to the controller in a standardized manner.
- Plugins can use config files which should be in a standard format. (see python Configparser)
- Menu driven options or features should be kept to a absolute minimum and if some sort of menu is needed, the menu objects provided by childsplay should be used.
This all, for now. Anybody who's got some comments or ideas can try to get them in the manifesto.
