if user makes:
class Elephant(Animal):
image = "some_image_that_in_resource_folder"

than image will be resources/some_image_that_in_resource_folder.png
else image will be like image of Animal (base class, some abstract image)

That will require us to tell the user in some way what all the available images are. (And, of course, to make these images.) So it will have to be a help screen with a legend between animal images and names.

And if the child makes a mistake, his Frog will have an image of a turtle, and I think that children will find this much more emotionally upsetting than us programmers do.

I'm starting to think this is too complicated. Maybe instead of Animal, we'll have Turtle, and if the child wants to make subclasses, he can call them JumpingTurtle, ColorfulTurtle, ShakyTurtle? So they will all have turtle images. (Possibly with slight random variations, computed with a hash function on the class's name, that'll be cool.) This will prevent these problems.

ow, i have idea!
we can extract image name from name of class and from it's superclass.
so, we have some base classes:

• Animal, with image of some "Abstract Animal"
• Turtle, with image of turtle
• Frog, with image of frog
• something another classes

so, child make it's own class:

• JumpingTurtle(Turtle) - we shows turtle image
• JumpingTurtle(Animal) - we shows turtle image
• LazyFrog(Animal) - we shows frog image
• FroshLittle(Frog) - we shows frog image
• JumpingTurtle(Frog) - child means Turtle, so, we shows turtle image
• PrettyLittleGremlin(Animal) - we don't know that child means. so, we shows some "animal abstract" image, if child don't make: image = "path/to/custom/image"

i think it is preferable scheme, and we have artist! )

Great idea. Though we'll have to prepare quite a few animals in advance, so it'll be some work. (I'd say 10-20 animals.)

yes