作者：Steve Fulton

几年前，当我正为Urban Squall 4K大赛制作游戏时，我决定重制一款以ActionScript 1语言编写的旧式游戏，并将它呈现在现代平台。由于《Breakout》一直是我钟爱的游戏，我打算以《Brickbasher》为范本，看下能否在4K内存中重新打造这款游戏。我想到《Brickbasher》原版为8K内存，而且我也知道自己现在的编程水平比2002年时更胜一筹，所以，我相信自己可以完成这项任务。

在删掉所有无用的代码，重写更具效率的游戏引擎后，游戏的核心有3K内存。这听起来很棒，但却给我带来一个问题：我要如何创造出有趣的关卡呢？虽然原版雅达利的《Breakout》中只设置了一道关卡，但现代风格的“Breakout”却设计了数十道玩家可以破坏的复杂关卡。《Brickbasher》采用“一个砖块一个字节”的设计模式，并不能让我在4K内存下设计出足够有趣的关卡。为实现这一想法，我重新反思了Atari VCS程序员avid Crane给我的建议。

这要追溯至2001年，David Crane到我的工作所在地推广一个游戏理念。会议之后，我在大厅上拦住他，表达了对他作品的欣赏之情。他并没有立刻走开，我借此咨询了某些一直困扰我的问题：他是如何在《Pitfall!》游戏中植入如此多的画面，而Atari VCS只能容纳4K的容量，但《Pitfall!》（游戏邦注：以及他合作设计的游戏《River Raid》）中设置了256个不同的画面。因为通常情况下，这些有限的条件并不能达到这样的效果。他指出，为了在VCS模拟器中制作《Pitfall!》的场景，他采用多项式序列与位操作优化的结合。简而言之，他抽取了一组256个随机生成的数字，然后检查每个数字的特定比特，了解可以在画面中呈现哪些事物。做完这些后，他在序列中发现让玩家开始的最佳位置，这样，《Pitfall!》世界就诞生了。

之前我从未做过此类事情，但这似乎是在4K breakout风格中创造多道关卡的不错方式。

我的第一个想法是依据精选的随机数字顺序，制作出完全随意的砖块布局。然而，我在尝试这一想法后，我所设计的关卡如预料中单调：如同一组完全胡乱放置的砖块，与我的想法背道相驰。

我又冒出了另一想法，同样多少以Atari VCS为基础。在编写VCS程序时，开发者都持有一个可用的“背景”画面。然而它只占屏幕的1/2。此方法的逻辑即基于Atari VCS的最初设计创意：双人模式的乒乓球和坦克！这些游戏中的场景两端基本上是完全相同的。如果游戏场景相同，VCS硬件设计师就不必耗费额外精力制作出全部场景，他们只需复制这1/2背景，映射，然后就可获得相同效果。这就是为何许多Atari VCS游戏设有对称的游戏场景。

有了这些想法，我测验下哪个游戏场景看起来像采用了一组复制3次的组块（游戏邦注：左上图：正常，左下图：画面翻转，右上图：画面映射，右下图：画面映射后翻转）。当我复制这些画面时，最初看起来像一组任意砖块的画面，就成为对称的游戏场景。

第一组：随机生成的砖块(from gamaustra)

第二组：复制并翻转的砖块(from gamaustra)

第三组：复制并映射的砖块(from gamaustra)

第四组：复制、映射而后翻转的砖块(from gamaustra)

现在，我知道如何在不随机（但重复）布局砖块的情况下，制作游戏中的关卡，但我仍需要一种途径生成这些关卡。按照David Crane的理念，我需要一组重复数字。在研究一段时间后，我定下了关卡编号（1,2,3,……）而这并非一组任意顺序，而是正确排列的编号。由于我在4K内存中不存在多余的字节用于支撑一系列数字或者复杂的随机选择功能，所以这种方法更适合。

接着，我需要测试关卡编号中的字节，查看它们是否适合放置砖块。每一组砖块的面积为6*6（只要复制4次，就可以制作适合砖块的12*12的格子）。我决定逐位测试我所放置的砖块行数和列数。如果该值为“1”，我就会把砖块放置在这个位置：

if (l & j*i)

如果需要放置砖块，我会将它们全部放在画面中的这四个位置（即左上方、左下方、右上方、右下方），从而得到对称性：

makeBrick((j) * 50,(i * 18) +20, level,i);
makeBrick((j) * 50,182 – (i * 18), level,i);
makeBrick(600-(j+1) * 50,(i * 18) +20, level,i);
makeBrick(600-(j+1) * 50,182 – (i * 18), level,i);

以下为我测试砖块及适合它们位置的全部代码：

while (bricks.length <= 0) {

for (i = 0; i < 6; i++) {
for ( j = 0; j < 6; j++) {
if (l & j*i) {
makeBrick((j) * 50,(i * 18) +20, level,i);
makeBrick((j) * 50,182 – (i * 18), level,i);
makeBrick(600-(j+1) * 50,(i * 18) +20, level,i);
makeBrick(600-(j+1) * 50,182 – (i * 18), level,i);
}
}
}
l++;
}

我用这一方法制作出20幅完全不同的画面。我通过提升砖头的坚硬性（需要多次敲打才可击碎），增加关卡中的难度，那样我就可以成倍增加关卡数量。如果我打算扩大6*6的格子规格，那么也要相应增加对称设计。未来，我打算增加更多砖块，更多随机有趣的对称关卡，重新打造这款游戏。

由于《Neon Brick 4K》是一款高难度游戏，我已经截下前20道关卡的画面，所以你可以在这款产品中同时看到位操作优化、数字顺序和画面复制这些元素。

关卡1(from gamasutra)

关卡2(from gamaustra)

关卡3(from gamaustra)

关卡4(from gamasutra)

关卡5(from gamaustra)

关卡6(from gamaustra)

关卡7(from gamaustra)

关卡8(from gamasutra)

关卡9(from gamasutra)

关卡10(from gamasutra)

关卡10(from gamasutra)

关卡11(from gamasutra)

关卡12(from gamasutra)

关卡13(from gamasutra)

关卡14(from gamasutra)

关卡15(from gamasutra)

关卡16(from gamasutra)

关卡17(from gamasutra)

关卡18(from gamasutra)

关卡19(from gamasutra)

关卡20(from gamasutra)

这就是我的想法。简单地采用一些旧式理念，创造出一款更加丰富的游戏。

顺便说下，我采用了其它一些优化方式保持该游戏内存为4K。比如，这些相对简单的图像允许我重新使用所有砖块、背景、球、射击等元素的同张矢量图。我还使用内置的AS3功能的缩放、着色、透明化以及光晕效果，达到画面的复古风格。

最近，我将相同理念延用到《Brick Basher》的原型HTML5 Canvas版本。该版本使用可以从屏幕上方掉落下来的“先进”砖块，所以游戏中没有“关卡”模式。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Using Bit-Wise Operations To Create A Repeatable Sequence Of Procedurally Generated Levels

by Steve Fulton

A few years ago, when creating my game for the Urban Squall 4K Competition , I decided to go back and try to remake an old game that was written in ActionScript 1, and bring it into the modern era. Since Breakout is one of my favorite games of all time, I decided to take my old Brickbasher game and see if I could redo it in 4K. I recalled that the the original prototype for Brickbasher was about 8K, and I also knew I had better programming chops now than back in 2002, so I was fairly confident that it could be done.

After stripping out all the useless code, and re-writing a more efficient game engine, the core was about 3K. This was cool, but it left me with one problem: How do I create interesting levels to play? While the original Atari Breakout had just one level design, modern “Breakout” style game have dozens of intricate levels to destroy. Brickbasher used a “one byte per brick” design that simply would not allow enough levels to make it interesting in 4K. To make this work, I would have to dig back to some advice I received from one of the star Atari VCS programmers, David Crane.

Back in 2001, David Crane came to my place of work to pitch a game idea for an RFP we were conducting. After the meeting, I caught him in the hallway, and professed my undying appreciation for his work. Since he did not instantly run way, I asked him something that always bewildered me: how did he get so many screens into the game Pitfall! The Atari VCS could only address 4K of memory (more with RAM bank-switching), but Pitfall! (and River Raid, a game he helped design) had 256 different screens. This always seemed impossible to achieve within those limitations. He told me that to create the Pitfall! world on a VCS cartridge, he used a combination of a polynomial sequence, and bit wise operations. In short, he took a set of 256 randomly generated numbers (mind you, only randomly generated the first time ), and then checked specific bits in each number to know what to draw on the screen (pits, scorpions, treasure, etc.). When that was done, he found the perfect place in the sequence to start the player, and the Pitfall! world was born.

I had never done anything like this before, but this seemed like a good way to try to create multiple levels for a 4K breakout style game.

My first idea was to create completely random brick placements based on a sequence of seeded (repeatable) random numbers. However, when I tried this the levels looked predictably lame: like a set of completely random bricks, and this is not what I wanted at all.

Instead, I came-up with another concept, also loosely based on the Atari VCS. When programming the VCS, developers had a “background” screen available to them. However, this “background” only took-up 1/2 the screen. The logic for this was based on what the Atari VCS was originally designed to do: play 2-player Pong and Tank! games.. Each of those games has an play field that is essentially identical at both ends. If the play field was going to be identical, the VCS hardware designers did not have to waste extra power trying to create a full background, when they could just copy 1/2 the background, mirror it, and have the same effect. This is why many Atari VCS games have symmetrical play fields.

Armed with both these ideas, I tested what a play field would look like using a set of blocks, copied 3 times (upper left:normal, lower left:flipped, upper right:mirrored, lower right:mirrored, flipped). When I did these copies, what originally looked like a set of random bricks, became a symmetrical play field.

(First set of randomly generated bricks)

(Copied, and flipped second set of bricks)

(Copied and mirrored 3rd set of bricks)

(Copied, mirrored, and flipped 4th set of bricks)

Now I had a concept for how I would build levels out of random (but repeatable) placed bricks, but I still needed a way to generate those levels. Going with David Crane’s idea, I needed a repeatable set of numbers. After playing around with this for a long time, I settled on the level number (1,2,3,…). Yes, this was not really a random sequence, but it very well could have been. Since I did not have the bytes to spare in 4K to hold a list of numbers or complex random seeding function, this would have to do.

Next I needed to test the bits of levels number to see if I should place a brick. Each set of bricks was 6×6 (copied 4 times to make a 12×12 grid of possible bricks). My decision was to bitwise AND the level number with the product of of the row and column of the brick I was placing. If the value was was “1″ (on, true,yes), I would place a brick in that position:

if (l & j*i)

If the brick was supposed to be placed, I would place put it in all 4 places (upper left, lower left, upper right, lower right) the screen, achieving my symmetry:

Using this method, I was able to create 20 distinct screens. I added difficulty by making bricks that had to be hit multiple times (different colors), and the number of possible levels increased almost two-fold. If I had decided to increase the grid size from 6×6 to anything larger, the possible symmetrical designs would have increased as well. I plan to remake this game in the future with more bricks, and even more interestingly random, symmetrical levels. (See HTML5 Brick Basher link at the end of the story)

Since Neon Bricks 4K is quite a difficult game, I have taken screen shots of the first 20 levels, so you can see the product of the bit wise operation, number sequence, and screen copy ideas all in one place:

And that is it. A very simple use of some old ideas, to create a richer game than would have been possible otherwise.    Play the final version of Neon Bricks 4K.

By the way, there were a few other optimizations I used to keep the game under 4K. For instance,  the relatively simple graphics allowed me to reuse the same single  vector image for all the bricks, backgrounds, balls, shots, etc.   I used the built-in AS3 functions for scaling,  tinting, alpha, and glow effects to achieve the retro look I was striving for from that single image.

I’ve very recently used a similar concept for a prototyped HTML5 Canvas version of Brick Basher.    This version uses “progressive” set of bricks that continuously come down the screen, so there are no “levels”. It’s mobile-ready and uses touch controls (you need to click and drag the mouse on the web to move the paddle).

Steve Fulton is Vice President Of Software Development for Producto Studios, an independent development house in Redono Beach, California specializing in animation, games, e-learning, Flash,  HTML5, web and mobile. (source:gamasutra)