[Tuxmath-devel] Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi,

First and foremost, thanks to all the people who have contributed to tuxmath, 
making it a great program that my family is benefitting from a lot.
Particular thanks Bill Kendrick for creating tuxmath and GPLing it, and to 
David Bruce for all the enhancements he's given it.

Because we're liking it so much, I thought I'd try to contribute a bit to the 
project. I'm new to contributing back to open source, so I'm probably not 
very sophisticated in my use of the tools.

Attached are two tiny enhancements:
1. (trivial) Provide a bit more description of what the play_through_list mode 
does---I kept trying to supply a text file for the problem list until I looked 
at the source code. The relevant patch file is mathcards.diff. This patch 
also adds a comment on a point that I initially found confusing.
2. On some systems (e.g., older, or perhaps even current, KDE systems using 
aRTs), sound hardware can be temporarily unavailable, because aRTs 
didn't/doesn't share the sound resources nicely. In that case, sound gets 
turned off. The problem is that this then gets saved as the user's preference 
for the next session. This is fixed in the other 3 patch files: config.diff, 
setup.diff, tuxmath.diff. (Presumably if I knew what I was doing I could have 
made this a single patch file?) Note my use of "verbose = 2" seems a bit 
cheesy, at least if you ever had anything else planned for gradations in 
verbosity---feel free to change this.

I'd also consider working on some more significant enhancements:
1. The options configuration screen doesn't reflect current reality all that 
well, especially with regards to the numerical ranges; my older daughter is 
working on her times table up to 10, and was briefly disconcerted to see "12" 
there even though I had manually edited the config file appropriately. The 
addition of the "speed" control is very nice; my daughters might also like to 
be able to control the game's acceleration (speedup_factor). So it might be 
nice to be able to give users more control over certain parameters.

Conversely, tuxmath is clearly to the point of being useful for classroom 
purposes---but there, a teacher might want to be able to prevent students 
from changing the assignments to "plus" when they're supposed to be working 
on "times." So, some method for allowing someone to set, say by a 
configuration file, which options should be "locked" (and not even show up on 
the options screen) could be a useful feature. (Of course there might be 
other ways of accomplishing the same thing, say, by watching the kids while 
they play!)

But if these thoughts make sense to others, it might be worth doing something 
of a general reworking of the options screen.

2. It strikes me that a good way to control the pace of the game might be 
through feedback. Many kids (in particular, mine) will probably have a 
comfort range: it's boring when it's too slow, and it's intimidating when 
it's too fast. Instead of controlling the speed directly, one might want to 
instead try to achieve a particular "adrenaline level." For example, one 
could specify in the configuration file that this kid loves the challenge 
when the problems frequently almost nuke the cities; another kid (using a 
different config file) might be more cautious and prefer it if the problems 
rarely get more than halfway down the screen. The game could adjust its speed 
to achieve, say, an average height at which the player zaps the problems. 
With braver players that level could be set lower (closer to smashing the 
cities), with more cautious players it could be set higher.

While this might work well for some players, an easily-foreseeable problem is 
that if kids discover the feedback, some of them might try to take advantage 
of it---or, if they decide for fun to "wait until the last minute" before 
zapping a problem, in order to try to build a sense of excitement, then the 
game will slow down rather than speeding up, perhaps contrary to what the kid 
himself/herself would actually prefer.

For that reason, one would of course want to be able to leave the current 
controls available, and have feedback only as an option. It might be 
especially good for the first-time user, to set the game to the appropriate 
level; one could choose to then fix the speed in the config file, for 
example.

However, giving the users direct control over speed & speedup might be just as 
good, or better, for achieving these aims---so it's not obvious that this 
would be a desirable feature. Discussion?



There are also a few other points I thought I should mention, but either I 
can't do anything about them or hesitate to do so without some input from 
those with more expertise:

1. Please, the tuxmath web page and the sourceforge page should both point to 
the current subversion tree. When I started hacking on it, I was going to use 
the CVS; but by chance I had first downloaded the sources from Debian 
unstable, and was surprised to see that these seemed newer and more 
featureful than the CVS. I then poked around and found the subversion tree, 
but it could have easily worked out differently, wasting a bunch of time.

2. Installing: the PREFIX=?? syntax doesn't work for me unless I take root 
privileges. It complains about the "chown" (here are the last 4 lines of 
output):

cp tuxmath /home/tim/src/tuxmath/build/bin
chown root:root /home/tim/src/tuxmath/build/bin/tuxmath
chown: changing ownership of `/home/tim/src/tuxmath/build/bin/tuxmath': 
Operation not permitted
make: *** [install] Error 1

I edited the Makefile to allow me to set OWNER, and that works the first time. 
However, when I modify & recompile, then I get a different problem: it turns 
out that the install script also copies all the .svn directories (presumably, 
this is not actually desirable?) and on these directories I get permission 
errors (because these files are locked for writing even by the owner).

Unfortunately, not being a C/C++ wiz I haven't had enough experience with 
Makefiles to solve this one easily myself. I tried putting in a
     cp $(find . | grep -v ".svn") $(DATA_PREFIX)
but I think make tries to interpret my shell command as a makefile variable. 
Anyone else know how to fix this? (Use rsync instead of cp? Or do some people 
not have that installed on their systems?)

3. In the configuration file, I've noticed that the ranges for subtraction are 
not specified as the complement of the addition problems---for that, one 
would specify "subtrahend" and "difference" rather than "minuend" 
and "subtrahend". This is in contrast with division, which is the complement 
of multiplication. One consequence is that kids get 121 addition problems if 
they go from 0 to 10, but many more subtraction problems that include 20-4=16 
etc. This is not a bug, and may not even be bad, but it's something I 
noticed. I can try to help change it if that's desirable.

Once again, thanks for a great program!
--Tim Holy