[Tutor] python, speed, game programming

Keith Winston keithwins at gmail.com
Fri Jan 3 23:04:45 CET 2014


Just to be clear: this is equal parts learning Python project, prototype
tutorial software project, OOP practice, and the beginning of a more
general inquiry into learning styles/paradigms/parameters... I'm (slowly)
writing some of these ideas up in a separate doc.


On Fri, Jan 3, 2014 at 4:53 PM, Keith Winston <keithwins at gmail.com> wrote:

> Shoot, sorry for the empty message. Here's what I was going to say:
>
> I am gearing up for the next project (yeah, an eventual end to Chutes &
> Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak
> but I would expect it easily adapted to QWERTY or anything else.
>
> The basic idea is build a database of the key and response time of every
> keystroke, with simultaneous background processing going on, based on a
> customizable set of parameters to select the test text in more or less real
> time. So for example, I might wish to adjust the interval at which I
> revisit old material, to be sure I "get" it without becoming bored by it:
> we could call this the repetition interval, and it might well be a function
> that increases with time, though it might also be keyed to the speed of
> recall... all responses are to be saved long-term for subsequent analysis.
>
> My concern is with speed. This will have to keep up with (somewhat
> arbitrarily) fast typing, while doing background processing, with a GUI of
> course. This illustrates why I was concerned about the fact that my Chutes
> & Ladders game seems to run at the same speed on my 8 y.o. Core 2 Duo and
> my 2 y.o. Core I7 with 3-4x as much memory. This WILL require a faster
> machine and a more significant share of it's resources, if I develop it in
> the direction I am thinking.
>
> I hope Python is a good choice here, though I suppose some modules or
> classes or parts will have to be recoded into something faster... Any
> thoughts on this will be appreciated, including how to structure it in such
> a manner that it might be more portably applied to future versions in
> entirely different knowledge realms (music/midi input,
> language/vocabulary/audio output, etc).
>
> --
> Keith
>



-- 
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140103/65d65b8c/attachment.html>


More information about the Tutor mailing list