Oooooh. Interesting. Maybe there's a reputation threshold?

Such an imbalance really strikes me as wasteful and sloppy

You're using Java. The most memory inefficient platform there is.


Instead of worrying about fixed per-object member overhead, minimize allocations to some reasonable extent. The bulk amount of memory doesn't really matter all that much, considering JVM requires about 4x the working set to run without GC hogging up all the resources. Or, if you have 250MB textures (somewhat permanent), expect JVM to require 1GB of RAM. If your entire overhead of this state is then 100MB, it's simply absorbed in the reserve.

Can you factor the most-commonly used members into a base class or three, and then use subclasses for the special cases that need more data?

I considered this. The main issue in this case is that while I know that most sprites will not need any extended properties at any given time, I don't easily know in advance which of them will need them. For example, consider a motion trail effect that can be applied to any moving sprite. This is only used for certain special attack and spell animations, but these could theoretically apply to any creature or projectile. It's just that, in practice, 99% of creature and projectile sprites will never use it. The same thing applies to a great many of the extended properties.

Given that I can't make very good advance judgments about when to give a creature a (for example) BasicSprite over an ExtendedSprite, this would seem to require a way to construct an ExtendedSprite from a BasicSprite (and vice versa), and convert a creature's sprite from one to the other whenever advanced effects are applied to it or when those advanced effects end. This... seems unpleasantly cumbersome, to say the least.

You're using Java. The most memory inefficient platform there is.

The fact that a platform itself is inefficient doesn't mean that one should disregard efficiency entirely. If anything, it might be even more important since there are many ways to incur overhead.

Instead of worrying about fixed per-object member overhead, minimize allocations to some reasonable extent. The bulk amount of memory doesn't really matter all that much, considering JVM requires about 4x the working set to run without GC hogging up all the resources. Or, if you have 250MB textures (somewhat permanent), expect JVM to require 1GB of RAM. If your entire overhead of this state is then 100MB, it's simply absorbed in the reserve.

While you make an interesting point about 'free' memory within the allocated heap size, texture memory actually resides outside the JVM entirely (and isn't garbage-collected, etc.) So even if I did have 250MB of textures (In practice, I would have much, much less), this wouldn't buy any 'free' heap space to use for other purposes. (Although, more fortunately, this also means it doesn't force memory usage much larger than the textures themselves, either)

At some point you have to decide which tradeoff to make: accept simpler code with higher memory consumption, or accept more complex code to get the lower memory usage. Depends on your priorities.

Reasonable enough, really. So much of development is about making tradeoffs, anyway: performance vs. flexibility, and so forth. In the end, saving a couple hundred KB probably isn't worth the additional code complexity of encapsulating property groups, checking a half-dozen things for null references each frame, and creating/destroying property classes as effects become active or inactive. Even when this extra memory is almost entirely a result of overhead known to be unnecessary ahead of time in the general case. It may simply be the cost of avoiding something potentially worse.

I had hoped there might be some obvious alternate way to go about this, but if not... Nearly all the source code I've perused to examine their rendering systems either had sprites that were much less flexible and capable in the first place, or legitimately needed most of their extended properties for the majority of their sprites. But it's probably better to err on the side of flexibility and clarity than worry about memory that is probably largely an ideological concern at this point.