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 g
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
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 n
On 12/12/2012 01:26 AM, Ertugrul Söylemez wrote:
> Nathan Hüsken 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
>>> recommen
Nathan Hüsken 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 immutable and
Am 10.12.2012 16:56, schrieb Ertugrul Söylemez:
Nathan Hüsken 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
Nathan Hüsken 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 the model
> (the ga
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
>>>bAsteroidPo
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 ga
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 th
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 r
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 e
Nathan Hüsken 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)
> > getPlayerPos
On 11/27/2012 07:12 AM, Ertugrul Söylemez wrote:
> Nathan Hüsken 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 there (or
Nathan Hüsken 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 there (or can someone think of) a different
> pattern by which this co
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 (imperativ
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
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 so
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 w
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 del
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 Fun
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
http://www.has
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?
Poss
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 a
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:
http://old.nabble.com/
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, before
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 want
28 matches
Mail list logo
