Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


What is the difference between "Entity" and "Sprite"?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
22 replies to this topic

#1 nimrodson   Members   -  Reputation: 275

Like
1Likes
Like

Posted 03 February 2013 - 09:04 PM

Just that. Thanks.



Sponsor:

#2 Hodgman   Moderators   -  Reputation: 30926

Like
5Likes
Like

Posted 03 February 2013 - 09:14 PM

Depends on the context wink.png

 

An "entity" is a thing. Usually in game engines, every object in the world is an "entity".

 

A "sprite" is a 2d image. Some game engines might have a sprite-entity, which is a thing that can be drawn using a picture.



#3 Serapth   Crossbones+   -  Reputation: 5581

Like
3Likes
Like

Posted 03 February 2013 - 09:17 PM

Well, both are fairly abstract terms, so there isn't strictly a definition of either.

 

Generally a sprite is a visual object drawn to the screen, often a single texture or image contains multiple sprites ( called a spritesheet ).  Sprites can represent the visual representation of all kinds of things... the score, the player, enemies in the world, etc...

 

Entity generally is at a higher level.  Let's take PacMan as an example, there might be a dozen sprites repesenting PacMan in his various frames of animation.  The Entity would be PacMan itself, but in addition to graphic information, it could also hold values like number of lives remaining, current facing direction, current frame of animation, etc.



#4 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 03 February 2013 - 09:26 PM

Depends on the context wink.png

 

An "entity" is a thing. Usually in game engines, every object in the world is an "entity".

 

A "sprite" is a 2d image. Some game engines might have a sprite-entity, which is a thing that can be drawn using a picture.

 

So should I mantain these concepts separated? Or for the sake of simplicity, can I manage them together?. I mean if I could "mix" graphics issues with game object logic...



#5 Serapth   Crossbones+   -  Reputation: 5581

Like
2Likes
Like

Posted 03 February 2013 - 09:36 PM

Depends on the context wink.png

 

An "entity" is a thing. Usually in game engines, every object in the world is an "entity".

 

A "sprite" is a 2d image. Some game engines might have a sprite-entity, which is a thing that can be drawn using a picture.

 

So should I mantain these concepts separated? Or for the sake of simplicity, can I manage them together?. I mean if I could "mix" graphics issues with game object logic...

 

Definitely separate.  While an entity may have a sprite, the doesn't mean all entities will be sprites, nor necisarily that all entities will even have a sprite and quite possibly an entity will have a number of sprites.. 

 

At the end of the day though, entity is whatever you make it, if you choose to use such a class at all.  ( While sprite has a pretty well defined meaning, and shouldn't really be used to be anything other than a 2d image ).



#6 frob   Moderators   -  Reputation: 22218

Like
4Likes
Like

Posted 03 February 2013 - 09:48 PM

Spawners are a great example of an entity that is not a sprite.

Doors/portals, waypoints, and other invisible things are all game objects without visible components.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#7 Servant of the Lord   Crossbones+   -  Reputation: 20275

Like
2Likes
Like

Posted 03 February 2013 - 10:07 PM

A "sprite" is a 2d image. Some game engines might have a sprite-entity, which is a thing that can be drawn using a picture.

 

But, as mentioned, it depends. Some games don't consider 2D tiles to be 'sprites', but will consider character and NPC animations to be composed of sprites. A GUI button might not be considered a sprite, but the particle effect image for a fireball might be. So it really is vague and varies from game engine to game engine.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#8 MrDaaark   Members   -  Reputation: 3555

Like
1Likes
Like

Posted 04 February 2013 - 12:46 PM


Typically, and as simply as possible: These terms can and will be redefined, reused, and used interchangeably by other users and any engines.

In pong, the paddles and the ball are entities. A paddle entity would consist of a size and a position. The ball entity would be a size, position, and a velocity.

The sprites are the images that are drawn to the screen to represent those entities visually.

*Sprites are also soft-drinks and fairy like creatures. biggrin.png

#9 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 04 February 2013 - 04:42 PM

Typically, and as simply as possible: These terms can and will be redefined, reused, and used interchangeably by other users and any engines.

In pong, the paddles and the ball are entities. A paddle entity would consist of a size and a position. The ball entity would be a size, position, and a velocity.

The sprites are the images that are drawn to the screen to represent those entities visually.

*Sprites are also soft-drinks and fairy like creatures. biggrin.png

 

And how can i managed sprites and entities in separated way? I think I need to read some resources about entities, and how interconnect it with sprites.



#10 MrDaaark   Members   -  Reputation: 3555

Like
1Likes
Like

Posted 04 February 2013 - 04:54 PM

And how can i managed sprites and entities in separated way? I think I need to read some resources about entities, and how interconnect it with sprites.

That's entirely up to you. Everyone's implementation is different.

If you are writing a simple game, they might not know about each other at all. Your rendering code will just loop through the list of things you want to draw, and hardcode everything.

If you were writing an engine, or a had a system with a generic entity that could be used for anything, you'd have a pointer or reference to a sprite to be used, along with all the other data that entity needed.

#11 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 04 February 2013 - 05:47 PM

If you are writing a simple game, they might not know about each other at all. Your rendering code will just loop through the list of things you want to draw, and hardcode everything.

 

Yes I'm writing a simple game: on the one hand, I have an entity (i.e. a spaceship) in which I've already coded all it logic (moving forward, backward, rotating to a direction). By the other hand, I have a spaceship sprite which contains a 2D image and a render function.

I could have in a Game class a list of sprites where each one of those has a relation with a entity. So, when I want to update the screen, I would do the following:

 

def updateScreen(game, screen):
  for sprite in game.sprites:
    sprite.render(screen)

But, what if I wanted to update the game state?

 

def updateState(game):
  for sprite in game.sprites:
    sprite.entity.update() #Something like this could be fine?

Or would be better to mantain two lists (sprites, entities) and manage them separatly?

 

Thanks



#12 Ravyne   GDNet+   -  Reputation: 7743

Like
2Likes
Like

Posted 04 February 2013 - 06:26 PM

As we see, the general consensus is that an entity represents a distinct thing or actor in the game, and sprite represents its graphical representation -- but, every engine is different and you can split hairs 6 ways from Sunday.

 

The important thing is that your design is functionally decomposed -- that's just another way of saying, "uphold the single responsibility principle". At some level you have a thing that participates in the world in some way, and that thing may or may not have a visual component. At another level, you have a graphical representation, or appearance, which could be a 2-D image or a 3-D model, which is used to represent certain things within the game visually. Usually, many things might share this appearance, so its more optimal for visually similar things to share a single appearance, than for every thing to have its own, distinct appearance. If animation is involved, then the appearance will often know that it supports animation, and the animation state for each thing is stored separately, either as part of the thing, or in an object dedicated to storing animation state, which is referenced by each thing.

 

This separation, of thing and appearance, with animation somewhere in between, usually suffices for simple graphics. But you can introduce additional variables to affect the basic appearance in subtle ways -- for example, a variable might control whether a particular enemy slime is green, blue, or red, without having a wholly different appearance object than other slimes of different colors. In that case, this color variable would, like animation state, either be part of thing, or in an object that thing references.

 

I've used thing, and appearance here to sidestep any preconception about what these terms mean, but for my money they're synonymous with entity and sprite (or model, for 3-D). You should use names that make sense, but at the end of the day its the organization of and relationships between objects that make things "right" or not. Concern yourself first with a structure that makes sense and is properly decoupled. In isolation, having the right names on the wrong solutions won't make your code any more usable.



#13 Ravyne   GDNet+   -  Reputation: 7743

Like
1Likes
Like

Posted 04 February 2013 - 06:33 PM

It's also worth mentioning that component-based design largely sidesteps the subtle hair-splitting that occurs around wishy-washy notions like entities (and their properties like sprites) in all their permutations. Its more complicated to get running, but its very flexible thereafter. Component-based design essentially does away with such hair-splitting by accepting and embracing it as a natural consequence of trying to put so many slightly different things in a single bucket.


Edited by Ravyne, 04 February 2013 - 06:43 PM.


#14 MrDaaark   Members   -  Reputation: 3555

Like
2Likes
Like

Posted 04 February 2013 - 06:42 PM


I'll go back to the pong example here.

The GAME code doesn't need to know anything about the graphical side. While it's very important that game be DESIGNED with all subsystems in mind, working in harmony, the actual coded sub-systems don't need to know or care about each other most of the time.

The paddle entities move back and forth either on player input, or a AI tick. The ball entity will move according to it's velocity, and will check other entities for collision. It doesn't need to know or care about resolutions, or sprites, or anything else.

The renderer will take the current state of the game and create an image that represents it. It will loop through the entities and render the proper sprite at the proper position for each one. The sprites don't need to know about anything except maybe how many unique objects are referencing them.

You can even replace the 2D renderer with a 3D one, and the gamestate and it's entities don't have to know, or even change, because of their single responsibility (as Ravyne puts it).

#15 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 04 February 2013 - 07:25 PM

The renderer will take the current state of the game and create an image that represents it. It will loop through the entities and render the proper sprite at the proper position for each one. The sprites don't need to know about anything except maybe how many unique objects are referencing them.

You can even replace the 2D renderer with a 3D one, and the gamestate and it's entities don't have to know, or even change, because of their single responsibility (as Ravyne puts it).

 

Great. You're suggesting that a GAME hasn't any reference to render code; instead, it might have a renderer subsystem that cares about it (which could be 2D or 3D, it won't affect the game logic). But then, how can I know how a entity could be rendered (or how can i bind it a sprite ) without have any "graphic" information on it?

 

Newly thanks to all 



#16 Ravyne   GDNet+   -  Reputation: 7743

Like
1Likes
Like

Posted 04 February 2013 - 08:27 PM

Typically, there's some kind of abstract (by which I mean the general meaning of, not 'abstract' in the C++ sense) 'marker' which is system-neutral.

An object has some marker which says its a ball, or a paddle, or a zombie, or whatever, and so the game logic looks at it and makes it behave like a ball and, independently, the renderer looks at the same object and makes it look like a ball. The game logic has some mechanism for updating all the stuff it needs to update, and the renderer likewise has some mechanism for looping over all the stuff it needs to draw -- this might be a scene graph, or some list of entities that need to be drawn, often involving the visitor pattern. But the key point here is that, as far as the game logic is concerned, a ball only has to behave like a ball--it couldn't care less what a ball looks like--and likewise, the renderer only needs enough information to draw the ball--it couldn't care less about the direction, mass, or velocity of the ball, or whether its controlled by a human or AI player.

Note that this doesn't mean that the two systems don't have to agree for best results. Your pong game is going to behave rather oddly if the game logic thinks that the ball has radius 5, but the renderer draws it as if it has radius 7. So, at some point, usually either by convention or at construction, these systems come to agree on certain properties of the object, but the game logic never *directly* influences the renderer, nor vice versa.

Edited by Ravyne, 04 February 2013 - 08:33 PM.


#17 Ravyne   GDNet+   -  Reputation: 7743

Like
1Likes
Like

Posted 04 February 2013 - 08:41 PM

By the way, all this talk about component-based systems and having game logic and graphics rendering so completely decoupled is sort of the "industrial strength" solutions.

 

Are these solutions better practice than less-general, more-coupled code? Absolutely. But it's also not strictly necessary for lighter-weight situations. It really comes down to whether the weight of your needs is sufficient to pay the cost of admission for decreased coupling. It's also a spectrum of solutions -- I'd still keep a separation between thing, animation, and appearance, in all cases, but would I go full-bore, mega-scene-graph, abstract-renderer for Pong, or Tetris? Probably not, unless there were real plans to  support multiple ways of viewing the game.



#18 MrDaaark   Members   -  Reputation: 3555

Like
1Likes
Like

Posted 04 February 2013 - 11:31 PM

Great. You're suggesting that a GAME hasn't any reference to render code; instead, it might have a renderer subsystem that cares about it (which could be 2D or 3D, it won't affect the game logic). But then, how can I know how a entity could be rendered (or how can i bind it a sprite ) without have any "graphic" information on it?
 
Newly thanks to all

Beginners tend to mix all their game logic, rendering code, and input into one big mess.

A Game of course will have references to everything. But every component that a game is made up of only needs to know about itself. This is no different than a real machine.

I just made a cup of coffee in a single cup coffee maker. It is composed of a few subsystems that don't know about each other, but work together to solve the problem.

When I turn the unit on the main part asks the water tank if there is enough water. If it says yes, it turns on the heater for about 30 seconds. Then it says 'ready'.

This means I put my cup on the tray, and a coffee cartridge in the holder and close it. Then I press one of the brew buttons.

The machine sucks the water out of the tube and sends it to a little heater. Then it shoots it through the cartridge and out a hole. Then that drop of coffee lands in my cup.

All those little components do their job independently and don't know about each other. The tank heats on command and reports water level. The tube moves the water from point A to B. And finally the little nozzle thing heats that one drop to boiling point and shoots it through the cartridge and out of the machine.

The machine doesn't even know if there is a cup on the tray, or a cartridge in the slot! That's out of it's scope of responsibility. Just like any component in the machine, that's my single area of responsibility in the equation.

So, you can combine several types of things into a higher level thing.

class GameObject
{
Entity entity;
Sprite* sprite;
WhateverElse we;
}

Also, another example would be a resource loader. It just passes pointers to loaded objects, and doesn't know anything else about them.

When you create a gameobject you need to assign a sprite. You get it from the resource loader.

GameObject Paddle1;
Paddle1.sprite = ReourceLoader.GetSprite(".../Paddle.dds");

The GetSprite() will scan over it's list of loaded assets. If it finds ".../Paddle.dds" has already been loaded, it will simply return a pointer to it, and add 1 to the reference count. If it's not loaded, it will load the image, add it to the list of loaded images, add 1 to the reference count, and then return the pointer.

When you are done with your objects, you call ResourceLoader.KillSprite(".../Paddle.dds"), and that will simply decrease the reference count on ".../Paddle.dds". If the reference count reaches 0, it will be deleted from memory (or marked as free so another can be loaded on top of it).

The ResourceLoader knows nothing about the game or anything else outside of it's realm of responsibility. It just counts, loads, and passes out pointers to loaded assets on request.

#19 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 05 February 2013 - 04:39 PM

So, you can combine several types of things into a higher level thing.

class GameObject
{
Entity entity;
Sprite* sprite;
WhateverElse we;
}

OK, and who is responsible of listening events? A game object? Or an entity? Thanks

#20 MrDaaark   Members   -  Reputation: 3555

Like
1Likes
Like

Posted 05 February 2013 - 05:38 PM

The game logic will update all the data on the GameObject.Entity objects, and then the renderer will loop through those GameObject.Entity objects to use their positions and sizes, and it will draw them using the GameObject.Sprite data they are pointing to.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS