12 issues.

Too many articles to count. From assembly to RPG Scripting, to your first looks at DA2 and ProjectRt, among others, to art, music, and more, we've covered a ton in that 1 year. And it's not just us that have brought ya a lot in the last year: the qbasic community has been more active than at any point ever before. Don't believe me? Let's take a walk down memory lane, and see what's gone on in the qb community each season since August 1998.

Fall 1998
Summer was winding down, qbasic.com was still being updated with regularity, and Angelo Mottola, recently revered with his creation Wetspot 2 that spring, announced on his page that he had "big plans for a DirectQB library". Blast! was then the most-used, and Dash was gaining subscribers, although no one could've guessed just how pertinent to the future of qbasic those "big plans" would end up being.

SFB2, still the best fighter in qbasic, with a primitive-based graphics system, great particle support, and a fab roto-zooming camera, became a splash in this season also. Danny Gump released a build of Super Mario World Clone, showing that Super Nintendo quality games were by all means possible in qbasic today.

But all was not well in the qbasic community. The newly-christened (and short-lived) QBVoice broke news of an attempted sabotage of Dash by implanting a virus into the file caused qb'ers to question for the first time the safety of the .exe's compiled in qb on the internet. Tsugumo's heralded graphical acheivement in TheGame and big plans for the game were sidetracked as he cancelled the project. Apester disapeared from the qb scene, in all respects. And the IDSA sent letters to top qb sites including the qbt50 that they would no longer be able to post links to or post quickbasic4.5 on threat of having the site license revoked. As we know now, that threat never carried thru, but it made it hard to find for those who had "lost their only copy" at the time.

Most saddening though, was the loss of arguably one of the greatest qbasic coders ever in Milo Sedlacek, who passed away as a result of a chronic illness on September 24, 1998. Milo, aka Gradius, is known for many of his programs, most notably Monospace Shooter and the never-completed RPGDemo4, both amazing technology demos for qb in the pre-library days. But happier days would soon follow, as we entered the frosty cold of...

Winter 1998/1999
As winter rolled along, all of America was focused on Slick Willy and the White House Three; all except the qb community was hearing enough good news to "blow off" the allegations, so to speak. With Winter beginning, DA2 production also started. But, almost as importantly as this, were the following words from the November issue of the mag:

"More interestingly, we've picked up some rumours about Enhanced Creations future plans (cough...next game...cough)"

Of course, this game ended up being "Project RT", still one of the most hyped and most secretive qb games in the works (despite the first screens which we procured for this spring's issue). Speculation about what the game was ranged from a Massive Multiplayer RPG to Wetspot 3D to a Real Time Strategy title. Amazingly, what's known about the gameplay of the game is almost as vaulted over at Enhanced now as it was then.

With Christmas break, us coders were enjoying the frosty snow...by looking out the window near the computer, of course. Who has time to trim the tree when announcements such as "a new Vertical Scroller by Pasco", "a super-secret, rocking demo called Xeno", Puz and DA2 shots were coming thru the pipes? Recollecting back, we'll also notice the December issue commented on a "secret graphics library from LordQB". Could this be the LiquidGL from News this month?

And even with the holidays passing, new paradigms in qbasic coding such as uNESs, the first Nintendo emu in qbasic, or LTPB, Interplay's new beginner level BASIC language proved that qbasic was far from dead. But the frivalty of the holidays proved no match for...

Spring 1999
Spring is conventionally "lull-time" as far as qb code is concerned, and although no earth-shaking programs came out, there was certainly nothing to complain about in terms of the qb community.

Most of the talk during this month focused on speculation about what would win at Sonicblue's Qlympics. The 1st Qlympics were tainted by allegations of cheating, and Sonic assured us he was doing all he could to prevent that from happening. In the end, there weren't many major upsets in any category, with big name titles like Dark Ages and Wetspot 2 easily conquering their category, as had been suspected.

PP2, the Labryinth and MOTG Project all got their fair share of publicity, either due to the demos that were released or the name recognition of their creators. And, as luck would have it, they've all panned out thus far to be equals in the regality they recieved, most notably thus far The Labyrinth by Seav. The only major First Person Shooter in qb so far, progress continues on it at a good clip, and it already plays very well.

Much chatter was also diverted to the future of the QBIDE. The memory and speed problems of qb have hindered the language from being anything but a hobbyist language since it's creation, but plans such as QBCC by Leroy threatened to change that distinction. QBCC is planned to work by taking qb code and "converting" it into a DJGPP file, which would give it muchisimo speed. Not only that, there were, and still are, plans to make an alternate IDE that is Windows based, to give you the ability to have multiple progs open at the same time.

All was not well, though. Viruses hit many qb coders, including Angelo Mottola and myself, which is why qb:tm reccomends you never accept a file from someone you don't know except in .bas form. Nekro's game Killerz stirred up controversy among some, much as WoS before it, because of it's content. Nekro, true to form, was not swayed by the commentary, standing up for his games whenever possible.

Finally, our April Fools joke about Project RT being an Action Strategy RPG starring Cuby and Coby was not, err, picked up by some, leading to boards being peppered questioning whether it was, in fact, an Action Strategy RPG.

Summer 1999
The summer of '99 is by no means over yet, but it has already become one of the greatest for qb enthusiasts. Shadow of Power and Of Hell and Magic, two acclaimed RPG's, were both released, and both offered quality as high or higher than Dark Ages, the benchmark for programs of that variety thus far.

Dmitry Brant and Petter Holmberg showed that they were the most 1337 of coders by displaying (relatively) fast jpeg viewing in qbasic. Jpegs, are, of course, one of the most difficult types of files to decode, due to the complex compression they use. The future of Qb also looked to have been shown by two libraries, and one future one, in Gslib, FutureLibrary and Glib.

QB's next year promises to be as great as the one before. The mainstream considers qbasic all but dead, but the last few pages have shown what a group of quality coders can accomplish. As has been said before, the difference between good and bad code doesn't hedge on the language. See ya next year!

Hail!

Welcome to the second installment of the new RPG tutorials. Hopefully by now, most of the rust has worn off... and I'll be able to provide you all with a much better tutorial.

If you missed the previous one... It showed you how to write a scripting engine for your RPG. If you don't see it around here somewhere, ask zkman, I'm sure that he still has it. :)

This time around, I'll show you how to write a semi-active battle engine!

Before we start, let me point out that all of the code used in this tutorial is available in a zip file, along with some graphics, which demonstrate the engine in action. You can download it now, or read the tutorial first. If you're new to this, I would suggest reading the tutorial, as the code is not commented.

NOTE: This tutorial is aimed at a novice QB programmer. If you're a beginner, it shouldn't be too tough to figure out, But you may wish to brush up on your coding skills first.

Setting it all up.
First, we need to set up our variables, and the sub routines which we will use. Remember, always start with the two lines below. The $DYNAMIC meta- command is used to store arrays dynamically; This means that your array space is much more flexible. DEFINT A-Z defines all arrays as integers. This basically speeds up execution of the program.

'$DYNAMIC
DEFINT A-Z
Next, we delcare our sub routines. I'll explain what each of these is for once we get to them, so don't worry about it for now. You may also wish to know that this step is optional, as QB will automatically create these lines when you write the actual subroutines.

DECLARE SUB GetHandLocation ()
DECLARE SUB TimerDelay (Seconds!)
DECLARE SUB Battle ()
DECLARE SUB StatsBox ()
DECLARE SUB ChoiceBox (BoxType%)
DECLARE SUB DrawBattleScreen (ScreenType%)
DECLARE SUB InitBattle ()
DECLARE SUB InitRandomStats ()
DECLARE SUB InitSprites ()

Next, we must dimension our arrays, set up our global variables, and our constants as well. The first constants, are true and false. We will be using these for our 'flag' variables, to see check for certain happenings and tell the program to comtinue doing something if they are false, or to do something else if they are true.

CONST True = -1, False = NOT True

Next, we dimension the arrays we will use in the engine. These are needed to store our graphics. For this engine, there a four different enemies, and all are 32x32 in size. The two player characters are also 32x32, there are also three frames of animation for them. Next, our hand pointer is one 16x16 sprite. Finally, we need to allocate two arrays to hold parts of the graphic background which our sprites might be put over. This way, we can get what's behind the sprites, put or sprite on the screen, then, restore the background when we're done. Finally, we will also allocate space for masks in our sprite arrays.

Basically, This is the calculation I used to determine how big each array would have to be:

((SpriteXSize * SpriteYSize / 2) * NumberOfSprites) - 1

If you are not familiar how this all works, I would suggest reading a tutorial about sprites and graphics in SCREEN 13. It would help you understand more of what we're doing here.

DIM SHARED Hand%(258)
DIM SHARED Players%(4626)
DIM SHARED Enemies%(2570)
DIM SHARED BackSprite%(1028)
DIM SHARED BackHand%(129)

Next, we need to declare all the variables and dimension all of the arrays, which we will be using for our data. Basically, we need space to hold the players stats and enemy stats. Below, are the stats I deemed necessary for this engine to work. It's a good idea to give everything a name which will tell you what each variable is for; Ie. PlayerHP% is a much better variable name than, say A1% to hold the player's Hit Points.

DIM SHARED PlayerName$(1 TO 2), PlayerAlive%(1 TO 2), PlayerType%(1 TO 2)
DIM SHARED PlayerHP%(1 TO 2), PlayerMaxHP%(1 TO 2), PlayerMP%(1 TO 2), PlayerMaxMP%(1 TO 2)
DIM SHARED PlayerST%(1 TO 2), PlayerDF%(1 TO 2), PlayerAG%(1 TO 2)
DIM SHARED PlayerMS%(1 TO 2), PlayerMD%(1 TO 2)
DIM SHARED PlayerEXP&(1 TO 2), PlayerGold&
DIM SHARED PlayerX%(1 TO 2), PlayerY%(1 TO 2), PlayerGo%(1 TO 2)

DIM SHARED EnemyName$(1 TO 4), EnemyAlive%(1 TO 4), EnemyType%(1 TO 4)
DIM SHARED EnemyHP%(1 TO 4), EnemyMaxHP%(1 TO 4), EnemyMP%(1 TO 4), EnemyMaxMP%(1 TO 4)
DIM SHARED EnemyST%(1 TO 4), EnemyDF%(1 TO 4), EnemyAG%(1 TO 4)
DIM SHARED EnemyMS%(1 TO 4), EnemyMD%(1 TO 4)
DIM SHARED EnemyEXP%(1 TO 4), EnemyGold%(1 TO 4)
DIM SHARED EnemyX%(1 TO 4), EnemyY%(1 TO 4), EnemyGo%(1 TO 4), EnemyThere%

DIM SHARED HandX%, HandY%

Now, we will initialize the random number seed. What is this? Well, we need the ability to generate random numbers, so that player and enemy damage isn't always the same. This line tells QB that we will be doing so later.

RANDOMIZE TIMER

Okay... Now we're more or less set up. The next parts of this tutorial will deal with individual parts of the engine. It is recommended that you read all of them carefully, as they are all intertwined closley together.

The rest of the main module.
This is how the rest of our main module would look. Note that some of this refers to subroutines I have not talked about yet... You may scroll down and read about these subroutines first... Then come back here.

Well, we have to tell QB to load our initialization routines next. To do this, we just call them by name like so:

InitSprites
InitRandomStats

Once we're initialized... Let's switch to screen 13 (320x200 resolution video mode, with 256 colours if you don't know) and call our main Battle sub to begin the fight:

SCREEN 13 Battle

Well... The battle's done. Now, the engine reverts to text mode and displays a short message and waits for a key press. After this, it exits. This last bit of code, you should leave out.

SCREEN 0: WIDTH 80
PRINT "Semi-Active Battle Engine. Created by DarkDread, 1999"
PRINT "You may use this in your programs... Just give me credit :)"
PRINT "Press any key to exit."
WHILE INKEY$ = "": WEND
END

The main battle sub.
This is the biggest sub routine in the engine, as it controls the flow of the battle. You may split this up into smaller routines, but for the sake of simplicity, I kept it this way for the tutorial.

Our subroutine starting code... QB will automatically do this for you, when you create a new sub, so you may skip this part if you wish.

REM $STATIC
SUB Battle

First, we must initialize our battle stats, then tell the program to draw the battle screen. It is done by calling the DrawBattleScreen. Note that we also pass a value of 1 to it. This way, the sub will know to draw a starting battle screen, and not an ending one.

InitBattle
DrawBattleScreen 1

Now, we begin our main battle loops.

DO

DO

These next lines, will calculate the agility of player and enemy characters that are still alive. This sub will take the agility of each character, and add it to a total every time it loops. Once a character's total is greater than 99... That character will be allowed a turn. Also, some of the player part of these lines, draws the little red and yellow status bar, which shows how much longer a player has to wait until their next turn.

FOR I = 1 TO 4
IF EnemyAlive%(I) THEN EnemyGo%(I) = EnemyGo%(I) + EnemyAG%(I)
IF EnemyGo%(I) > 99 THEN
EnemyGo%(I) = -1: GoThere% = True
END IF
IF EnemyGo%(I) = -1 THEN EXIT FOR
NEXT I
FOR I = 1 TO 2
IF PlayerAlive%(I) THEN PlayerGo%(I) = PlayerGo%(I) + PlayerAG%(I)
IF I = 1 THEN
Yellow = PlayerGo%(I) + 128
IF Yellow% > 228 THEN Yellow% = 228
IF Yellow% > 128 THEN LINE (128, 16)-(Yellow%, 18), 44, BF
IF Yellow% < 228 THEN LINE (Yellow% + 1, 16)-(228, 18), 40, BF
ELSEIF I = 2 THEN
Yellow = PlayerGo%(I) + 128
IF Yellow% > 228 THEN Yellow% = 228
IF Yellow% > 128 THEN LINE (128, 32)-(Yellow%, 34), 44, BF
IF Yellow% < 228 THEN LINE (Yellow% + 1, 32)-(228, 34), 40, BF
END IF
IF PlayerGo%(I) > 99 THEN
GoGo% = True
END IF
IF PlayerGo%(I) > 99 THEN EXIT FOR
NEXT I

Here, we have a little timer delay. This is to slow the battles down to a playable speed. If the delay wasn't here, you would notice that everyone attacks almost at once! The battles wouldn't be much fun then. You can raise this number to slow a battle down, and lower the number to speed it up.

TimerDelay .1

LOOP UNTIL GoThere% OR GoGo%

A character can now take a turn... If GoThere% is true, this means that it's an enemy's turn.

IF GoThere% THEN

Next, we check which enemy is allowed a turn, and if they are still alive or not... Just in case. Once we have found out, we draw the enemy mask on it's location. This will draw the enemy in all black, so the player knows which enemy is about to attack them.

FOR I = 1 TO 4
IF EnemyGo%(I) = -1 AND EnemyAlive%(I) THEN
PUT (EnemyX%(I), EnemyY%(I)), Enemies%(514 * 4), AND
This next line randomly selects which player the enemy will attack. This is where our random seed generator is put to work.

HitPlayer% = INT(RND * 2) + 1

After a player has been selected, these next lines check if that player is alive. Then a calculation is made based on the enemy's strength, the player's defense, and the help of a few random numbers, to determine how much damage the enemy has done. The random numbers are used just to add some variety to the damage. Instead of an enemy doing, say, 5 damage on a player all the time, they may do 3 sometimes, and 6 some other time.

Finally, we must take the damage done off of the player's HP. If the player's HP is less than one after this, it means they are dead. We then change the player's HP to 0 (So you don't see negative numbers in their stats) and make the PlayerAlive% variable of that player false. This way, the engine will know not to let that player have a turn, or to show their picture on the screen.

IF PlayerAlive%(HitPlayer%) THEN
Damage% = (EnemyST%(I) * 2 + (INT(RND * 4))) - PlayerDF%(HitPlayer%)
IF Damage% < 1 THEN Damage% = INT(RND * 2) + 1
PlayerHP%(HitPlayer%) = PlayerHP%(HitPlayer%) - Damage%
IF PlayerHP%(HitPlayer%) < 1 THEN
PlayerHP%(HitPlayer%) = 0: PlayerAlive%(HitPlayer%) = False
END IF
ELSE
IF HitPlayer% = 1 THEN HitPlayer% = 2 ELSE HitPlayer% = 1
Damage% = (EnemyST%(I) * 2 + (INT(RND * 4))) - PlayerDF%(HitPlayer%)
IF Damage% < 1 THEN Damage% = INT(RND * 2) + 1
PlayerHP%(HitPlayer%) = PlayerHP%(HitPlayer%) - Damage%
IF PlayerHP%(HitPlayer%) < 1 THEN
PlayerHP%(HitPlayer%) = 0: PlayerAlive%(HitPlayer%) = False
END IF
END IF

Next, we show the damage done on the appropriate player, and delay for 3 seconds. The delay is necessary to allow us to see how much damamge the enemy did, and on who.

IF HitPlayer% = 1 THEN
LOCATE 12, 36: PRINT Damage%
TimerDelay 3
ELSEIF HitPlayer% = 2 THEN
LOCATE 18, 36: PRINT Damage%
TimerDelay 3
END IF

Now that the enemy's turn is done, their agility meter must be set back to 0. We must also make GoThere% false, so the engine knows to return to the pervious loop. Finally, we must make our DrawNeed% variable equal to 1. We will use this variable later when calling the DrawBattleScreen so we know what parts of the battle we will need to redraw.

EnemyGo%(I) = 0: GoThere% = False: DrawNeed% = 1
END IF
NEXT I
END IF

Next, our routine checks if it was a player's turn right after the enemy's. If so, we must redraw the screen, using our DrawNeed% variable from before.

IF DrawNeed% = 1 AND GoGo% THEN DrawBattleScreen DrawNeed%

Now, we check if it's the player's turn to go. If so, we check which player will be going. Then, we draw a choice box for them which will give the player their options (RUN, ATTACK) and set up our hand pointer X and Y values. We then draw the player's mask over the player, this way, we will know which character's turn it is. We also draw our hand pointer next to the first choice in our choice box.

IF GoGo% THEN
FOR I = 1 TO 2
IF PlayerGo%(I) > 99 AND PlayerAlive%(I) THEN
ChoiceBox 1
HandY% = 5: HandX% = 10
PUT (PlayerX%(I), PlayerY%(I)), Players%(514 * 6), AND
PUT (HandX%, HandY%), Hand%(0), PSET
ChoiceMade% = False

Now, we have to create a loop. Then, we trap the keyboard buffer using INKEY$ to check which keys the player has pressed. This is all used so that the routine knows to move the hand pointer up or down, and which choice the player has selected when they hit enter.

DO
SELECT CASE INKEY$
CASE CHR$(0) + CHR$(72)
IF HandY% = 5 THEN
HandY% = 29
ELSEIF HandY% = 29 THEN
HandY% = 5
END IF
LINE (5, 7)-(24, 45), 0, BF
PUT (HandX%, HandY%), Hand%, PSET
CASE CHR$(0) + CHR$(80)
IF HandY% = 5 THEN
HandY% = 29
ELSEIF HandY% = 29 THEN
HandY% = 5
END IF
LINE (5, 7)-(24, 45), 0, BF
PUT (HandX%, HandY%), Hand%, PSET
CASE CHR$(13)

The player has hit enter. Now, we check where the hand pointer was when they pressed the enter key. If it was at Attack (HandY% = 5), then we allow the player to choose which enemy they wish to attack. This is done with the hand pointer, and another loop while checking the keyboard. You will also notice that before the handpointer is moved, the routine checks if which enemy is still alive and which one isn't. This is so that the hand pointer is never pointing to an enemy that is no longer there.

You will also notice that this is where we use our array to hold the back- ground graphics were the hand pointer is put. This is necessary because once the player moves the hand pointer, we need to restore the graphics that were there before the pointer was drawn.

After the player hits enter here... We determine which enemy they have decided to attack. Then, we make a calculation based on the player's strength and the enemy's defense... As usual, we throw in a few random numbers to add variety.

Finally, we show an animation of the player attacking (We use our second array to hold background graphics here) and display the damage done on the enemy they've attacked. Again, we pause after this for 3 seconds, so that we may see who was attacked by whom, and how much damage was done.

IF HandY% = 5 THEN
ChoiceBox 0
GetHandLocation
GET (HandX%, HandY%)-(HandX% + 15, HandY% + 15), BackHand%
PUT (HandX%, HandY%), Hand%(130), AND
PUT (HandX%, HandY%), Hand%(0), XOR
ChoiceMade2% = False
DO

SELECT CASE INKEY$
CASE CHR$(0) + CHR$(72), CHR$(0) + CHR$(80)
PUT (HandX%, HandY%), BackHand%, PSET
IF HandX% = 8 AND HandY% = 85 THEN
IF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
ELSEIF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
ELSEIF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
END IF
ELSEIF HandX% = 114 AND HandY% = 85 THEN
IF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
ELSEIF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
ELSEIF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
END IF
ELSEIF HandX% = 8 AND HandY% = 135 THEN
IF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
ELSEIF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
ELSEIF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
END IF
ELSEIF HandX% = 114 AND HandY% = 135 THEN
IF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
ELSEIF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
ELSEIF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
END IF
END IF
GET (HandX%, HandY%)-(HandX% + 15, HandY% + 15), BackHand%
PUT (HandX%, HandY%), Hand%(130), AND
PUT (HandX%, HandY%), Hand%(0), XOR
CASE CHR$(0) + CHR$(75), CHR$(0) + CHR$(77)
PUT (HandX%, HandY%), BackHand%, PSET
IF HandX% = 8 AND HandY% = 85 THEN
IF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
ELSEIF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
ELSEIF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
END IF
ELSEIF HandX% = 114 AND HandY% = 85 THEN
IF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
ELSEIF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
ELSEIF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
END IF
ELSEIF HandX% = 8 AND HandY% = 135 THEN
IF EnemyAlive%(4) THEN
HandX% = 114: HandY% = 135
ELSEIF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
ELSEIF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
END IF
ELSEIF HandX% = 114 AND HandY% = 135 THEN
IF EnemyAlive%(3) THEN
HandX% = 8: HandY% = 135
ELSEIF EnemyAlive%(1) THEN
HandX% = 8: HandY% = 85
ELSEIF EnemyAlive%(2) THEN
HandX% = 114: HandY% = 85
END IF
END IF
GET (HandX%, HandY%)-(HandX% + 15, HandY% + 15), BackHand%
PUT (HandX%, HandY%), Hand%(130), AND
PUT (HandX%, HandY%), Hand%(0), XOR
CASE CHR$(13)
IF HandX% = 8 AND HandY% = 85 THEN
EnemySelect% = 1
ELSEIF HandX% = 114 AND HandY% = 85 THEN
EnemySelect% = 2
ELSEIF HandX% = 8 AND HandY% = 135 THEN
EnemySelect% = 3
ELSEIF HandX% = 114 AND HandY% = 135 THEN
EnemySelect% = 4
END IF
ChoiceMade2% = True
END SELECT
LOOP UNTIL ChoiceMade2%

Damage% = (PlayerST%(I) * 2 + INT(RND * 4) + 1) - EnemyDF%(EnemySelect%)
IF Damage% = 0 THEN Damage% = INT(RND * 2) + 1
EnemyHP%(EnemySelect%) = EnemyHP%(EnemySelect%) - Damage%
IF EnemyHP%(EnemySelect%) < 1 THEN EnemyAlive%(EnemySelect%) = False
FOR J = 7 TO 8
PUT (PlayerX%(I), PlayerY%(I)), BackSprite%(514 * (I - 1)), PSET
PUT (PlayerX%(I), PlayerY%(I)), Players%(514 * J), AND
IF J = 7 THEN
PUT (PlayerX%(I), PlayerY%(I)), Players%(514 * (PlayerType%(I) + 1)), XOR
ELSEIF J = 8 THEN
PUT (PlayerX%(I), PlayerY%(I)), Players%(514 * (PlayerType%(I) + 2)), XOR
END IF
TimerDelay .5
NEXT J
IF EnemySelect% = 1 THEN
LOCATE 12, 4: PRINT USING "###"; Damage%
ELSEIF EnemySelect% = 2 THEN
LOCATE 12, 17: PRINT USING "###"; Damage%
ELSEIF EnemySelect% = 3 THEN
LOCATE 18, 4: PRINT USING "###"; Damage%
ELSEIF EnemySelect% = 4 THEN
LOCATE 18, 17: PRINT USING "###"; Damage%
END IF
TimerDelay 3
ChoiceMade% = True: DrawNeed% = 1

Welcome to the third art tutorial, written by…Me. This tutorial can be read independently of the previous two, although it is suggested that you read the others anyway, because they were written by Me (and you can pick up the conventions used in My tutorials). Is there a slight air of egotism in this article? =) This tutorial steps out of shading concepts and into the wonderful world of tiling. Tiles are (usually square) blocks of art that can be repititiously blitted to the game screen to make a world. The advantage to using tiles, as opposed to using very large bitmaps depicting entire areas, is that tiles take up much less space, and are easier to work with from a programming perspective (testing collision, for example).

The downside to tiles is that they are not entirely flexible, and the final product they represent tends to look "blocky" or repititious. There are several methods of tiling, but first it is necessary to learn seamless tiling, the root of tiling techniques. One thing to note in this tutorial is that some of the larger coordinate blocks are depicted with cyan borders for the purpose of simplicity.

seamless tiling
For the purpose of making this tutorial less confusing (as if it were not confusing enough to begin with |-) ), I have divided the example bitmap into two parts: the first part shows the tiles used, the second part shows the tiles being tiled in a two by two square. I will distinguish between the two examples by using a prefix of "A" or "B" (the former refers to the first bitmap, the latter to the second) in front of the bitmap coordinates. That said, look at the asphalt tile in A(1,1). You can already tell this tile sucks =)…and sure enough, looking how it tiles in B(1,1), you can see that it is definitely not seamless.

What is that you ask, grasshopper? What is a seamless tile? A seamless tile is a bitmap that can be copied and placed repeatedly in an adjacent fashion such that the viewer can not tell where the origin of the original bitmap is. In simpler terms, a seamless tile, when tiled, has no visible edges. One bitmap should line right up with the next with no awkward lines between if it is seamless. Look at A(2,1) for an example of a seamless tile, and its tiled output in B(2,1).

Making a seamless tile can be very complex and frusterating, if you only use trial and error. However, a fairly simple trick can save you lots of work. I call it CAPEA, or "cut and paste edge alignment." It works like this: first, a tile is made, without regard to its seamlessness. Next it is cut in half horizontally…the upper half is place adjacently below the lower half. Then the edge between the two is "fixed," such that no seam appears in the currently visible tile. Then the lower half is placed in its original position, and the tile is cut vertically, the right half is placed adjacent to the other side of the left.

Finally, the seam between the left and right halves is fixed, and the right half is placed back in its original position. This process may seem awkward, but it is the single most efficient way I know of making a seamless tile. To clear things up a bit, I made two examples. In the first example A(1,2)-A(7,2), the goal was to create a checker pattern that would blend completely along the edges, but not the inside (which is rather redundant for a checker tile, but it was intended for an easily visualized example). The resulting tiling can be seen in B(3,1). In the second example A(1,3)-A(7,3), a (more real-world) random ellipse pattern was made; the goal of course, was to have it tile seamlessly.

This required, in some instances, slightly reshaping or resizing the ellipses. In the result B(4,1), there are several larger ellipses in the center of each tile…this results in a conspicuous pattern (the viewer can easily discern where each tile is, relative to the akward oval). In general, you will want to avoid making any sections of your tiles too different from other sections…no internal components of your tiles should be akwardly large, small, colored, or greatly varied in any other way from the rest of the tile components. I noticed in a certain game the bookshelf tile had a skull on it, next to several books. The skull did add a bit of atmosphere, but when I saw that every bookshelf in the game had the same skull on it…it made me wonder =). To make lots of jargon short, avoid this mistake.

blending tile regions
Knowing how to make a seamless tile is only the first step…what if you want to make one tile type blend with another type? This is particularly useful for terrain…say if you wanted your grass tiles to gradually fade to your sand tiles, or your rock tiles to your dirt tiles. We want to have tiles that fade in every direction, so we can create any possible shape (imagine trying to create a large, rectangular patch of grass on some sand: we would need pieces that fade to each of the four sides, and the four corners). So let us enumerate ALL possible transitions, so we can build any shape of transitions. This can be done with some simple block tricks…if we divide a tile into four quadrants, where each quadrant can be "on" (represented by black) or "off" (represented by any shade of red) (think binary =) ).

There are sixteen possible combinations…but we do not want the one that is completely blank (all quadrants off); after all, how useful is a blank tile? Subtracting one, this leaves us with fifteen possible combinations. If you align these possible combinations A(1,4), you can easily distinguish that they form four sides, four corners, four inverse corners, two touching corners, and a whole tile. This is the base set we want to use for creating tiles that shift from one tile type to another. From this set, we can create a blender mask, a mask that will dither your base tile set onto any type of terrain. To create a blender mask, simply fade the black dot region onto the red, using less and less frequent dot dithering, and do the opposite with the red region A(2,4). Then, once you have a base tile, you can just make fifteen copies of the tile and place this blender mask over it A(3,4), dropping out the black color as a transparency. Then only the red region has to be dropped out from the transitioning tiles when they are placed on top of other tiles, as shown in B(1,5). As difficult as I may have made that simple process seem, I guarantee that it works great, and is very easy once you create the blender mask…or you can even copy mine if you are lazy =).