3 ms·

I had to come here after reading up to the "Command" interface idea. This book has a lot of things that look good on a 3 to 4 element case but, when scaled up,

I had to come here after reading up to the "Command" interface idea. This book has a lot of things that look good on a 3 to 4 element case but, when scaled up, will become unwieldy. Adding all of this complexity to button clicks does not sound very intuitive. The original if statement wasn't either but the Command interface wasn't a good replacement. I've always liked using event systems for handling actions like this. C++ would probably be a great language to implement a fast priority based, cancellable, and event system. For something along the lines of what I'm talking about see [1]. It's not perfect (you need a dispatcher for every event) but it still better captures the idea that "Something happens and it triggers N many actions". Maybe it's just different style. Maybe it's just different ways of thinking about the problem. Maybe it's just that I'm not a gamedev and I work in a different sector. [1] - https://codereview.stackexchange.com/questions/118628/c14-event-system https://codereview.stackexchange.com/questions/118628/c14-ev...

ghusbands 9y ago
Given that the book talks about it being used for controller buttons and for undoable actions in strategy games and editors, performance is not a significant concern and event-dispatchers are insufficient. Your comment is not particularly on-topic.
- gravypod 9y ago
  > Given that the book talks about it being used for controller buttons and for undoable actions in strategy games and editors The state should be managed by a UI object if you're talking about calling up UIs. The key presses will be subscribed to in that object and, when the event is triggered, the UI object takes over. Then the button is clicked again the UI object can undo whatever state it has created. > performance is not a significant concern Performance isn't my concern. My concern is that you've created 6 new classes to handle 5 button clicks. That sort of class bloating makes it very difficulty to enter the code base (lots of unneeded wrappers for actions). It also decouples the action from the object that the action is built for. This spreading doesn't make sense to me. The UI object should handle all things UI. The player's object should handle all things player. A Command object shouldn't be extended by 10 other objects who all touch different objects doing different things. > event-dispatchers are insufficient Why? > Your comment is not particularly on-topic. It is. I am talking about how I only got a few pages in and found it to be promoting patterns I'd consider harmful which either use an abstraction that doesn't fit the problem, or do things that make it very hard to enter a new code base.
  - ghusbands 9y ago
    As you say, you've not programmed games, and it becomes clear in your further replies. To describe the often-used Command pattern as "harmful" is somewhat obtuse. Event-dispatch does not include undo functionality, and the command pattern can itself enhance debugging. That you dislike a particular, widely used pattern in the few pages you've bothered reading of a book that's outside of your experience doesn't really help anyone interested in reading that book. That's why I described it as not particularly on-topic.
    - MereInterest 9y ago
      And in that case, the polite response would be to explain why the pattern is used, rather than attacking the OP as being off-topic. Reading and asking questions when things are not understood, as the OP did, is how one gains understanding. Saying that someone should not even ask questions unless one has experience, as you did, is how one discourages people from learning.
      - ghusbands 9y ago
        If the OP had been asking questions, I might. Instead, they were posting unfounded, authoritative, nitpicking negativity ("the Command interface wasn't a good replacement") against what looks to be a reasonably good book. I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.
        gravypod 9y ago
        > unfounded, authoritative, nitpicking negativity After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example. The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already. If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms. I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment). > against what looks to be a reasonably good book A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1]. > I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal. If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end. [1] - https://en.wikipedia.org/wiki/Knuth_reward_check https://en.wikipedia.org/wiki/Knuth_reward_check
BatFastard 9y ago
In my game engine each set of events has its own event dispatcher (for example a model loading event has 6 stages). Its make it much easier to see who events a class is using, exactly who is using them. Also provides a better sense of encapsulation.
- gravypod 9y ago
  I agree that it can help with debugging but it puts that other "load" into your brain. Which dispatcher do I want for this event? If you're using C++ or another strongly typed language then it's probably fine because you'll get a compiler/IDE error about your types. If you're using something more "loose" having a central router helps.
  - BatFastard 9y ago
    For me it does just the opposite. Since each event class has its own dispatcher, the question of which dispatcher disappears. RegionEvent.create( RegionEvent.ADD_MODEL, series, guid, modelData ); The dispatcher is internal to the RegionEvent. The other great thing here is the custom events allow me to pass the type of parameters that are appropriate for this class. which is handled by RegionEvent.addListener( RegionEvent.ADD_MODEL, addModel ); I also use the rule that all event have to be treated as async events. This pattern works great for non real time portions of my engine.
    - gravypod 9y ago
      That's very nice. I'll have to give this a try in my work. Never thought about that.

ghusbands 9y ago

Given that the book talks about it being used for controller buttons and for undoable actions in strategy games and editors, performance is not a significant concern and event-dispatchers are insufficient. Your comment is not particularly on-topic.

gravypod 9y ago
> Given that the book talks about it being used for controller buttons and for undoable actions in strategy games and editors The state should be managed by a UI object if you're talking about calling up UIs. The key presses will be subscribed to in that object and, when the event is triggered, the UI object takes over. Then the button is clicked again the UI object can undo whatever state it has created. > performance is not a significant concern Performance isn't my concern. My concern is that you've created 6 new classes to handle 5 button clicks. That sort of class bloating makes it very difficulty to enter the code base (lots of unneeded wrappers for actions). It also decouples the action from the object that the action is built for. This spreading doesn't make sense to me. The UI object should handle all things UI. The player's object should handle all things player. A Command object shouldn't be extended by 10 other objects who all touch different objects doing different things. > event-dispatchers are insufficient Why? > Your comment is not particularly on-topic. It is. I am talking about how I only got a few pages in and found it to be promoting patterns I'd consider harmful which either use an abstraction that doesn't fit the problem, or do things that make it very hard to enter a new code base.
- ghusbands 9y ago
  As you say, you've not programmed games, and it becomes clear in your further replies. To describe the often-used Command pattern as "harmful" is somewhat obtuse. Event-dispatch does not include undo functionality, and the command pattern can itself enhance debugging. That you dislike a particular, widely used pattern in the few pages you've bothered reading of a book that's outside of your experience doesn't really help anyone interested in reading that book. That's why I described it as not particularly on-topic.
  - MereInterest 9y ago
    And in that case, the polite response would be to explain why the pattern is used, rather than attacking the OP as being off-topic. Reading and asking questions when things are not understood, as the OP did, is how one gains understanding. Saying that someone should not even ask questions unless one has experience, as you did, is how one discourages people from learning.
    - ghusbands 9y ago
      If the OP had been asking questions, I might. Instead, they were posting unfounded, authoritative, nitpicking negativity ("the Command interface wasn't a good replacement") against what looks to be a reasonably good book. I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.
      - gravypod 9y ago
        > unfounded, authoritative, nitpicking negativity After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example. The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already. If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms. I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment). > against what looks to be a reasonably good book A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1]. > I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal. If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end. [1] - https://en.wikipedia.org/wiki/Knuth_reward_check https://en.wikipedia.org/wiki/Knuth_reward_check

BatFastard 9y ago

In my game engine each set of events has its own event dispatcher (for example a model loading event has 6 stages). Its make it much easier to see who events a class is using, exactly who is using them. Also provides a better sense of encapsulation.

gravypod 9y ago
I agree that it can help with debugging but it puts that other "load" into your brain. Which dispatcher do I want for this event? If you're using C++ or another strongly typed language then it's probably fine because you'll get a compiler/IDE error about your types. If you're using something more "loose" having a central router helps.
- BatFastard 9y ago
  For me it does just the opposite. Since each event class has its own dispatcher, the question of which dispatcher disappears. RegionEvent.create( RegionEvent.ADD_MODEL, series, guid, modelData ); The dispatcher is internal to the RegionEvent. The other great thing here is the custom events allow me to pass the type of parameters that are appropriate for this class. which is handled by RegionEvent.addListener( RegionEvent.ADD_MODEL, addModel ); I also use the rule that all event have to be treated as async events. This pattern works great for non real time portions of my engine.
  - gravypod 9y ago
    That's very nice. I'll have to give this a try in my work. Never thought about that.