Interesting polymorphic problem.

Working the way it does is exactly why polymorphism exists (maybe you guys having problem with that should try to find a decent tutorial about the topic) if you'd call mySprite.Draw and it wouldn't call the Draw method of the concrete object mySprite points to, it wouldn't make any sense at all. It's meant to decouple your code from knowing concrete types but work with the given interfaces of it's base class.

In that specail case the solution would be to create a system without cycling contexts.

Type Sprite
	Method Draw()
		BaseDraw()
	End Method
	
	Method BaseDraw()
		Print( "BaseDraw" )
	End Method

	Method SpecialDraw()
		Print( "SpecialDraw" )
		BaseDraw()
	End Method
End Type


Type Player Extends Sprite
	Method Draw()
		Print( "PlayerDraw" )
		SpecialDraw()
	End Method
End Type	


Type SuperPlayer Extends Player
	Method SpecialDraw()
		Print( "SuperPlayerSpecialDraw" )
		Super.SpecialDraw()
	End Method
End Type


Local spr:Sprite = New SuperPlayer
spr.Draw()

now our spr is only of the base type Sprite but it calls Player.Draw() which calls SuperPlayer.SpecialDraw() doing something specialspecial, Then calls Sprite.SpecialDraw doing the standardspecial and then calls Sprite.BasicDraw
Note that you can in addition customize the BaseDraw for derived types, but you first have to get what in that sample happens and *why*, then you shouldn't have problems with this in the future.