This thing just an idea at this point. Basically, your typical game loop will consist of iterating over a collection of objects and calling some kind of update operation on each. I would like to replace this with asynchronous signaling. Signaling could include messages like "update this object". These messages would trigger certain async processes to start in the object. This may allow for more flexible and asynchronous programming, since not everything has to fit into an update cycle.
On Sunday, 3 April 2016 21:10:16 UTC-7, Rangel Spasov wrote: > > Without knowing too much about the internals, but having used > core.async/channels a lot, I don't think "hundreds" of channels will be a > problem ever. However, as always the devil is in the details. People might > be able to give better feedback if you give more details about your use > case. > > On Saturday, April 2, 2016 at 7:59:50 PM UTC-7, JvJ wrote: >> >> >> Lately, I've been working on a game in Clojure, and I've been trying out >> various ways of modelling the game state and objects. >> >> One of these ideas is to give each object its own channel and make a >> fully asynchronous architecture. >> >> I would like to know if having potentially hundreds of channels operating >> at once would be a significant performance issue. >> >> Thanks. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
