Sprites Are Coming

I began working on sprites last week.  Sadly, I'm finding the work slow-going, because I've never done anything like it.

I've mentally worked though several potential approaches to this, but parts of the design bother me.  I will figure it out.  It's just a matter of time.

I've got an untested prototype for this written where the type object and the rendering object are one and the same, but it has no support code to load and then display it (that's my next task).

The final version for release will use a separate rendering object, the same way everything else currently does.  However, in this case, the type object is going to be aware of and/or involved in the rendering process. 

I'm calling sprites Actors in this project, because they won't just be sprites in the end.  They'll also have physics functionality and audio capabilities.

To illustrate what I'm planning, I'll compare to blocks.  Each block has a BlockType instance that's used somewhat like a flyweight object.  References to the type of the block are produced at run-time by querying a BlockCell for the cell's type, which looks up the BlockType and then spits out the reference.  I built things this way to save a huge amount of RAM at run-time.

In contrast, my design for Actors is not nearly as concerned with minimizing RAM usage, because there will likely only be, at most, a hundred actors in any given world, as compared to millions of blocks (Terraria uses worlds as large as 8000x2000, which is 16 million blocks and yes, I have tested this game engine at such sizes, without forcing the use of a 64 bit JVM). 

Everything starts from an ActorType instance, which is responsible for constructing Actor instances and will be responsible for nearly everything an Actor can do, especially visual rendering and audio.  This is somewhat similar to furniture, without the complications of being bound to a BlockPlane.  The Actor instance itself will be responsible for holding data, such as position and the current alpha value for transparency in rendering.

Sooner or later, rendering will be tasked to an ActorRenderer, such that rendering and the underlying behavior of the Actor can be pluggable via modding.

You'll be seeing a release for this functionality (labeled as "Soda Edition") as soon as I've got sprites on screen with a functional ActorRenderer interface.  The next big release after that (there may be bug fixes in-between) will address attaching physics to actors, as provided by JBox2D.  After that, who knows?  I will probably work on getting some basic sprite artwork together to serve as a set of examples.  Probably something using a complete LPC character sprite sheet.