Re: [Tuxmath-devel] [SPAM] Re: Patches & plans for tuxmath

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

Hi David,

On Tuesday 29 August 2006 07:47, David Bruce wrote:
> > 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.
>
> I had also noticed this and fixed it in a slightly different way in the
> code currently on my computer.  Briefly, I also added another flag to the
> game_options struct which I called sound_available, which is not read or
> written to the config file.  I then added a brief accessor function,
> opts_using_sound(), which returns true only if both flags are true.  The
> rest of the program now uses this function instead of looking directly at
> game_options->use_sound.  It will be in the next svn commit.

Sounds like a cleaner solution to me.

>
> > I'd also consider working on some more significant enhancements:
> > 1. The options configuration screen doesn't reflect current reality all
> > that well,
>
> Agreed.  Once I get the config file reading and writing into a more general
> and flexible form, the options screen is due for a major overhaul.  It will
> be a lot of work to write an in-game options system capable of controlling
> every setting in the config file without some sort of widget set (e.g.Qt).
> The rewrite of 'options' will likely be a compromise.  After that, a
> Qt-based tuxmath-config standalone program might be on the agenda.

I agree. It sounds like a scary project, and one of the main reasons I started 
with the feedback was that it seemed so much easier. GUI programming is not, 
sadly, a strength of mine.

> > 2. It strikes me that a good way to control the pace of the game might be
> > through feedback.
>
> Sounds like a good idea.  Currently, the game offers several settings
> related to speed and the number of comets.  The default is for both to
> increase progressively, but this can be turned off by setting
> "allow_speedup" to false.  There is also "slow_after_wrong", which turns
> the speed and comet number down to the starting values if a comet hits a
> city.  Certainly, more dynamic or fine-grained adjustments could be
> implemented.

Yes, those settings are indeed useful, and so at first I wasn't sure that 
implementing feedback would be necessary (in fact, it's not, as long as kids 
eventually get the ability to control the speedup through the improved 
options screen you described) or even helpful. But, it turned out to be quite 
easy to do. Furthermore, it occurs to me that my daughter's math skills will 
probably increase faster than her tolerance for danger, so having the speed 
adjust itself to achieve a fairly constant sense of danger might work well 
(at least for her). Similar considerations might apply to a room full of 2nd 
graders who have different math abilities.

> As others have pointed out, the make install target could be improved.  At
> least for now, I also don't know enough to feel very comfortable changing
> it. (I am a middle-aged surgeon and dad who is nearly completely
> self-taught with regard to programming - my last formal computer course was
> used Algol on punchcards in 1981).

I'm a neuroscientist who also hasn't taken a computer course since, oh, high 
school. We may be closer in our "real lives" than I would have expected. 
Certainly, I don't feel that I really know what I'm doing, I'm just hoping to 
make modest improvements to an already-great game for my kids.

Thanks again!
--Tim