This game should include powerups. Initially they could give just points, additionally they could have something more.

There's code in the android version that already implements this, it only needs to be merged.

SDL1 and SDL2 have different resource definitions and different resource managers.

These should be standardised.

The code in Magic Cookies has a resource manager that could be included in SAGE and re-used here maybe.

improve installation instructions regarding needed required packages and how to install them on debian/ubuntu

There's no need to add blitSurface 4 times.

Should be obvious: these are used by cabal during compilation and should be ignored.

There's a missing module that should be listed.

• Add a different kind of powerup that gives lives, not points.
• Change the level definition to select which blocks/bricks give what.

The last commit had to remove the background music because Magic Cookies' resource manager did not support it.

It needs to be added back.

As a reference see:

https://docs.travis-ci.com/user/languages/haskell/
and
https://github.com/ivanperez-keera/dunai/blob/develop/.travis.yml

That is, use the standard building image for Haskell ("ghc" variable, remove install section, etc.).

Just so that stack users can build this out of the box :)

In the section Documentation of the README.md I think
$ cabal init
should be
$ cabal sandbox init

The mobile version of this game includes menus.

These should be brought over.

Many modules are not documented. It would help beginners and developers alike if all modules were documented.

The assets used by the mobile version are nicer (imho). For now, bring those over.

In the future we can improve the assets or buy them.

Following the below steps

$ cabal update
$ cabal sandbox init                # skip if you are using cabal-dev
$ cabal unpack haskanoid            # or git clone http://github.com/ivanperez-keera/haskanoid
$ cd haskanoid-*                    # Game resources are here
$ cabal install  -f-wiimote -f-kinect   
$ ./dist/build/haskanoid/haskanoid

errors with

Resolving dependencies...
Configuring SDL-0.6.5.1...
Failed to install SDL-0.6.5.1
Build log ( /Users/niki/.cabal/logs/ghc-8.0.2/SDL-0.6.5.1-KvB334CFAgc2g1XAOFu4La.log ):
cabal: Entering directory '/var/folders/g_/rh7h5cnx7nl5t_894q4gn58w0000gn/T/cabal-tmp-4710/SDL-0.6.5.1'
[1 of 1] Compiling Main             ( /var/folders/g_/rh7h5cnx7nl5t_894q4gn58w0000gn/T/cabal-tmp-4710/SDL-0.6.5.1/dist/setup/setup.hs, /var/folders/g_/rh7h5cnx7nl5t_894q4gn58w0000gn/T/cabal-tmp-4710/SDL-0.6.5.1/dist/setup/Main.o )
Linking /var/folders/g_/rh7h5cnx7nl5t_894q4gn58w0000gn/T/cabal-tmp-4710/SDL-0.6.5.1/dist/setup/setup ...
Configuring SDL-0.6.5.1...
configure: WARNING: unrecognized options: --with-compiler
checking for sdl-config... no
checking for sdl11-config... no
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
cabal: Leaving directory '/var/folders/g_/rh7h5cnx7nl5t_894q4gn58w0000gn/T/cabal-tmp-4710/SDL-0.6.5.1'
cabal: Error: some packages failed to install:
SDL-0.6.5.1-KvB334CFAgc2g1XAOFu4La failed during the configure step. The
exception was:
ExitFailure 1
SDL-image-0.6.1.2-pDi03sWFuc8kJwXw5DdPB depends on SDL-image-0.6.1.2 which
failed to install.
SDL-mixer-0.6.2.0-L1008IeMTiHBThc5g1Z1Nl depends on SDL-mixer-0.6.2.0 which
failed to install.
SDL-ttf-0.6.2.2-BxbtB9T5H8D1ZYMVeFPr3Y depends on SDL-ttf-0.6.2.2 which failed
to install.
haskanoid-0.1.5.2-Beb4t66NOkN9jrXt1oHxba depends on haskanoid-0.1.5.2 which
failed to install.

After the last change to the resource manager (c90e2fb), resources are loaded only once.

This should change so that resources are loaded-unloaded as the game progresses.

A possible approach would be to:

• 1: Obtain needed resources from the current game state.
• 2: Obtain used resources from the current resource manager.
• 3: Unneeded resources (to be unloaded) is (2) - (1)
• 4: Resources to load is: (1) - (2).

This game only has a few demonstration levels, but it could have so many more. They could have different shapes, and maybe it would make sense to add other kinds of objects.

As a starter issue, I'd suggest adding 10 levels with different cool block arrangements.

It should be pretty simple: the level definitions are all in a separate module.

Update README.md installation:

$ cabal update
$ cabal sandbox init
$ cabal unpack haskanoid            # or git clone http://github.com/ivanperez-keera/haskanoid
$ cd haskanoid-*                    # Game resources are here
$ cabal install
$ ./dist/build/haskanoid/haskanoid

should be:

$ cabal update
$ cabal unpack haskanoid            # or git clone http://github.com/ivanperez-keera/haskanoid
$ cd haskanoid-*                    # Game resources are here
$ cabal sandbox init
$ cabal install
$ ./dist/build/haskanoid/haskanoid

With the new ID-based resource manager, rendering is much slower than before.

It used to hit over 700FPS, and it needs to be back to those performance levels.

This needs to be done simultaneously on mobile, to make sure it's fast enough there too.

In haskanoid/src/GameState.hs the ordering and naming 'general info' and 'actual gameplay info' in the first and second documentation paragraph is confusing. The order should match the impementation and the names should refer more precise to the implementation.

The ghcjs branch of this game should be one with master, and the selection of which compiler and backend to use should be based on the current compiler or a cabal flag.

Yampa 0.11 is being released.

The version constraint on Yampa is, currently, < 0.11, but it can be < 0.12. I've tried it and it works.

I'd like to compile and run this, but setting up cwiid seems like a pain. I'm going to add a flag so you can do something like cabal configure --no-cwiid or something and get a working version without that dependency.

All functions should include the type signatures, so that code is easier to follow.

The scheme of having a branch that points to the latest stable release (master) and one that points to the current development version (develop) works well.

(Some people prefer to make the former implicit, by tagging them with release-*, and call the latter master. It's conceptually almost the same.)

However, it seems that this project does have a develop branch, so it suggests that it is using git flow, so develop should be the default branch, or removed.

I am getting the following error (multiple instances) when installing haskanoid under ghc 8.0.2. I tried a sandbox install too with same resultL

madjestic@nu ~/Projects/Haskell/haskanoid $ cabal install
Resolving dependencies...
Configuring haskanoid-0.1.5...
Building haskanoid-0.1.5...
Failed to install haskanoid-0.1.5
Build log ( /home/madjestic/.cabal/logs/haskanoid-0.1.5.log ):
cabal: Entering directory '.'
Configuring haskanoid-0.1.5...
Building haskanoid-0.1.5...
Preprocessing executable 'haskanoid' for haskanoid-0.1.5...
Linking dist/build/haskanoid/haskanoid ...
/home/madjestic/.cabal/lib/x86_64-linux-ghc-8.0.2/freenect-1.2.1-IWHP9yhnEhcEQ0pDPsW6C9/libHSfreenect-1.2.1-IWHP9yhnEhcEQ0pDPsW6C9.a(Freenect.o):(.text+0x13037): undefined reference to `freenect_set_flag'
collect2: error: ld returned 1 exit status
`x86_64-pc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
cabal: Leaving directory '.'
cabal: Error: some packages failed to install:
haskanoid-0.1.5 failed during the building phase. The exception was:
ExitFailure 1

Error message:

[ 8 of 23] Compiling Audio ( src/Audio.hs, dist/build/haskanoid/haskanoid-tmp/Audio.o )
src/Audio.hs:40:32: Not in scope: `<$>'
src/Audio.hs:58:32: Not in scope: `<$>'

Complete log: https://travis-ci.org/ivanperez-keera/haskanoid/jobs/291139506

Explanation: (<$>) was only available in Control.Applicative in older versions of the base library. Modules that use (<$>) should import Control.Applicative (<$>).

The resource manager from SAGE and Magic Cookies is more versatile.

That one should be used instead.

The fplab's blog is gone from bitbucket.

Problem

Right after startup the application does not respond to mouse motion events. Clicking to start the ball works but the ball goes straight up and leaves the window through the top. All keyboard events go to the terminal that started haskanoid.

System info

macOS 10.13.15
Darwin lorien.local 17.6.0 Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASE_X86_64 x86_64

GHC: x86_64-osx-ghc-8.0.2
Clang: Apple LLVM version 9.1.0 (clang-902.0.39.2)
SDL: 1.2.15

The current description does not show much.

It might make for a more attractive hackage page if it included an animated gif.

For example, the lens package includes an image in the documentation with the syntax:

 <<http://i.imgur.com/ALlbPRa.png>>

There is an animated GIF included in the README.md file. Care should be taken to point to a version of the image that is always accessible even when new versions are released.

It requires a slight fix, if anyone else encounters a problem installing with a recent ghc, here's how I fixed that problem.

File structure is something like

haskanoid-root/
|-> cabal.sandbox.config
\-> haskanoid/
      |->haskanoid.cabal
          .....

From haskanoid-root, (where you ran cabal sandbox init, also do cabal sdl unpack, to get something like:

haskanoid-root/
|-> cabal.sandbox.config
|-> SDL-0.6.5
\-> haskanoid/
      |->haskanoid.cabal
          .....

And edit Graphics/UI/SDL/Events.hsc line 56 to just be import Data.Typeable instead of being very selective in it's imports. Now you can cabal install from the SDL directory to get that dependency fixed.
You'll also need to bump up the base==4.6.* requirement in haskanoid.cabal`.

How is Javascript Data.now better than Data.Time.Clock.POSIX. getPOSIXTime? The latter does work in ghcjs.

It builds fine with GHC 7.10.1 with base bumped up.

Prepare an HCAR entry for Haskanoid.

See https://github.com/ivanperez-keera/Yampa/tree/develop/doc/hcar for an example.

This will be assigned to @chriz-keera only.

Currently all blocks are started with three "lives". That means they need to be hit three times until they disappear.

• Modify the definitions in Level so that they include an initial duration for each block.
• Modify the block ObjectSF generation function in Game to use that information.
• Modify existing levels to use blocks with different initial durations. It's best to make levels increase gradually in difficulty.

Code in Haskanoid could be cleaner.

In particular, there are redundant brackets and fmaps that could be replaced by <$>

It would be best to first improve those and then see which other hlint suggestions should and should not be introduced. In particular, suggestions about FRP.Extra.Yampa and Data.IdentityList should no be introduced just yet.

Feature Ideas

created for ZuriHac2018 by Christina Zeller

• This document gives an unsorted overview of some Haskanoid feature ideas.
• The unsorted tasks vary in complexity and the tasks are not at all described in detail.
  Don't get (too) frustrated but ask me for hints or how to start.

Table of Contents:

• Some Feature Ideas
• Confused?

Some Feature Ideas

• Feature New Levels:
  Create new levels that are beautiful to watch and fun to play.
• Feature Obstacles:
  Add a new level that includes obstacles.
  Obstacles can be seen as a variation of blocks that cannot be destroyed.
  Make sure that the level is still finished when all destroyable blocks are removed.
• Feature Changing Block Behaviour:
  • Store the catch of a power up in the game state.
  • Change the behaviour of blocks after catching a power up
    (e.g., blocks die at next contact/hit with ball)
• Feature Finish:
  Catching this power up let you finish the level without clearing the screen.
• Feature Restart:
  Catching this power up will returns all blocks of the level to the screen.
• Feature Paddle Size:
  Catching this power up will enlarge and/or shrink the paddle.
• Feature Catch Words (homage: Bubble Bobble 'EXTEND'):
  Catch power ups in a specific order and earn points.
  • Change the amount of points that will be gathered from a power up.
  • Add a new power up.
  • Store the catch of a power up in the game state.
  • Check whether two successive caught power ups are the same / different.
  • Only give bonus if power ups are caught in a certain order (e.g., forming a word).
• Feature Wormholes:
  Lets the ball jump/move to another position on the screen.
• Feature Get Knowledge:
  Catch this power up and see which other blocks contain power ups.

Confused?

Don't panic! Let's talk and find a solution. ;-)

gameWithLives :: Int -> Int -> Int -> SF Controller GameState
gameWithLives numLives level pts = dSwitch
  -- Run normal game until level is completed
  (gamePlayOrPause numLives level pts >>> (arr id &&& isLevelCompleted))

  -- Take last game state, extract basic info, and load the next level
  (\g -> let level' = level + 1
             lives' = gameLives  $ gameInfo g
             pts    = gamePoints $ gameInfo g
         in runLevel lives' level' pts)

Is there a reason, why state-passing is done with 3 explicit arguments, instead of packing them into a state-holding datatype?

For instance, can we not, instead of this:

gameWithLives :: Int -> Int -> Int -> ...

Have this?:

gameWithLives :: GameState ->...

This issue is generated to split #68 in which two problems were found while debugging.

The calculation of the velocity in Game.hs (line 519) returns invalid and very small values near 0.

@asandroq:

1. Can you figure out, which part of the calculation makes the number nearly zero? That is, what are the values for refPosPaddle ci and p in each cycle?

2. Besides, if I remember correctly your paddle is only for a very short moment in the middle of the screen (initPosPaddle) and then it immeadiatly goes to the left side of the screen. If you do not move the mouse, I think, it should stay in the middle of the screen (initPosPaddle = ((gameWidth - paddleWidth)/2, yPosPaddle)). Can you take a look what are the position values at the very first steps of the game.

Reminder for further consideration: In issue #68 the events LostFocus and GetFocus are mentioned. Maybe at a later time we should take a look whether this is related to this issue.

It would be great to replace the GIF shown in the readme by an animated GIF recorded from an android phone. This would require installing the game for free from Google Play and having a phone that allows recording screen videos.

Apparently, something needs to change to support this.

PR #62 Needs to be split in two, one for this issue and one for issue #61 .

When playing on a device with a touch screen, the platform is jumping in a "teleporting" fashion, with an infinite velocity. Instead, a finite acceleration (and velocity) need to be introduced.

There's a port of Haskanoid to SDL2 which is being used for the mobile versions. It should be a good first approximation.

Ideally, haskanoid should use the newer SDL2 bindings. That would also help people who want to do some SDL get started.

In either case, it's time to start "ditching" SDL 1.2.

It would be great if the README.md included a banner linking to the hackage package, much like this one in Yampa's repo: https://github.com/ivanperez-keera/Yampa/blame/develop/README.md#L4 but, obviously, customized for haskanoid.

Any gaming experience is twice better with apt event sounds and/or background music. One of my favorite 2D games https://en.wikipedia.org/wiki/Pocket_Tanks features excellent sounds and music.

The Paths mechanism provided in cabal for normal packages does not currently work on mobile. It's been disabled for the whole game in the feature-sage branch.

There should be a way around this. For resources, one could have a resource "Locatable" instance in the package that implements the right approach during compilation, and is only expressed with type constraints in libraries.