Sign in to follow this  

[java] Sprite design

This topic is 4690 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there. In designing my java gaming engine, I've come across a thought in sprite design (or rather graphical-object design in general). The typical sprite setup (at least from what I have seen), is .. in a simplified form, an object with a location, velocity, image(s), and an update and render method. Now, I have come across the idea of implementing behaviour as its own set of classes. an example from a sprite perspective might be:

public void setBehaviour(IBehaviour b)
{
   spriteBehaviour = b;
}

public IBehaviour getBehaviour()
{
   return spriteBehaviour;
}

Nothing magical there, of course. However, in the sprite's update and/or render methods (depending on the type of behaviour), control is passed to the sprite's IBehaviour object, which has methods to render and update. My ideas for implementing this: It makes it extremely easy and fluent to add similar patterns of rendering and movement for several sprites, using the same IBehaviour object for multiple sprites. It also makes it very easy to switch render and update patterns for a sprite, by simply giving it a new IBehaviour object. In addition, it makes creating a link between several graphical objects (whose movement algorithms for instance, are dependant or related to each other), so that they may more easily affect and interact with each other. So, my question to you is .. What do you think about this idea? Are there any immediate drawbacks that I am missing? Do YOU use such a setup? If not, why? (because you simply havent thought of it, or because you do not like it?). To me, it looks like a good idea, but I would like some second opinions before I bring it to life. All feedback appreciated.

Share this post


Link to post
Share on other sites
So you are using the IBehavior class to setup the update/render/other methods for the class?

In my engine I have a seperate class that holds all of my images, and then in my Actor class I have a value which is the Sprite Cache Key. This way multiple Actors can have the same graphic without using more memory or resources. So in my Actor class I have a update() and a getSkc() which takes care of the updating and getting the current image. In a seperate class called Tracker the tilemap is stored, and the methods for drawing the Actors are there. That way in my mainloop I can go something like tracker.drawEntireScreen(); and the tracker iterates through all of it's tiles and draws them according to the tile's internal graphic pointer.

I also use this same kind of concept (the sprite cache) with events. I can attach events to Actors. The most common event called in the actor.event("Activate") which is when my cursor hits enter. But because I have an event cache, I can use the same event on multiple Actors. For instance a chest might have a activate event that gives the player gold. You don't want 200 instances of the event to change if you want to edit one line of the code.

Your implementation of the Behavior stuff would then encapsule all of the graphics and events, making it so you have a generic behavior to attach to any number of Actors. I like it!

Share this post


Link to post
Share on other sites
Hi,

Seems like a good idea to me. I use the following:


public interface ActiveObject {
void update();

void render(GraphicsContext3D gc3d);
}

public abstract class Sprite implements ActiveObject {
//...
}


Your post made me re-think this.

son of cain

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Addictman
So, my question to you is .. What do you think about this idea?


This is the "correct" way to write a game.

For the alpha of Survivor we did exactly this, and implemented some of our behaviours as Beanshell scripts (transparent to java code - it just thinks they are class files) and others (those that ran too slowly in bsh) as compiled java classes.

So...go ahead and do it :)

Share this post


Link to post
Share on other sites

This topic is 4690 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this