Where to store extra data when subclassing Sprite

If I subclass Sprite because I want to track some extra data with it, should I write get/set accessors that are implemented by storing that extra data in the sprite’s custom data? Or is it fine to add my own data members to my Sprite subclass?

Strictly speaking storing in data is likely safer in case we add to the sprite class in the future so that they don’t conflict, but if it’s a reasonably particular name I’d imagine it won’t matter - only an issue if we end up adding the same property name (e.g. if you had added fx it would have caused issues for this coming release with Peli’s friction fields)

That said, get / set won’t help much in that case as it behaves very similarly to how creating a new property does, so there’s no proper solution (besides hacky things like prefixing the field name on the sprite with a namespace or using a function outside the class to access the field). Do you have an example of the data you want to add?

1 Like

That all makes sense. I plan to track similar things to what I would ordinarily track with the sprite data extension. Things like a boolean tracking whether my sprite is busy (whether it can respond to controller input) and the current frame of the animation I’m manually running.

The reasons I don’t just use the sprite data extension (and/or sprite data directly) are: the syntax is a little more verbose, and I’m thinking I might want to store a reference to some data types that aren’t supported by the sprite data extension’s API (like an array of images; the frames of the currently running character animation; or rather, a reference to a custom data type that represents the currently executing attack).

Ah, sounds good. It sounds like it’s mostly internal state then? If so, the risk for breakage will be pretty low - worst case would just be a quick find and replace within the extension after an update.

If it’s exposed to users, maybe just be a little bit more verbose with the property name and we’ll almost certainly not conflict with it :slight_smile:

1 Like

Oh, and as a sidenote, storing directly as a field on the subclass should be significantly faster than storing in data - most of the time this doesnt end up mattering that much in practice, but if it’s a hot path it’s definitely important. This is also true with object literals that implement interfaces vs classes - we got a fairly noticeable bump from switching out a few interfaces we used for events / physics to be data classes.

1 Like

It sounds like it’s mostly internal state then? If so, the risk for breakage will be pretty low - worst case would just be a quick find and replace within the extension after an update.

Ha. Yeah, I’m not even worried about building reusable/distributable code at this point. :sweat_smile:

I’m asking mostly because I don’t think I have a good handle on the limitations of the conversion of TS/JS to executable code that can run on hardware. I didn’t know if Sprite-derived classes had limits on what additional field data they can carry.

Thanks for that additional info, too.

1 Like