JANUARY 16th, 2004

Welcome to the new version of QBOA! I am greatly honored to be a part of this magazine, and I thoroughly enjoyed co-editting alongside with Nekrophidius. It took us awhile to get this issue out, so many things have happened along the way. But with lots of support from the community (and plenty of pestering from Lachie), we were finally able to put out this issue.

In this issue you will find some long awaited articles, recent news in the Qmunity and many other features which readers have come to expect from QBOA. This magazine is still as radical and cutthroat as the first day, only now with a feminine touch. (I hope to make the next issue pink. j/k ;) ) I hope you enjoy this issue as much as we did creating it for you.

Nekrophidius made me write this corny introduction. :)

eQuuskia, Co-Editor, QB ON ACID
A few people were expecting to see the second part of the UGL review in this issue. Unfortunately, time constraints have made this impossible. The review will either be in the next issue, or will be an addendum to this issue as soon as it's completed. Apologies ahead of time to those looking forward to the second part of the review, but rest assured, it will be here in due time. :)

Nekrophidius, Co-Editor, QB ON ACID
QBASIC.TK Explodes Onto The Scene
Zap, Rhican, and SumoJo have brought a unique new QB experience into the Qmunity. QBASIC.TK, generously hosted by wildcard, launched its new website in late December and is built around a phpbb forum. Everything is on the forum, from downloads to news to competitions. Although the site has technically been around for almost 2 years, it has experienced problems such as faulty hosting (Geocities) and not-so-nice designs, as stated by SumoJo, one of the QBASIC.TK founders.

"SumoJo 'registered' the qbasic.tk domain", says QBTK co-owner Zap, "and put up a site on Geocities featuring downloads, stuff, and a forum. I don't know how long it was going, as I first began looking around in the scene again, because I had just left my previous programming group (QGZ, Kackurot, Lachie and LooseCaboose) because it was kinda falling apart. So... I was 'freelance' for a while, until a missed someone to be in a group with. I looked on various new sites, and bumped into qbasic.tk.

I noticed that Rhican had suggested a redesign of the site, and I decided during about 10 secs that this was what I wanted to do, as I still had some php code from the last site I had begun to redesign (qgz). And so the group was formed.

I spent some months doing the site, and Sumo, Rhican and me discussed and talked and stuff, until I suddenly lost interest and nothing happened for months, though all that was missing was the 'about' section. So interest fainted, and months went by, until I finished the site and things was going again, though I talked mostly with Rhican because I had discovered MSN. Some people might remember the look the site had then, something with spring-green or whatever you call it. By impulse, I decided to throw it away, and replace it with phpBB2. Well the thing that really set it of, was my lack of skill to do a proper file searcher, and I though 'Hey, phpbb can do that'. So I modded phpBB2 heavily during this xmas, and we launched the site. And here we are today.

Motivations? Well, I think that Sumo and Rhican wanted to make a site that was easily accessible for newbies (which I just remembered, so I came up with a new deign idea during my french lesson), with resources for people wanting to learn QB. That's why it's qbasic.tk and not bla.lobilidup.hulibuli.com/~iloveqbsomuch/, an alternative to qbasic.com, meaning it's a site newbs might find when they enter something in the address bar. My motivation is mostly that I love coding sites ;) . I guess expectations are to create a great site with many useful downloads and tuts, and a forum full of nice people."

QBASIC.TK's first official challenge: Make a Roguelike in QB! Zap originally intended this competition to run until March 1st. However, at the request of some of the competitors, it has now been scheduled to end May 1st, adding two more months of development time.

"Rhican had suggested that we made a compo to sorta promote the site", continues Zap, "and get people here, like qbasic.com did (which I'm too young to remember). I had completely forgot when we launched the site, but remembered soon enough. So I though hard, and at the same time happened to just have read Jocke's article on rogue likes, where he said that he hoped that there would come some qb versions soon. So I figured to shut him up... I forgot to talk with Rhican and Sumo about it, but I Sumo have paid me back by modifying some of my posts a little... damn him. I extended the date because of three things: 1. Some people said it was to short a time, 2. More people might join because the have a chance to finish something now, and 3. because I think the quality will be better, which is cool."

QBASIC.TK is currently looking to redesign their logo. If you have any ideas for their new logo, surf over to the site and post your ideas.

QBASIC.TK website

News by eQuuskia and Nekrophidius
Chione Challenge
The Chione Challenge, named after the Greek Goddess of snow, was held throughout the month of December on rpgdx.net. Although not an exclusive QBASIC challenge, 5 out of the 15 competitors were developing their games in QuickBASIC. The rules were simple: make an RPG with a snowy theme: snow weather effects, snow tracks, and some snow covered objects. Six games made the cut in the end, with the majority being developed in C++. The voting ended on January 15th with Blorp Zingwag's "Elf Detective" emerging as the victor. BadMrBox's "Chrystal Winter" was the only QB-based entry to win in the top three, scoring a tie for third with Independence's "Arthur Dents Dreams Winter Edition". Bjørn promises a summer competition in a few months. Great compo Bjørn!

News by eQuuskia
New Meets Old In A New QB Archive
Veteran scener Blitz, together with RPG developer XBot, are working hard to complete a new QB archive center. It features all of the content from QB45.com, as well as anything considered "interesting" across the internet. The site is based around Postnuke and contains QB45's old Postnuke skins, as well as a number of others.

When asked why he's doing this project, site founder Blitz says "cuz such a thing been missing for a while". You can check out the progress this far at http://archive.bad-logic.com/.

News by Nekrophidius
The Comeback Of The Zeldaesque
The team of FRoG32 and cha0s are producing one of the rarest styles of games in QB: the zeldaesque. Named "Lynn's Legacy", this work-in-progress has a history shrouded in secrecy. We were able to obtain a working model of the engine, it's looking great and shows tremendous promise.

"Well", says LL conceiver FRoG32, "at first Lynn's Legacy was just a side project... I didn't really have a coder or much knowledge of coding back then, until I met this one guy... I think he called himself Codered... He was a Game boy advance coder, and seemed interested in developing LL- But one walkaround demo later, he apparently became too busy to manage the project. It lay dead for a year or so, until I met Cha0s. Now he's doing the coding for the project. Anyway, I guess I wanted to do a zelda-esque game because of two reasons: one, there are hardly any indie-zelda style games out there, and two: Zelda: A link to the past had to be my all-time favorite RPG-- I still play it through to this day, heh."

Not since Shadow Of Power has the QB scene seen a serious Zeldaesque.

"Oh one other quick thing...", says FRoG32, "Lynn's Legacy is being coded by a stoner, and it's graphics and music are done by a 15 year old kid-- I don't want to give the illusion this is some huge blow-your-mind project coded by all the big blow-your-mind bigshots. ;)"

Lynn's Legacy is featured in this month's Gallery.

News by Nekrophidius
***RESPECTED*** Member Of The Qmunity Scheduled For __Deletion__!!!!
The Qmunity's highly eccentric and often grossly offensive Adigun A. Polack demonstrated just how arrogant and self-centered a QB programmer can be. Over the course of roughly two weeks, the New Jersey-based programmer managed to go from a misunderstood eccentric to Xepher.net's most hated antichrist by using religion as a weapon, offending a vast number of Xepher.net regulars, hyping himself up to be "one of the most respected QB4.5/QB7.1 community members", and challenging the owner himself, Xepher.

"Wow. I never pictured someone could be that self-centered", says Xepher.net's owner. "Nothing anyone says seems to even get through to this guy."

Xepher has scheduled Adigun's site for removal on January 20th. Xepher's primary motive for the deletion? Adigun's responses to the accusations of breaking the Internet Privacy Protection Act as well as the COPPA, set forth by the Federal Trade Commission. Xepher states, "I'm not against the 'abuse of law' people claim AAP has demonstrated... I'm against the inherently amoral nature of it. If someone asks you to remove their name, you don't go and post it on the front page again. It's wrong. If there was no COPPA, it'd still be wrong. That's all that matters to me."

News by eQuuskia and Nekrophidius
There have been many faces in this community that have come and gone. Some we'd like to remember, others we'd rather forget. This little section is a chance to track down these people and see what they're up to these days. So, without further ado, here's this issue's list of WHERE ARE THEY NOW?

---Angelo Mottola (DirectQB, Wetspot I & II, Project RT, was at ecplusplus.com but the site has since disappeared)
---Rich Geldreich (DeGIF6.BAS)

Last issue, we looked for TaxDAY and Dae Breaker. TaxDAY had been located by toonski84 on the old QB45.com forum but the link has since become defunct. No one seems to know what's become of Dae Breaker. Are these two now lost to history?
Finite State Machines are the basis for many games, especially fighting games. This is a snippet from the M.U.G.E.N. documentation:

"A finite state machine (henceforth abbreviated FSM) is an automaton with a finite set of subroutines, each of which performs some function and then employs some criterion to choose the next subroutine to jump to. Each subroutine is called a "state", and the FSM is said to be in a given state when it is currently processing the directives in that state. A FSM can only be in one state at any given time."

"The following is a trivial example of a FSM, given in pseudocode."
State 0:
1. Read in a number.
2. If the number is 0, go to state 0. Else, go to state 1.

State 1:
1. Print "Woohoo!"
2. Go to state 3.

State 2:
1. Go to state 0.

State 3:
1. Quit
"Suppose this FSM starts in state 0 and reads in the value 0. Then it will return to the beginning of state 0, and read another number. This will continue until the FSM reads a nonzero number, at which point it will switch to state 1. In state 1, the FSM prints "Woohoo!" and then switches to state 3. State 3 causes the FSM to quit. State 2 is never reached in this example."

"Here's a state out of an FSM which might be used for a fighting game character."
State 555:
1. Try to punch the other guy.
2. If successful, and the user is holding punch, go to state 555 (chain move).
3. If successful and the user is not holding punch, play recovery animation.
4. If not successful, play miss animation.
5. When the recovery or miss animation ends, go to state 0 (idle).
So basically, an FSM is like an engine that interprets and controls these "states" based on various factors and conditions. Each "state" has a number of attributes which determine what it does and how it can change to a different state. For a practical example, we will look at how states might be defined for a fighting game.

Generally speaking, a state is always running. Therefore, there is likely some sort of "default" state. We'll call this default state "State 0". For our example, let's say State 0 is your game character just standing around, doing nothing, waiting for something to happen. That something could be you controlling him, him getting beat on by the opponent, the timer running out, or virtually anything else. So this default state continually repeats itself until it is interrupted by most anything.

Now let's say you decide to move your character forward. He will now switch to what we'll call "State 10", or moving forward. As long as you keep pressing in the same direction and nothing else affects the state, this state will repeat itself. Releasing the direction will revert him back to State 0.

If the opponent comes too close, you'd want to try to fight him off. So, you press one of the attack buttons. Let's say the one you pressed starts State 50. State 50 now puts your character into a state with different attributes than States 0 and 10; now he's in a sequence where fewer things can change the state, and this state will revert back to 0 if nothing changes this state before its sequence is completed.

Now in this State 50, there is going to be a time when it can put the opponent into another state. Let's say we have two main states for this, being a "block" state and a "hit" state. We'll call them State 1000 and State 2000 for Block and Hit respectively. Depending on the opponent's state during your State 50, one of these two states could be called. Being a certain distance away, or the collision of bounding boxes (another fighting game concept but outside the scope of this article) will put the opponent in one of these two states. As with all states thus far, once the state is over, if they're not put into another state, they'll revert back to State 0.

The concept of this logic is called a "trigger". Triggers determine what states are called. One way to affect a trigger is through the use of a "Command", probably better known as a keypress or button press. For example, let's say you have a Command that binds the key "A". When "A" is pressed, its Trigger goes off that changes to State 50. This is one of the ways a State can be changed.

For example:
Trigger1 = Command("A")
SetState = 50
Now, what happens if "A" is entered while the character is in State 2000, for example? Will you want him to throw his punch during a fall animation? Probably not. So, there are a couple of ways of handling this problem. The first way is to add a Trigger to the "A" Command, telling it not to execute if the character is in State 2000. However, this method would require it to also check for State 1000, and possibly hundreds of other States. So, what do you do? You implement what we call a Flag, and in this case, we call it "Ctrl", short for "Control". Ctrl can be either on or off, and is tied to whether or not Commands can be entered or not. So, we include a new trigger into our "A" Command, telling it not to execute if Ctrl = 0 (player has no control). In our State 2000, we will set this Ctrl Flag to 0, which now disables Commands. When State 2000 or whatever State it transitions into has completed, we add a Ctrl = 1, making Commands usable again.

As a build-on to our previous example:
Trigger1 = Command("A")
Trigger2 = Ctrl = 1
SetState = 50
Note how it now looks for Ctrl = 1. Both of these conditions must be true for the State to activate.

You will find that you will need to implement more and more triggers as time goes on. For example, now we can check that our guy can't punch someone if he's already in another state which has Ctrl disabled. But what if he's in the air? Or crouching? Certainly we don't want him to use the same exact attack State, so we can create a new kind of trigger. For this example, we'll call this trigger MoveType. To build on our previous example:
Trigger1 = Command("A")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = STANDING
SetState = 50
You could theoretically assign any value system you want to MoveType, provided your state machine can read and understand its syntax. The key issue is that now, this State is only entered IF (1) Command = "A" (2) Player has control and (3) Player character is Standing.

Now for the States themselves. What specifically happens in a State? Well, a State contains the data the FSM needs to carry out functions. It does this through a series of what we call State Controllers. A State Controller is basically like a function call to a very specific action. Here's an example of what State 50 could possibly look like:
[Statedef 50]

[State 50.1]
Set Ctrl = 0
Anim = 50

[State 50.2]
Trigger1 = AnimFrameLeft = 0
Set Ctrl = 1
Now, what the heck did we just do? Okay, from the top: First, we set a "Statedef", short for State Definition. This Statedef says "hey look, I'm State 50!". The FSM looks at this State 50 and carries out the first instruction it finds, which will be State 50.1. Now, it turns off Ctrl and plays Animation 50 (it is wise practice to keep your animations the same number as your States, to avoid confusion). Now, having done this, it goes on to the next State. Hrm...it sees that there's a Trigger here, so it needs to check to see if it can execute the code in this particular snippet. Until AnimFrameLeft = 0 (this would be a variable that returns the number of animation frames left in the Anim sequence), it cannot execute the function. Once this is true, Ctrl is reset to 1, and because the Statedef is now completed, the FSM returns to State 0.

Set and Anim are what we call State Controllers. So is Trigger. Anything that controls the State can be considered a State Controller.

Now, this is all working theory. The task you are faced with is developing an engine that can interpret a language that you develop for your FSM. There is no standard methodology for developing this language. However, there are several working models of FSM's in action. For fighting games, one of the most popular is the M.U.G.E.N. fighting game engine, available on the WWW (the official webpage disappeared). It contains a VERY rich FSM language, and is a good basis for your own language.

A final note on Commands: The M.U.G.E.N. engine uses Commands as a special State, called State -2, which is checked every frame. This is not a terribly difficult process to accomplish, but if the Statedef -2 gets too many State -2's, it can easily bog down any FSM no matter how optimized it may be. In addition, this Statedef -2 exits itself as soon as it has carried out the very first State -2 it finds that meets all of its criteria (all the Triggers check out ok), so it can never execute more than one State change per frame. This is an extremely effective system, and it is recommended that you use this type of system in developing an FSM language.

By this note, a proper example of some Commands might look like this:
[Statedef -2]

[State -2]
Trigger1 = Command("A")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = STANDING
SetState = 50

[State -2]
Trigger1 = Command("B")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = STANDING
SetState = 60

[State -2]
Trigger1 = Command("C")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = STANDING
SetState = 70

[State -2]
Trigger1 = Command("A")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = CROUCHING
SetState = 150

[State -2]
Trigger1 = Command("B")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = CROUCHING
SetState = 160

[State -2]
Trigger1 = Command("C")
Trigger2 = Ctrl = 1
Trigger3 = MoveType = CROUCHING
SetState = 170
Does it look like a lot of work? It is. This is not an easy system to implement. Finite State Machines are not trivial, but the time you spend implementing one will give you the flexibility and power to create some very spectacular games.

In the next issue of QBOA, I will build on State Controllers and attempt (!) to cover Bounding Boxes and Animation Definitions (they usually go together).

Article by Nekrophidius
Blazing Ball Fantasy - Screenshot 1

Blazing Ball Fantasy - Screenshot 2 Ball Blazing Fantasy is a game produced by Kentauri which pits you, a ball, against another ball, in an effort to either push yet another ball into your opponent's goal, or collect little "minerals", depending on which game mode you play. There is a backstory for this game, but who really needs a backstory for this kind of game! Anyways...the review! :)

Although not overly flashy, the graphical representation of this game is very well-done. The movement is very fluid, and the game controls surprisingly well. It takes a lot of getting used to, but once you adjust to the controls, you're unstoppable. In a way, this reminds me of the old game Ballistix by Psygnosis.Blazing Ball Fantasy - Screenshot 3

The enemies are...well, annoying, to be nice. OK OK, they're a pain in the ass. This game is quite challenging, to say the least, which will either keep it fresh for you, or just irritate the hell out of you. I found myself continuously "trying again", so it certainly has a good amount of replay value.

The sounds and music are well-placed, and double congratulations are in order considering the fact that the author has no sound card. But what really surprised me is the double palette...a "normal" and a "bright" palette (all screenshots taken with the "bright" palette). That is REALLY helpful to those of us with dark monitors.

Blazing Ball Fantasy - Screenshot 4The dual gameplay really pushes this game over the standard mark. Tournament mode is about shoving the ball into the opponent's goal without hitting a creature, and Quest mode involves running around various world, collecting "minerals" without falling in a hole, getting hit by a creature, or other such things. This variance in gameplay differs from a lot of games out there today, and is a very nice touch.

It was difficult finding anything bad about this game. As with many games out there today, the only real flaw (and this is grasping for straws), is the lack of proofreading of the text. I don't know about the rest of you, but improperly spelled sentences are just irritating.Blazing Ball Fantasy - Screenshot 5

The only other thing that could be considered a downfall is the challenge. The game is VERY frustrating at times, and gamers in a hurry will find another game to dominate. However, it is designed to be challenging, and nothing beats the level of satisfaction when you conquer a game like this fair and square.

If you haven't yet played Ball Blazing Fantasy, do yourself a favor and download it NOW. If you're into these kind of games, it will certainly not disappoint. This reviewer would argue that it's better than Ballistix, which I think it appears to be inspired by. Congratulations on a fine piece of software, Lachie!


Review by Nekrophidius
Rally - Screenshot 1

Rally - Screenshot 2 This was posted for review on the old QB45.com forum, the author wanted it to be looked at. Well, yours truly has done just that.

Umm...unlike most games which I review that are hard to find what's bad, this is a case of it's hard to find what's good. About the only interesting thing in this game is the flying bird in the background. Wow...I'm out of words already.

Where to begin...let's just put it this way: the author says he intends on making a game as good as Ghini Run. Wow...does he have a loooooooooong way to go. Number-keyed menus, unresponsive controls, terrible graphics, and no sound whatsoever. It looks like this game was programmed in SCREEN 7 (from the lack of colour depth). I give this guy props for trying, but he has a very long way to go on this before even considering it release-worthy. Something like this *might* have been acceptable 20 years ago but not today.Rally - Screenshot 3

Don't even bother with this game unless you want to see how a game SHOULD NOT BE when it is released. In its current state, this game is so poorly constructed that it's difficult to even write a proper review on it. Word to the author: keep trying. If you have the motivation to produce something great, keep trying. However, this is a far cry from what was good even ten years ago.

Review by Nekrophidius
One Key Challenge trophy!

The Winner!On October 22, 2003, Lachie Dazdarian from Croatia opened a compo called the One Key Challenge. This unique challenge involved the development of a complete mini-game of any genre in QB, which only used one key to control the whole game. Seven submissions and 37 days later, the compo was closed and the voting commenced on Qbasicnews.com. Members of this community voted on their favorite game by means of a poll. The competition was tight between Nekrophidius' shooter game "Fundee" and Lachie's arcade style "The Man Who Had A Boat".

"And people, stop voting for me. I so don't want to win this challenge. It would be really silly for me to write my own name on the prize I drawed for the challenge I organized. I didn't wanted to leave my entry out of competeition since it would be patronizing to others who participated." said Lachie as his game pulled ahead with a total of 9 votes, leaving "Fundee" behind with 6. A total of 24 members voted, leaving Lachie Dazdarian as the clear and unquestionable winner of his own competition. He plans on perhaps opening another "One Key" challenge next year, with more submission time, or a similar challenge with a different twist.Not quite good enough to win

My opinion: This challenge was truly unique, and I believe thoroughly enjoyed by the contestants and the community alike. I can't wait to see what Lachie comes out with next year. (And btw, how did it feel to write your own name on the trophy, Lachie? ;))

You can find more information and all the entries for download at Game With One Control Key Challenge Official Website.

by eQuuskia
Since I was asked to write something down about the one key challenge I organized and since the challenge itself drew a respectable amount of attention, I'm using this opportunity to take you through the entire challenge and present my final thoughts on it.

I don't remember exactly how I did came up with the idea for one key challenge. I think it was in the moment when I was reading some posts in the Challenge forum on the QBasic News site. I had nothing against other game making challenges in that forum but they were either too restrictive but still demanding or too general, like genre based game making competitions. They simply, by my opinion, weren't enough motivating for people who don't code or design games often. That was in the October of the last year, year 2003. The one control key concept was something present in my mind, since I've played few games of that kind but the idea to organize a one key challenge in QBasic community never came to me. Until that moment. Right away, when this idea arrived in my head I wrote the rules, from my head. I mean, I did thought a bit and rewrote few rules before clicking on submit button but it was not something planned for hours/days.

Rules, in a nutshell were that entries had to be under 1 Mb, gameplay had to be restricted to one control key(no mouse support was allowed to avoid misunderstandings) and that participants had one month to finish their entry, which was later prolonged on 37 days. Entries, of course, had to be coded in QBasic and usage of libraries was allowed.

Initially, the challenge drew a lot of attention. Many promised to participate. From the start I personally wanted to participate but pondered on if I should officially participate in the challenge poll, through which the winner would be determined.

I finished my entry quite early. I was happy with the graphical design but wasn't too happy with the gameplay so I decided to participate in the challenge poll because I didn't expect to win and still wanted to contribute to the overall size of it. As the time passed, more and more entries were submitted, and with few prolongations the total number of entries stopped on number 7 which is great. Quite a few people didn't submit anything but did promise to do so. Despite that fact the challenge was a success. Since I finished my entry quite early I was able to help a couple of people with their entries. Challenge officially lasted from October 22nd till November 28th. After the period for submission expired I opened a poll in QBasic News forum which lasted for 12 days and in which forum members could vote for their best one key challenge entry.

Before I comment on the final results I would like to say something about each of submitted entries.

Cannons by red_Marvin was the first entry I checked. It's a simple Scorched Earth clone with a very nice feature which allows you to add your own terrains. One key restriction was smartly solved. Sadly Cannons doesn't support AI which is a rather downside. I contributed to this game quite a lot with advises and graphic.

Falling Starz by James Kinney is a very technically imperfect space shooter. I did liked the monochrome graphic. It reminded me of the legendary Monospace. Still, I simply wasn't able to enjoy at all in Falling Starz due the mentioned technical imperfection. I think this was the first finished challenge entry. James completely forgot about it so I had to remind him to submit it few days before the challenge deadline.

Free Fall by RST was my most favorite entry. It had that addictiveness. A simple vertical scroller in space. It featured a neat space ship sprite and challenging gameplay. Sadly, it is obviously unfinished. But RST ensured me he plans to release a new, better version.

Fundee by Nekrophidius is probably one of the best challenge entries. I cannot confirm that since I wasn't able to play it properly but from the little I saw and from what the other people commented it's one of the most polished and fun entries. Anyway, we are talking about Nekrophidius here.

Red Jumpy Ball by Ryan was described by many as the most addictive entry with the best gameplay. A side view platform game. Sadly, I wasn't able to play this one too. I was also warned that Ryan plans to really improve this game and release a completely finished product, hopefully in the near future.

Tanks by potato was coded in pure QBasic as Falling Starz too. I think it was also made in screen mode 12. When it was submitted it was rather unpolished and unfinished. More a working code than a demo. I had to add a menu and few tweaks so it could be a proper challenge entry. Tanks is a mini, top view, arcade game with tanks. Nothing much tanks related, really. It could as well feature bugs or cars. Simple game of collecting objects but addictive and potential. I hope someone will decide to make a real game based on this concept.

The Man Who Had A Boat was my entry. I was very happy how the graphical design turned out. I mostly used routines from Ball Blazing Fantasy when making this game so the coding wasn't demanding. It only features three levels which is way too little to consider it a real game. But the concept itself doesn't leave much space for expansion. Short but colorfully boat rowing game with little content and almost no replay value.

Overall a nice sum of effort. Maybe not enough finished and properly packed entries as a expected but that's probably due the time limit which leads to conclusion that a future possible challenge of this kind must have a longer period for submission.

As I said voting lasted for 12 days. I didn't like how the ratio of cast votes was on the beginning but in the end 24 people voted which a respectable sum of people. People were warned to pay attention on the gameplay, technical perfection and how clever was the one control key restriction used when voting.

The results were:
Cannons - 1 vote
Falling Starz - 2 votes
Free Fall - 2 votes
Fundee - 6 votes
Red Jumpy Ball - 2 votes
Tanks - 2 votes
The Man Who Had A Boat - 9 votes

Yes, I won. In one period during the voting I didn't really want to win. But from other people's comments on the entries and mine especially, I guess I got convinced that my entry isn't that bad. I assume they liked the graphical design and the fact that The Man Who Had A Boat, no matter how small, was a finished game.

Honestly I really didn't care who would win. More important to me was that the challenge is a success and I think I managed to do that. The challenge showed that there is quite a lot of life in community and that all we need is to motivate people to create something. It remains a question is there something similar to one control key concept which will draw the same interest. Still, a possibility of organizing a second one key challenge is there, definitely with a longer period for submission, but I think it would be wrong to start a new one too soon. If you are interested in more detailed information about this challenge and perhaps didn't had a chance to play the entries you can visit the official challenge website on this URL: www.samods.com/~lachie/onekeyc and download them.

"Game With One Control Key Challenge" or "One Key Challenge"?
Well, the first one is the official title but I can't expect from people to use it always so One Key Challenge is more that acceptable.
Anyway, I use it too. :P

Once again, thanks to all the people who participated in this challenge on any way. Peace.

Article by Lachie Dazdarian (slightly edited for presentation)
Right now I'm sitting in a Greyhound bus station in Thunder Bay, Ontario to hide from my past. That thought only grazes my consciousness for a minute though, because I have a secret I need to share. A big secret. A lot of professional programmers have been keeping a secret from you. They don't want you to know the truth. To be honest, I wasn't sure if I should tell you, but it must be said. I'm here to tell you what every programmer needs to know; I'm here to tell you how to program everything and anything. I'm sure you can understand that I'm putting myself into mortal danger by telling the world like this, but without this information, an entire generation of programmers may keep living with the wool pulled over their eyes, and I cannot allow that, especially in QB, where the programmers are so bright, but many of them still don't understand the one fundamental truth.

There has only ever been one program ever written, and every other has been a clone of that.

In these paragraphs, I'm going to explain The One Program in detail, I'm going to point how that original program works, and how you can use the innate knowledge of The One Program to code anything you've ever wanted.

The One Program

The one program ever written is deceptively simple, mostly because programming languages make it simple. In reality, the operating system, the BIOS, and the programming language dummy it down so much most people can't see it, but I'll tell you what it is.
20 INPUT "Try again"; Answer
30 IF answer = "yes" THEN GOTO 10
Deceptive, isn't it? Let's look at what the program is really doing though. There's where things get interesting.


The first line of the program is probably the most abstracted, so read carefully. After that things get a lot simpler, so just bear with me.

The PRINT statement represents several stages of memory reading and writing, array indexing, pointers, and many other aspects of most output engines, whether it's a 2d tile engine in VGA, or a fullscreen bitmap renderer using SVGA, or an RS232 teletype terminal. In many ways, it's even more difficult.

The first major part of the PRINT statement is a huge memory location at &HB800. In this segment, all text data is stored. To let the video card know that a character is at a certain location, two bytes are written to the screen: The first is a character code, which is just a pointer to a certain element in an array of font sprites in the video cards memory, the second is a type code, which determines the foreground colour, background colour, and status as a special text type (bold, underlined, flashing, etc...), which tells a special routine on the video card how to render it. In turn, that rendering program on the video card will try to draw to the video segment at &HA000, placing the fonts by placing the bitmaps found at the array I mentioned earlier onto the screen in a prescribed format, which is determined by the video mode, which is stored elsewhere.

Knowing how that process works from &HB800 onwards, the largest hassle for the moment, several steps before the text appears to the screen, is knowing what kind of text you're rendering and where. Internal variables keep track of both of these, whose movement is likely controlled by other routines which are designed to scroll the screen down when text reaches the bottom of the page.

From here, we finally have enough information to send the text to the screen. This is done by starting at the sprite pointer, whose first couple bytes are descriptor bytes in QB which describe the length of the string (C and C++ use a null character at the end, which is easier for low-level programming by humans, but opens the door for things like buffer overruns, the cause of many internet vulnerabilities in software today). Reading the relevant information and skipping over the rest of the header, the print routine reads the character from the string, puts it at the correct memory location, and goes on until the end of the string is reached. Then the OS is sent a "carriage return" character, which increments the row variable mentioned earlier.

Finally, the text is on the screen.

20 INPUT "Try again"; Answer

Since we have already defined the print routine, this command becomes much, much simpler. In fact, the first step is to just print "Try Again", then without sending any "Carriage Return" characters, a "?" is printed, again without a "carriage return", and finally the input function itself starts.

The first step of the input routine is simple; input. BIOS routines handle reading the keyboard, and change a stream of pure keydata into a manageable single character ASCII code. This is added to the string being captured, and drawn onto the screen using something like PRINT. After an enter key keypress is detected, the string is converted into a floating point number (because we didn't do a defint earlier), which is entered saved into the memory location provided, Answer.

30 IF answer = "yes" THEN GOTO 10

The final step of this program is deceptively simple in terms of actual work done, but for most people, the work done isn't immediately apparent. The important thing to realize is that a PC cannot simply check if two strings are the same. The machine goes through the letters, one at a time, and if any differences show up, only then does the program know that they are not the same. At this point, the processor itself sets a variable right on the processor, and another instruction tells the instruction counter on the CPU that it must go to instruction 10. In terms of machine language, it's slightly more difficult because there is no instruction 10 as we know it, but the compiler counts that for us, thank god.

How is this relevant?

By now, You're probably asking yourself "What happened to teaching us how to write any program?". Well, I'm sure most of you recognised parts of that description. From start to finish, no major part of programming wasn't covered. More importantly, all major algorithm types required to handle Input, Output, and data manipulation.

For example, if one was going to write a particle system, a data structure not unlike the &B800 array would be perfect. If one were to write a tile engine, a routine not much different from the PRINT routine would work just fine as a starting point. If someone wanted to write a 3d game engine, the same pointer structures and the same multiple rendering modes used for different video modes' text routines would be added, with only a few small changes.

In essence, once you understand exactly HOW any program works, on an intimate level, you can create any other program using the framework of knowledge you get from the first. It sounds like a cop-out, but I invite you to take the next program you want to write, and try to break it down into known elements, like pointers, arrays, strings, data structures, et. cetera. You should find, as most people do, that once you start thinking in that way, all programs break down, and you will indeed, as I promised, be able to write any program.

In other words, I hope you were paying attention.

Article by SJ Zero
This is a series of various shots and snippets from this upcoming Zeldaesque game from FRoG32 and cha0s.

Lynn's Legacy -- Screenshot 1
A mockup of how the finished game will look.

Lynn's Legacy -- Screenshot 2
A nasty boss.

Lynn's Legacy -- Screenshot 3
Another nasty boss.

Lynn's Legacy -- Screenshot 4
From the current engine beta.

Want your game's screenshots displayed here? Submit them to us!
DECLARE SUB DrinkACouple ()


IF FeelingSpunky = True THEN

  Say$ = "Man, you always puss out on me"
  Say$ = "Hell yeah! I'll see you then"


IF PartyTime = TIME$ THEN



IF AtParty = True THEN


  IF NumOfGirls < NumOfGuys THEN Book




IF SpecialCalculation = True THEN 'Note: This is extremely rare!



IF FeelingPukey = True THEN

  SELECT CASE Location$

    CASE "In house"

    CASE "Outside"


    CASE "In a car by the road"

      Say$ = "Oh I just remembered something came up"




IF HaveTwister THEN

  Say$ = "Go get your boyfriends first"

  IF GirlsAreLame = True THEN






DO UNTIL PreppieBitchWantsTaGo = True




IF TIME$ > "06:00:00" THEN



IF AtHome = True THEN

  Say$ = "OMG, sorry man!"


IF FeelingBetter THEN GOTO Start

SUB DrinkACouple

FOR Number = 2 TO ((Craziness \ Responsibility) + Balls)

  SELECT CASE FeelingSquirrely

    CASE True

      Shotgun = Beer(Number)


      Drink = Beer(Number)



Submitted by cha0s
Every issue, we try to annoy a random Qmunity member the best we can. Why? Because we can, and we think it's funny. :) So, without further ado, here's this issue's Quote Of The Month! This time, we look at the infinite wisdom of


"serisuly nathan everyone with more then 2 brain cells knows that's BS really funny joke nathan since everyone knows gets is a rellic from a long ago past time and what happens if you write outside the buffer and scanf shouldn't be used like that scanf is kinda useless sscanf and fscanf on the other hand.... funny on nathan I'm still laughing..."

This is a post on Qbasicnews.com's General Programming forum from November 29th, 2003. Seems these two were arguing over some C code, and Shogun whips out this nicely butchered mommery of semi-English. However, na_th_an was quick to reply: "Funny how the spammer laughs at me... Funny indeed. May I have two brain cells but I use them to try to help and not posting silly posts and links to stupid sites."
QB Colony
An all-game-review site, QB Colony has undergone massive changes over time but is now up to stay! And besides...he found Vance the Pirate! The site is small but growing, and will eventually be THE center of game reviews for all the Qmunity.
Well people, this concludes the most anticipated release of QBOA ever in its four year history. Yep, it's been over four years since the very first QBOA appeared in the Qmunity. Over the last four years, the scene has continued to evolve and advance, but the one thing that remains constant is the Qmunity is strong and even now almost twenty years after QB was released, it's still going strong. Even as Microsoft has denounced its existence along with the rest of MS-DOS, we still cling to this ancient technology like we would a beloved child. But it is not the language itself, it's the community that surrounds the language that keeps this scene alive. That being said, the Qmunity will never die...even as the language itself migrates to other platforms. Keep up the coding spirit and never let it die! :)

This is Nekrophidius, signing out.
QB ON ACID can be reached via email.