Pipe Mania
I often seem to have the following motivation problem: whatever task Iam supposed to be working on is the thing that I least want to do,while the thing that I can't work on is the thing that I most want todo! This seems to hold regardless of the tasks that are involved. Iseem to be constantly forcing myself to get on with the essentialtasks, while my mind is pulling me towards the less important tasks.I suppose this is just a corollary to the "shiny object syndrome" thatI described in my blog some time ago!At the moment I am supposed to be writing a textbook (nothing to dowith the Atari), and the publishing deadline is fast approaching.However, what I really want to do is some more 2600 programming. Thishas been exacerbated by watching the rapid progress that others aremaking on their 2600 projects, such as Reindeer Rescue, Strat-O-Gems,and Colony 7. Fortunately, the holiday season has come to my rescueand I have a few days when I don't need to feel guilty about avoidingwork. As a result, I have managed to make some progress on one of theideas that has been distracting me for several weeks, while pretendingto visit my parents In a previous entry, I mentioned that I had already started to thinkabout the 2006 minigame competition. There is a rumour that thecompetition will start in January, and I want to be ready. The gamethat I have been thinking of developing is a version of the classicpuzzle game PipeMania. I think some versions are called PipeDream,but this was later changed to avoid possible drug connotations (Icould be wrong about this?). Anyway, the game was released on avariety of different platforms and was very popular at the time, butseems to have been largely forgotten these days. The version that Iremember most was for the Atari ST. The game-play is somewhat similarto Tetris, although the configuration is rather different.If you are not familiar with the game, then it basically works asfollows. This description is from memory as I haven't managed todownload the game yet or find a version on eBay, so please correct meif I have got any of the details wrong. The game is played on a 10x7grid. Each square can contain a segment of pipe, and one square isdesignated as the "start" square. The idea is to construct a pipelinefrom the start square and make it as long as possible within a timelimit. The pipe pieces are chosen in a random sequence, and you canonly place the piece at the front of this sequence on the grid. It ispossible to replace a piece that has already been placed, but thistakes more time. Once the time limit has run out, the pipeline startsto fill with liquid, beginning from the "start" square. The liquidflows slowly, and you can still place pipe pieces while the liquid isflowing. A second time limit determines how long the liquid flowsfor. If the liquid spills out of the end of the pipeline then thegame is lost. As the game progresses, the initial time limitdecreases, the second time limit increases, and the liquid flows everfaster. Eventually you end up slapping pieces down on the grid madlyin a futile attempt to contain the liquid!Although the basic game mechanics are very straightforward, the gameis difficult to implement on the Atari 2600. As ever, the big problemis with the screen display, i.e. the kernel. I have been giving thissome thought for a while, and I think I have a solution. It isn'tpossible to draw a 10x7 grid using sprites without some seriousflicker (which I hate), and so this leaves the playfield. Early on, Ifigured that all of the pieces could be represented on a 3x3 grid.The screen can accommodate a 10x7 grid of pieces using just PF1 andPF2 (32 pixels width) with my favourite playfield configuration(asymmetric and reflected). However, I quicly ran into problems withthe colours, and so the design as put on hold for a whileTo represent the pipes using the PF, we require 3 colours at minimum:one colour for the pipe, one colour for an empty pipe, and one colourfor a full pipe. Unfortunately the Atari has only 2 colours for theplayfield: the background and the foreground, and there is not enoughtime to change these colours between pieces. To overcome thislimitation, I decided to use a technique that was suggested bysupercat for PoP. If the screen is drawn using alternate yellow andblue lines, then it is possible to generate the appearance of morecolours even though each line is still limited to two colours. Inparticular, a yellow line and blue line next to one another appearswhite. Using this technique, I have implemented a mockup kernel toshow this in action. The source code is attached, though the kernelis rather messy at present.The mockup shows an example pipeline which is partially filled withliquid. What I need to know is whether this looks convincing enough,or if I should just abandon the game now? The problem with theminigame competition is that there are many different platformsrepresented, and a lot are capable of far superior graphics, e.g. theC64. Therefore, if the graphics are confusing or unappealing then thegame will be harshly judged. Honest feedback about this will beparticularly appreciated! Also, any suggestions for improving thekernel are also welcome. The current version required a largeunrolled kernel which will be difficult to modify. Also, I haven'tfigured out how to draw the vertical grid-lines, or the cursor yet.Anyway, I hope everyone has a great holiday season, and I'm lookingforward to seeing what the homebrew community can produce in 2006.The year is a permutation of 2600, so it just has to be special :DChrisInitial Version: EDIT 1:Improved Version: Screenshot of improved version (without gridlines):EDIT2:This version switches colours on alternate frames: cdbypass.zipThe effect works best using the -f switch in z26 (Phosphorescence). There are a few minor timing glitches in this version, but I am not yet sure it is worth continuing or adopting an alternative technique?EDIT3:Slighly more polished version with some timing bugs fixed: jukebox24_20030617.zipScreenshot from this version:jaguar.zip
15 Comments
Recommended Comments