It would be better if we could see the adjacent cubes with same color clearly. Especially on objective part, it is hard to determine how long a line segment is if it is same color.
Like others I would like to second the visualization of block sizes better. And a brief explanation of commands like stackEqual (is there some sort of normalization going on to unit size?). push(X) would probably be better read as layer(X) or stack(X).
Is there a way to normalize the program into a text string and also convert text string back into the program. This would allow for easy cut/paste sharing between users (including HN comments).
This feedback is based on having completed up to 1.2 only.
I definitely like the idea, however. It should be quite simple to implement it. Basically, the 'code' right now is just the compositions of different 'transformers'. In pseudo-PureScript:
[white] as a catchall is a bit misleading. Perhaps a different border color or an asterisk inside the square to clearly mark that it's not an actual white block?
Now that I've seen the update, I think just make it transparent, so it is the color of the button on which it is placed. The dashed border is nice though.
* Rather than saying to hit 'R' to reset have a button (keyboard can work too, but only allowing the keyboard goes against the rest of the game which is mouse/touch driven).
* On the right have the words "Goal" on top of the image, maybe put a box around it or something to separate it from the other images that appear.
* For the first level you need a "pit of success". Limit the available functions to only the one that works.
* The first few levels need to introduce and teach the user how to use each and every function separately. Say for 12 levels the first three teach/introduce a concept, the next 6 are actual simple/medium levels and the final 3 are the more difficult (but not impossible) levels before repeating and introducing a new concept.
* When you solve it don't put the message up top in little text, but next to the program and bigger bolder so the user knows. Ideally with some sort of css transition.
* When you solve it put a link to "Play next level" or automatically go to the next level after a short animation or something
* Only expose levels after you have beat them.
* After doing a function rather than instantly showing the next cube put a .5 second opacity transition (or something) so the user will notice what they did.
Lastly, but most importantly play test in person. Show someone your game, but don't say a single word. Write down everything they do wrong and debate how you can improve it and try again. Do not give them advice on what to do. If they can't figure it out neither will a ton of random people on the internet (I didn't the first time I saw the game and just closed it as I didn't realize I had to drag it over and I was on a tablet and saw the 'R' command and figure there was other keyboard only commands.)
Remember it is not fun to lose. Hard is fun, but you want to guild the user to have fun, be challenged, and build on the game concepts you have taught them. It isn't fun to give up because you have no clue what to do.
If you build in a way that users can create puzzles and share them (say by putting the user generated level in the url) the game would have more life as users spread the word by showing off their creations.
Wow! Thank you so much for the detailed feedback. This will be very helpful for the future development. Most of these are 'small/easy' changes but I definitely see how they will improve the user experience. I think I agree with all of your points and will try to use it as a roadmap :-). The 'play test in person' tip is also very helpful. I will try this!
Yeah .5 seconds is way to long, the reason for the animation is that in this game you are looking at the list of functions and only after you are done does your eyes have time to register changes elsewhere. If it has already changed your brain has to try to figure out what has changed when the system can provide hints.
Because you would rapidly move them around changing it to be 0.05 or something just slow enough so that your brain would notice movement above, but not slow enough to impede in trying new things.
The block function diagrams would be clearer if they were stacked like they work instead of being turned on their side. That is,
▥ ↦ ▥ ▧
could instead be:
▧
▥ ↦ ▥
I hope that makes sense!
Also, the dropdown menu for levels could be replaced by something more informational (perhaps a tree control?), that indicated e.g. by color which levels have already been solved.
Poseidon was very tough for me, but I got it just now! Had to go back to it after finishing the rest. If you rotated the entire block display 90 degree vertically then the commands would match the display (as in R -> R R shows two red blocks adjacently instead of vertically), without having to make the commands too tall. (Just a possibility, maybe not a great way to do it.)
Thank you. The drag and drop should work on mobile (I use https://github.com/RubaXa/Sortable). I definitely have to make the layout responsive, however.
I couldn't come up with a better name for this function. I will try to add a help-panel or introductory chapters to make this more clear. Thank you very much for the feedback.
PureScript is a game changer. Compilation is fairly simple (unlike GHCJS), full Haskell'ish type system and modern/compact syntax, picked up a lot of momentum lately.
It find it by far the best AltJS implementation currently available.
Have a look at the code implementing the transformer functions, so clean!
Thank you! I started this project with plain JS + lodash, went on to JS + ramda and ended up using PureScript. I absolutely recommend it. I also have been using Haste before (Haskell to JavaScript), but I really like the lightweight architecture around PureScript, the super-simple FFI and the generated JS.
Thanks for these insights. I used the Fay project to compile Haskell to JS for some time. But in the next overhaul I probably switch to GHCJS, as for my project interop with server-side Haskell code it a requirement.
If I did not need that interop I go for PureScript in a heartbeat. CoffeeScript/TypeScript/ES6/Opal, they all don't come close to what PureScript delivers.
On the "Fort" level, the map [blue][white]->[blue] removes the [blue] block, rather than the [white]. This is a different behavior than the map [red][red]->[blue], which converts two [red] into one [blue].
Great implementation! I'm researching functional programming front-end solutions for my latest web app project. PureScript has been on my radar but would love to hear about others' experiences. Has anyone else here used PureScript? What was your experience like?
Maybe I've just stared at the page too long looking for what to do, but I had to come into the comments to figure it out. My eyes completely glossed over "Goal" as it doesn't really stand out and I just assumed that shape was a logo. Could use some short text saying something like, "Make the left image look like the right image."
Otherwise cool/fun game concept, although like others have mentioned, stackEqual is a bit confusing as to what it does.
49 comments
[ 2.2 ms ] story [ 125 ms ] threadGitHub link: https://github.com/sharkdp/cube-composer
Is there a way to normalize the program into a text string and also convert text string back into the program. This would allow for easy cut/paste sharing between users (including HN comments).
This feedback is based on having completed up to 1.2 only.
There is no import/export available right now, but you can take a look at the developer console for an output line like
Program: ["rejectO","replaceYbyBY","replaceBbyOO"]
I definitely like the idea, however. It should be quite simple to implement it. Basically, the 'code' right now is just the compositions of different 'transformers'. In pseudo-PureScript:
rejectO >>> replaceYbyBY >>> replaceBbyOO
* On the right have the words "Goal" on top of the image, maybe put a box around it or something to separate it from the other images that appear.
* For the first level you need a "pit of success". Limit the available functions to only the one that works.
* The first few levels need to introduce and teach the user how to use each and every function separately. Say for 12 levels the first three teach/introduce a concept, the next 6 are actual simple/medium levels and the final 3 are the more difficult (but not impossible) levels before repeating and introducing a new concept.
* When you solve it don't put the message up top in little text, but next to the program and bigger bolder so the user knows. Ideally with some sort of css transition.
* When you solve it put a link to "Play next level" or automatically go to the next level after a short animation or something
* Only expose levels after you have beat them.
* After doing a function rather than instantly showing the next cube put a .5 second opacity transition (or something) so the user will notice what they did.
Lastly, but most importantly play test in person. Show someone your game, but don't say a single word. Write down everything they do wrong and debate how you can improve it and try again. Do not give them advice on what to do. If they can't figure it out neither will a ton of random people on the internet (I didn't the first time I saw the game and just closed it as I didn't realize I had to drag it over and I was on a tablet and saw the 'R' command and figure there was other keyboard only commands.)
Remember it is not fun to lose. Hard is fun, but you want to guild the user to have fun, be challenged, and build on the game concepts you have taught them. It isn't fun to give up because you have no clue what to do.
If you build in a way that users can create puzzles and share them (say by putting the user generated level in the url) the game would have more life as users spread the word by showing off their creations.
Please, no animation. Instantaneous feedback is perfect as it is. My 2cts.
Because you would rapidly move them around changing it to be 0.05 or something just slow enough so that your brain would notice movement above, but not slow enough to impede in trying new things.
Also, the dropdown menu for levels could be replaced by something more informational (perhaps a tree control?), that indicated e.g. by color which levels have already been solved.
I think I will first try to display the two R blocks on top of each other in the name of the functions. I will keep your suggestion in mind, though.
Very very challenging
It find it by far the best AltJS implementation currently available.
Have a look at the code implementing the transformer functions, so clean!
https://github.com/sharkdp/cube-composer/blob/master/src/Tra...
Nice demo!
If I did not need that interop I go for PureScript in a heartbeat. CoffeeScript/TypeScript/ES6/Opal, they all don't come close to what PureScript delivers.
The interface is really fun though, and the blocks look nice. Only the "Solved!" text is quite small and not easy to spot.
The columns have to be the same pattern exactly (same height, same colours)
I should definitely add a better description somewhere!
On the "Fort" level, the map [blue][white]->[blue] removes the [blue] block, rather than the [white]. This is a different behavior than the map [red][red]->[blue], which converts two [red] into one [blue].
Thanks for the feedback!
http://david-peter.de/quizzity/
[0]: http://jdan.github.io/isomer/
Otherwise cool/fun game concept, although like others have mentioned, stackEqual is a bit confusing as to what it does.