What is an entity?

[Stef569]

davedes on the slick forum sais: I'm not familiar with MarteEngine, but why do your HUD/GUI elements need to extend Entity? Can't you just render your own HUD graphics after rendering your game entities/characters?

I agree, gui and hud don't need to extend entity. Some will use Thingle/nifty/twl or a custom ui that does not allow to extend Entity.
The solution render the gui after the entities:

 render(Graphics g) {
    world.render(g);
    gui.render(g);
 }

This brings us to an interesting question. What is an entity? Mario is an entity, Units and buildings in an rts are Entities. But in my opinion the ui is not. Because mario and units move around, they interact with the game world.

For example a button to mute the music, is that an entity? I would say no, because it does not move. That would be a Button class.
It should not collide with entities in the game for example.

thoughts?

[Gornova]

An entity is something have to be rendered or updated in my mind

[xori]

I agree with @Gornova. UI is just an entity on a different z index.

[Stef569]

I disagree =)

When you extend an Entity you get so much more then rendering and updating like:

• Collision detection, Animation, Moving, Rotating, Alpha, State manager, keep in world bounds

While an ui does not collide, does not animate, does not move, rarely rotates, does not fade, maybe has different states, never leaves the world boundaries. It's even not part of the world.

Based on these facts ui is not an entity, but there is nothing stopping somebody to do it, we will just not encourage it.

There is too much confusion about the world.add extra param for example, above game below.

An entity is always in the world what gives. If entity is not used as ui what would the usage of above/below be?

This is how fuzzy shows the ui, not using an entity
https://github.com/Gornova/MarteEngine/blob/master/test/it/marteEngine/test/fuzzy/FuzzyGameWorld.java#L333

This is how starcleaner shows the ui, using an entity, notice that it is using 1 method of the super class.
https://github.com/Gornova/MarteEngine/blob/master/test/it/marteEngine/game/starcleaner/MessageWindow.java

[xori]

When I built my engine a while back an Entity (for me) was anything that was drawn to the screen. Let me show you my hierarchy.

Entity -> AnimatedEntity -> CollisionableEntity -> ControllableEntity

• The Entity base class would be x,y,z and the image. Basics for drawing.
• AnimatedEntity would be... animating.
• CollisionableEntity was how I included collision detection, extended classes could subscribe/produce events.
• ControllableEntity an Entity with a 'brain', whether the 'brain' was AI or the mouse/keyboard.

This way depending on the flexibility of what you wanted you could just extend what you needed. The UI you gave as an example would only require extending the base class. But imagine with me this...

If everything drawn to the screen is an entity, then what if we consider the Mouse an entity? It has a hitbox and can collide with other entities (buttons) and change their state/its state. For my game I had some quadratic easing also applied to the mouse. With this in mind what class would you extend? The ControllableClass.

I think the issue is that the Entity class in this project isn't abstracted enough. It's one monolithic super class. (Probably done for simplicity.) But creating another class duplicating a lot of what Entity already does seems silly to me.

By all means the above method I choose isn't perfect and I'm not suggesting you follow it, but doesn't a more structured render pipeline seem easier to maintain in the future? Rather than duplicate code?

[Gornova]

My idea from the start for ME was simplicity. With MarteEngine you are doing little games, not big games. So duplicated code isn't a matter. What you can achieve with ME is get things on screen fast and moving, even UI.

I'm blocket by this idea too! In my tower defense game I'm stuck with UI, because all is an entity. So I propose: simple UI can be done with entities, but more complex require other library (nifty or Twl, for example).
We can discuss how we can support third part libraries into ME: this can be a real help for game developer using ME, what do you think ?

[Stef569]

Entity -> AnimatedEntity -> CollisionableEntity -> ControllableEntity

I don't like this hierarchy, having 1 Basic Entity class seems ok to me. Don't make the user choose what entity they need. It should not become a god class but it is kinda large... the angle math could go into MathUtil, and collision code could be delegated. Besides that it is fine.

My idea from the start for ME was simplicity

If ME is simple it should not have to support an ui lib. The ui should just be rendered after the world like in my first post. I haven't tested if this works but we can't support all ui libs, first there was sui then thingle then nifty and now twl...

Do we want to code a simple Menu, Button, Panel, pop up menu ourselves? classes that don't extend entity...
Like a button with a single image:

Button b = new Button(img, 100, 10)
b.addKeyBind(Input.KEY_M)
b.addMouseBind(Input.LEFT_MOUSE_BUTTON)
b.addPressedSound(Sound)
b.addPressedListener(ButtonListener)
b.render
b.update

Without theming, just a simple Button.

[Stef569]

If Entity was an interface Button could implement it:
The world atm uses following entity methods:

getBounds()
isType(String)
removedFromWord()
hasName(String)
update(GameContainer, int)
render(GameContainer, Graphics)
isActive()

[xori]

Button b = new Button(img, 100, 10)
b.addKeyBind(Input.KEY_M)
b.addMouseBind(Input.LEFT_MOUSE_BUTTON)
b.addPressedSound(Sound)
b.addPressedListener(ButtonListener)
b.render
b.update

With the addition of addHoverListener() that would be a sexy way to make UI.

[Gornova]

So we disagree on this. No problem: Github can help us: Stef, just fork ME and take your direction, what do you think? So I can see your idea at work

[Stef569]

I'll make a new fork, to show what I mean...