On 12/18/2012 10:52 PM, Heinrich Apfelmus wrote:
Nathan Hüsken wrote:
On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote:
Fair enough, but I don't see how this can be fitted into a general
pattern. If the animation state is coupled tightly to the game logic
state, then the question whether the
hey all, i've been lurking in this thread for a bit i just found this
interesting article from chris granger (yeah, the light table guy). he
just completed the node knockout they had recently decided to make a
game. he did it all in clojurescript he discusses some aspects of
programming a
Nathan Hüsken wrote:
On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote:
Fair enough, but I don't see how this can be fitted into a general
pattern. If the animation state is coupled tightly to the game logic
state, then the question whether the animation is part of the game
logic or not does not
On 12/12/2012 01:26 AM, Ertugrul Söylemez wrote:
Nathan Hüsken nathan.hues...@posteo.de wrote:
Actually it is very scalable, as the same map is passed to every
object. It can even live in the underlying monad, which means that
you could even use a mutable vector, if you wish; however, I
Am 10.12.2012 16:56, schrieb Ertugrul Söylemez:
Nathan Hüsken nathan.hues...@posteo.de wrote:
I put a pseudo C++ example below the mail. I use the terms model and
view for the game logic and rendering respectively.
The example is a little different. Asteroids explode when they
collide. The
Nathan Hüsken nathan.hues...@posteo.de wrote:
Actually it is very scalable, as the same map is passed to every
object. It can even live in the underlying monad, which means that
you could even use a mutable vector, if you wish; however, I don't
recommend that.
Remember that a map is
On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote:
Nathan Hüsken wrote:
Heinrich Apfelmus wrote:
In that light, the separation seems straightforward to me. Given the
time-varying values that represent game objects,
bSpaceShipPosition :: Behavior Position
bAsteroidPositions :: Behavior
Nathan Hüsken nathan.hues...@posteo.de wrote:
I put a pseudo C++ example below the mail. I use the terms model and
view for the game logic and rendering respectively.
The example is a little different. Asteroids explode when they
collide. The moment asteroids explode, they are removed from
Nathan Hüsken wrote:
Heinrich Apfelmus wrote:
In that light, the separation seems straightforward to me. Given the
time-varying values that represent game objects,
bSpaceShipPosition :: Behavior Position
bAsteroidPositions :: Behavior [Position]
bTime :: Behavior Time
Sorry for the late reply, I somehow missed this eMail ...
On 11/29/2012 06:28 PM, Heinrich Apfelmus wrote:
If I take for example the breakout game from here [1]. It outputs an
object scene of type Picture. But this picture is calculated from the
objects ballPos and paddlePos. So first a game
Nathan Hüsken wrote:
Heinrich Apfelmus wrote:
Personally, I would recommend is a complete change in perspective.
The main idea of FRP is that it is a method to describe the evolution of
values in time. What is a game? It's just a picture that evolves in
time. The user can exert influence on
On 11/27/2012 07:12 AM, Ertugrul Söylemez wrote:
Nathan Hüsken nathan.hues...@posteo.de wrote:
When writing games in other (imperative) languages, I like to separate
the game logic from the rendering. For this I use something similar to
the observer pattern.
[...]
So I am wondering: Is
Nathan Hüsken nathan.hues...@posteo.de wrote:
In fact it could be a (free) monad:
myApp :: MyWire a (GameDelta ())
someDelta :: GameDelta ()
someDelta = do
randomPos - liftA2 (,) getRandom getRandom
replicateM_ 4 (addCreature randomPos)
Nathan Hüsken wrote:
Hey,
When writing games in other (imperative) languages, I like to separate
the game logic from the rendering. For this I use something similar to
the observer pattern.
With rendering I mean anything only related to how objects are drawn to
the screen. Animation state for
On 11/27/2012 04:18 PM, Heinrich Apfelmus wrote:
Nathan Hüsken wrote:
Hey,
When writing games in other (imperative) languages, I like to separate
the game logic from the rendering. For this I use something similar to
the observer pattern.
With rendering I mean anything only related to how
Hey,
When writing games in other (imperative) languages, I like to separate
the game logic from the rendering. For this I use something similar to
the observer pattern.
With rendering I mean anything only related to how objects are drawn to
the screen. Animation state for example.
On my journey
Not sure, but maybe you can define a Drawable class with a method in
converting inner state to something draw func could use, so it would be
like this:
draw :: Drawable a = a - IO ()
вторник, 27 ноября 2012 г. пользователь Nathan Hüsken писал:
Hey,
When writing games in other (imperative)
Hi all,
I've been doing some GUI programming recently, using wx. To help
manage dependencies between state and UI elements, I looked for a
Haskell version of the Observer design pattern, and I found an
implementation written by Bastiaan Heeren of ou.nl [1].
It pretty much did what I
Andy Gimblett wrote:
Hi all,
I've been doing some GUI programming recently, using wx. To help
manage dependencies between state and UI elements, I looked for a
Haskell version of the Observer design pattern, and I found an
implementation written by Bastiaan Heeren of ou.nl [1].
Now,
Andy Gimblett-2 wrote:
To help manage dependencies between state and UI elements, I looked for a
Haskell version of the Observer design pattern
Isn't Reactive Programming approach more suitable than Observer if we talk
about Haskell?
--
View this message in context:
Hi Neil,
On 9 Nov 2009, at 14:50, Neil Brown wrote:
1. Does anyone have any comments, on either version?
There is no way to remove an observer, which is something I'd expect
to have available. I realise this would require assigning a key to
each observer (and thus perhaps storing them in
On 9 Nov 2009, at 15:21, Eduard Sergeev wrote:
Andy Gimblett-2 wrote:
To help manage dependencies between state and UI elements, I looked
for a
Haskell version of the Observer design pattern
Isn't Reactive Programming approach more suitable than Observer if
we talk
about Haskell?
Andy Gimblett-2 wrote:
Possibly. Care to expand? If you have a more elegant solution, which
fits in well with ordinary wxHaskell, I'd be interested.
I believe there are a few experimental frameworks built on top of wxHaskell
which use Functional Reactive Programming, like
On 9 Nov 2009, at 16:47, Eduard Sergeev wrote:
Andy Gimblett-2 wrote:
Possibly. Care to expand? If you have a more elegant solution,
which
fits in well with ordinary wxHaskell, I'd be interested.
I believe there are a few experimental frameworks built on top of
wxHaskell
which use
Andy Gimblett wrote:
was a bit surprised at first that the observers were called
synchronously. Asynchronous is what I'd expect, and it's also
harder to code the asynchronous handlers wrongly. One blocking call
(such as putMVar) in a synchronous handler can screw up your whole
program by
On 9 Nov 2009, at 17:41, Neil Brown wrote:
Just to clarify -- I meant access to another MVar. Basically, if I
do this:
do v - newMVar
addObserver sub (putMVar v)
If when the observers are run, the MVar v (that I've allocated) is
non-empty, my code will block until it is empty, which
I haven't looked at the code extensively, I just wanted to comment on
this point:
There is no way to remove an observer, which is something I'd expect to have
available. I realise this would require assigning a key to each observer
(and thus perhaps storing them in an associative map) or some
27 matches
Mail list logo
