This post was long overdue.Me and 1025 students were selected for GSoC 2010.
I was selected for the project Enhancement and Integration of Tux4kids-admin with Tuxmath and Tuxtype for Tux4Kids for the organization Tux4kids.
My mentor Michal Switakowski is awesome.
Here is almost all of the proposal. I have removed personal contact info etc. so that the post becomes a bit less lengthier.
Title: Enhancement and Integration of Tux4kids-admin with Tuxmath and Tuxtype.
Abstract: The core issue faced by teachers in schools regarding including Tuxmath and Tuxtype in their curriculum is that they cannot assess the kids as they want.A configuration/administration program Tux4kids-admin was thus developed for teachers.But it does not integrate with Tuxmath and Tuxtype.My project is to add/modify code in Tuxmath and Tuxtype so that the Tux4kids-admin program supports them while simultaneously working on improving the
Tux4kids-admin program by mentor.
Content:
Project Goal
TuxMath is a game to help kids practice math facts while Tuxtype helps kids learn typing.Tux4kids-admin
is an administration tool for both(Tux4kids in general).The goal of this project is to improve the
Tux4kids-admin program and integrate it with Tuxmath and Tuxtype.
Description
Currently Tux4kids-admin has a school_data directory which has two subdirectories namely Computers and Students.
The problem with this is that there is no such classification as on the basis of a grade and thus two students of different
grade are difficult to distinguish and thus it is difficult to assign them missions of their level.
What I will suggest to have school_data directory with three subdirectories.
1.Grades. 2.Missions. 3.Computers.
We can have the school_database.db file in school_data directory.
The setup of each directory is as follows.
1.Grades
First we will define the number of grades for the school using Tuxkids-admin.
Then for each grade Tux4kids-admin will create a corresponding subdirectory in the Grades directory.
Eg Grade1,Grade2 etc.
The Tux4kids-admin program has a set of dialog boxes to perform the following tasks.
Add teachers to their corresponding grades.
Then for each teacher it will create a subdirectory in the corresponding Grades directory.
Eg Mrs. Jones,Mr Smith etc.
Add students assigned to their corresponding teacher.
Then for each student it will create a corresponding subdirectory in the
corresponding teacher directory. Eg Student1,Student2 etc.
The add a teacher dialog box has following entries to be filled.
First Name - First Name of the teacher
Last Name - Last Name of the teacher
Grade - Which grade the teacher belongs
The add a student dialog box has following entries to be filled.
First Name - First Name of the student
Last Name - Last Name of the student
Tuxmath/Tuxtype check boxes - Whether mission can be assigned for that program
Teacher - Teacher responsible for that student
By now the directory heiarchy for Grades is set up.
2.Missions
It will store the all missions created by teacher in the past.Each mission corresponds to one file.
Thus teacher can load a selected mission anytime from the list of missions and not have to create a new mission everytime.
It will have two subdirectories
a)Tuxmath b)Tuxtype
Both will store mission files corresponding to them.
The mission files are created by teacher when giving a mission to a student
and contain various settings related to the mission assigned.
eg for Tuxmath teacher may have a mission file containing setting as
Allowing addition only.
Numbers from 1 to 10 allowed.
Maximum speed=40.0
3.Computers
The Computers directory will have the same features as earlier implemented
i.e. it will have further subdirectories Computer1,Computer2,etc.
Each of Computer1 or Computer2 will have Tuxmath and/or Tuxtype subdirectories.
Now suppose teacher uses Tux4kids-admin to assign a mission1 from mission file
to student1 and assigns him/her Computer2.Further suppose while adding student1 we had allowed him/her to
be assigned missions for Tuxmath only.
So one subdirectory in Computer2 directory will be created by the name of Tuxmath.
The Tux4kids-admin will create the configuration files(explained later) having the following
information in the Computer2/Tuxmath directory for the case we are considering-
The name of student who is assigned this Computer
The mission assigned
The path of student in Grades directory and mission in Missions directory
Other information
Work Scenario
When a teacher uses Tux4kids-admin to assign a ComputerX to a student1 and
gives student1 a mission and loads the Tuxmath/Tuxtype plugin,the *configuration files*(explained below) for that
student1 are created in the ComputerX/Tuxmath or ComputerX/Tuxtype directory.
Now suppose Tuxmath --school-mode is run on ComputerX.
The Tuxmath program will skip the default beahviour of presenting a set of menus.
Instead, it forces the mission assigned for that student1 by the teacher by reading the
configuration files(explained below) present in the ComputerX directory.
From code point of view,it involves recognising the --school-mode argument and
changing code in Tuxmath/Tuxtype such that default menu doesnot show up and presents
the assigned mission by loading the settings from the mission file.
So basically during school-mode the Tuxmath program reads information
from Missions directory and ComputerX directory.
Now when the student exits the game,his/her scores and performance is saved in his/her folder
which can be retrieved later by teacher by using Tux4kids-admin program.
From code point of view it involves reading the various information from the variables containing related
information at runtime and writing them into a result file.
Result files can be text files which may contain following information and more
High scores by the student
Missions accomplished
Questions asked and questions missed
Numbers of correct and incorrect answers and the percent correct
Other values.
Result files are saved in student's home directory.There can be a result file per day for a student
or a file per mission/lesson.
There can be high scores of a class in sorted form stored in a highscores.txt file saved in teacher's folder
and similarly for a grade.Each time a student's score is written in his/her home directory it is checked with
highscores.txtand if it finds place it is added and the last item discarded.
Likewise we can store other items. eg.most difficult question for class,maximum percentage for a mission etc.
*Configuration files* are the files that are produced in the ComputerX/Tuxmath
directory on loading the Tuxmath plugin or are produced in the ComputerX/Tuxtype
directory on loading the Tuxtype plugin or both.
They are used by Tuxmath and Tuxtype to run the missions as configuredby the teacher.
They contain information related to the mission assigned to the student,its location,
name of student and his/her home directory and other configuration options(to be decided).
The configuration files can be CSV files or text files .
If required, their format can be discussed later also during the time of actual coding.
This is because the flat file database management system involves security issues.
For eg a student can change his score by merely updating the text file
(we cannot make it read only because the score needs to be written after playin the game)
in his folder.Even though they are kids but a security concern is always there.
But since tumath and Tuxtype are natively made to read text files and
dump back results to text files, it is better to go with the idea of text/CSV files.
Project Plan
Since my summer holidays start from 1st May 2010 and end on 15th August 2010,
and I have nothing else to do this summer, I feel that I can give ample time
till the end of the project.
Time per week - 42-56 hrs (6-8 hrs per day).
The whole work is a two way process.It means work is to be done on both Tux4kids-admin side and Tuxmath and Tuxtype side.
First we implement the whole idea for the Tuxmath and then implement for Tuxtype.This will help us to write code effectively.
I have divided the coding period in community bonding period and 5 number of phases.
Timeline
Community Bonding period
Further discuss idea with the mentor
Finalise the project specifications(This means that phase timeline below is liable to change).
Get a grip on git,SDL and other tools
Phase I (May 24 - May 31)
1. For Tux4kids-admin
Decide the interfaces to be designed for Tux4kids-admin.
Dialog boxes for the Tux4kids-admin program to set options and give missions to kids.For eg. Create/Assign Mission Dialog box, Show Result Dialog Box etc.
Decide how it will generate configuration files.
2. Decide on structure of configuration files and mission files means how and which values will be stored in them.
3.Decide on the structure of result files of Tuxmath program once the game is over.
4.Discuss and plan out how the changes in Tuxmath and Tuxtype will be carried out so that it reads the configuration files and how to write back the result files.
5.Begin coding.
Phase II (June 1 - June 30)
In this phase work will be done on Tuxmath and Tux4kids-admin only.If it is done code
can be ported with required changes to integrate Tux4kids-admin with Tuxtype.
This will help us to concentrate on one thing at a time.
Implement the first feature
This involves creating mission and configuration files which are read to load the mission.
Tux4kids-admin
Able to create mission files.
Able to create to confiuration files for a particular student.
Tuxmath
Able to read details from the configuration files and mission files.
The configuration file will describe the path of mission file for a student.
Able to start the mission in school-mode by loading the configuraion file by skipping the default menu.
Implement the second feature
Now,the game is ended but before exit the game has written result files.This feature also involves reading result files and display statistics.
Tux4kids-admin
Read result files from a student's home directory and display the student's performance.Other features can be added here like comparing performances and preparing a performance card for last month and deleting earlier results etc.
Tuxmath
Able to write the result of the student in the student home directory on the basis of which performance card can be generated.
Phase III (July 1 - July 15)
Port the code generated in earlier phase to Tuxtype by making appropriate changes (I think it will consume a lot of time but will be a better option than rewriting whole thing) by following strategy as described above in earlier phase.
Submit for the mid-term evaluations.
Phase IV (July 16 - July 30)
Finishing up what is left in implementation.
Improve upon the code written till now to suit best to the target audience(teachers and parents).
Start work on documentation.
Start testing and debugging.
Phase V (August 1 - August 16)
Finish documentation.
Testing and debugging continued.
Final evaluation.
Biography
...
I am writing this blog when I have just passed the mid term evaluations.
A lot of things come into picture once you begin coding.
So keep your structure/plan of proposal strong and other things flexible.
If this post was of any help to you, my purpose is achieved.
On a personal note I wish to see more GSoC'ers from nitdgp in future.
Bye
