Consider a modified version of the game AircraftWar where instead of firing bullets, the aircraft uses lasers to destroy enemies. The laser immediately eliminates the nearest enemy at the same xpos when fired.

Implementing this using the touching and onTouched API is not feasible because:

• There is no "touching" event triggered.
• Even if a laser sprite is created and the "touching" event is utilized between the laser and enemies, it becomes challenging to identify "the nearest enemy" since each enemy cannot determine its proximity.

In this scenario, game developers may need to manage a global sprite array, which simplifies the logic:

// main.spx

var (
	enemies []Sprite
)

func onPlayerAttack() {
	// Locate the nearest enemy with the same xpos as the player
	// Iterate through `enemies` and use `enemy.xpos()` / `enemy.ypos()`
}

// Enemy.spx

onCloned => {
	enemies = append(enemies, this)
}

However, there’s a complication: spx lacks an appropriate type definition for Sprite.

The Sprite type currently refers to a struct, while any enemy in the game is an instance of Enemy:

type Enemy struct {
	spx.Sprite
	*Game
}

So it is inappropriate to use []Sprite to store enemy instances.

Using []Enemy for the enemies array is inappropriate either because:

• We need []*Enemy to store the correct data, while we want to avoid pointer usage by game developers.
• If multiple enemy types exist (with different appearances and behaviors), representing them could lead to ambiguity—should we use []*SmallEnemy or []*BigEnemy?

I propose renaming the existing type Sprite struct{} to SpriteImpl and defining a new type Sprite:

type Sprite interface {
	Visible() bool
	Xpos() float64
	Ypos() float64
	// Any methods intended for game developers will be defined in this interface
}

type SpriteImpl struct {
	// Additionally, `*SpriteImpl` will implement `Sprite`, as will sprite classes like `*Enemy`
}

With this structure, the sprite array logic will function as intended.

Please share your ideas here, @xushiwei @JiepengTan.