user471 Posted March 24, 2018 Share Posted March 24, 2018 Phaser 3 uses eventemitter and callbacks and I want something similar to Signals from Phaser 2. What should I use? Link to comment Share on other sites More sharing options...
rich Posted March 24, 2018 Share Posted March 24, 2018 You should use Event Emitter and callbacks. Link to comment Share on other sites More sharing options...
user471 Posted March 24, 2018 Author Share Posted March 24, 2018 5 hours ago, rich said: You should use Event Emitter and callbacks. When JS is moving from callback hell to abstractions like Promise and Rx why would I what to use callbacks? It's much easier to work with Signals. For example when I need to wait all events to complete I can do something like this waitAll(x.onComplete, y.onComplete, z.onComplete).addOnce(x => ...) Link to comment Share on other sites More sharing options...
PixelPicoSean Posted March 24, 2018 Share Posted March 24, 2018 The DOM API uses Event Emitter like approach, and you can still use Promise and Rx on top of that. And Rx does have event emitter support, you only need to create streams for the events you are going to use. Link to comment Share on other sites More sharing options...
user471 Posted March 24, 2018 Author Share Posted March 24, 2018 12 minutes ago, PixelPicoSean said: The DOM API uses Event Emitter like approach, and you can still use Promise and Rx on top of that. I know. The problem is promises doesn't fit because they doesn't support subscription and Rx is to heavy, so I am looking for something like Rx but lightweight. Link to comment Share on other sites More sharing options...
PixelPicoSean Posted March 25, 2018 Share Posted March 25, 2018 There're a lot of FRP libraries, I've used kefir.js and flyd, both of them are really great (and also support EventEmitter like interface) and much better than Rx IMHO. Link to comment Share on other sites More sharing options...
rich Posted March 26, 2018 Share Posted March 26, 2018 One day I really ought to write an article about what's good for a web app is almost never good for a game loop. Electrk, OneSillyLion, hexus and 1 other 4 Link to comment Share on other sites More sharing options...
snowbillr Posted March 26, 2018 Share Posted March 26, 2018 That would actually be a really helpful article. I come from a web dev background and would love to see what the do's and don'ts are compared to that and game dev best practices. Link to comment Share on other sites More sharing options...
rich Posted March 26, 2018 Share Posted March 26, 2018 I just found it amusing that the original post was asking what to use instead of Signals in v3 (the answer is, of course, Events), and then gave an example of something a Signal couldn't ever do anyway. The biggest issue is that web devs lead almost exclusively asynchronous development lives. The overwhelming majority of your code and practices are honed around this, and there are so many libs out there to help with it. Which makes perfect sense, it's how the web itself works after all. Look at Promises, created specifically as a proxy to an as-yet-unknown value. A very common occurrence in web apps. In a game, this is almost never the case though. Very rarely do you ever have to wait for the value, it is nearly always calculated instantly (or should be) or available elsewhere in memory. So introducing an artificial async jump into this value fetch is a really backward step. It's the same with data streams too. Unless you are genuinely fetching remote data all you've actually managed to do is add overhead to a situation that didn't need it. The absolute shortest possible path for your data is the best. Retrieved in the fewest jumps possible, with minimal or no branching, invocations or creation of un-necessary objects (which includes anonymous functions, those wonderful little bundles of gc bait). This goes against everything that is standard for a web app. But you're not building a web app. msickle, labrat.mobi, mazoku and 3 others 5 1 Link to comment Share on other sites More sharing options...
user471 Posted March 26, 2018 Author Share Posted March 26, 2018 4 hours ago, rich said: an example of something a Signal couldn't ever do anyway. What do you mean? You can do something like this function waitAllOnce(signals: Signal[]) { const signal = new Signal() var count = 0 signals.forEach(x => x.addOnce(() => { count += 1 if (count == signals.length) { signal.dispatch() } })) return signal } 4 hours ago, rich said: Very rarely do you ever have to wait for the value Every time you need to use EventEmitter you have an asynchronous process and you need to wait for the value. So if a game doesn't use too much events it wouldn't be a problem. But if it's something like a puzzle game it's very similar to web app, just a complex UI. If it uses tweens for animations and you want to do something after this animations you can use Event Emitter, but it's just easier to use some abstraction over it. Link to comment Share on other sites More sharing options...
rich Posted March 27, 2018 Share Posted March 27, 2018 I meant that Signal.waitAll isn't a native feature of Signals. If you're going to hand-roll it like in your example above then anything is possible and it becomes irrelevant if you use Signals or Events, either would work. Link to comment Share on other sites More sharing options...
Recommended Posts