LÖVE

I two days ago found my self programming Tetris™ clone with Löve. Today I noticed that the MiniLD #66 was open for submissions. Decided to semi-troll.
Anyway. Here is my first proper game made with löve using object oriented methods. Next I plan to take it to bit different direction but decided to finish up proper clone first.
You can either follow path of LudumDare or grab the *.love file down bellow.
http://ludumdare.com/compo/minild-66/?a ... &uid=60315

Release 1.0 (1.4.2016) Update 1.5 (5.4.2016) Update Notes:
-Changed art style to more simplistic.
-Individual blocks are now object oriented.
-Controller support.
-Multiple player support (they don't interact at this time but on my to-do list I have something planned.)
-Bit more special background.
-Music is defaulted off until I get some better music.
-Identity set to keep the high-score from previous versions. (it will reset on this one.)
-Down button now flushes the tile to bottom.
-No Longer plays in borderless window.

Update 1.6 (6.4.2016) Update Notes:
-Background and Tile graphics Updated.
-Some alignment fixes for texts.
-Fixed: Game Speed not being reset after restart.
-Fixed: Music
-Added: Indicator line where you lose the game.
-Disabled: Key Repeat (holding keyboard buttons)

It's a pretty solid version of Tetris, and I've only experienced a few slow downs here and there. The biggest problem I feel is the music, it's really bad. Otherwise, this is a decent effort, even in terms of semi-troll submissions. I'd honestly play more if the music wasn't so bad.

M to change/disable the music.

Thanks! are the controls listed somewhere?

Well, it's simple but solid. I liked it.

anastasiaorosegirl wrote:Thanks! are the controls listed somewhere?

https://drteaspoon.itch.io/lovelytet

Good stuff and it plays ok but I noticed these things:

• I think you need to flush the input after using 'down' (fast fall or whatever you might call it - as a former Tetris monster I used that key habitually until the score got up into the tens of thousands!) as it continues to affect the next piece which I'm pretty sure didn't happen in the original.
• The music made me laugh, started like a church service then went off into the cheeeeeeziest chord progression. I had to turn it off quickly
• One cell in each piece is brighter than the rest (eg the centre in the T-shaped piece) - not sure if that is intentional but couldn't think of a reason for it (or maybe it's not brighter, it's just my old eyes?!)
• There's a bit of shearing when drawing/moving the pieces; I had a very quick look at the code and spotted some things you could optimise although I'm not sure how much difference they would make - eg removing the function call for GameGrid.RenderTile that gets called about 200 times every frame and placing it in-line, removing the algebraic operations from that function etc. I know little about Love/Lua atm but I suspect that creating/blitting an image for the grid squares would be quicker than using primitives to draw them.

Nice clean code though, even for a Love novice like me to follow!

Thanks for the feedback. I really appreciate it.

• 1. I thought of that. Right now I am working on setting this up for local multiplayer. With controllers it might work better with flush on down rather than just hold.

• 2. http://abundant-music.com/ is wonderful.

• 3. The centrepiece is "lighter" intentionally. It shows the point of origin for rotation. I, Z, S and O pieces experience behaviour of this irregular centre because of how the coding is done. L and T pieces could do without.

• 4. The game is drawn with primitives right now because I wanted to get graphical interface done fast. This will change when I get all the features I want. The graphics may have minor differences depending on your monitor setup as I have coded the game to scale on monitor based on the height. Also with graphics algebraic operations are just better to keep within adding and subtracting. Multiplying by two is also very cheap operation.

whitebear wrote: 4. The game is drawn with primitives right now because I wanted to get graphical interface done fast. This will change when I get all the features I want. The graphics may have minor differences depending on your monitor setup as I have coded the game to scale on monitor based on the height. Also with graphics algebraic operations are just better to keep within adding and subtracting. Multiplying by two is also very cheap operation.[/list]

I think as long as you avoid division it won't make a lot of difference unless you are calling the routine zillions of times - mul is so cheap compared to the old days of fixed point math and endless shifting!

With regard to scaling, my monitor is set at 1920x1080 meaning your game leaves a blank area between it's bottom edge and my panel (er, Taskbar in windows?). No biggie just seems a bit odd.

Truth is that I could use full screen mode. But I like to play on borderless window especially while doing something else on the side. When I get main menu and settings menu done lot of this screen size manipulation is redundant. Here is the part of the code dealing with all that.