I also implemented Tetris not long ago in Swift3. Maybe someone is interested. It has 3 frontends, iOS, macOS and CLI using the same game logic.
https://github.com/Stitch7/Tetromino
Just thought the same while playing. I was always sure that if I press once more then the tile is exactly rotated like I want it, but instead it was the other way around. It's interesting that we keep such a feeling how Tetris should work after all these years.
It's the right way for me, conditioned by Tetris for Mac ('90s black and white game) and whatever version I had on my TI-83 calculator.
Edit: Just as importantly, at least on a touchscreen, the arrows are on the right and drop is on the left, which is opposite of Gameboy but the same as a computer or TI calculator ;-)
That being said, I took a look at the code and the way Redux is being used feels kind of weird to me - pretty much a separate reducer for every kind of action.
I think primary focus of this project was to showcase proper Redux implementation. There certainly are much easier ways to accomplish Tetris but that is not what they were shooting for.
Only connecting the root component, fetching the entire state, and passing down all those props manually isn't proper. You shouldn't pass props that can be grabbed directly from the store IMO.
How long before github takes it down? Not trying to make fun of Github's record of "censorship", just that the Tetris Company is known to be active in protecting the game. Even mechanics, which is weird, but they are pretty successful.
> Even mechanics, which is weird, but they are pretty successful.
I haven't been able to find a free source for the actual ruling, but apparently a district court ruled in 2012 that the particular playfield dimensions, set of tetromino shapes, set of movement actions, and scoring rules are copyright-protected expressions of more general/abstract rules, and only the latter are ineligible for copyright [1]. To my untrained eye, this seems to parallel Oracle's "structure, sequence, and organization" argument for API copyright.
I know it's too much to ask really, but I'd love to see the history of the individual commits. I'd be curious to see where it all started (is it all greenfield or is it built on top of a previous game concept perhaps?), and would love to learn what decisions and challenges a developer faces while working on a game like this.
That sad, this is just fantastic, thanks a lot for posting!
I agree, that would be a great read. Also, I think there is value in having standard exercises that people do just as a way of learning and then talking about their learning.
I've recently discovered https://book.mixu.net/css/ and want to test if it actually makes it easier to think about css layout in the context of an app. Maybe I'll find the time to work through this and do a writeup.
It takes a lot of courage for a person to reveal how they learned. Learning is about making mistakes, doing things the wrong way, and then having to recover. It's too easy for others to imply superiority by asserting/proving they would/did not make the same mistakes.
Providing a blog post is completely different, as this is a narrative composed after the fact, not a historical record of lessons. Here, the author is explicitly choosing to reveal specific lessons learned, but has the dignity of concealing the learning mistakes by which they're particularly embarrassed. They can humblebrag about the hardships of writing something cool, like a JSON deserializer - nobody need know their embarrassing hardships, such as the 3 days they spent debugging, only to find they had a hardcode hiding in the variable init section.
Not wanting to take anything away from your sentiment, which I do agree with, but the Gameboy version of Tetris wasn't the original. Far from it in fact as several NES ports of Tetris existed even before Nintendo won the licencing to it. The story of Tetris is quite fascinating if you're interested video game history: http://www.denofgeek.com/games/tetris/30840/10-remarkable-th...
Sometimes it is not only about results. It is about the journey (Takes off my philosophical hat). The fact that Tetris was built is not that important. Show HN is about showing and doing something creative even if that means building a 1984 game.
Plenty of take aways from this Show HN for me. I can look at the code and understand how React was used to achieve this. Sure, this could be done with 100s of other frameworks or even plain C++ but thats not the point. But again, you missed the point.
I honestly think he has a point. There are hundreds of implementations of Tetris for any kind of platform and technology. This is only noteworthy (for some, at least, not for me) because it's build with React.
By the way, it's pretty dumb and shortsighted to depict flash as a neanderthal, because both its capabilities and its ease of use are (were) way beyond what current JS frameworks offer today (and in the upcoming years, at least).
Yup, react part makes it noteworthy, worth bookmarking and learning from. Also that this implementation is actually fun to play, most of them are not.
This is how people and communities learn. They do small projects to see what is achievable. There is nothing shameful about it.
About the parent poster: he is just an adult equivalent of a kid that came into the room, scrapped other kids drawings and told them they are all suckers. Otherwise said, just someone having emotional meltdown and taking it on the random people around. No reason to take him seriously.
If this were a student project or an intellectual exercise to implement Tetris in an obscure language, good on them. I can respect that.
However it is undeniable that there are overkill levels of abstractions in play here, for the purpose of using what is currently the most commercially viable web framework. This is like taking FizzBuzz Enterprise Edition seriously for being written in Java.
>just someone having emotional meltdown and taking it on the random people around
I won't stoop down to your level of using personal attacks. You don't know me.
> By the way, it's pretty dumb and shortsighted to depict flash as a neanderthal, because both its capabilities and its ease of use are (were) way beyond what current JS frameworks offer today (and in the upcoming years, at least).
You're taking his depiction of Flash out of context.
He was clearly only comparing the different solutions in terms of audio capabilities.
I can appreciate how much of a gigantic leap in capabilities Web Audio API offers compared to HTML5 audio alone, so I can vouch for that part of his depiction.
I haven't ever worked with Flash audio, nor Flash itself in general though, so you may still be right about him being unfair and shortsighted in making that comparison in the context of audio capabilities, but I think it's still an important distinction to make if that was in fact your critique.
I know he was talking about the audio, but my critique works both about flash in general and about audio support in particular.
ELEVEN YEARS ago Flash was already capable of both playing and recording audio from multiple sources, using several different codecs and offering the usual bells and whistles you're expected to find in any multimedia framework (vis.eq., channels, etc). And everything working exactly the same way in every browser equipped with a flash player.
And I'm taking eleven years ago because that's when AS3 was released. Flash had considerable audio support before that anyway.