• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
nimrodson

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

22 posts in this topic

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...

0

Share this post


Link to post
Share on other sites

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 ).

2

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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).
2

Share this post


Link to post
Share on other sites

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 

0

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
For me, Entity is the top level thing, and it contains components, among them perhaps a sprite.

The sprite is rendered because the sprite component registers it with the graphics subsystem.

Similarly, an event listening component could register to receive events. But what I actually do is push the events out, because I know which entities need input.
1

Share this post


Link to post
Share on other sites
Yes, that or whatever works best for your purposes.

There is no 100% catch all answers for things like this, because programming allows you to organize your data any way you like.

Figure out how your game is going to work. Then you'll know what data you need to keep track of, and how you'll need to organize and process it.

A GameObject class will then consist of anything you know you'll need. Then an entity will also consist of anything the logic will need to see. It might even be an abstract class with different versions that do different things.
0

Share this post


Link to post
Share on other sites

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  
Followers 0