Game Design

After some play testing, it seemed like the keys 1, 2, 3 .. 0 were very hard to hit.

So we added SHIFT functionality which performs a 180° rotation to whatever is pressed. That way, SHIFT + home row is the same as Number row.

Tetrominos as blocks

There were only a few options to use for blocks - duominos were silly, trio-minos were too easy.

Pentominos were too wide for the playfield (see well dimensions below).

For stacking fast, I did a survey on a block-stacking community.

They agreed that for a line-clearing type mino game, tetrominos had the best balance between s

tacking speed and stacking difficulty.

Well Dimensions

Since there are only 10 keys from a to ; (standard touch typing positions), there can only be 10 columns.

A well height of 20 was used because this enables the user to stack up quickly for the first half of the game,

without clearing any lines. 10 was used as well width because having a wider well gives more opportunities

to place pieces without leaving ugly holes.

Piece Orientation

A quick analysis of youtube videos and user opinion showed that "flat bottom" pieces were used most

when placing them. Also, user analysis believed it to be the superior spawning orientation (for speed).

Therefore, it would be highly beneficial to have the home row (asdfghjkl;) as a flat bottom orientation.

Piece Colours

Again, from analysis of "fast tetromino" videos (e.g. quadra, cultris, tetris) having a different colour for each

piece helped users identify the piece when playing. Also, a quick survey found a consensus that the more

distinct the colours, (i.e. the primaries and secondaries vs using 7 shades of red) aided in distinguishing colours

and hence pieces. The majority of fast tetromino videos (from a variety of games) used the following colour scheme:

Hence I picked this colour scheme because it seemed like it had a positive impact on speed.

Also it would enable fast players of games with these colours to transition easily to this game.

Since using these piece colours might infringe on TTC Trade Dress, I made the the pieces

all completely different.

Piece Previews

Again, it appeared that a minimum of 1 preview, and often times at least 3 previews were required to play "fast".

A survey of opinions I ran agreed with this hypothesis.

Randomizer

A bag style randomizer appeared to produce fast times, while making the pieces "random enough". Pure random

appeared to be too harsh (not enough I pieces resulted in players just dying, despite playing incredibly fast

and placing pieces without making gaps). An alternative would be a "re-roll" randomizer (re-randomize the next

piece if the previous x pieces included the piece), or perhaps an 8-bag randomizer.

Hold

A "hold" piece was used in many tetromino games to mitigate having "bad pieces".

Most fast playing did not involve actually using the hold function more than 3 or 4 times.

I included just in case. (Players can always choose not to use the function). I decided to implement

a double-hold system (you can hold and unhold multiple times).

Delays

Obviously, removing all possible delays (line clear delay, lag) would make the game

more fluid, faster etc. This in turn results in faster play times.

Rendering

A lot of tetromino games rely on frame-based timing (e.g. nullpomino).

I thought this was a terrible idea. There should be an MVC.

Since LWJGL uses a crappy polling system, i was able to remove the

frame based timing, but everything is still based on frames, rather than events (which is the ideal result).

Basically, other games like Nullpomino rely on a fixed frame rate (60hz) which the game timer relies on.

This means if your end game time is 1 second, it is actually between 1 second and 1 second - 1/60 of a second,

AT A MINIMUM (a lower framerate means your time could be between 1 second and 1 second - 1/framerate)

due to the fact it only polls once per frame.

This is why nullpomino has a "game rate %" in replay stats - there is a difference between the frame-based

timer and the system.nanoTime() timer.

To alleviate this, I render as fast as possible, meaning if your frame rate is 2000 then the end time

is accurate to 1/2000 of a second. In testing, my average frame rate was well over 1000 at all points of time.

Since this game has mostly static graphics, "flickering" is not really an issue due to Vsync being off.

The end result: the end time for your game is as accurate as 1/framerate

vs

Nullpomino: the end time for your game is accurate to 1/60s.

Finesse: Inconsistencies in game speed due to lag will still result in the same final game time (accurate to framerate).

Nullpomino: Inconsistencies in game speed due to lag will result in completely different time (however multiplying by gamerate will give a result close to what Finesse gives)

Feedback

Players in a survey agreed that some forms of feedback were beneficial.

Obviously the speed at which they were playing (and hence the length of the game) were crucial,

due to the fact that the player needs to know if they are improving. High scores were an easy way

for players to keep track of local maxima.

Replays were crucial in allowing them to review past performance as well as gloat.

In game feedback (e.g. sound, some forms of animation) are extremely helpful.

A sound played every time a block was played was a form of tactile/auditory feedback letting

the player know that they had placed the piece. I used a different tone for every column,

so users could differentiate which column they had placed the piece in, as well as a simple

highlight showing where the piece had landed. This helps the user ascertain the action they

just did.

Animation

All forms of animation that slow down the game were removed. Some helpful animations

(drop trails) were kept because they help the user get tactile/visual feedback of their actions.

Spectator

Having a virtual keyboard as well as some statistics enable spectators as

well as replay-watchers to visualise what the original player was doing.