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