Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualfutlib

Posted 24 October 2012 - 10:52 PM

What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP.


Widget is definitely a meaningless term in general. But in user interfaces, it universally means "UI element". So yes, there are things that are true for all widgets. That's probably why OO and UIs where invented together Posted Image Widget isn't only the base class for code reuse, but for polymorphism, and understanding.

With my lack of experience in game development, I cannot say if classical OO makes as much sense there. I've read a lot about component-based systems lately, so maybe not. But my main sources of inspiration (the Doom 3 engine and Frictional Games's HPL1Engine) seem to be wired that way. (Both admittedly a bit aged, but I'm struggling to find good open source game code bases, let alone recent ones.)

The component-based approach seems like a good idea, definitely more flexible. But I'm not sure if it's the right choice in my situation. I'm working on a small-ish 2D game with pretty simple gameplay, mostly myself. You're saying: "It’s not that an inheritance based entity system is inherently wrong per se, but in large systems it tends to become an impossible to manage web of sloppy code". I'm not working on a large system, I think it makes sense to keep things as simple as possible.

I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable.


Hm. I think it makes a lot of sense to think about my game objects in terms of components, even if I don't use a component-based system. In my case this would be:

Entity
  • Can be drawn
  • Can be updated
Widget
  • Can be drawn
  • Handles its own input
  • Can contain other widgets

Looking at this, it seems I cannot reasonably derive one from the other. A widget is not updated by the game loop, it handles input itself and invokes callbacks. And it contains other widgets, to which it forwards any relevant input. Entities on the other hand are regularly updated by the scene, which handles all user input and decides what should happen to the entities based on it.

Now how does that distinction fit in with scenes? Should scenes be able to handle both entities and widgets? Should I have a special kind of entity that acts as a container for a widget? I'm stumped.

#1futlib

Posted 24 October 2012 - 10:51 PM

What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP.


Widget is definitely a meaningless term in general. But in user interfaces, it universally means "UI element". So yes, there are things that are true for all widgets. That's probably why OO and UIs where invented together :) Widget isn't only the base class for code reuse, but for polymorphism, and understanding.

With my lack of experience in game development, I cannot say if classical OO makes as much sense there. I've read a lot about component-based systems lately, so maybe not. But my main sources of inspiration (the Doom 3 engine and Frictional Games's HPL1Engine) seem to be wired that way. (Both admittedly a bit aged, but I'm struggling to find good open source game code bases, let alone recent ones.)

The component-based approach seems like a good idea, definitely more flexible. But I'm not sure if it's the right choice in my situation. I'm working on a small-ish 2D game with pretty simple gameplay, mostly myself. You're saying: "It’s not that an inheritance based entity system is inherently wrong per se, but in large systems it tends to become an impossible to manage web of sloppy code". I'm not working on a large system, I think it makes sense to keep things as simple as possible.

I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable.


Hm. I think it makes a lot of sense to think about my game objects in terms of components, even if I don't use a component-based system. In my case this would be:

Entity
  • Can be drawn
  • Can be updated
Widget
  • Can be drawn
  • Handles its own input
  • Can contain other widgets
Looking at this, it seems I cannot reasonably derive one from the other. A widget is not updated by the game loop, it handles input itself and invokes callbacks. And it contains other widgets, to which it forwards any relevant input. Entities on the other hand are regularly updated by the scene, which handles all user input and decides what should happen to the entities based on it.

Now how does that distinction fit in with scenes? Should scenes be able to handle both entities and widgets? Should I have a special kind of entity that acts as a container for a widget? I'm stumped.

PARTNERS