Hi,

as some might suspect from my recent rise in post frequency, I'm investing some energy into trying to get my code base right ATM.

I'm rather far (luckily, the game is quite simple), and I'd wager I have a usable understanding of the concepts of 2D games by now. What I probably didn't get right yet is the terminology, because I'm more used to 3D games (has been a while though).

Can you give me feedback for my naming of the following classes?

Texture
In a strict 2D sense, I don't think the word "texture" exists, does it? It's pretty much an image, and I'm wondering if I should call it image. What's common here?

Sprite
Actually everything that is visible on the screen. Consists mostly of a texture and a x/y position, but also has support for animations and collision detection. Does this class do too much for the name? Since everything's a sprite in my game (even the background image!), I'm wondering if I should add other types of "renderables", e.g. static images. Again, I'm looking for the most conventional way to do this.

Scene
Pretty much just a list of sprites. Can be drawn by the graphics system. Has a purely abstract "update" method that is regularly called by the main loop, in which input handling can be done. I'm yet wondering whether this is an appropriate use of the term. I'm also wondering if I should add scenes to scenes instead of individual sprites in some cases. Would make it possible to create composite elements, e.g. for the on-screen dialog system. But would it still be a valid use of the word "scene"?

For example, a menu in my game is just a subclass of scene to which I'm adding subclasses of sprite, which act as menu items. Sprite has an "update" method that is regularly called by the main loop and can be overwritten, so that I can check for mouse input and do a mouse over effect etc. Does that sound reasonable (or, which is obviously important to me, common) to you?

If you're using a 3-d rendering API such as OpenGL or Direct3D to create your 2-d game (which is fairly common), then the term 'texture' has the same meaning regardless of dimension (at least as far as the API is concerned). If you're using a non-3-d library or framework to do your rendering, then the term 'texture' probably isn't particularly relevant to you. (This also applies if you're using a library, such as SFML, that hides the details of interoperating with the underlying graphics API from you.)

As for terms like 'scene' and 'sprite', they basically mean whatever you decide they mean. The term 'sprite' is sometimes used to refer only to the images used in a 2-d game, and is also sometimes used to refer to the actual game objects or entities in the game. (To adhere to the principle of separation of concerns, I'd recommend the former usage if you're going to use the term. That is, use the term 'sprite' to refer to the visual representation, not to the entity itself.)

Quote:Original post by jyk
If you're using a 3-d rendering API such as OpenGL or Direct3D to create your 2-d game (which is fairly common), then the term 'texture' has the same meaning regardless of dimension (at least as far as the API is concerned). If you're using a non-3-d library or framework to do your rendering, then the term 'texture' probably isn't particularly relevant to you. (This also applies if you're using a library, such as SFML, that hides the details of interoperating with the underlying graphics API from you.)

I do use OpenGL. I was just wondering whether me talking about "textures" would confuse 2D devs, I generally try to avoid confusing people.

Quote:Original post by jyk
As for terms like 'scene' and 'sprite', they basically mean whatever you decide they mean. The term 'sprite' is sometimes used to refer only to the images used in a 2-d game, and is also sometimes used to refer to the actual game objects or entities in the game.(To adhere to the principle of separation of concerns, I'd recommend the former usage if you're going to use the term. That is, use the term 'sprite' to refer to the visual representation, not to the entity itself.)

In my case, they're refering to all of that, and I'm not quite sure how to separate sprite from "entity".
Sprite = texture, animation, x/y position, collision detection
Entity = What's left?

Quote:Original post by swiftcoder
In traditional terminology:
Sprite = texture.
Entity = everything else.

These days, people often use sprite to mean a combination of the two, but for clarity's sake, I would avoid it.

I see, I can pretty much rename my Sprite class to Entity then, huh? Funny enough, that was it's original name, I thought Sprite was the correct 2D term :)

Beats me that "sprite" is such a loosely defined term... I've read somewhere that some people refer to 2D animations when they say "sprite"...

EDIT:
By the way, would you say that my menu items being sprites/entities is "weird"? I don't really know why, but it feels wrong. Probably because menus and entities are two completely different things in 3D games, to which I'm more used.

[Edited by - futlib on December 29, 2010 2:01:56 PM]

Quote:Original post by futlib
I see, I can pretty much rename my Sprite class to Entity then, huh? Funny enough, that was it's original name, I thought Sprite was the correct 2D term :)

It wouldn't really make sense for entities/game objects to be named differently depending on dimension (the basics of game logic and entity management are more or less independent of spatial dimension).

Quote:Beats me that "sprite" is such a loosely defined term... I've read somewhere that some people refer to 2D animations when they say "sprite"...

The term is used pretty loosely, but again, I'd recommend sticking with the definition of 'a visual associated with an entity in a 2-d game' (or perhaps just, 'a visual characterized by being two-dimensional in nature').

Quote:By the way, would you say that my menu items being sprites/entities is "weird"? I don't really know why, but it feels wrong. Probably because menus and entities are two completely different things in 3D games, to which I'm more used.

I think you're too hung up on dimension. A lot of the things you seem to think differ between 2-d and 3-d games really don't, IMO. The concepts of menus, game entities, and so on are basically the same in each case. As such, I'd suggest not thinking of 2-d games as being qualitatively different from 3-d games. Instead, think of them as being essentially the same, but differing in certain details due to the different spatial and visual representation. (Whatever needs to be done differently due to these differences will become clear during the development process.)

As for menu items being entities, although it's common for the UI system to be separate, no, I don't think menu items being entities would be weird. (Personally, I'm a big fan of component-based entity systems, which largely erases the distinctions between the different 'types' of entities in your game or simulation.)

Quote:Original post by jyk
It wouldn't really make sense for entities/game objects to be named differently depending on dimension (the basics of game logic and entity management are more or less independent of spatial dimension).

Entity it is then. Sometimes the first name one choses is the best one after all I guess. I'm just a bit worried that my terminology may be so off that I basically can't talk to other 2D game developers. If they're familiar with the term "entity" (which is used in every single 3D game/engine I've ever seen), it's favorable, because I'm used to it. Is mixing behaviour/presentation a common thing for entity classes?

And does "scene" still fit? For some reason, I can't seem to recall how this is usually called in a 3D game. "World"? Some 2D libraries call it "screen", but I'm not sure if that's appropriate in my case, where each menu is one scene, and the whole gameplay is (at the moment) a single scene. That's a bit more than just a "screen", isn't it?

Quote:
As for menu items being entities, although it's common for the UI system to be separate, no, I don't think menu items being entities would be weird. (Personally, I'm a big fan of component-based entity systems, which largely erases the distinctions between the different 'types' of entities in your game or simulation.)

I do have a UI system (a couple of classes for menu items etc. - no central class like the graphics system though), but it's based on entities/scenes which reside in the graphics system right now. Wondering if I should move it to a different one, "game" or something, but that's probably another story.

If you say component-based entity systems, I guess that also includes composite entities, i.e. entities consisting of several other entities? That would probably be beneficial, but how would I call something like that?

Quote:Original post by futlib
Entity it is then. Sometimes the first name one choses is the best one after all I guess. I'm just a bit worried that my terminology may be so off that I basically can't talk to other 2D game developers. If they're familiar with the term "entity" (which is used in every single 3D game/engine I've ever seen), it's favorable, because I'm used to it. Is mixing behaviour/presentation a common thing for entity classes?

And does "scene" still fit? For some reason, I can't seem to recall how this is usually called in a 3D game. "World"? Some 2D libraries call it "screen", but I'm not sure if that's appropriate in my case, where each menu is one scene, and the whole gameplay is (at the moment) a single scene. That's a bit more than just a "screen", isn't it?

You're still doing it :) You're acting like 2-d and 3-d game developers are two distinct, insular organizations that guard their respective lexicons jealously and view each other with suspicion and mistrust ;) In other words, you're really making too big a deal of the 'dimensional' aspect of game development (IMO).

Yes, different terms are more frequently used in some contexts than others, and yes, you may get blank stares from some developers when you use certain terms, but that will likely always be the case.

As for your specific questions, conventional wisdom would be that for all but the most trivial applications some effort should be made to keep behavior and presentation (i.e. visual representation) separate (which follows the principle of 'separation of concerns', among other things).

Again, words like 'scene', 'world', 'level', 'screen', and so on mean whatever you say they mean. You'd probably be more likely to use the term 'screen' for one level of a non-scrolling 2-d game than for a level of a 3-d game, but that's fairly self-evident. In 3-d the term 'scene graph' is often used to refer to any logical organization of the objects in the world, e.g. for rendering purposes (a 2-d game could also have a scene graph, but is probably less likely to need one). Separate from that though, the word 'scene' can also be used however you see fit (e.g. to refer to a single level or to the 'game world' as a whole).

In short, don't think of things in terms of dimension, but rather in terms of what they do and what they mean in general.

Quote:If you say component-based entity systems, I guess that also includes composite entities, i.e. entities consisting of several other entities? That would probably be beneficial, but how would I call something like that?

'Composite' or 'hierarchical' entities would probably be fine. (Also, you can have composite entities without a component-based system, and vice versa - the two aren't related in any direct way.)

Quote:Original post by jyk
You're still doing it :) You're acting like 2-d and 3-d game developers are two distinct, insular organizations that guard their respective lexicons jealously and view each other with suspicion and mistrust ;) In other words, you're really making too big a deal of the 'dimensional' aspect of game development (IMO).

That's a bit exaggerated, but I do think along those lines, especially because I don't know any devs that do both 2D and 3D. If that's not the case, that's an answer to my terminology questions as well, I'll try to get used to the idea :)

Quote:
As for your specific questions, conventional wisdom would be that for all but the most trivial applications some effort should be made to keep behavior and presentation (i.e. visual representation) separate (which follows the principle of 'separation of concerns', among other things).

Well, my sprite/entity has most notably two properties: "x/y position" and "texture". The former are two ints, the latter is a Texture object. The sprite/entity is not doing the low-level drawing itself, but it tells the graphics renderer to draw the supplied texture at the supplied position. That's IMO separation of concerns, but everything does come together in the sprite/entity class.

Quote:
'Composite' or 'hierarchical' entities would probably be fine. (Also, you can have composite entities without a component-based system, and vice versa - the two aren't related in any direct way.)

Would you mind explaining what you mean by a component-based system? I'm thinking about something like JSF where each ui widget is, in their terminology, a "component". It's not really self-contained or arbitrarily replaceable as I understand the term.