Hi guys,
It's been a long time since I posted last time. By fate last half a year I worked on one non-game project (3d editor actually). Despite non-game character of the program, I tried to apply maximum of the architecture solutions described in the book.
I must tell that logic-view-screen approach is simply awesome (despite that in the program I had only single view, obviously no bots will 'play' the editor :D). Sending input in the form of messages down from the function which catches the input is great as well (although I didn't have controllers and just handles the input in the screens, probably I didn't understood the purpose of the controllers...). Used processes in several places, but yet again seems likes (at least in Unity) ticked updates is fairly simpler way to make simple animations.
All good so far, but the event system raised more questions than everything else. At the first glance, it's perfect for solving many questions, but on practice I faced the fact that I simply can't construct the set of rules when the system should be applied. Detailed description below.
Look at the image. It shows pretty standard workflow in the program. Although the scenario is non-game related, but you can easily change it to the example with throwing a grenade..
[IMG:http://s17.postimg.org/m19j4ujpb/Workflow.png]
Clearly there are two places where we need some form of communication (marked with blue number 1 and 2). If we make more generic conclusion, these two numbers can be called: request and notification.
So, where should one use the events? At first phases of my program I've used events in both cases, e.g.
Using this method I quickly realized that this bring more complications that profit... While number '2' from the scheme still should be implemented as an event so I don't need to call every system manually when the file is opened, but number '1' probably shouldn't... In the practice '1' has been addressed to the one and only one method in the whole program (e.g. ProjectManager.Open() method). Now I can of course call that method indirectly by using the event, but I can't see any pluses to just calling the method directly!
Trying to derive some meaningful thoughts from the situation I came to the conclusion that '1' rarely need an event at all (while '2' still should be an event). And this applied to almost any scenario in the program. Request is always aimed at single object and/or method. While the effect may disturb many sub-systems. What do you think about this? Am I missing something here?
I also found that changing the object via events bring complications as well. If we forget for a minute that I was working on the editor then the objects in my scene could be treated as game actors and many properties they have could be just 'health', 'mana' etc.. But writing an event for changing every single property quickly added a bunch of events even in the beginning, so I dropped this idea and just changed the properties via instance of the object (actor) directly. Probably this is not applicable to the editors, and only work for game scenarios with scripting systems.. I couldn't figure out this myself. Speaking generally, this question could be summarized as - should one change object properties via events or directly? And this touch both cases - GUI screens and 'game' screens.
One of the ideas I got is - sometimes it's hard to get the object which should handle the event (e.g. it's deep down the 'has-a' hierarchy, in this casecalling via events simplifies things, but these cases are rare). Second thought is that probably request event can solve the problem of changing the symantics? E.g. if for example I need to change the name or parameter order of the actual method, all the events will stay the same! But if I add some data to the event I will still need to revisit every single place in the program where the event is constructed and modern refactoring features of the VisualStudio solves renaming as well... So I could count second thought as a plus...
Another thing that I found is while events are aimed to decouple systems, some systems are still tightly coupled by their data. Simple example from my program (yeah it's bad style from architectural point of view, but I didn't had much time to fix it alas..) - tooltip system should know if the mouse if over the scene window to handle things properly. If I call SceneManager from the TooltipManager I make solid connection which I don't really want to have.. Rephrasing this case - how do I solve the problem of coupling between systems when I need to GET information from one system in the other? Events, as I understand, are designed to SET information rather than GET. Of course, we can do something like this:
Yet again this is more complex, and slower than just calling and bring EVEN MORE events to the program..
Thanks for reading this long posts, share your thoughts on this!
It's been a long time since I posted last time. By fate last half a year I worked on one non-game project (3d editor actually). Despite non-game character of the program, I tried to apply maximum of the architecture solutions described in the book.
I must tell that logic-view-screen approach is simply awesome (despite that in the program I had only single view, obviously no bots will 'play' the editor :D). Sending input in the form of messages down from the function which catches the input is great as well (although I didn't have controllers and just handles the input in the screens, probably I didn't understood the purpose of the controllers...). Used processes in several places, but yet again seems likes (at least in Unity) ticked updates is fairly simpler way to make simple animations.
All good so far, but the event system raised more questions than everything else. At the first glance, it's perfect for solving many questions, but on practice I faced the fact that I simply can't construct the set of rules when the system should be applied. Detailed description below.
Look at the image. It shows pretty standard workflow in the program. Although the scenario is non-game related, but you can easily change it to the example with throwing a grenade..
[IMG:http://s17.postimg.org/m19j4ujpb/Workflow.png]
Clearly there are two places where we need some form of communication (marked with blue number 1 and 2). If we make more generic conclusion, these two numbers can be called: request and notification.
So, where should one use the events? At first phases of my program I've used events in both cases, e.g.
Using this method I quickly realized that this bring more complications that profit... While number '2' from the scheme still should be implemented as an event so I don't need to call every system manually when the file is opened, but number '1' probably shouldn't... In the practice '1' has been addressed to the one and only one method in the whole program (e.g. ProjectManager.Open() method). Now I can of course call that method indirectly by using the event, but I can't see any pluses to just calling the method directly!
Trying to derive some meaningful thoughts from the situation I came to the conclusion that '1' rarely need an event at all (while '2' still should be an event). And this applied to almost any scenario in the program. Request is always aimed at single object and/or method. While the effect may disturb many sub-systems. What do you think about this? Am I missing something here?
I also found that changing the object via events bring complications as well. If we forget for a minute that I was working on the editor then the objects in my scene could be treated as game actors and many properties they have could be just 'health', 'mana' etc.. But writing an event for changing every single property quickly added a bunch of events even in the beginning, so I dropped this idea and just changed the properties via instance of the object (actor) directly. Probably this is not applicable to the editors, and only work for game scenarios with scripting systems.. I couldn't figure out this myself. Speaking generally, this question could be summarized as - should one change object properties via events or directly? And this touch both cases - GUI screens and 'game' screens.
One of the ideas I got is - sometimes it's hard to get the object which should handle the event (e.g. it's deep down the 'has-a' hierarchy, in this casecalling via events simplifies things, but these cases are rare). Second thought is that probably request event can solve the problem of changing the symantics? E.g. if for example I need to change the name or parameter order of the actual method, all the events will stay the same! But if I add some data to the event I will still need to revisit every single place in the program where the event is constructed and modern refactoring features of the VisualStudio solves renaming as well... So I could count second thought as a plus...
Another thing that I found is while events are aimed to decouple systems, some systems are still tightly coupled by their data. Simple example from my program (yeah it's bad style from architectural point of view, but I didn't had much time to fix it alas..) - tooltip system should know if the mouse if over the scene window to handle things properly. If I call SceneManager from the TooltipManager I make solid connection which I don't really want to have.. Rephrasing this case - how do I solve the problem of coupling between systems when I need to GET information from one system in the other? Events, as I understand, are designed to SET information rather than GET. Of course, we can do something like this:
Yet again this is more complex, and slower than just calling and bring EVEN MORE events to the program..
Thanks for reading this long posts, share your thoughts on this!
Looking for a job!
My LinkedIn Profile
My LinkedIn Profile