What Went Wrong With Polytope Tetris

A few years ago I, with the help of my friend Jon developed a software project named Polytope Tetris. Polytope Tetris is a Tetris game played in a user set number of dimensions. For instance, the user can say "I want to play Tetris in two dimensions." and they will get standard Tetris. However, the user could also say "I want to play Tetris in five dimensions.". This was pretty much all the thinking behind the design of the game. In retrospect there were several significant issues affecting this project.

Summary

So, to sum up the issues:

Although, in my defense I can say this about it:

Issues

Name

The name sucks. "Polytope Tetris" isn't cool or catchy. As I note on the description page, HyperTetris was taken but still, couldn't I have come up with something better than Polytope Tetris? It may be applicable. A portion of the Mathworld definition of Polytope follows: "Coxeter (1973, p. 118) defines polytope as the general term of the sequence "point, line segment, polygon, polyhedron, ...," or more specifically as a finite region of -dimensional space enclosed by a finite number of hyperplanes." So that sounds like its applicable here, but something else would have been much better here.

Game View

Tetris lends itself well to display on a monitor. Tetris has a two dimensional gamespace and a monitor displays two dimensional images. Perfect! But what about four, five, or fifteen dimensions? Ultimately I decided to use two and three dimensional displays onto which the n-dimensional gamespace is projected. Unfortunately this means that you lose information. For example, given three two-dimensional views of a three-dimensional game space imagine you see a 3x3 block on each view. At this point you might imagine a 3x3x3 cube in the gamespace. However, if you remove any one block from that 3x3x3 cube it will still project as a 3x3 piece on the two-dimensional views. Obviously, with just the projections you can't tell exactly what's going on in the gamespace. To approach understanding the gamespace a view of each combination of the available dimensions is produced. This fills up the screen fairly quickly.

User Input

In Tetris the user has two keys to move a piece forward and backward in one dimension and one more key to move the piece forward in the other dimension. So how do you assign keys given an aribtrary number of dimensions? What keys do you assign to move the piece backward and forward through the N-1th dimension? For this I created controls that are relative to the dimensions displayed in the selected view. If your current view is two dimensional and displays dimension 8 by dimension 9 then the arrow keys will move the piece around in those dimensions. This means that in order to get full control of the piece the user is forced to jump back and forth between the various views. Alternatively the user can set keys that apply to particular dimensions no matter the current view. While I think my keys relative to the view solution is a good idea the end result is still a bit difficult to use.

Human Comprehension

How the hell do you even visualize a gamespace above three dimensions? Given some time I can come up with something for four dimensions, but not something I can update in my mind in real time to keep pace with a game. Let alone, anything more than four dimensions. Perhaps if we train children from a very early age they can become masters of Polytope Tetris. So far none of my friends are willing to let me use their children to try this out.

Install

Polytope Tetris is written in Java and Java 3D. In college Java was the primary language and Java 3D was the API on which we were taught 3D graphics and animation. When someone sees Polytope Tetris they probably think "that sounds neat" and perhaps they even want to try it out. In order to try it out you have to download and install Java, Java 3D, and Polytope Tetris. Java and Java 3D are rather large downloads. In the same situation I know I would lose interest and forget after installing Java.

Fun

Ignoring the previous comments regarding the user input, game view, and ability to actually understand what's happening, playing in more than two dimensions gets rather tedious. All those extra dimensions mean there's a lot more space to fill up before you can clear a row (or hyper row or whatever you want to call it). It takes a lot of time. I can't say I've completed more than five lines in a three dimensinoal game. This could be fixed by descreasing the gamespace size as the number of dimensions increases.

Origin

The game was created when I saw a page on HyperTetris linked off of Slashdot. I thought it was cool and talked with my previously mentioned college roommate Jon about creating a Tetris game of an arbitrary number of dimensions. He said I couldn't even create a regular game of Tetris. At that point it was of course "on" and the rest of that weekend was spent writing the gamespace class. The origin of software projects probably shouldn't be spite. They should be created because there is a group of users who will use it. In this case there are no users which at this point includes me. This means that as soon as I lose interest (which happened sometime in 2005) the project languishes. Of course I still have aspirations of improving the project. This leads into the next point...

Tetris

As if there aren't enough Tetris games out there. Really. Come on.