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
18 matches
Mail list logo
