Side note: On the most recent occasion that I tried to figure this out, I attempted to resurrect my old Tet4-auto-player program (not trivial, since it’s a graphical DOS program and hence doesn’t work on Vista) and modify it to see if it could solve the SSZ repeated sequence. Once I’d got it running, I was amused to see that it was already set up to solve the SSZ repeated sequence – I’d done the exact same thing before and forgotten all about it!

Talking of Tet4, it’s had a couple of updates since I last mentioned it here. The original version has had a bug fix so that playback of games in which the curtain reaches the bottom works properly. Also, a second version has been added, which is exactly the same but with no undo (and which is therefore less forgiving). This may be one of very few occasions on which the second version of a piece of software is identical to the first version apart from the removal of a significant feature.

When I first wrote the Javascript version of Tet4, I took the opportunity to change the keys from the DOS version a bit, to make them more logical and faster (so that if there were 5 or fewer possible positions for a piece, either hand could be used, for example). This meant that I kept making mistakes because (although I hadn’t played Tet4 for years) my muscle memory was still trained with the old keys. Hence I added the undo feature. But in making the game more forgiving, I changed its nature significantly.

There’s two ways I could have added undo to Tet4. One way is to undo the random number generator one step when undoing. The other is not to. Undoing the random number generator essentially gives you unlimited lookahead capability. To look ahead n pieces, drop those n pieces (anywhere) and then undo n times. I didn’t want to grant that power, so I wrote it in such a way that dropping n pieces and undoing them changes the random number generator state. However, this gives an even stronger ability – now you can essentially choose which piece comes next by dropping and undoing until you get the piece you want. I think this makes the game too easy (at least until it gets really fast), hence the new version.

I think the real value in this would be lowering the barrier to entry for 3D game creation, much as the appearance of HTML and web browsers made it easy for anyone to create rich documents and publish them to the world.

The first thing we need is a very high level way of specifying simple 3D environments. I think the best interface for such a task ever conceived is that of the holodeck in Star Trek: The Next Generation. Captain Picard walks into the holodeck, which initially is an empty room. he says “Computer, create me a table” and a generic table appears. Next he says “make it pine, 2 inches taller, rotate it 45 degrees clockwise and move it 6 feet to the left”. Iterating in this way, he converges on the design he had in mind. Seeing the intermediate results immediately allows him to determine what’s “most wrong” and therefore needs fixing first, and may also provide inspiration in the event that he doesn’t really know what he wants just yet.

The difficult thing about this interface is that one needs to have a big database of objects to start with – tables, trees, bees, books and so on. Once also needs a big database of textures, a big database of transformations and so on. In fact, there are all sorts of databases which would come in handy – animations, AI routines, material properties, object behaviours. The obvious “Web 2.0″ way to populate these databases is to encourage people to publish the things they create for their own games in such a form that they can be used by other people for their games. I don’t think the software should necessarily go out of its way to forbid people from making content that can only be used in their own game, but making the default be “this is free to use” would probably help a lot.

If you’re creating a website today you can easily find lots of free backgrounds, buttons, menus, applets and so that have been created by the community. With the right encouragement, a similar community could form around creating game things. Put a search engine on top of this community’s effort so that when you search for “chair” you get a gallery of models to choose from and you’re well on your way to the holodeck interface.

To create compelling games, one needs more than just a decorated 3D space to wonder around in – there need to be challenges, there needs to be something at stake. The web model breaks down a bit here – since you can get from anywhere to anywhere else just by typing in the appropriate URL, what’s to stop players from just transporting themselves to the holy grail room?

I think that any non-trivial game would generally involve writing some code (possibly in an ECMAScript-ish sort of language). That code would need to have certain powers over the player, including associating information with them (like “has the player been through this obstacle yet?”) and the ability to move the player (which could be done by moving a portal through the space that the player’s avatar is occupying) to send them back to the beginning if they haven’t completed a required obstacle or if they are “killed” by the minotaur. In computer games, death is of course never permanent, so can be effectively emulated by teleportation.

Another web principle that I think this software should embody is decentralization. Someone who wants to create a website has many options for hosting it (depending on their needs), one of which is to run their own web server. A major problem with a system like Second Life is that there is a central server, which is a single point of failure and a monopoly of sorts over the game universe. Virtual “land” is not not free in second life, it leased from the central authority. And if that central authority decides to raise their prices, censor content they find objectionable or has a server failure, there is nothing that the users can do about it. I suspect that this is a limiting factor in SL’s growth.

If no-one “owns” this universe, who decides how it “fits together” (more concretely, what’s to stop everyone saying “our site is directly north of Yahoo!”). I think in this scheme one has to give up having a single Hausdorff space and instead have many worlds connected by portals. The owner of a space decides what portals go in it, how large those portals are, what their positions and orientations are, how they move and where you end up when you go through them. Portals are not necessarily bi-directional – on going through one, one cannot necessarily get back to where one was just by retracing one’s steps. They are more like links on a website than the portals in Portal. Mutual portals could be constructed though, if two gamemasters cooperate with each other to do so.

Ideally a portal should be rendered in such a way that you see what’s on the other side – this just means that that “world” would also be loaded by the client software and rendered from the correct perspective (though should not be able to affect the player).

I think it would be great fun to wander around and explore different game worlds this way. It might be confusing sometimes, but if a place is too confusing people probably won’t create many portals to it, so the system would be self-governing to some extent.

The system I’ve described could run with a standard HTTP server to implement a wide variety of single-player games. But where the internet really comes into its own is real-time interaction with other people – (massively) multiplayer games. Here, things become more complicated because the movements and actions of each player need to be sent to all the other players, and conflicts need to be resolved (who actually got to that loot first?) These problems have all been solved in real-life multiplayer games – one just needs a server which does some of this “real time” stuff as well as serving the content.

While games would be probably be the initial “killer application” for this, I’m sure all sorts of other interest applications would emerge.

Shortly after I originally wrote this, Google announced their O3D API which seems like it has at least some of the same aims, though at the moment I think it’s really just an in-browser 3D API rather than a 3D version of the web. However, it’ll be interesting to see what it evolves into.

I think at some point the games industry will reach the point where game engines are independent of the games themselves. In other words, there will be a common “language” that game designers will use to specify how the game will work and to store assets (graphics, models, sound, music etc.) and there will be multiple client programs that can interpret this data and be used to actually play the game. Some engines will naturally be more advanced than others – these may be able to give extra realism to games not specifically written to take advantage of it. And games written for later engines may be able to run on earlier ones with some features switched off.

Many classes of software have evolved this way. For example, in the 80s and early 90s there were many different ways of having rich documents and many such documents came with their own proprietary readers. Nowadays everybody just uses HTML and the documents are almost always independent of the browsers. As far as 2D games are concerned, this convergence is already happening to some extent with flash.

3D games have always pushed hardware to its limits, so the overhead of having a game engine not tuned for a particular game has always been unacceptable. But as computer power increases, this overhead vanishes. Also, game engines are becoming more difficult to write (since there is so much technology involved in making realistic real-time images) so there are economies of scale in having a common engine. Finally, I think people will increasingly expect games to be multi-platform, which is most easily done if games are written in a portable way.

If game design does go this way, I think it will be a positive thing for the games industry – it will mean that more of the resources of the game can be devoted to art, music and story-telling. This may in turn open up whole new audiences for games.

But occasionally I do slip into excess playing of Tet4, Freecell or Spider Solitaire. I think what makes these games particularly addictive is that restarting them is a move which seems to bring you closer to winning. In all these games, the state of the game starts out as quite simple and the moves are obvious, but as you play things get more complexified and constrained until either you lose or (if possible) winning becomes inevitable. Restarting decomplexifies so when you lose your brain (which is still thinking in terms of the game) naturally reaches for the “restart” key.

Many years ago, I decided to write a Tetris game, just to see if I could. I succeeded, but the play area was very wide. So I added controls to make it adjustable. I figured the minimum sensible width was 4 (otherwise not all orientations of all pieces can be used). Playing Tetris on a board of width 4 (or Tet4 for short), I discovered, is very different to normal Tetris. Things change much more quickly, every piece has a profound effect on the state of the board and the normal Tetris strategies don’t apply because it’s impossible to play without leaving some gaps.

After playing for a while, I discovered that Tet4 was even more addictive than normal Tetris, and that it was much easier to get to the state of mental concentration known as “the zone” – where the entire rest of the world seems to melt away and there is nothing left except you and the falling blocks. When you notice this (and can do so without leaving the zone), it becomes almost an “out of body” experience – your conscious mind almost seems to observe from outside as your unconscious mind plays the game as if on some kind of automatic pilot.

Once I experienced this, I wanted to intensify it. I realized that a gradual increase in speed is intrinsic to the zone experience (otherwise it’s just repetitive). But at a particular speed, the limiting factor becomes how fast your fingers can move to maneuvre the piece into place – this can take as many as 4 or 5 keystrokes with the normal Tetris controls. I realized that Tet4 only had at most 10 possible combinations of orientation and position for each block. Most people have 10 fingers so let’s just assign one combination to each of 10 keys and have a finger corresponding to each key. This is the control mechanism that Tet4 uses, and it worked exactly as I had hoped.

This version is a rewritten version in JavaScript (because I wanted to learn the language, and because by making it run in a web browser more people would be able to play it). I’ve tested it on IE7, FireFox 3 and Chrome and it seems to work fine but there may be bugs with other browsers. Let me know if you find any. I’ve made some fairly substantial changes with this rewrite, which makes this a rather unusual and minimalist version of the game:

• A display which shows the position and orientation for each key (on my original version I learned the combinations by trial and error). This display is really just to reduce the game’s learning curve a bit – to truly get into the zone you’ll need to commit all the combinations to muscle memory.
• In my original version, the 10 keys just set the position and orientation of the tetroid – you had to press the spacebar (or wait for gravity) to drop the piece to the bottom and get the next piece. This meant a decrease in zone at the point where it gets too fast to use the space bar and you switch from 11-key mode to 10-key mode. In this version, the 10 keys drop the piece as well, so you always press 1 key per piece.
• In my original version, the game ends rather suddenly when your tower gets so high that there isn’t time to think before your active tetroid locks. In this version, there is a “curtain” which falls behind the playfield, and you always have until it gets all the way to the bottom before your tetroid drops. This means that the amount of time you have isn’t dependent on the height of your tower. Also, the piece doesn’t enter the playfield until it is dropped, so you can take care even with the endgame (you lose when you drop a piece and it would protrude from the top of the screen).
• The single key control mechanism is rather unforgiving of misdrops, so I added an undo feature – at any time you can press Q to undo the last drop. This helps in learning the keys, but for getting the best scores it is best avoided as your score is also undone but the time speedup is not. This also doesn’t allow you to “look into the future” (further than you can anyway with the next piece indicator) – a new tetroid is chosen at random for the new next piece whenever a piece is placed.
• I added a persistant, global high score table which includes a facility for replaying the top 10 games.
• I modified the colours and key to position correspondances to better take advantage of the symmetries. This puts me at a bit of a disadvantage (since I’m used to the original keys) but should be easier to learn.

One other thing I’d like to do in the future is make an ActionScript/Flash version so that it can be embedded into other pages. I started this but it turns out that without the official Adobe development kit, Flash is really hard to learn.

Well, I hope that in the future, online games are designed in such a way that cheating is impossible – that is, no information sent to a player’s computer that would allow them to gain an unfair advantage and no information received from a player’s computer is trusted to be untampered-with. In such a game, a player would be allowed to use whatever client software they like, and would be encouraged to use client software that gives them the best odds. Serious golf players pick the clubs that give them the best advantage, tennis players pick the best tennis rackets and so on – why should on-line gaming be any different?

One implication of this is that the best games will be Turing tests of a sort – a game of aiming accurately and reacting quickly won’t be much of a challenge since the computer can do those things better than human players. Tasks that humans can do well but computers are poor at will need to be integral to the game.

That’s not to say that games of aiming accurately and reacting quickly won’t exist, but if they are played online they will be played between people who each other and trust each other not to cheat, not between strangers.

The player would be in control of a ball which could be accelerated by means of the direction keys. So holding down right would give a velocity increase in the positive x direction proportional to the length of time the key was held down (there have been a few games that work like this but in my experience in most non-simulation games the player only has one or two speeds and acceleration to/from these is instanteous). Wind resistance would be implemented to avoid the possibility of the ball reaching unlimited speeds.

Once the player has got used to these controls the next complication is maze traversal. While you could in principle just maneuvre around the maze slowly, it is much more fun to play at speeds close to the ball’s terminal velocity. At these speeds, the ball’s turning radius will be much larger than the scale of features in the maze, so the ball will hit the walls. When it does so, the obvious thing to happen is that it should bounce off (unless the wall is dangerous or special in some way).

Another possible complication is areas of the maze with gravity fields. The strength of the gravity could be smaller than the control acceleration (in which case it just changes the controls a bit) or could be greater (in which case entire directions become impossible to travel in). Gravity fields can be constant or central (or may have even more complicated configurations).

Then there could be places in the maze where the drag factor is proportional to some the velocity plus some constant field (i.e. windy places).

Some parts of the maze could be flooded with various different kinds of fluid, giving the opportunity to show off fun 2D fluid dynamics simulations.

Then of course there are the usual game elements – things to collect, power ups, space warps, spikes, enemies with various degrees of artificial intelligence and so on.

A concept that I think is interesting in games is to “raise the stakes” as the game progresses, so that later levels seem to be more important than earlier ones. A couple of contemporary games (neither of which I have played) that embody this principle are Katamari Damacy and Spore. As the game progresses, the very scale of the action increases, causing the early parts of the game to pale in comparison.

3D graphics have become much more impressive in the past few years but the trouble with 3D is that the extra degrees of freedom make the controls more complicated and difficult to learn (especially for people who don’t play many 3D games).

I think it would be interesting to apply the “increasing scale” concept to a 2D game using modern graphical techniques. My idea is a 2D-scrolling shoot-em-up. You start off with a very small, simple “asteroids” spaceship with a very simple weapon. As you blow things up, you can collect more weapons which make your spaceship bigger. Using these bigger weapons, you can attack bigger and bigger targets. The view gradually “zooms out” as the size of the ship, weapons and targets increases.

This idea also reminds me of the Seven Force in Gunstar Heroes on the Megadrive. Easy parts of this boss appeared in an early level and then in a later level there was a “scaled out” version which was much harder and with smaller sprites.

And with modern technology, 2D games can be seriously beautiful. Aquaria does actually zoom in and out a bit, but not by orders of magnitude as I’m imagining.