QB Express

Issue #9  ~  May 10, 2005

"A magazine by the QB community, for the QB community!"

In This Issue



From The Editor's Desk

Written by Pete

So....it's now May 11th. And this is technically the APRIL issue of QB Express. Sorry guys. My bad. Real life wasn't giving me any breaks, and everything ended up being due all at once. But now that I'm out of college for the summer, I've got plenty of free time to do plenty of QB Express stuff.

Even though this issue is two weeks late, I think it was definitely worth the wait. For the third month in a row, we've got a super-sized issue, with NINE tutorials and TWENTY-SIX separate articles. No other QB mag in history has had this much great content so consistently. The writers and contributors of this magazine are incredible.

But instead of tooting everybody's horn, I'm gonna just let you get to the issue. (Besides, if you read the letters section, you'll get enough of it this month.) There's tons of great articles in store, and you've all been waiting long enough.

Enjoy!

Submit To QB Express

You all know the drill. This magazine can't exist without people SUBMITTING articles, editorials, tutorials, reviews, news and feedback. This is not just a solo effort by me... it's a group effort by people throughout the QB community. If you have anything to submit, or have time to write something, DO IT!

If you want to write about something, but can't think of a topic, or need inspiration, email me! I'm good at thinking of stuff to write about, and I know quite a bit about the QB community and about QB programming. If you're interested in getting your own monthly column or just want to write an article or two, by all means, do it! Anything that is submitted will be included!

I also want feedback and letters to the editor regarding this magazine. I want suggestions and critiques. What do you like? What don't you like? What could be done better? Let me know!

All submissions and feedback can be sent to pberg1@gmail.com. You can also PM me on the Pete's QB Site or QBasic News message forums. Or, you can just fill out this form to send an email directly to me.

If QB Express is going to continue to be so good, YOU need to contribute!

-Pete



Letters

Letter From Joseph Burke

Hey Pete,

Thanks for accepting my review.

I'm sorry to hear that your site was spammed. I suppose it is an unfortunate reality that there are some incredibly sad and twisted hackers out there. And they haven't just targeted your site. For instance, one of my favourite Sonic fan game sites, sfghq.emulationzone.org, was hacked recently. This dude took over the messageboard, and then threatened to destroy the site if the webmaster (Smidge) didn't make him a moderator. Smidge backed up his site, told him to get stuffed, and deleted sfghq.emulationzone.org in its entirety. Bloody sad.

So, death to hackers.

I said in my last email that I would give you an update of sonicx, so here it is. In the limited spare time I have had, I have been focusing on some presentation issues. In every commercial sonic game, levels start with a black screen that only has the level name shown. As the level loads, the screen fades from black and the level name text is taken off the screen. This was partially implemented in sonicxV9, but the text always read "icecap zone". I have now fully implemented it for sonicxV10, and the text displayed can be anything the level designer wants.

The other major presentation touch up relates to the score screen which appears when the level is finished. This is now implemented and calculates a ring bonus and time bonus which it adds to the score.

There has also been some further work with the scripting engine. It can now process variables like ChangeSignPath, Nextsign, CreateTempSignPath, DeleteTempSignPath, CreateObject, ChangeObject, DeleteObject, IsSonicLeft, isSonicRight, IsSonicUp, IsSonicDown, IsSonicClose, IsSonicFar, DoesItTouchSonic and DoesItTouchAnotherObject. These variables are calculated relative to the object calling the variable. Basically what this means, is that an object can move along a certain path, and change paths depending on where the sonic sprite is. It can also create new objects depending where the sonic sprite is. So SonicX can have heaps of virtually autonomous interacting objects.

About my scripting engine, this is what scripts look like:

66 24 59 67 68
66 25 59 25 51 67 1
63 25 59 67 3 64 25 59 67 1
63 25 59 67 1 64 35 59 ring1.wav
63 25 59 67 2 64 35 59 ring2.wav
66 1 59 1 51 67 1
66 2 59 67 100 51 2
65

It is activated when a ring is picked up. It actually means:

Execute varpointer% = 68
Execute var1!(varpointer%) = var1!(varpointer%) + 1
If var1!(varpointer%) = 3 then var1!(varpointer%) = 1
If var1!(varpointer%) = 1 then PlaySoundFx ring1.wav
If var1!(varpointer%) = 2 then PlaySoundFx ring2.wav
Execute rings! = rings! + 1
Execute scoring! = 100 + scoring!
End

Regards,
Joseph Burke

Thanks for the scoop on SonicX! Your game is really popular around the Qmunity, so I'm sure the readers will be glad to find out about it.

As for the hacking and spamming, yeah, it really sucks. It's annoying as hell. A few weeks ago, I was fixing my site literally every night because of either hackers or spammers. But I guess there's not much I can do about it except secure my site better, since the number of spammers, hackers and other lamers visiting my site is only going to go up.

-Pete

Letter From Lachie Dazdarian

Greetings Pete,

After few weeks I finally found time to read the last issue of QB Express and to write this email. I was mostly busy working on my entry for Nek's Space Invaders competition. It's called Evil Baron Lachie. :P Check it in QbasicNews forum.

I also downloaded ALL the issues of QB Express released so far so I checked some of the articles I missed in the past issues. Since I share you interest in QB community history I quite enjoyed reading the article about Qlympics. Very interesting stuff. Especially now when I'm working on my QBasic Games Directory project(84 games in a MQL database so far!). Elysian Fields contains so much disgusting self-boasting that it makes me sick.

Anyway, after reading issue #8 I realized that all the things you said in the editorial of the mentioned issue is absolutely true and not exaggerating. Definitely the best issue of QB Express so far, by quality and quantity. No one could predict such growth of the magazine. It's wonderful to see what QB Express has done to the community. I can't thank you enough for being such a positive force. It's not only the fact you release new issues so regularly and the quality of your editing. It's the way you comment things and your whole positive approach. You rule man.

There are some things I really liked so if you don't mind I would like to point them out.

Letters section. Absolutely wonderful, interesting and funny. Loved the letter from Lurah about QBasic being alive or not and your response to it. Beating a dead horse. Heh. I was amused.

News Briefs section. I'm amazed how that section is detailed and covers practically every event happening in community. Great work!

"What QBasic Means To Me" article by Michael J. Wyldman. I'm so in the same track with this guy. I absolutely hate people who can help but are not helpful and in the same time find time to be obnoxious. I remember when I was looking for XMS routines I needed for my project and some guy responded to my post(in QBasicNews forum) with a question: "Do you know at all what XMS is? I can't help you if you don't know what you are looking for." Wanker. If you can't help don't be an ass!

"ASCII Ain't Goin' Anywhere And It Will Live Forever" article by Lurah. Brilliant. The way he delivers the idea why ASCII is superior...just great. Sentence "Do you see just some boring thing up there?" is for the anthology.

Third chapter of Na_th_an's IF Tutorial. Can't wait for the examples in the next issue. I was kind of disappointed to find out that hard coding exceptions is bad since LONG code is filled with hard coded exceptions. Mainly because I thought that was the only way to code them. :P And I'm still not sure how Na_th_an's scripting language or whatever goes around that. Still, this language can't be simple. More exceptions there is, more complex this language has to be. Well, that's what me stupid thinks. I better wait for the next chapter of the tutorial.

Antoni Gual's article about FreeBasic. Finally someone decided to write a tutorial about starting in FreeBasic. Table with differences between QB and FB is a complete hit. EXACTLY what I needed. Still, it didn't said that DEF SEG statement is not supported. I was kind of frustrated with that since I can't load sprites made in Pixel Plus 256 in a program compiled with FB. And many other things I need(like a gif loader). Being a game designer I don't even have a slightest idea how to replace code which uses DEF SEG statement with something else.

Gustav's FreeBASIC Allegro Tutorial 1. Very smart, detailed and easy to understand step by step tutorial. The idea to show the equivalent code in C++ is just great. Can't wait for the next issue.

I did not like ALL the content in this issue but I think it's more constructive to discuss that with the very authors of these articles or tutorials.

What this issue succeeded is to finally turn me on the dark side(:P), FreeBasic. Yes, I'm officially switching to FB. LONG will not be finished in QB. My first program in FB will be Evil Baron Lachie, or in other words, I'm porting it to FB. I'm sincerely hope that during this porting I'll learn all the routines and libraries I need to substitute my current way of coding. Loading, storing and displaying sprites and background images and similar. I so don't won't to abandon Pixel Plus 256. I also want to implement sound in my games so I need to find good sound routines/library. It will be a painful transition since mainly I'm a game designer. Switching compilers to a game designer....well, it hurts.

My contribution to this issue is another review. This time it's the review of Larry The Dinosaur 2. For the next issue I hope I'll be able to compile a review of TerraScape by Pieslice Productions. That game is a brilliant achievement. Definitely the best 3D QB game and one of the best QB games overall. I'm also planning to start some sort of column for very unknown or relatively unknown QB games. Still not sure about the column title. Something like "Unknown gem or not?" or maybe "Should you be knowing about this?". Maybe you can help me. I already have two games for the first two editions of this column, Astral Worlds and Star Trek: The Capture. The idea is that the column won't be a classic review but more an article about the game. I'm going to be such a busy man.

Uh, I kind of went overboard with this email. Just keep up the outstanding work. :)

Best Wishes, Lachie D.

I love getting long, insightful emails about what QB Express is doing well -- they really help me figure out what you, the readers want. So thanks a lot for that (and your other submissions).

I'm pumped about your project to collect the important and influential QB games, and your plan to write about overlooked QB games that people have been released. I definitely share your interest here. A column on unknown QB games is a great idea. I'm really looking forward to your future articles. Also, keep us up to date on your QB game collection. When it's finished, it will be a phenomenal resource for the Qmunity.

-Pete

Letter From MystikShadows

Hi Peter,

Well, I don't wanna sound like a broken record but hey, all I can see about QB Express is that, like you said, it really does seem to have nowhere to go but up. You mentioned in your intro to Issue #8 that the quality of that issue was second to none and I can't help but agree with you on that. I think people are putting the effort into their writings two ways, the first is in the selected topics which I've noticed the contributors seeem to be attacking the right subjects to make QB Express a better magazine for the casual reader as well as the programmer looking for solutions to his programming needs alike. QB Express is definitaly broadening it's horizons and still manages to keep the essence of being "A magazine by the QB community, for the QB community!".

This tells me that:

  1. The reader base is definitaly growing like you mentioned. I don't need to see the traffic stats of the magazine to know that.
  2. The list of contributors to the magazine is gaining alot of experience in searching and finding the right things to talk about or teach to the readers.
  3. The users are reaching programming directions (in their projects) that need more and more specialized knowledge at hand to help them complete their project.
  4. The community is definitaly more alive than ever, and more kicking than ever before too.
  5. The community is evolving and expanding too. More people doing more things tend to do that to a programming language and a community but it's great news to see that it IS happening in the QB Community.

I think it's great to see this happening before our very eyes. Victor gave us the tool (FreeBasic) but that wouldn't be anything without the users actually doing things with that tool. So to see all that's happening right now, is refreshing to me. And it's very motivating to me to continue pushing that momentum forward because it's far from over from what I can see. Take me for example, I just came out of the hospital yesterday, when I got home, I finished one of my contributions to the next issue. And ideas, unlike when I started contributing to your magazine, seem to flow right out of head and into document form. This is just an example of what momentum can do I think and I think it should definitaly be mentionned. I'm sure I'm not the only one that's been like this in the mast 2 months or so.

The more stubborn (lurah for example ;-) ) are converting to freebasic not because of lack of choice but because they are seeing the new possibilities that are there for them. So I know that more and more people are going to see this and convert, i'm not even worried about that.

I can't wait to see what people will do with their newly found power (freeBasic) combined with their inner powers (imagination and creativity). I for one strongly believe that we haven't even begun to really "create" things yet except for games. we're still at the stage of making the computer do what we don't want to do, in the corporate world too and we're not out of it yet so there's plenty of room for creativity to manifest itself and we're all on the forefront of that creativity. :-).

Anyways, I gotta get back to writing some more, so I'll end this letter by saying congratulations once again, and let's see what the future holds for FreeBasic and it's users.

MystikShadows
Stephane Richard

Another one of your gushing letters, man. You've got to be QB Express's #1 fan -- and contributor. Nobody has submitted more tutorials than you have -- and they're all phenomenal quality. The readers might like to know that I actually held off on SIX of the TEN tutorials that you submitted this month, because I didn't want the magazine monopolized entirely by Mr. Stéphane Richard. :)

But seriously, thanks a lot for the great feedback. And sorry again this issue is late (I know how much you've been looking forward to it). Talk to you next month (I'm sure I'll hear from you :) ).

-Pete

Letter From Lurah

Hi Pete.

Gee, what a issue #8 was? Great, huge, big, awesome...lol...i dont wana waste whole letter just to describe different synonyms. And as i did say on QBNews forum, i print issues and that last one, literally killed my printer :D

It was nice to notice that my project was mentioned there too...(do I feel a pressure...) :D And our new site, www.ascii-world.com was great to see mentioned there.

Summer is coming, and even here in cold northic Finland, snows are almost melted away. Does it mean that even "nerds" can turn off pc's and go out? Is it only me, or has there been happened a some sort of quiet down thing on forums etc.? Well, in spring time, peoples usually have lots of to do and world outside of doors is pretty interesting thing :D

I was hoping that i could release new and more extended demo of my project before this issue but...well, i quote myself "...in spring time, peoples usually have lots of to do." Practically, only thing that i have moved on is linux version of it.

But before every one is goin out to enjoy for that summer... ...there is a demo contest starting on this precisely minute at ascii-world.com And of course, as you probably can guess from url, it's a ASCII-Demo contest. Summer is coming, so what could be better theme for that contest?

And price for winner, beside of all that glory and honor, a nice "summerlike" t-shirt with some , not so summerlike, but ASCII like words. :D

But, because MystikShadows has allready emailed accurated details of that contest to you, I'll end up here and give to readers a free way to see what you have this time on issue #9.

Regards. Lurah

You're crazy, man...printing this magazine out is ridiculous. One of the reasons why it's always so big and I include just about everything is because it's an Internet magazine -- not a print magazine! With this medium, there's little need for conciseness. I can go on for pages and pages and pages and pages and pages and pages and pages and pages and it costs me next to nothing. Ink and paper, now that's another story.

Anyway, I've featured your competition in this issue. Readers, if you're interested, click here to check out the ASCII-World competition. I hope it's a big success!

-Pete

Letter from Rattrapmax6

QBE Suggestions...

Hmm,.. I liked noticed, and you've said, that its hard for you to put it together every month, the mag...

Well, I think you might have a Deadline problem,. You say its the 15, and yet you can still send in if the mag is not out yet.. When I first read this I was really like: "What?!"

Possible solution: Have a submission Date, and a Release Date:

Lets say, Deadline to submit is the 15th of the month,. no more submissions are allowed, or any taken after that will go into the next mag..

Then give yourself a deadline to compile the mag, say the 20th of the month.. or what ever you estimate you need... and since nomore submitions are coming in,. you can freely make the mag with less hasle..

Just a thought,. anyways.. Wink ..see ya around..

-Rattrapmax6

Thanks for the suggestions...but they're not going to help.

It's not that I get lots of submissions that holds back this magazine, it's that I have to write my own articles. Formatting and adding other people's articles takes me a very small amount of time. What takes forever is: The News Briefs, the Gallery, the Competition sections, the Awards and the Blast From the Past! (if I do one). Adding someone else's article takes maybe 5 minutes, meanwhile each news brief usually takes more than 5 minutes to research, write and format. And I do dozens of those.

I encourage people to keep on sending in articles up until the bitter end of when I release an issue. Honestly, the only reason why I have a deadline for submissions is to remind and motivate people to submit articles. It's not that I really need them far ahead of time.

-Pete

Have a letter for the editor? Send all your rants, raves, ideas, comments and questions to pberg1@gmail.com.


Express Poll

Every issue, QB Express holds a poll to see what QBers are thinking. The poll is located on the front page of Pete's QBasic Site, so that's where you go to vote. Make sure your voice is heard!

How did you first learn QBasic?

AnswerVotesPercentGraph
In a class2116%
From a book3123%
An online tutorial2116%
From a friend / mentor97%
The QB Help File1914%
From looking at code2619%
Other75%
135 Total Votes
Next Month's Poll: What is the most overrated QB game?
Click here to vote!


News Briefs

News from all around the QB community, about the latest games, site updates, program releases and more!

QB Site News

Todd Seuss Launches Data Components GUI Reviews

On March 27th, a new QB GUIs site launched: Data Components Software Development GUI Reviews. Already, this site is probably the biggest QB GUIs site I've ever seen, with no fewer than 53 GUI reviews (I counted). All of them feature screenshots, information about the developer, and a thorough text description. It's amazing that a site this big just popped up overnight. Since the March launch, Todd Seuss has done regular updates, and there's no signs of slowing down. Check it out!

QB45 Celebrates Tenth Anniversary?

A while ago over at QB45, Jofers posted the following message:

Well, I'm not really sure when Jorden started the site. The wayback machine only goes back to 1999. But I know it was '95, and I figure, why not have it on International Joe Day. Or Easter, whichever is your preference.

So here's to you, qb45. Kept unnaturally alive with a forum like a braindead woman on a feeding tube for over 10 years, you provide us all with wasted time at our expense. Cheers!

Wow, I can't believe the Qmunity is getting that old. Whether or not late March is Future Software / QB45.com's tenth birthday, you have to give it props -- it's been around just about forever in Internet time.

QBasicLab Launches, ASCIIQUEST Editor Coming Up

Jace Masula / momoguru has been pretty busy in the last month. Not only has he launched a great site called QBasicLab, he has also released a lot of information about his upcoming ASCII adventure game maker "ASCIIQUEST Editor". With this program, he's working on a few games, such as Dragon Quest v1.0. I suggest you check out the site and read up on these exciting programs. (I mean, look at this editor!):

Nekrophidius Resigns as V Planet! Editor

Since Vance Velez passed on his position as managing editor of V Planet! to Nekrophidius early last year, the site has seen only a handful of small updates and has really fell into disrepair. There hasn't been a new review added to the site since Nekrophidius took over, and the latest Gaming Gold Awards just seemed to fizzle out due to lack of interest. Instead of working to update the site in the past year, Nekrophidius has been working to create a dynamic, PHP backend that will make maintaining the site easier.

Well, he was... until last week. Here's a message he posted at QBasic News on May 2nd:

I had planned to have the new V Planet up about two weeks ago. Because of lack of time plus some file corruption (FAT32 going nuts over mass file deletion), I was unable to put up the finished new site. The immediate future doesn't look so promising either, especially since I would have to start over at the 25% completed point. So getting straight to the heart of the issue...I'm resigning my position as V Planet editor to whoever wants the job. Whoever takes on this responsibility needs to have the kind of time I did not have to maintain the site as well as develop a new PHP-based version of the site. You will also have to take on an entirely new staff, as every member of the old staff is now basically vapour with the exception of Jofers. I will give you the domain and will allow the site to be hosted on our server for as long as you wish. Anyone interested in this offer, please email me at the soonest possible time at dave@nodtveidt.net so I can transfer control of the site to whoever is most fit for the job. I'm only looking for someone with a lot of available time and a love of the scene, PHP and QB/FB coding, and a good sense of style when it comes to designing websites.

With this done, my last responsibility to the Qmunity is complete. I will be taking my permanent leave. I grew sick and tired of all the infighting ages ago, the only thing keeping me here has been my responsibilities to the legacy of V Planet. Since I can no longer do this, I have nothing else to offer the Qmunity.

Well... that was quite a shocker, though everyone doubts Nek will be gone for long. The next day, he posted the following news:

A new V Planet owner has been chosen. Joe King and Fishstix will be the new owners, effective immediately.

Neither FIDO nor FBXL will be released as-is; neither were past the prototype stage and neither are very useful in their present state. I may work on them again some day but it's doubtful, as I have other responsibilities now.

Since Joe King and Fishstix were put in charge, there have been no changes made to the V Planet! website. Here's hoping that they're able to return the former QB mecca to its former glory. And also, here's hoping that Nek was just having some type of midlife crisis and will be back. QB Express will keep you updated on the latest developments.

x.t.r.GRAPHICS FreeBasic Site Launched

Rattrapmax6 has opened a sister site to his former QB website, which specializes in FreeBasic. But as far as I can tell, there's not much of a difference between the two sites -- they have almost exactly the same content, just a different logo and newer news on the FB site. Anyway, you can compare them if you'd like: x.t.r. FB site and x.t.r. QB site.

Project News

Blitz's Text Mode Space Shooter

Last month, Blitz released a very fun ASCII-based text shooter. It has some of the coolest ASCII explosions I've ever seen and it runs really well on my Windows XP box -- sound and all -- without any tweaking or emulation. I got nearly 11,000 frames per second, and had fun doing it. I highly recommend you download it.

New QBasic Drawing Program: DosDraw Artist

Jarrard Software, a QBasic developer that I hadn't heard of until just a few days ago, released a new drawing program called DosDraw Artist. This program, along with DosDraw Artist Viewer, allows you to draw pictures in DOS, Paint style, and then load them back up again to view. It's not a sprite editor like most QB art programs, but an image drawing program. While you're at the site, you should also check out Jarrard Soft's other programs, "Psyco Alarm," "Star-Clock," "Star Pilot Alarm" and "Color Mixer."

New FreeBasic IDE: "BE"

A chap at the Sourceforge.net forum by the name of Roland posted about a new FreeBasic IDE that he just created a few weeks ago: "I have programmed a nice small editor which now supports FreeBasic directly (before it was made for PowerBasic only). The editor's name is simply 'BE' (BasicEditor). I hope You like the IDE. It supports function/sub/macro toggling to single lines, syntax coloring, auto case correction, can export the listing as RTF file, can directly cooperate with a resource editor and so on." I haven't had time to check it out, but I thought I'd pass along the good word. Here's the forum post and here's the download link.

Red Jumpy Ball!

Ryan has released an awesome FreeBasic arcade/puzzle game called Red Jumpy ball that I recommend everyone check out. Here's the description of RJB from the Readme: "In the game, you control a red jumpy ball. Surprise! The object of the game is to complete the course with as many points as possible. The courses are generated randomly depending on the game type you choose. They are filled with random bricks and bonuses. The map will scroll continuously unless you're stuck behind bricks. But fear not, this red jumpy ball comes equipped with a laser to blast through those bad daddies. The game still only uses one key for game play. Having more would just complicate matters."

This is a really fun, challenging game that I enjoyed for quite some time. Visit Ryan's Site or just download Red Jumpy Ball. Also, you can check out this review that Delta Code did of the game just a few weeks ago.

SPY -- The ASCII Puzzle/RPG/Shooting Game

Kaboom Code (D.S.) released a cool ASCII game called SPY this April, which you can check out at his website, The Home of SPY on the Net. Here's a description of the game:


This is a text based shooting/puzzle/RPG game I created. In it, you play a spy that has been hired to infiltrate a evil scientist's laboratory. To do this, you must first survive the evil black forest, and then journey to the scientist's underground laboratory!!

I tried out SPY briefly and found it to be a very cool game, with some very neat stealth elements. Definitely worth a look!

Bill Sindel's Memory Editor

William W. Sindel ("Bill") uploaded a new Memory Editor program to Pete's QB Site last month called, simply, MEMEDIT.bas. It's a program that can read and edit the first megabyte of memory in the PC: "The program accesses memory as 16 blocks of 64k addresses for a total of about 1.088 megs or so. Changing the segment address will let you select different blocks of memory as the segment address is added to the 64k block address to form the pointer into memory." Cool.

The Legend of Aquarius begins development

MystikShadows and anarky have teamed up to make a FreeBasic RPG called The Legend of Aquarius. They've just started, so right now it's vaporware -- but they have a story and some cool features in mind, which you can read about on their website: LegendOfAquarius.tk.

The FreeBasic Slot Machine

Gambling fans: Dr_D posted an impressive screenshot of his upcoming FreeBasic slot machine game...complete with 3D slots.

Here's his description:
"It has >15,000 polygons, and it runs without a hitch! I made one in QB that had less than 2000 polygons, and it ran, well, it crawled like a turtle. Btw, when you win, it shoots balls out of the bay at the bottom that collide with the machine, and each other."

Check out the FreeBasic.tk thread where the announcement was made.

Squares!

Xerol released a little puzzle / arcade game called "Squares!" this month. There have been three versions so far, and the latest is available here. This game is pretty difficult to get the hang of, but it's not too bad once you figure it out. The object is to destroy the squares, while keeping your ship intact for as long as possible (not that that means anything if you haven't seen the game). Give it a shot if you've got some time to kill.

The Hungry Jocke Game by Ryan

Jocke The Beast stars in Ryan's newest ASCII adventure, The Hungry Jocke Game. Ryan's announcement at this FBTK thread was as follows: "I made a little ascii mini-game starring everyone's favorite action game hero, Jocke the Beast. You have to direct him to eat all the food on screen (boy is he hungry!) while blowing up monsters with bombs. Yes, Jocke has bombs. Don't mess with him." It's a very fun, addicting game that I highly recommend. So...go play it!

FreeBasic v0.13b Released

V1ctor released the latest version of FreeBasic on April 14th, which you can find at www.freebasic.net. A lot of small features were added or fixed, which you can read about here. V1ctor and Lillo can't be thanked enough for keeping the FreeBasic updates coming. They rock.

Side-Scroller Creation System (SSCS) by Atom Ant

Atom Ant posted about a platform game level designing program he's developing that looks pretty nice. Check the thread for some more info and a gigantic screenshot. Now, the next step is to create a game engine that will load the levels you design in this utility. :)

Some other Releases

A lot of cool QB and FB programs came out this past month and a half. Here's a quick look at a few more of them:

  • "Better Looking Calculator" by Rattrapmax6. The GUI looks just like a real calculator -- complete with solar panels.
  • Jark's Rayracer ported to FB by Antoni Gual. Whooo!
  • 400x400 Scrolling ASCII Map Editor by Ratrapmax6. It uses the SCREEN 14 engine found here.
  • FreeBasic Package Downloader and Installer by Z!re and Zap. This program helps you manage the downloading and installation of various components and add-ons for the FB compiler. Useful!
  • Quest For A King 1.5 by SJ Zero. A new demo of SJ Zero's RPG has been released -- now being made in FreeBasic. This is the first demo in over a year.
  • 3D FreeBasic Chess Program by Garvan. "This is an experiment in using OpenGL with FreeBASIC fbgfx libraryScreen Shot. The front end of the program is coded in FreeBASIC with the chess engine (an adaptation of gnu chess 3.1) coded in BCX and linked as a static library." This is looking really good, and definitely worth a look.
  • FBIde 0.4 WIP by VonGodric is in progress. Some work in progress screenshots were released.
  • QBasic to FreeBasic tutorial by mennonite -- a witty little tutorial that helps QBers make the switch to FB. I enjoyed it.


Gallery

Written by Pete

This issue, I didn't get any real submissions for the Gallery, so I decided to put screenshots and information of a bunch of upcoming games. I kinda like this format, so let me know if you want me to keep it or go back to the old one-game-per-issue method.

SpaceMerc - Mitth'raw'nuruodo

Mitth'raw'nuruodo has been working diligently on his space shooter, SpaceMerc for a few months now. Recently, he released a new Intro/Trailer of the game, and then a few days later, another debugged version of the game.

It's looking pretty good so far, featuring several types of enemies and gunfire and smooth mouse control. I'm looking forward to seeing what Mitt is able to do with this game.

You can find Mitth'raw'nuruodo on the Pete's QB Site forum.


Inspiration Engine - Wallace Software


In honor of the one-year birthday of Wallace Software's FPS Contact, Wallace released another demo of his excellent Inspiration engine. In the last two months, new features including bloodspatters and bloodstains have been added, guns and crosshairs have been re-added to the engine, and a new sprite importing routine has been incorporated. Check out the often-updated Wallace Software for the latest information.

Larry The Dinosaur 3 - Delta Code

Radical Raccoon, the lead developer of Larry The Dinosaur 2, has revealed some new informaton about the upcoming game. The game engine now features sloped surfaces (which you can see in the shot to the right). Here's part of the Delta Code post that accompanied this screen:

"I got slopes working! This means the levels can now have more depth to them. Now it doesn't feel like you're trapped inside a grid of squares. Like the graphics? They are all 100% mine. I still need to touch up some areas and add some stuff here and there, but for the most part this game is starting to kick butt! I also redrew the graphics for Larry. He now looks 10 times cooler and has full body animation.

Anyways, I'm working on making that forest level more into a jungle level. So far I don't have any good idea for a story. I was thinking of just dropping Larry off into the jungle and have him blast his way to the end. But if I don't have any story or foundation for one the game can fall apart later down the road. Here are some ideas I came up with:

  1. New alien race attacks earth. Larry must stop them!
  2. Some enemy from the previous game becomes the main badguy and seeks revenge on Larry, so he captures his friends and family. Larry must save them!
  3. Satellite photos uncover strange activity in the jungle. Larry must investigate.

Or maybe a starting jungle level is too cliche'? Unless somehow I can make it look different than the other 500 games out there. Maybe I'll come up with some interesting plants or something."

Nightlife - SBM Productions


SBM Productions just released a demo of their upcoming first person shooter called Nightlife. This game is still in early stages of development, but it's really starting to come together. Here's some info from the programer:

"This has been in development for about 7-8 months, although obviously not constant. Most of that time was spent optimizing and trying to get a fast perspective tmapper using uglpset. Imagine my shame when I realized I should've just got Blitz's attention, though I thought ugl24 wouldn't come out anyway. This program uses a bsp tree for collision detection, but displaying stuff is just a standard z-sort(which is why you have dumb sorting glitches). I wanted to release this with at least 2 mins of gameplay(I had big plans for this) but unfortunately I didn't have time, and I couldn't get sound to work. Of course now I won't be able to code till maybe near the end of the year, as I have my A-levels then hopefully get into the uni course I want. Then I'll write a decent ogl engine in fb...."

You can download the demo at this address. But first, you should check out this thread for some instructions.



Review of Larry The Dinosaur 2 by Delta Code, 2002

Written by Lachie Dazdarian

The release of Larry The Dinosaur 2(LD2), a cool mixture of platform and adventure genre with very good graphic and sounds, passed rather silent in QBasic community. I only remember one thread about it in QBasicNews forum and nothing more than that. We can blame the designer for not being pushy enough or the community for being in terribly groggy period but LD2 definitely deserves to be remembered. Therefore this review.

Graphics

Game graphic is very good and done very professionally. LD2 looks like any other commercially released, quality platform game from the period of early nineties. The tiles are well shaded and varied and characters nicely animated(in the limits of the game concept). Lighting, a very important part of the game graphic, makes LD2 really shine. Also, some cool effects, like flying body parts, increase my overall impression. Still, the graphic is not perfect thus the score 4. There are few small details, tile or two I didn't liked and the lack of cinematics. It's nothing so relevant to decrease the overall quality of the game graphic but leaves space for improvement.

4/5

Sound/Music

Unfortunately I was not able to play this game with sound turned on. I tried both in DOS and Windows XP and failed. There is a warning in readme file that starting LD2 with sound is a problem in Windows XP. How can I score the sound then? Well, all the sound effects and music files can be heard with Winamp or some other player outside the game. What I can conclude from there is that they are very good and probably work great inside the game. I'm not happy I have to score this section like this but I can help it.

4/5

Gameplay

LD2 gameplay is a smart mixture of platform, action and adventure elements. Delta Code completely succeeds in combining various genres into one game. During this game you'll encounter many monsters which you can kill using different weapons. These weapons will need specific ammo which you have to find and load your weapon with it. Also, during this game you have to find objects, use them on proper places or even combine them. LD2 is played in a building with 24 floors. Some floors feature smaller maps and some bigger but what is sure is that you'll be doing a lot of walking and jumping in order to finish this game. Game controls and interface are designed very nice, on a user-friendly way, while the game physics remind me of Giana Sisters which makes LD2 very enjoyable to play. If I would have to point out something bad about the gameplay I would say that none of the specific genre elements are used to their full potential. Action part is not enough challenging or varied, puzzles are too obvious(game could use more objects and places where you need to use) and the jumping part is never difficult(there are not pits in which you can fall or similar obstacles).

4/5

Story

I wasn't sure if I should give LD2 more in this section. There are several things I didn't liked in the game story. First of all, the story begins a bit strange. We don't actually know what Larry and his friend Steve are doing in the building where the game starts. I suppose they work in it but that is not told to us. There are few more loop holes in the plot which are not explained to us. What is good is that the story develops while you play the game and it develops rather surprisingly. There is also a nice amount of quality humor in the dialogues which is another plus. LD2 is placed in the age of dinosaurs(same as the part one) and assumes that dinosaurs were highly evolved and civilized.

The actual plot of this sequel begins when Larry's friend Steve falls unconscious after drinking a cola. Larry runs to get help and finds the nearby Janitor. Both of them run back to unconscious Steve after what Janitor gets eaten by an alien and now the game really starts. Later you'll learn that the building has been taken by aliens. Like I said, the plot develops much more interesting than it starts.

3/5

Replay value

Well, I finished LD2 only once and still don't feel an urge to do it again. It's hard to tell what is the problem regarding the replay value of this game. The shortness of the game, lack of real challenge, the fact that there is no a save game option or something else. There is also the question of how much the replay value is relevant in this type of game. LD2 is not really a game that's meant to be played over and over. Nevertheless, the game is not so short that playing it again, once you finish it, makes no sense. After few months, or maybe a year, why not?

2/5

Challenge

I was tempted to give LD2 even a lesser score in this section. The action part of the game is terribly easy. At least to me. The main problem I see with it is that you can ignore most of the aliens/monsters and run away from them. Another problem is that you start the game with 5 lives which is way too much. What would help are more difficult enemies, placed on tricky parts, and more available ways to kill them. Like throwing or placing bombs. I only found the end boss somewhat challenging to kill. I can say nothing bad about the adventure part of the game. Well, almost nothing. The building is big enough and you'll spend a lot of time wandering through it looking for various objects. Still, when you find an object that is not ammo or extra health you'll know immediately or very soon where and how that object needs to be use. You'll need about 4-5 hours to finish LD2(when you play it for the first time) if not more. The action part does require concentration but like I said, it's really difficult to lose ALL of your lives playing LD2.

3/5

Fun factor

I know I'm getting boring with giving 4 in this review but maybe that's the most accurate score for the entire game(4 out of 5). LD2 reminds me on the old days of Amiga 500, when save game option was something exotic and finishing the game during one day something normal. I wouldn't be fair asking for more content since Joe King(the developer) done a very big and nice job in creating and designing the building floors. What is obvious is that this game failed to be more challenging and to have a save game option. With these two things corrected LD2 would offer plenty more hours of play time.

4/5

Total Score

24/35
Good: Excellent mixture of different genres. Enjoyable game physics. Very good graphic and sounds.
Bad: Shortness of the game. Lack of real challenge. No save game feature.

Review by Dean Janjic(Lachie Dazdarian)

Extra notes: If you are wondering about Larry The Dinosaur part one it's a pseudo-platform game(you don't actually jump on platforms) with very bad, buggish and flickerish game engine but strangely addictive gameplay. Similar to LD2, the story develops while you play the game and if you manage to get pass the awful code and poor graphic the first part of Larry The Dinosaur can also be a fun to play.

Visit Delta Code or download Larry The Dinosaur 2 or Larry the Dinosaur 1.


Review of Robo Raider by Rattrapmax6

Written by Zap

INTRODUCTION

In this game you are put in charge of a series of robots, on at a time, and your mission is to control them through mazes, in order to either fetch some items, explore ruins, get out alive, and some other things. Also you must not bump into the walls, since in doing so you will get fired by the doctor who hired you for these missions.

This game is a single player game, programmed in qbasic. Source code is include. In fact, it's the only thing included, as the game is too large to compile in qb (authors words).

STORY

The story that caries you through Robo Raiders is catchy and well told. There is an overall story introduction to the game, as well as a short text before each mission telling you where you are, what robot you will be controlling, as well as what you are actually supposed to do.

Story Rating:
8/10
It's catchy. It excites me.

LEVEL DESIGN

Now bad stuff is sneaking in. The levels are boring. In the first three missions you go through EXACTLY the same level, only differences are that some of the walls turn into water (...) and in the third you have to pick up some items. This makes me think that the author just wanted to have some more levels in his game, without offering too much for it.

Later on it gets even worse. Ok, they change now, that's something, except shortly after you cheer for that, you find out that they are freaking huge! This would be cool, but it isn't, for reasons which I shall mention later on in the review.

Also the levels consist of lines, only, which could be alright, had they not been placed in such a boring way. Mostly you will encounter only either a straigth way across the screen, a crossway, or a T-way.

Level Design Rating:
1/10
More ingenuity is required in this area.

GAMEPLAY

The idea is original. Sadly, it has not been carried out very well. The robots drive waaaay too slowly, and it can drive only in 4 directions, with no animation what so ever when changing direction, it just happens. POOF. This might have been good enough for any other type of game, but for a driving game, it just doesnt work. Same goes for using INKEY$ for key detection. Having to wait a second from you press the key to change direction till the car does anything really ruins the illusion.

There are no hints of physics either, no acceleration, and no decceleration. Without a slow decent to a stop, it's no challenge to avoid hitting the walls...

I have no words to describe how anoying it is to drive through monotonic tunnels for 3 minutes, only to find out that you have to go all the way back again. I found myself staring out the window while playing some missions of this game.

Gameplay Rating:
5/10
The idea draws it up, excecution takes it back down again.

GRAPHICS

Robo Raiders can't boast of its graphic side. The levels are drawn using green lines, and it seems rediculously zoomed in. Sometimes you just drive on a "road" that goes from bottom screen to top screen, only to get moved on to another just as boring passage. The game doesnt have any hint of scrolling either, when yuo move from one part of a level to another, it's just drawn on the screen, with no transistion what so ever.

Another very disturbing thing is how the screen modes are changed between each story-passage and mission, when it seems that both could have been done in the same screenmode.

The only good parts to say about the graphics in this game are the robots, they are fine.

Graphics Rating:
1/10
It's getting the point for the robot.

SOUND & MUSIC

None. Would have been great with some sound effects, and especially music since the game environment is well set up by the story. I was listening to soundtracks from Lord of the Rings at some points while playing, and it was good.

Sound & Music Rating:
0/10
It doesnt have any, but it would've been nice if it had.

CONCLUSION

The idea and concept of this game is really good, and if it was carried out properly, this game would rock. It needs physics, proper controls, sound and music, and some kickass graphics.

Overall Rating:
25%
This game could have been good, the idea and story is really cool. I'm hoping someone will redo this game.
Download Robo Raider at the x.t.r. GRAPHICS QB / FB Site.


Where Are They Now?
Jorden Chamid

Written by anarky

Welcome to QB Express' newest column, "Where are they now?" I go and have a chat with QB programmers of days gone by. Some you may have heard of, some you may have not. This month, Jorden Chamid - formally of Future Software (www.qb45.com) and now of www.mobileringtonez.com - spares a few minutes of his hectic business schedule to sit down and have a chat with me.

(I did originally intend this interview to be longer, but I ran out of things to ask in time. Such is life. Perhaps I'll follow it up a bit further down the track.)

A> What got you interested in programming in the first place?

J> One of my close friends started programming QB on his PC. He showed me a demo fractal and it immediately got me interested. We both started creating textbased-games, and soon I was starting doing all kinds of things in QB. I really liked to have some power over the PC.

A> How old were you when you were hit by this inspiration?

J> I was 12 at that moment.

A> When your name is mentioned, people think of Future Software. When did you open the site to the public and did you think it would take off like it did?

J> At first I had a lot of horrible names for the "company" (No, I'm not even naming one of them!), but when I got some better at programming I decided to pick Future Software as the name. In the beginning I was looking into BBS'es through my dads modem to find some example sourcecode. Soon Internet starting coming off the ground and my dad took a subscription. Internet wasn't so famous yet, but started getting popular real soon. The same guy who got me into QB challenged me to make a site about QB. So I put my files online and started learning HTML (no fancy WYSIWYG editors back then!)

I soon got to know the Neozones website at GeoCities.... it was really awesome, Tek ran it.

I really loved it but there weren't so many updates on it. I decided I could do better than that, so soon I was allowing people to submit their games. :)

I think it was 9 years ago when the site was opened, all on free addresses, which we moved from often... GeoCities, Angelfire, Xoom, Hypermart, and some more. :P

A> At what point did you notice a community of programmers who called Future Software "home"?

J> I think it took up to 1998 or so, I vaguely remember the site existing for 3 years when I got some popularity. We had a forum back then, and it suddenly became fun to read all new messages. And ofcourse the archive was becoming huge!

A> Do you feel you started a trend? Or did other sites beat you to it?

J> Well I don't really know if we did. With Future.Library Michael (Smoky) made a lot of people happy, but of course DirectQB (Angelo Motolla) did that too.

At least I think we were a nice place to distribute all those great applications and games to a big bunch of people. I think we owe a lot to Smoky, Future.Library surely added to the popularity of qb45.com and the Future Software games as well.

In addition, I personally also owe a lot to Andreas Nagy (I think that was his name, could also be Andy), who made a kickass design in the beginning and added a perl search engine (Q-Finder!) to the site. Because I started rebuilding his layout and search engine. I also got better at designing and my first steps in perl were done.

A> What was the best program you personally ever made?

J> I think BomberZone (The Bomberman clone) was getting to be the best, but we've never finished it.

A> What was the best program that someone else had made at the time?

J> The best program in my opinion was the Future.Library. The best game is a hard question, although I really liked (how boring) Wetspot 2. That game was fabulous.

A> And the worst overall?

J> Well the worst programs weren't added to the website, they went straight to the recycle bin. ;) There might have been some textgames which weren't so good in my opinion but some other people loved them.

A> While we are on that topic, what was your favorite text game?

J> I wasn't a fan of text-based games, so I can't really name a favorite.

A> Have you had much of a chance to look at some of the work being released today? For example SJ Zero's Quest for a King?

J> I haven't seen any new QB games for years now... not since I've sold the site, that generally was at the moment that I completely had lost my interest.

A> The site seemed to go downhill from that point, and went through a number of other owners and numerous facelifts. If you had the time, would you take back control and give it the popularity it once had and thus still deserves?

J> Well, it's always been a hobby of mine, but at some age you can lose interest in a hobby. I haven't programmed in QB for a few years, don't even remember how to do it. I absolutely enjoyed the site in the main days, but if I'd have to do the same thing now it would be impossible to enjoy.

A> A little while ago you put the site up for sale and moved on. You have mentioned losing interest in a hobby, but would you care to elaborate about how all that came about, and what made you move into the ringtone business?

J> When gsm's became popular, I bought a Nokia 3210 and loved how you could make your own jingle. Soon I started looking up ringtones on the internet and got to know www.totalgsm.net I loved the site, but thought "I can do that" and started a GSM-website with free ringtones. After only 3 months this site became more popular than the qb45.com main site. This made a new challenge for me, and soon it was possible to sell those ringtones and make money with it. At that moment I really started getting an income from my website (in the past, only a few $$$ from advertisements) and had to decide to quit all other sites that only pay back the costs, and focus solely on ringtones. At this time I am still glad I made that decision, being one of the bigger ringtonewebsites of the Netherlands (and quite famous in USA and some other countries too).

Later on I bought www.totalgsm.net, and also bought www.polyphonic.nl / www.polyphonic.net which are doing quite well too.

A> Wow, you've been busy!

J> I also own one of the biggest gamesites in the netherlands too, www.coolegames.com; 20.000 unique visitors daily, and am now trying to get a nice position in the hosting-market of Holland and Belgium with www.totallyhosted.nl

A> Ok, now you're boasting! :) Would you like to go back programming one day, just for the memories?

J> Well I "program" PHP and MySQL daily. Rarely I use VB for some tasks, but those are only small tasks, so I don't really miss it.

A> Any words of advice for the budding QB programmer out there?

J> Just keep programming. :) It will help you if you ever want to learn another language if you know (q)basic programming.

A> Thank you for your time, Jorden.

Jorden Chamid now runs a number of sites, including the very popular www.mobileringtonez.com

NEXT MONTH: Perhaps you have heard of 1000101, aka Eric Cowles. Perhaps you haven't. Perhaps you have heard of FARQB? "Is that a game?" you ask? No. File Archiving Routines for QB. Piptol used it in Ghini Run. I am unsure where else it was used. Beside the point, next month I have a chat with Eric Cowles. We'll see what he got up to in the days when QB was IT and FreeBasic wasn't even a thought in anyone's head yet.

Until then, folks.

>anarky


"Remake Space Invaders" Competition Results

Organized by Nekrophidius and Pete

Last month's contest was a great success, and four excellent entries were submitted. A vote was taken on the QBasic News forums, and here are the results. But first, let's recap the rules of the competition:

Rules

You can use either QB or FB for this challenge. Bonus for sound and gamepad control. The compo begins now and ends on April 17th, 2005 at midnight AST. Team entrants are allowed. I don't care if you rip graphics and sound effects, this is not the Boy Scouts. :)

The Prizes!

Aside from the typical "Winner" bitmapped plaque, the winner will receive a free domain name of their choice and free hosting for a year at DBS (total value: $93.59US). The runner-up will also get a bitmapped plaque. If either the winner or runner-up fulfill the bonus requirements, I'll throw something extra in as well. :)

The Entries

anarky

This traditional Space Invaders clone by anarky looks and feels just like the original 1978 arcade game by Taito. And it's a blast to play, too. It captures all the fun and intensity that make Space Invaders one of the most popular game franchises in history.

Download this entry. (48 KB)

TheDarkJay

TheDarkJay entered more of a joke entry than anything else -- he claims this took him only two minutes to make, and that "If mine gets one vote I will eat my hat." This game features tiny monochrome sprites and one non-attacking alien spaceship that you must shoot before it crash lands into you.

Download this entry. (1 KB)

dumbledore

Dumbledore's Space Invaders game has two modes -- "classic" and "present-day". One is a traditional SI clone set in space, and the other has you play as George Bush trying to shoot down an infiltration of Saddam Hussein heads with a giant rifle.

Download this entry. (921 KB)

Lachie Dazdarian

Lachie Dazdarian outdid himself with his entry, entitled Evil Baron Lachie. In addition to the traditional Space Invaders action, this game features a cut scene story of love and deceit, bosses, power-ups, multiple types of fire, an awesome menu screen, all original graphics and a whole lot of polish.

Download this entry. (103 KB)

The Results

It was an extremely close battle -- so close, in fact, that we had three ties between the two rounds of voting. In the first round, TheDarkJay and dumbledore both received two votes each, and Lachie Dazdarian and anarky received nine votes each. Since there was a tie, Nek set up a sudden death revote for first place, but once again anarky and Lachie tied -- this time they each received seven votes. So in the end, Nekrophidius declared it a tie, and both of them winners!

First Place (tie): anarky and Lachie Dazdarian

Third Place (tie): TheDarkJay and dumbledore

Nekrophidius promised "bitmapped plaques" and a prize of webhosting to the winners, so you should be getting that soon. Congratulations to everybody who entered!

Next Month: QB Express will be hosting a summer-long Mini RPG competiton! Stay tuned.


ASCII-WORLD Launches Its First Competition

Organized by Lurah and MystikShadows

ASCII-World is running a cool summer competition, and they asked me to help them out. Here's their "press release" on the competition. I encourage everyone to enter it!

-Pete

TITLE: A Summer's 2005 Themed ASCII Demo

START DATE: Same as QB Express #9 Release Date

DURATION: 2 Months (2 days before the QB Express #11 Release Date to allow for processing)


DESCRIPTION: ASCII-WORLD Annouce the official opening of its very first online competition. Indeed, now is the time to test your ASCII graphics abilities and foster your creativity into a demonstration of your abilities. The contest will be held for a period of 2 QB Express Releases (2 days before the release of QB Express #11 to allow to prepare everything for the voting process). The voting will be done in the form of a poll so w'll need to submissions before the release date in to create the poll.

RULES:

  1. Theme must be summer related in one way or another
  2. All Basic Dialects are welcome (DOS and Console Windows or Linux)
  3. Maximum Compiled size must be 1 Mb or under
  4. You can include sound and music files (not part of the compiled exe)
  5. All ASCII / Text only, no graphics mode (ASCII Graphic characters allowed)
  6. Maximum Demo Length should be between 2 and 3 minutes.
  7. Demos are demos, not games, tools, utilities or applications, but presentations.
  8. Source code must be included, so we can confirm the use of a BASIC dialect. We do not publish sorces with out the author's permission.
  9. Music and sound don't have to be original creations, but they could be.
  10. Points will be awarded for Originality of Concept, details of the ascii artwork itself and coherence throughout the presentation.

You can contact ASCII-World through this feedback form, and you can upload your entries to Lurah and MystikShadows with this upload form. Good luck!



Cue Basics

Written by Mike Wechsler

When Pete first asked me to write a column for his magazine, Cue Basics Express, I was slightly confused. Mostly, I could not figure out why a magazine needed to be devoted entirely to the basic uses and handling of pool cues, but also, I could not figure out why Pete was publishing this magazine.

Well, after several hours of him trying to explain it to me, I think I figured it out. Pete is a pool enthusiast.


I know, I know, it shocks me too, but under his thick, manly exterior, Pete enjoys some of the finer things in life. Things like a perfect rack. No, I'm not talking about breasts; I'm talking about a rack of pool balls! Also, breasts.

One question remained in my mind, however: why did Pete keep saying all that stuff about computers? Pool doesn't use computers, and as far as I knew, a computer hadn't been invented yet that could play pool for more than half an hour.

Then it struck me, Pete was probably inventing that computer as I typed. I hurried out to our garage/workshop and sure enough, there it was. Pete was just putting the final touches on it by applying a decal that said "EXTREME!!!" onto the cooling fan.

"Mike, I'd like you to meet my robot, Sheryl."

I was flabbergasted.

"Robot, meet Mike," Pete instructed.

The robot was pleased to meet me, but also immediately challenged me to a game of billiards. I agreed to the rules of the match and delicately picked up my cue. Luckily, I had read last month's issue of Cue B[asic] Express, so I kicked the robot's ass in robot pool.

That is when things took a turn for the worse. Apparently, robots, like wookies, tear their opponents' arms out of their sockets when they lose. Oops.

Well, anyway, I got out of there with only minor scrapes and bruises. Pete on the other hand will probably spend the next several weeks in the hospital as he relearns to use his five senses.

As for me, I've got to run; I promised Pete I would write up an article on honey for his other magazine, Cute Bee Express.

Mike likes to visit EricZapakin.tk and AnarchistVampire.com.


Review of The Quest for Opa Opa by Na_th_an and aetherFox

Written by cha0s

This is a review for the game: "The quest for Opa Opa" created by the "Los Monos del Obús" development group.

From the moment you start the game, there is a soundtrack accompanying it. This scores big with me, its very important for the proper environment in a sort of game like this and it was carried out basically flawlessly; grats on it guys.


The game is controlled by simple keyboard input. You specify a direction to move, or an action to attempt, and following a basic set of rules, the game will progress accordingly. Valid input can range from "get naked" to the slightly more modest "wear helmet". Heh. ;P


Overall game flow was pretty normal for this type game, some of the personality in it was funny, the way things were said and such, hehe. There was a fair amount of hidden type things and stuff that can be found by reading all of the material... and understanding what needs to be done.


On my first pass through the game however, I didn't find many of the things, :P and I spent a lot of time camping enemies for gold to save up for items. While this is not necessarily a bad thing, I would suggest adding some sort of method to heal the character, besides typing wait a lot until night and then sleeping (for 2 hp) over and over. Perhaps adding a way to use some of that hard earned money from enemies to buy an item to heal yourself. ;) Only suggestions.


The Interface to the game was fairly easy to use, the commands and flow very intuitive, very easy to "relate" to. My only request about it is that you add the "inventory" command in the document... i didnt even know i had a box of matches until i finished the game and looked thru the code, saw the command, and tried it in a new game. ;p


The only other thing I could perhaps suggest is an editor who speaks english as their native language. Don't get me wrong, the english is very understandable... but if you want to distribute the game to a target people that speak english, you should try to meake it the cleanest clearest english you possibly can ;)


Overall the descriptive scenery and the enveloping soundtrack were enough to keep me very interested in the game until I finished it. (There's even crickets over the music at night) and there was plenty of things to search for and look around in, if you thought about the circumstances and whatnot. :)

In closing, I rate this game highly, and I would recommend it to anyone who realizes that graphics don't make the game. :)

-cha0s

Visit Los Monos del Obús, or download The Quest For Opa Opa.


Review of The Quest for Opa Opa by Na_th_an and aetherfox

Written by Joseph Burke

With the arrival of freebasic onto the qb scene, many excited observers have been salivating at the prospect of seeing what talented qbasic programmers can do with 32 bits of uninterupted power. Goodbye screen 13, they said, as we now have access to the beautiful DirectX and OpenGL graphics modes. Why use 256 colours with no page flipping, when the power of 32 bit colour is at the fingertips of the Freebasic programmer. AetherFox and na_th_an thought so. They have used the power of freebasic to highlight the high contrast colour intensities that only a Zork style text adventure can show off. Their game, the quest for Opa Opa shows off the high contrast black and white display in fine style. This is the kind of project that only freebasic has the power to pull off. Or is it...

Graphics


It doesn't take long for AetherFox to really impress onto the player what a great artist he is. While other less talented artists would try to use pictures to convey the point of the story, AetherFox will have none of this. I really respect this position, as he is relying totally on the story to keep players interested. This is admirable, and brave, but as there are no graphics I must, for the purpose of this review, give a score that reflects this.

0/5

Sound/music

For those that don't know, AetherFox believes he is a talented musician. On his blog, he notes that he has just begun to teach his first student the guitar. I have a friend who was able to teach people guitar music at a music store. She only knows three chords, but boy can she use them...Despite my better judgement, I think it is really cool that he used his talent not only to teach, but also to create some Mp3 music for the game. This music is really not bad at all. In fact, I have made a CD of it, and it is nice to listen to while I'm driving. As a classically trained pianist, I mean this. Yet the music, while an impressive mix of new age ambience and Jazz, doesn't really suit the game. It would be great in a first person shooter, if you were entering a piano store. But in a text adventure, it just seems lame and showy. Out of respect for the quality of the music though, I feel the game deserves a point here.

1/5

Gameplay

This is a text adventure, so there really is not much gameplay except where you type commands. In this respect, playing this game is a bit like programming. Personally, I like programming. My continued work on sonicX reflects this. But, I would rather program than play this game. This is partly because I don't really like to program just for the sake of programming. It is also partly because I find the story boring.

1/5

Story

If you are going to make a text adventure, it pays to make it interesting. It also pays to make the main character someone that a player would want to portray. Pretending that I am the inbred son of a lumberjack not only doesn't interest me, but the fact that he was born in a place called wankerville absolutely repels me. I played this game for a good twenty minutes despite the abhorrent backstory, yet the plot development still didn't hook me in. As the game is so dependant on the story, and it didn't seem to contradict itself, I shall be generous dispensing points here.

2/5

Replay Value

The game is pretty boring, but the music is quite nice to listen to. Frankly, I feel like recompiling the game so that it shows the story, automatically scrolling, and plays the music in the background, shuffling the tracks as it scrolls. This way there would be some replay value.

0/5

Challenge

This game does present quite a formidable challenge, but not in the way that AetherFox and Na_th_an would expect. The difficulty comes in the form of the player ignoring his or her own boredom and deciding to play on. I suspect that few players will be taken in by this form of challenge. I certainly wasn't.

0/5

Fun factor

The quest for Opa Opa is not fun. Reading a story, without it being interactive, can be fun if the story is interesting. Reading a story that is boring is never going to be fun, no matter how interactive it is.

0/5

Total

As a game created in freebasic, a text adventure is always going to find it difficult to impress. In fact, it is disapointing to find that this game was coded in freebasic at all. I can't really think of a reason why this was not made in screen 12 of qbasic 1.1. If it were,then AetherFox and Na_th_an would have had an excuse for absent graphics.The quest for Opa Opa, as it is, seems to be a waste of freebasic's resources. It has also been a waste of 20 minutes of my life that I am never going to get back. But, at least the music was pleasant. I think that the authors of this game should focus on their music, and start an ensemble, or something. I don't think they have much of a future in the programming world.

Looking at the final score, I have probably been a little too generous with this review. Yet, given the quality, and originality of the background music, I think AetherFox and Na_th_an deserve every point.

4/35
Visit Los Monos del Obús, or download The Quest For Opa Opa.


Random Musings of a QBasic Game Programmer

Written by Rob Adams (Deleter)

I am going to give you an educational and formal lecture on the philosphical implications forebodingly presented by your seemingly innocent hobby....not! Rather, I am going to give a short rant on possible solutions to 'programming apathy', and tips to completing your QB/FB project.

Apathy, Merriam-Webster online defines it as "2: lack of interest or concern: Indifference". Quite obviously, when we start out on a project we have a lot of interest and are very concerned about its future. Then, why is it that we get this hated apathy? To try and understand this, we should first consider why we so desire to make this game in the first place that we dedicated our physical and mental condition to a grueling, filled with countless hours, debugging, brain cramming process. Why? Because this game HAS to be made. Why? Hopefully because it will present a fun idea that people will enjoy. Of late it seems that the entire computer game developing force, all the way from QB to ID(the doom guys, you know), has been focusing on making games cool, in other words, out-neating each other. The problem with a neat game, is that usually it fails to be a fun game. Yes, thats right, dynamic shadows don't mean crap. I'll play Diablo 1 anyday over doom 3. Why? Because its FUN! Fun first (usually involves gameplay), graphics second. This urge to make cool looking things demoralizes the qb community more than any other, because (with freebasic threatening this) a Basic FPS(usually most technologically advanced) is going to look like crap, there is no way around it.

So, now that I've slammed QB and its followers alike, lol, whats the solution? Well, its time we reorient our priorites. Put fun above neat. Do you really need a pixel by pixel scrolling engine with 321 sprites, over 100 effects, a dynamically updating sprite vortex....ok I'm making that up(i hope, lol)...but the fact remains. Instead of sacrficing countless hours of your time tweaking your pixel pushing techniques, put the gameplay and fun first. If adding this or that only makes it a small amount funner, cut it. Instead of seeing what the most you can cram into your uber-engine, see what the least is, then add only the things that add enough fun for the effort it takes to implement them.

Now, you may be wondering why I am saying not to spend more time on graphics, even when its not conflicting with making it fun. If not, thats good, if you are, here's why: When its all said and done, you want your work to reward you. Now, a game is only worth its weight in fun. If you spent hours doing something like 10x more animation sprites, and then you go to play the game and you don't get any more fun out of it, you're going to get demoralized, there's no question about it. So, my advice here is cut everything that doesn't carry its weight in fun.

Hopefully, I've gotten my point across to you. Perhaps one of you might decide not to include dynamic lights and accurate physics simulation for the sake of time and fun. Anyway, here are some general tips to follow which ought to help get your game out the .....port. :)

  1. Plan small - its easier to start too small and have it grow, than to start too big and be forced to cut

  2. Keep it simple - Both you and I know that some of the funniest games(still!) are quite simple in every aspect.

  3. Keep it fun - For every thing you plan/implement, you should keep in mind why its vital to the fun of the game.

  4. If its fun to program, its fun to play - I translated this from writing, where's its most definitly true, so it might not be true in all cases. However, I think it remains true enough. If you have fun while your programming your game (another reason not to do brain mashingly complicated things), people are going to have fun while playing your game.

  5. Send all proceeds to my address at......no, just kidding, actually send any and all comments/thoughts/counter-rants/and insults to my email barbarian_roleplayer@yahoo.com.

Thanks for reading! (Look below for a challenge based on this article!)

The Challenge

In reflection to my own words, an idea hit me, make a competition! Instead of other competitions, where hot gphx + sound will help you win, in this they might actually bring you down! The idea is to make the funnest game (best gameplay + usability + game FLOW) regardless of how simple. You can make anything from a textt-based adventure(not recommended, though) to a dynamically lit 3D - FPS, to a 2D RTS, I don't care so long as its fun. No, good graphics won't mark you down, but if one game beats another in gameplay but not graphics, gameplay will definitly win. If you win, you get the Anit-Apathy Award of Programmer Creativity (cool picture soon to follow!) send all entries to my email - barbarian_roleplayer@yahoo.com (no, an RPG won't score you brownie points =P)

This article was reprinted from this address.


Monthly Awards

Written by Pete and Z!re

Every month, QB Express hands out two awards to recognize QB or FB coders and websites that have done exceptional work in the last month. They are not awarded for work done in the past, only for work that has been released since the last issue of the magazine. Z!re and I have teamed up to bring you these awards on a monthly basis to help give credit where credit is due.

Site of the Month

JacobPalm.dk
http://www.jacobpalm.dk/

Webmaster: Jacob Palm

JacobPalm.dk has quickly become one of the most active QB sites on the Internet, and has really turned itself around in the past few months. Jacob Palm's site focuses on reviews of GUIs and Fake OSes, and as of right now, there are 38 GUI reviews on this site. Many of them have been written and posted in the last month. Also, Jacob is working on his own GUI called Costa, which you can find out about on the site. This site's frequent updates and quality presentation really sets it apart from many of the other new QB sites which have popped up over the past year. Keep up the good work, Jacob!

Programmer of the Month

Tio Bit
Freebasic.tk Profile

Tio Bit is a member of FreeBasic.tk who has been remarkably active over the past month. He (or she) has released four great programs in the last month that really demonstrate the capabilities of FreeBasic when it's used in conjunction with OpenGL. Some very impressive work. He's also devised an application that will load and display MD2 character models / animations from Quake 2. Also, a few months ago, Tio Bit released a neat application that will show tile maps that were created with the Tile Studio package, which I'm sure could be adapted to create a really cool platforming game. For being so productive this month, Z!re and I are pleased to reward Tio Bit with the Programmer of the Month award!



Suggest a site or programmer for an award!


Comics

Written by Rattrapmax6

Rattrapmax6 returns this month with another Horse Humor Comic.




QBasic Horse Humor




I.F. Games Chapter 4:
"Let's Code!"

Written by Na_th_an

At last, after three (boring) chapters full of theory and advices, we are ready to begin coding. It's said (it's true!) that before coding you have to do some brainstorming, planning and designing, and we have had enough of that. So let's code this. It's about time, ain't it?

Looking at the big picture

Basicly we have to code three main parts and then the game loop. Those three main parts are the three we have already discussed: location manager, objects manager and parser. It's good practice to be a bit tidy and use a different module for each, and then a main module to contain your game (which will be reduced to a "main loop" as the exceptions are gonna be parsed from a function in the parser module).

This is where we have to put special care. We don't want to create a bloaty, untidy bunch of functions which need a tad of inter-module globals. Instead of that, we are gonna create module-level globals (which are shared among the functions and subs in the same module) and functions/subs which export just the things we want outside the modules. For example, all the interaction we'll have with the location manager is a function to tell it which location to load and then a couple of functions to get the description and the exits. Those will be the only functions which will be "exported" (so to call it) to the .BI file. Get it? TIDY! Why export symbols that we are not gonna use? Imagine that we are using a SUB to trim the whitespace of the data read from the file in the location manager. Why we would like to export it outside the SUB if it is not needed?

This may sound a little puzzling, 'cause maybe I'm jumping from intermediate to advanced BASIC coding. Let's try to break this into pieces.

As you may know, a program can be composed of several modules. A module is just a BAS file which contains a bunch of SUBs and FUNCTIONs, some global variables (which are global just to those SUBs and FUNCTIONs inside the module), constants and type definitions which are only valid inside that module. Basicly, everything that's inside the module can be called/used from within the module, but not from outside. WTF? Then, what's the use of this if we can't call them from outside? Well, we can, but for that we have to "export" what we want to use. And we "export" this using BI files which can be included from other modules. That is, if you DECLARE a SUB in the BI file and you include that BI file from another module, you'll be able to call that SUB from that module.

You don't have to include all your DECLARE SUBs/FUNCTIONs in the .BI file, just the declares to the SUBs/FUNCTIONs which are gonna be called from the outside. Other auxiliary funcions don't need to be included 'cause they are only gonna be called from within the module, and this way you keep a clean namespace.

For example:

main.bas 
'$include: 'library.bi'

foo "hello"
library.bas 
'$include: 'library.bi'
Declare Sub prntStr(a As String)

Sub foo (a As String)
   prntStr Ucase$(a)
End Sub

Sub prntStr (a As String)
   Print a
End Sub
library.bi 
Declare Sub foo (a As String)

Note how we don't add a declare for prntStr to library.bi, as we consider it is an "inner", auxiliary function which won't be ever called from outside. That's called "encapsulation", at least to a degree. We are not in an object oriented language, but the OO approach can be used to a degree using procedural code.

This is very important 'cause an IF engine can become really complex if we keep adding stuff. And for that reason, it's better to have a clean design from the beginning.

Coding the Location Manager

Let's remember: the Location Manager just reads the location from the file and updates exits and descriptions. It also reads static objects.

So here's what we need: principally, we need a small parser which reads the locations file and extract the info from there. Basicly, our Location Manager will remember the last read location. We'll have special functions to retrieve this info from another modules.

We have also to decide what are we gonna do with the static objects. As we explained in previous chapters, static objects are things that can be considered part of the location's background. All you can do with them is examining them. Another special feature is that these objects exist only in the ambit of the current location, this means that they are created when you enter the location and destroyed when you exit.

We can do two different things with this kind of objects:

  1. Deal with them separately. That means that they have to be stored in the Location Manager and that the Objects Manager would have to access this data when the player attempts to examine a static object.
  2. Let the objects manager deal with them as if they were "only examinable" objects. If we go this way, we have create these objects and then destroy them in the objects manager, so we need a couple of SUBs which do this.

I've tried both, and I prefer number 2. Going this way, you can do this in a really simple way: As you will be storing all the objects in a static array which is defined in the objects manager, just reserve the last slots in this array for the static objects. That way, when you are coding the objects manager, if the object id is greater than a certain value, you know it is a static objects and you act consequently.

So we are gonna act that way.

First of all, let's define some constants and global variables:

LM.bas 
Const MAXEXITS = 10       ' Max number of exits in a location.

' Type for exits:

Type ExitType
     w as String * 2            ' Exit name ("n", "nw", "up", "dw", etc...)
     go as integer              ' Which location this exit connects to.
End Type

Dim desc As String              ' Current location description.
Dim X(MAXEXITS) As ExitType     ' Current location exits.

This is the minimal stuff we need for now. At a later time we'll be adding things as we need them. For now, let's stay simple.

Note how the exits are described: a two characters array and a integer number. The two characters string holds the direction: n for north, s for south, e for east, w for west, nw for northwest, ne for northeast, sw for southwest, se for southeast, up for up, dw for down, en for enter, ex for exit. The integer number contains the lid of the room that exits connects to.

As you see, we just defined two constants (it's easier to modify stuff afterwards if you use constants), a type to describe the exits, and two globals: the location descriptions and exits.

The first thing we'll code is the small parser which reads the locations file looking for a concrete location id (from now on "lid", as it will be a number) and fills in the globals desc and X() and calls the objects manager to create the static objects. This function will be exported in the BI file as we need to call it from the main module everytime the player moves. It just takes a parameter: "lid".

What this does, for the first stage, is looking for a line in the file that contains two "#" and then the corresponding location number. For example, if the lid is 6 the SUB will search for a line in the locations file that contains "##6". That is the mark that tells us that the description for location 6 begins in the file.

LM.bas 
Sub LM.LoadLocation (lid As Integer)

    Dim fH As Integer      ' File handle.
    Dim f As Integer       
    Dim linea As String    ' To read from file.
    Dim obName As String
    Dim i As Integer
    Dim idxPt As Integer   ' index pointer when filling "X".

    ' First we seek for ##lid in the file.

    fH = FreeFile
    Open "desc.txt" For Input as #fH

    f = 0: While Not f

        If eof (fH) Then
           Print "** FATAL ERROR ** lid ="; lid; " not found in file!"
           End
        Else
            Line Input #fH, linea
            linea = Ltrim$ (Rtrim$ (linea))

            If len (Linea)>2 Then
               If Left$ (Linea, 2) = "##" Then
                  If lid = Val (Ltrim$ (Rtrim$ (Right$ (Linea, Len(Linea) - 2)))) Then
                     ' Found!
                     f% = -1
                  End If
               End If
            End If
        End If

    Wend

    ' Now we've found the location in the file and the file pointer
    ' is correctly placed...
    ' Then we read desc, fill the X array and create the fixed objects.

    ' Clear exits:

    For i = 0 to MAXEXITS
        X(i).w = ""
    Next i

    ' Clear fixed objects: (see notes below)

    OM.ClearFixedObjects

    ' 1.- Read desc:
    '     As we discussed in earlier chapters, the description can be split
    '     into several lines. We just read and concatenate until we find a
    '     line that contains just "}":

    desc = ""

    While linea <> "}"
        If eof(7) then Print "** FATAL ERROR ** Unexpected EOF when reading desc.": End

        line input #fH, linea
        linea = Ltrim$ (Rtrim$ (linea))
        if linea <> "}" Then desc = desc + linea + " "
    Wend

    ' 2.- Read exits:
    '     Exits are in the file in a list that is terminated once again by a
    '     "}". To make things simple, we have every exit in two lines: one containing
    '     the "direction" (this is, "n" for north, etc.) and another containing the
    '     "lid" it connects to:

    idxpt = 0
    f = 0: While Not f

        If eof(fH) then Print "** FATAL ERROR ** Unexpected EOF when reading exits.": End

        line input #fH, linea
        linea = Ltrim$ (Rtrim$ (LCase$ (linea)))        

        If linea <> "}" Then
            If idxpt > MAXEXITS then
                Print "** WARNING! ** Too much exits at lid =";lid;". Ignoring "+linea+"."
                line input #fH, linea
            Else
                X(idxpt).w = linea
                If eof(fH) then Print "** FATAL ERROR ** Unexpected EOF when reading exits.": End
                line input #fH, linea           
                X(idxpt).go = Val (Ltrim$ (Rtrim$ (linea)))
                idxpt = idxpt + 1
            End If
        Else
            f = -1
        End If

    Wend

    ' 3.- Read fixed objects.
    '     Objects are described in a list again terminated by a "}". Each object
    '     takes two lines: one for the object name and another one for the object
    '     description. Once we've read both fields we call the objects manager
    '     to create that object.

    f = 0: While Not f

        If eof(fH) then Print "** FATAL ERROR ** Unexpected EOF when reading fixobjects.": End

        line input #fH, linea
        linea = Ltrim$ (Rtrim$ (LCase$ (linea)))

        If linea <> "}" Then
                obName = linea
                If eof(fH) then Print "** FATAL ERROR ** Unexpected EOF when reading fixobjects.": End
                line input #fH, linea
                linea = Ltrim$ (Rtrim$ (linea))

                OM.CreateFixObject obName, linea
            End If
        Else
            f = -1
        End If

    Wend

   ' And we are done! Close the file:

    Close #fH

End Sub

As you may realise, the code is nothing very fancy. We are just parsing a text file (with the format described some chapters ago) and filling our data structures with which we stract from the file. Note that we have placed error checking all over the place. As we are developing, those things will help heaps to find bugs. The locations file format can be somewhat puzzling for the eyes as we have focused our efforts on having a simple format that can be parsed FAST. That's why it's very easy to forget a } or something like that, hence the tons of error checking. If you are a speed freak you can take away all the error checking once you have finished coding the game.

Well, now that we have the main function which reads a new location from the file, we just need a couple of functions to retrieve exits and descriptions so they can be used in the main module. This is pretty straightforward:

Function LM.GetDescription () As String
    LM.GetDescription = desc
End Function

This function just returns the current location description. Note how modularized code works: "desc" is global to this module. If we want that info outside this module, we just create this function and place the declaration in the BI file, so we can call LM.GetDescription from any module that includes this BI file. See how it works?

The next funcion will be used to watch the exits. The best way is to have a function that takes a "direction" and returns the lid that direction connects to, -1 if there is not such an exit. For example, if we need to check if we can exit to the northeast, we'd call LM.GetExit("ne"). If it returns "-1" we know that there is no exit to the northeast. If it returns another number, we know that there's an exit to the northeast which connects with a location which lid is the returned number. Clever, uh? ;)

LM.bas 
Function LM.GetExit (whichExit As String) As Integer

    Dim i As Integer
    Dim res As Integer

    res = -1               ' Assume not found by now.
   
    For i = 0 to MAXEXITS
        If Ltrim$ (Rtrim$(X (i).w)) = whichExit Then
            res = X (i).go
            Exit For
        End If
    Next i

    LM.GetExit = res

End Function

And we are done, for now, with the location manager. We don't need anything else by now. The fixed objects will be handled in the objects manager. All we have to do is creating the BI file. Let's call the files LM.bas and LM.bi.

LM.bi 
' ********************************
' * Location Manager export file *
' ********************************

Declare Sub LM.LoadLocation (lid As Integer)
Declare Function LM.GetDesc () As String
Declare Function LM.GetExit (whichExit As String) As String

If you want to test it right away, just comment the calls to the object manager (they are in the LM.LoadLocation Sub in the last section where it loads the objects) and create a simple test.bas file like this:

test.bas 
' Testing the location manager

'$Include: 'LM.bi'

LM.LoadLocation 1
Print LM.GetDesc ()

' add more tests if you like

If you work in QB, just open it and type test.bas, the select "Load Module" and load LM.bas. Compile. If you work in fB, just copy all the files to an empty folder and type:

fbc test.bas LM.bas

Remember that you have to comment out the lines where the LM.LoadLocation Sub calls the object manager, which is not yet coded.

Now, to try this, you can use a locations file like this:

desc.txt 
##1
You are in a graveyard. The sun is still low and it throws
long shadows over the wet fathom. Everything is full of 
mushrooms which throw a strange smell. To the north you can
see a strange stone arc. To the southwest, the hideous path
that leads to your house.
}
n
2
sw
4
}
fathom
Wet and somewhat muddy.
mushrooms
Populating all over the place.
}
##2
In front of you, scarily present, a huge stone arc. While it
looks terribly ancient, this is the very first time you
have noticed its presence. Everything is beginning to look
suspicious to you. You feel an overwhelming disenchantment,
and an urgence to get away from here as soon as possible.
}
s
1
}
arc
Made of stone.
}
##4
You are in front of the gateway to your house. It's very
strange: the door is closed and your key doesn't turn into
the lock. You are beginning to think that this is a really
bad joke. What's happenning here?
}
ne
1
}
house
Your house is very small but really comfortable.
door
A thick, wooden door made of old oak.
lock
Special security lock made of a strange aleation of iron and gold.
}

Place your generated test.exe and this desc.txt file in the same folder and run test.exe. You should see the description of location #1. If you don't whether you or me made a tremendous mistake.

Next chapter we'll code the parser module. We'll discuss different kinds of approaches and you'll learn how to make the player think that the game really understands natural language ;)

Cheers.

Visit Los Monos del Obús or contact Na_th_an.


ACCEPTED DOS/CONSOLE COLOR USAGE

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

In the course of many decades, programmers have tried just about any combination of the 16 colors available in DOS. There was a point in time when each program (application or game) that came out pretty much invented their own color combinations either to seperate themselves from the rest of the existing programs or simply because the author thought that his color combination was better than the the rest of them. When you create a program, the colors you decide to use will ultimately impact what users think of your application or game. And in the course of these decades of DOS/CONSOLE development, we can see that a certain standard has formed. Not a standard per se, but more of a popular and accepted set of color combinations so to speak.

In this document, we'll see what these combinations have come to be and I'll try to explain why these colors were chosen as well as alternate colors since there are some popular alternate color combinations that were almost as widely accepted. Please note that this is not a study on the psychological effects of colors on the human mind but rather a study on what color combinations became the most popular choices and why. Another quick note is to say that this pertains more to applications than games, sure some games can follow these if you want, but this is aimed more at application development.

WHAT COLORS ARE WE TALKING ABOUT:

Just what are these 16 colors that we are talking about? In DOS text mode applications, all you have are those 16 colors which limits the combinations you can make to give an intelligent visual aspect to your applications. These colors are:

0 - Black

8 - Grey

1 - Blue

9 - Light Blue

2 - Green

10 - Light Green

3 - Cyan

11 - Light Cyan

4 - Red

12 - Light Red

5 - Magenta

13 - Light Magenta

6 - Brown

14 - Yellow

7 - White

15 - Bright White



And there they are, these 16 colors are the only colors you can choose from in the design of your screens as you might imagine, some colors, when combined with other are close to unreadable for most of us. Avoiding those obviously bad combinations is already a step in the right direction to make sure the colors you select are clear and crisp for the eye to see.

WHAT ARE THESE POPULAR COLOR COMBINATIONS:

To answer this question I would suggest you take a look around at the widely spread application programs you can find on the internet. In essence they all have certain things in common and they can be seperated in intelligent roles. These colors combinations are usually on a per screen role basis and as I mentionned, over the years, people started to accept/expect as standard or close to it. So then, let's take a look at these different screen roles as well as what color combinations have been selected for them shall we?

SPECIAL COLOR CONSIDERATIONS:

By considerations I mean of course care for your users here. There are color combinations that simply don't make sense at all. The most obvious is of course having the same foreground and background color (which makes text unreadable as they cannot be seen). Another is for example, any low shade colors (left column in the color chart above) in combination with any other low intensity colors except black, these will be very hard to read. The same goes for the high intensity colors (right column in the color chart) in combination with any other color than 9 - Dark Gray. Again they might be easier to read in some cases but they would probably be to harsh on the eye which would tire the eye alot quicker.

I would say that common sense is important here. We're all different as individuals but our eyes pretty much work the same as the next person. If your eyes like what they are seeing regardless of the chosen color, maybe it's not a bad combination. If you have to look away from the screen when you are looking at a combination, well everyone else just might feel like looking away too. So use your logic and common sense and I'm sure you'll select at least a halfway decent color scheme for your application without too much of a problem.

IN CONCLUSION:

As a final word, I would have to say to remember that the combinations listed here are not standard, they just came to be the popular chose for the given screen role. You could try other combinations if you want in your applications, maybe you'll like the outcome of those selection. For example a Yellow Text on a brown background isn't all that bad to look at, it just seems that the majority of users simply did not like that combination for all types of reasons. So go ahead and experiment with your colors. See if you can find something that doesn't look too bad to the eye, if you can read clearly, chances are so will your users.

Color is a matter of personal taste and that's the reason why alot of applications come with the option to change the colors of any and all parts of a program. If you want to experiment with color combinations, perhaps giving the users that ability to change those colors wouldn't be a bad idea especially when you think about the color blind people that might not see reds or greens as well as you might. You can always email me (see my signature below for my email) to give me comments and suggestions about this or other articles and techniques I've written. I write these in the hope that they will be useful in some way to whoever reads them and that is my first goal when selected the subject of my articles and techniques.

MystikShadows
Stéphane Richard
srichard@adaworld.com
Download a copy of this tutorial.


Learning How To Optimize Your Game

Written by Jonathon Wallace

One of the things that most people do incorrectly is that they optimize the wrong part of their code. While it is true that every little bit will speed up your program, what you really want to do is to look for long loops or long complicated lines that could bring the speed way down.

The first thing that you need to get an initial frame rate, then write it down so that you have something to compare it to later. Sometimes what will seem like an optimization one minute, could in fact slow the computer down. Now, your game goes through a loop of subs (I hope). Have your program go through one loop, recording using the TIMER function how much each time each SUB takes. Now record that and figure out which SUB is taking up the most time. For most games it will be the one that draws the screen. Here is an example of what I mean from Inspiration:

Dynamic light – 8%
HUD – 2%
Drawguns – 4%
Raycast – 83%
Keyboard – 3%

Notice that most of the time is spent in the raycasting SUB. This means that if I optimize the HUD to move twice as fast I may only gain a half a frame per second, but if I do that for the raycaster, I almost double the frame rate. This means that most of the optimizations should be done here.

Here are some major optimizations that help a program out:

Use Integers whenever possible, they are 32 bit and one a 32 bit machine this works the best, they also don’t have to worry about finding a decimal point. FreeBasic automatically makes all variables integers, but in Qbasic you have to add DEFINT A-Z at the top of your program

Use lookup tables; if your program uses a lot of trigonometry then you will definitely want to have sine and cosine tables. This is essential for a 3D game, without them the framerates would trudge into the ground.

If you have two nested FOR loops and it is possible to do some calculations outside of one of them do it. This is what I mean:

FROM:
FOR a = 1 TO 10
   FOR x = 1 TO 10
     aa = sin(a) * a ^ 3 + x * 2
   NEXT
 NEXT

TO:
FOR a = 1 To 10
   suba = sin(a) * a ^ 3
   FOR x = 1 TO 10
     aa = suba + x * 2
   NEXT
 NEXT

If you have a small FOR loop, unravel it. It is a mistake by amateur programmers to try to save as much room as they can to make the code faster, this isn’t the case. Here is an example:

FOR x = 0 TO 5
	PSET(x, 1), x
NEXT

After compilation it has little difference from:

IF x < 6 THEN PSET(x, 1), x
x = x + 1
IF x < 6 THEN PSET(x, 1), x
x = x + 1
IF x < 6 THEN PSET(x, 1), x
x = x + 1
IF x < 6 THEN PSET(x, 1), x
x = x + 1
IF x < 6 THEN PSET(x, 1), x
x = x + 1
IF x < 6 THEN PSET(x, 1), x

Instead, just use:

PSET(0, 1), 0
PSET(1, 1), 1
PSET(2, 1), 2
PSET(3, 1), 3
PSET(4, 1), 4
PSET(5, 1), 5

It is much easier and therefore faster for the computer to read.

Wherever possible do multiplication and division my multiples of 2. This allows FreeBasic (and Qbasic I think) to compile using the bit shifting commands which are three of four times faster than MUL and IDIV

Don’t do comparisons against zero, all the comparison does is returns a value, either 0 or 1, then the IF statement uses that as a Boolean. If it is equal to 0 then it is false, if it isn’t then the statement is true and it performs everything inside the nest.

i.e. IF a THEN …

Multiplication is five or six times faster than using powers. If you have something that uses small power functions, expand them into multiplication:

No good:  A = b ^ 5
Good:  A = b * b * b * b * b

Now go back to your original framerate and do some comparisons, see how much faster your program runs, and see if there are now any other problem SUBs

Download a MS Word version of this tutorial.
Visit Wallace Software to contact Wallace or check up on his projects.


Writing A Simple BASIC Interpreter: Lesson #1

Written by Vincent Peters (BazookaSquirrel)

Why would you ever try to make a BASIC interpreter? There are enough compilers and interpreters available at the moment. And a compiler is much faster then a interpreter. So there is no reason to make one. Well, there is a small reason. We can use a BASIC interpreter as a script-engine. In the world of fake-OS creation there is always need for such a piece of code parser. Even in the game industry there is a good use for script-engine.

First of all we need to define which keywords we are going to use in our interpreter. If we take a short look in history we can see that in the beginning of BASIC there were only a few keywords. Later on it expanded to the advanced dialects we know today. A standard lesson that we can learn from history is that development is like evolution. It takes time. So we will start with making an interpreter for a very primitive BASIC language. The keywords we are going to use are: 

LET

PRINT

IF … THEN
ELSE
END IF

GOTO

SLEEP

Doesn’t look impressive at all, doesn’t it? But think about the gigantic possibilities you have with these simple keywords. They are enough for a simple program. Later on I will add more keywords to increase the possibilities.

First we will start with typing a simple program every one of us started with:

PRINT “Hello world”
SLEEP

Save it as “C:\TEST.TXT”

Now we start for real. Open your favourite FreeBasic editor and start to type the following code:

DIM LineOfCode$
SCREEN 12 ‘Yes we work in an old dusty/trusty screenmode
OPEN “C:\TEST.TXT” FOR INPUT AS #1
LINE INPUT #1,  LineOfCode$
PRINT LineOfCode$
CLOSE #1
SLEEP

And run it. If you did everything correct you will see the following screen:


Now we will advanced to the next stadium.

Type in the following code:

DIM LineOfCode$
SCREEN 12 ‘Yes we work in an old dusty/trusty screenmode
OPEN “C:\TEST.TXT” FOR INPUT AS #1
LINE INPUT #1,  LineOfCode$

IF LEFT$(LineOfCode$, 5) = “PRINT” THEN
  PRINT MID$(LineOfCode$,7)
END IF

CLOSE #1
SLEEP

Looks self explanatory doesn’t it? Run it and have a look. Now we only have to remove those irritating characters at the start and end of the line. For that purpose I designed a little piece of genius code:

  PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(32))-8)

Insert this instead of:

  PRINT MID$(LineOfCode$,7)

And have a look again, now our PRINT statement works the way it should, only the extra functions of PRINT don’t work at the moment.

But that can be changed:

DIM LineOfCode$
SCREEN 12 'Yes we work in an old dusty/trusty screenmode
OPEN "C:\TEST.TXT" FOR INPUT AS #1
LINE INPUT #1,  LineOfCode$
IF LEFT$(LineOfCode$, 5) = "PRINT" THEN
  M$ = MID$(LineOfCode$,instr(8, LineOfCode$, CHR$(59)),1)
  SELECT CASE M$
  CASE CHR$(59)
    PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8);
  CASE ELSE
    PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8)
  END SELECT
END IF
CLOSE #1
SLEEP

Since our code must run more than one line we have to add a loop. So now our final code looks like this:

DIM LineOfCode$
SCREEN 12 'Yes we work in an old dusty/trusty screenmode
OPEN "C:\TEST.TXT" FOR INPUT AS #1
DO
LINE INPUT #1,  LineOfCode$
IF LEFT$(LineOfCode$, 5) = "PRINT" THEN
  M$ = MID$(LineOfCode$,instr(8, LineOfCode$, CHR$(59)),1)
  SELECT CASE M$
  CASE CHR$(59)
    PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8);
  CASE ELSE
    PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8)
  END SELECT
END IF
LOOP UNTIL EOF(1)
CLOSE #1
SLEEP

In our next tutorial we will add more functionality. Feel free to add pieces of code to improve my basic code. My code is not optimized for speed and also not optimized for beauty, so get going and improve my code.

In the next tutorial I will add more keywords.

So long,

Vincent Peters aka the BazookaSquirrel

I’m not a FreeBasic professional, I’m just a BazookaSquirrel. If you improve my code, drop me a note at: vajpeters@gmail.com

Download a nice Word version of this tutorial, or email BazookaSquirrel.


Effective ASCII Development

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Looking at programming projects past and present it seems that one good advantage to ASCII and Text development is that you do not have to be binded by a bunch of rules, guidelines and standards when creating your programs. One must be careful however because this freedom can also make programs (applications or games) hard to use, hard to understand and therefore unusable to many people at least not without a huge user's manual that no one will ever want to read. Like most programmers, I'm sure you'd love your creations to be used and played alot and the only way to achieve this is to create an intelligently designed program. All this within the concept of Text and ASCII development only. No graphics, no Windows gadgets, A blank window and the 255 characters available in the ASCII character set.

This is what we will be covering here. We will be looking at what exactly is an intelligently designed programming project as well as attempt to cover most of the bases of what you can do to make sure your programming endeavours are indeed the success they deserve to be. So if you'd like to create a project, detailed and complete, and would like to know how to help your chances that your project will become useful and hopefully a classic (if it's a game you're making) fasten your safety belt and let's begin this journey shall we?

WHAT I ASSUME:

This is not a story line tutor. We assume here that you already have your story line if you need one, that you defined your characters and their role in the game should you need them, we've also assumed that you defined special locations and places where users can do certain types of things and accomplish certain tasks. We are at the next phase in this document. The phase where you start taking everything you have and making them work into functional/logical groups of related or non-related groups. The phase when it's not time to start planning and organizing things in order to bring them closer to the development stage in a organized fashion to help you filter out the bad things and keep the good ones. With all these papers and notes, this document will take you into the next phase of the game development process, the analysis and conceptualization.

THINGS TO TAKE INTO CONSIDERATION:

When you design your application, you have to take certain things into consideration to "effectively" create a game or a program that users will want to use. To do that, there are a few questions you need to ask yourself and whenever you can, ask your typical user base as well since they are the ones that will be using your application or playing your game. These questions are:

In other words, if you take the time to sit down and think about things for a while, it's not that hard to plan a well planned program and it doesn't add all that much to the work you'd have to do wether you do standarize or not and which way you decided to offer your options and deal with the interactivity factor of your application or game.

PUTTING THINGS IN PERSPECTIVE:

With all this theory in mind, I think now is the perfect time to take a look at how these questions were answered in a particular game i've been playing to see why things were designed the way they were designed. We'll try to see what answers they could have come up with to create the games they did the way they did it. The reason why I'll use a game here instead of an application is simply because I like that game, I still play it today, and to me it's a great example of program design, and appropriate interface design for the type of game it is. The game is called Starfleet 2 - Krellan Commander a Startrek like game that I enjoy playing alot.

GAME DESCRIPTION:

As you might have guessed from the title of the game (yes the game title is as important as the rest of the design) This is a space battle and conquest game. You are at the command of your ship and you take on different types of missions to gain experience and up your ranks. This is what's known as a command based strategy game in that you select commands and things happen based on the commands you executed. The key words for this game are, strategic space simulation, all ASCII graphics, Command Based. This is basically what the game is about. With this kind of game you can expect certain things and not expect others at all. here is a few screenshots to give you a visual idea of what that game is all about. just click on them to get the larger view see the details. I strongly encourage you to take the time to look at these screenshots and try to see what is in them and how the screens are designed, the rest of this document is based on these screenshots.

    

Default Game Options:

This is where you will typically set the general options of the game such as if there will be sound, color or monochrome, keyboard set and other such options. You select the options with the arrow keys and when you are satisfied, you press enter to save the options.
    

Game's Main menu:

As you can guess, this is where everything can happen. You can load a previously saved game, start a new mission, retouch the settings of the game and review your service record among other things.

    

Main Screen Layout:

This is where you end up when the game officially begins. As you can see here there are many things on that screen but notice that they are very intelligently designed and layed out. This some feat of wits considering it's all text and ASCII graphics only and yet so clear to see what's going on where.

    

The Navigational And War Map:

This image is the Navigational Map, the War Map is red and features Tactical information. It's in blue and serves the purpose of travel as you might have expected from the name of the screen. you navigate with the cursor keys to your destination and add it to your targeter. you can then turn on your engines (in the main screen) and get on your way to the selected destination.

    

The Star System Map:

The Star System Map layout is a view of a solar system in the middle of the grid on the left is the star represented by the Asterisk (*) you move a selector around to get information on surrounding planets and other spacial objects including star forts and ships.

    

The Space Forces Locator Screen:

As it's name implies this screen serves the purpose of allowing the user to quickly localize where each ship of his fleet is and what they are currently doing (docked, invasion and other single word references to quickly give the needed information).

    

Propulsion System Schematics:

The main reason why I'm showing this screen is because it is a well drawn screen especially for an ASCII text screen. It lays out a basic schematic of the propulsion engines quite clearly and you can see where each component of the propulsion system is connected to the other components.


As you can see from all these screen shots, this is definitaly a complete game that offers many options as well as many types of missions and all the tools you need to accomplish them as well. These screenshots represent a sample of what's available in this game, there's more screen all equally as functional and as well designed as these. I also showed this many screen shots to emphasize the work that must have went into the creation of this game. These are the screens themselves, the story lines and mission details (just as important as the screens and the game themselves) are quite good too and definitaly capture your interest from start to end especially if you're a trekkie of any level.

BREAKING IT DOWN:

As mentionned in the description above, there's a whole lot of screens and many different operational modes in this game. so I'm not going to detail every single one of them. The way we will be breaking down the game will be quite different. We'll be looking at the game, what it was meant to offer, what it does offer and detail all this as per the questions we could be asking ourselves. We'll be basically designing the game as if it wasn't made yet and see why certain screes look the way the do based on the functionality we'd like to see in a given part of the game.

THE GAMING CONCEPT:

This is usually the first step to creating a game in my opinion, if you don't have a concept, there is no game or application. In Starfleet 2 the concept could best be described as a futurist space strategic simulation game. What's the first thing that hit your mind when you read that? Futuristic Space Simulation right? Now, without looking at the game itself, what does that reflect to you? How would you explain what a futuristic space simulation entails? I would define it as a game that happens in the future (typically, this represents advanced technology) it happens in space (chances are there's ships involved) and it's a simulation (chances are there's a certain degree of realism and factual information involved to make it a convincing simulation). With this in mind, let's see what kind of answer we can give our now famous 5 questions of the beginning. Remember that the answers given here are strictly in the context that we are create a Futuristic Strategic Space Simulation game. The answers would most definitaly vary for other types of games and other types of applications.

FROM CONCEPT TO CONCEPTUALIZATION:

At this point we have a good idea on what the game should be. Maybe by now you've created some mental images of what you'd see in the game and you're thinking maybe that you can sit down and start coding. This is where I have to stop you a bit and talk to you about conceptualization. What is this word? Well conceptualization is the art of putting into paper what you are seeing in your mind basically. Good artists have this ability to paint on canvas the exact picture they have in their mind. When creating a game, you need this phase especially if you know you'll have many screens involved in the game play. Starfleet 2 has a huge variety of screen layouts that have been designed to give a realistic feel to the game as well as superior control over the realization of the missions at hand. Conceptualization is more than just drawing screens and taking a few notes. Chances are each screen you design will probably impact or interact with other parts of the programs including other screens. The relationship between the screens is just as important as the screens themselves. When you think about it, taking the time to know the relationships between the individual screens will cut down the coding time involved because if you forget a relationship, chances are you'll have alot of alterations to make to create the missing relationship, not to mention the impact it will have in other screens and gaming engines.

So then, as I mentionned at this point you have mental images in your head and well it's time to concetualize these screens and their relationships. Where do we start? This is what this document is for. In the case of Starfleet 2 and many games regardless of whether they are Text or Graphical games, you can probably think about a certain set of screens that they all should have. By that I mean that all games could typically have a basic list of screens. Those are:

Of course, in the case of Starfleet 2 there's plenty more screens than these, and they are all there for specific reasons. One is to of course allow interaction with the user and giving the necessary feedback on their actions, the other is to help in the hole look and feel of the game itself. Some might argue that some screens could have been combined into one, maybe they are right but think of the complexity of some these screen if they were combined into one. This is all part of the conceptualization phase too. You need to stop for a second and define where to stop, when you can consider it enough contents on a given screen. And, of course, you need to ask yourself if it's better, for the player (not you) to split a given screen into more than one. Again I say here, ask around, post questions on forums, create polls on your website but do what you have to to get the feedback you need to make your game a good one.

THE ACTUAL DESIGN OF THE SCREEN:

At this point you have enough info, I believe, to start the official conceptualization of your many screens and user interfaces. Personally I like to take some quadrilated paper and start designing from there, I can draw lines and give me some good pointers for when I'll actually code the given screen. The important thing before you start is to make sure you have all the screens and user interfaces you'll need ESPECIALLY if this game is going to be a group effort. Distribute the screens amongst the different people that will be designing them and ultimately programming them. Once that list is complete and everyone have their respective set of screens to design, the method used for the actual design is really up to you (unless it's a commercial game and the company wants a certain set of design methods followed. Otherwise, you can draw them on paper like I do, or start creating code that will draw the screen. There are screen designing tools as well that offer you a blank screen on which you draw lines and characters to form and shape your screen design into place. In other words, there's more than one way to do it and there is definitaly advantages to all the existing screen designing methods.

One thing I always carry (well not so much now since I just about memorized it) is an ASCII character code chart. You never know when memory will fail you and having one of those handy gives you a quick reference of what you can use while designing your screens. Depending on your programming language and environment, some offer an ASCII chart as a popup tool that you can glance at, others also offer it in the help sections. Another thing I usually do while I design the screens (on paper or in code) is list the different elements of the screen. Taking Starfleet 2 for example, the main screen display offers more than one component like the Long Range Sensor, the Navigation Information, the Tactical Display, Damage Report and others. Typically each of these elements will represent a different part of the game play so I find it important to list those if not for anything else, just to give me a basic list of things to do when I start the coding process.

You do need to put all the efforts you need in your screen designs. If there's some part of a screen is not clear to you, the creator of the game, chances are they won't be any clearer to your players and probably require some more designing. Likewise if there's a screen you don't like, your players probably won't like it either so you should take the time to create the perfect screen for you based on the feedback you received from your forum posts and your polls. If you give this design phase enough time, you will create intelligent screens that you and your players can love to use. Even if just in ASCII character codes, you can definitaly give your screens the mood they need to become convincing to the player's eye. Take another look at the screenshots above and you'll see that each of these (and the others I have not shown here) are very well designed and offer realistic feedback to the player in a very efficient means. You can do the same.

PUTTING IT ALL TOGETHER:

At this point you have your relationships between your screen layouts, you have the screen layouts themselves. What's missing to make a game? Well if I told you that you could start coding at least you'd be a bit better prepared for it by now. But, and there is a but, there IS more to consider at this stage. With the screens described above, you will have created the interactivity between the game and the user. What happens with the interactivity between an enemy ship and a planet, or a ship and a warm hole, or a planet and it's moon? These interactions all have to occur for the game to reflect any type of intelligence and realistic consequences to events caused by other parts of the game as well as effects caused by the player.

This phase is the phase responsible for connecting the pieces of the puzzle together by providing the missing links between each pieces such as when pressing a specific key or key combination will make a certain screen appear. How things work within each screen (such as navigation between the different fields or elements on a screen, determining the order in which information is acquired, data validation to make sure the data entered is as expected and other such functionalities. This phase also determines the intelligence level of your opponents, the types of interactions you may encounter when you come accross this or that type of enemy, analysis to determine if your ship or your fleet is strong enough to take on this kind of opponent and vice versa. Calculations to determine when and where an enemy ship or an allied force will rendez-vous with you. All these details that add realism and depth to the game.

Let's not forget the reward factor. Players love to be rewarded when they did something right. There's many ways you can reward players of course. You can up their score a couple notches when the cross a big step in the game, you can install a Ranking system like in Starfleet 2 where you start as a the bottom and graduate towards captain with your many victories. Basically you could also just throw in some encouranging words too saying to the player that he's definitaly on the right track. All this depends on the game concept and the context of what's currently happening when the time comes to reward your player.

THE FINAL WORD:

If I've been clear, at this point you should have everything you need, organized and ready to go, to sit down in front of your selected programming environment and start programming. Remember that this document does assume you already listed your enemies, your locations, and all the other basic parts of your game components and took it from there. If you don't have that done, well I would recommend you take the time to do so, like what this document is trying to do, you won't regret already knowing who's doing what where before you start coding. Each little part of a game from a character to a location to a trap even can influence the design process greatly all depending on what they are supposed to be doing so, if you don't have everything listed with a good idea of what's happening where, you might find yourself redesigning more than you originally planned. Taking the time to do these things in advance just makes the rest of the game creation cycle flow smoothly. It can even give you a better sense of control over the development cycle as you now have a very close to complete list of things to do so you can take things one step at a time.

When creating a screen or an entity I like to do everything that I can do for the screen or entity. For example, if I am designing an Alternate Game Screen I already know it will have to be connected some way to the Main Gaming Screen and I'll tend to do that connection already. Likewise, if I create an entity for a ship and I know that ship will have a certain amount of power and a given weapon on my main ship will lower that power by 50 each time It gets hit, I'll tend to code that right away too. In the limits of possibilities I basically like to take one thing, create it, validate it, finish it and move to the next thing on my list. It saves notes here and there telling me (don't forget to add this or that later), well, saves alot of these notes, in programming there's always room for at least some notes like these.

As always, I try to be as clear as I can. However, not everyone will agree on that, so if there's a certain part that's not clear to you, feel free to send me an email (see my signature below) and tell me about it so we can make sure it all gets cleared up and you can grasp the concepts. Of course it's not always obvious to try to do all this before you start to code, but for any game or application that you'd consider a "bigger project", you'll see that it is definitaly worth the effort in the end especially in a group effort.

MystikShadows
Stéphane Richard
srichard@adaworld.com
Download a copy of this tutorial.


Conditional Compilation And You

Written by aetherfox

Conditional Compilation is one of those parts of programming that sit in the dusty corners of the knowledge banks of programmers world-over, yet is one of the most ingenious additions to any language. Usually something that was reserved for C/C++ programmers, with the power of freeBASIC's new preprocessor, you can now use conditional compilation to help your program.

The preprocessor allows you flexibility in changing the way code is generated through the use of conditional compilation. Take this scenario: you are debugging the code in your program, and you want to add some extra code to output a few variables, but remove them in the final version. The code would be something like this: 

#define DEBUG

#ifdef DEBUG
Print "Debug Value"
#endif 'DEBUG

Note you do not need the comment after the #endif, but is it good practice.

Basically, the above code checks to see whether DEBUG has been defined, and if it has, then the code between the #ifdef...#endif will be executed. While this may seem silly, the uses this has are amazing. If you simply remove one line at the top of your program (#define DEBUG), then all the 'debug code' that you've added won't be sent to the compiler -- the preprocessor removes it, reducing the bloat of the final executable.

'Turn on debugging
#define DEBUG

'Turn off debugging
#undef DEBUG

The #undef directive is a way of 'undefining' something, in this case DEBUG. While it is strictly not needed (just commenting out the line '#define DEBUG' is enough), it makes the code much clearer, and has other uses:

#ifndef DEBUG
Print "Production Version"
#endif 'DEBUG

While not the most useful example, this demonstrates the use of another directive: #ifndef. This directive will cause the code to be compiled if the symbol is not defined.

Much like a normal programming language, the sense of the conditional can be reversed using a variant of else, #else:

#ifdef DEBUG
Print "Test Version"
#else
Print "Production Version"
#endif 'DEBUG

Of course, there are many applications to this. Who says you need to do this on debug code only? You could actually check the effect of a new piece of code, or some test routines by simply defining a name like TESTCODE and using the preprocessor directives to encompass your code for conditional compilation:

#define TESTCODE

#ifdef TESTCODE
BulletRoutine()
TestFireRoutine()
#endif

The scope of this tutorial is a limited one, but this method is used by professionals. It makes life easy when programming. I have used this method in my own code. To see this code in action, view the source (flyaround.bas).

Avinash 'aetherFox' Vora

Download a copy of this tutorial (HTML format).
Visit avinash.apeshell.net, or email aetherfox at avinashvora [at] gmail [dot] com.


Spicing Up Some Custom Windows Icons In your FreeBASIC Programs!

Written by Adigun Azikiwe Polack

Have you ever wondered how that famous “FreeBASIC Horse” icon was shown on certain FreeBASIC programs that got compiled to .EXE format? Hey, better yet, ever wanted to have YOUR VERY OWN icon attached to the .EXE of your own compiled FB proggie? Well, this original tutorial presented by yours truly will *definitely* answer you these two burning questions and even make your wildest dreams come true in the process, all within the subject of what I am talking about right here! ^_^ !

To master this, please pay VERY close and careful attention now to the following steps that I will give you:

  1. Grab yourself an icon editor that can help you produce your own original .ICO files! Such examples of them include:



AWicons Lite by Lokas Software is one of the most useful icon-creating programs that you can use to help you get started on getting the icon of your dreams right into your *next* big game, graphics demo, or what have you in FreeBASIC!! ;*) !

  2. After you create your brand-new icon using your favorite icon/paint editor, be sure to save that thing as an .ICO file and place it into the “bin\win32\res” directory within the main directory where FreeBASIC is located (ie C:\FreeBASIC\bin\win32\res).


What you want to do at this point is to save your Windows-based icon file with an extension type that is circled here, in the directory clearly specified in step #2 of this tutorial.

  3. After saving, please check the “bin\win32\res” directory within the main directory where FreeBASIC is located (ie C:\FreeBASIC\bin\win32\res). There, your new .ICO file should be already up right now if you have steps 1 and 2 correct so far!! ^_-


HERE IT IS, so get your new and freshly-baked icon while it is sizzlin’ hot!! Let’s put it to some good use now, shall we?

  4. Next, open up the text editor of your desire (such as WordPad or Notepad), and create your own new FB resource file that points to the *exact* location of the icon that you’ve created.


  5. When done, select “Save As...” (or anything like that). Make sure you are at the “bin\win32\res” directory within the main directory where FreeBASIC is located (ie C:\FreeBASIC\bin\win32\res) and type in any filename you want there. But remember now, since we are gonna be saving an FB resource file indeed, be sure also to include an .RC extension at the end and *not* a .TXT extension there, please! Then, click “Save” when you are all good to go!! ;*)


  6. Your FB resource file with an .RC extension should come up in the “bin\win32\res” directory portion of FreeBASIC indeed!! :D If not, then repeat the procedure from step #3 to make sure, please.

For steps 1 through 6 so far: having followed all of them correctly in this example here, here now is our own test resource file for FB (circled in this screenshot), saved in the “bin\win32\res” directory where it is supposed to be. ^_- !

  7. To compile your FreeBASIC program to .EXE format *with* your own brand-new icon attached to it, in the command-line (or at the DOS prompt), try typing in the following:

fbc anyresource.rc -s gui anyprogram.bas

......whereas the “anyresource” portion is talking about the target filename of an FB resource file, and the “anyprogram” portion is talking about the target filename of your FB source code, too. Both of these portions may require you as well to type in the exact directory/path as to where they are located, so do be cautious here.

NOTE: You can even create a custom batch file (.BAT) based on what I have just said in this step to help make things a little easier, too! ^-^

  8. If your own icon is *successfully* attached to the .EXE of your compiled FreeBASIC program, CONGRATULATIONS TO YOU!!! d=^_^=b !! If the icon does not appear in that .EXE there, then please review step 7 again.


Whew!! Just compiled our test program for FB with our new custom icon, and BOOM, here it is!!! My, all that hard work *finally* paid off after all, didn’t it? ;*) !!

Once you learn how to do them all within this tute, then you are SURE to be ready to set up your custom Windows-based icons to be attached to your own FB-compiled programs just like a *real* pro!!! Hey, it may not always be perfect, BUT at least all eight (8) steps that I gave you will work if you just do ‘em right, I will tell you! COME ON, GIVE IT A SPIN AND SEE!!! ;*) !

Well, here ends my _very_ first official tutorial that I have ever written and prepared, and PRAISE GOD ALMIGHTY that He is the only One that has first and *surely* enabled and empowered me to do all of that, just to be an extra special blessing to the whole entire QB45/QB71/FreeBASIC community (and also to YOU, the FreeBASIC programmer!!) on purpose now! I HOPE YOU ENJOYED IT AS WELL AS EVER, SO THANK YOU RICHLY WITH ALL OF MY HEART FOR YOUR WONDERFUL TIME!!! Bye-bye for now!! ^_-=b !


From the words of Adigun Azikiwe Polack, the original author of this official tutorial for FreeBASIC.

Download a zip archive of this tutorial.
Visit the AAP Official Projects Squad - with links to all of Adigun's programming sites!


COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part One - The Project Begins

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

When you program a small game or a small utility size application, most of us just sit down and create the progam. All in all that's not all that bad of an idea for that size project. However, what if you were sitting at your desk at work, your boss send you an email that says "I need a program that allows to create accurate charts and diagrams, floor layouts, plan and estimate the cost of building a house from the grounds up and that gets determined as I create the plan of the house. In essence he wants a financial version of the now well known Autocad™ Application. He already knows what he wants. he doesn't want something that will interface with Autocad™ either he wants his own custom 100% original software product.

Now, how big do think this kind of a project would be? How long do you think it would take you to create something like this? Most importantly what are you going to do to make sure that this projects succeeds? For one thing, it's definitaly not something you can just sit at your computer and start coding, it's simply too big a project, it needs detailed analysis, probably some good engineering. Basically you cannot create this type of application without some degree of preparations and documentations.

This series of articles will help cover all this. We will start with the paper (or the email in this example) and work our way right down to the actual development of the application. We will be looking at what methods and tools are available to you every step of the way as well as the basis of how to choose the right tool for the task at hand. We'll be looking at cost and time issues too because in the business world, time is money and in the case of software developers, time is costs to the business that hired or contracted us. By the end of this series you should be well equipped to start, and finish, pretty much any size project.

WHAT HAPPENS FIRST:

Indeed here the question is not what happens next, but what happens first. While sipping your morning coffee, getting an email like this one won't exactly help you digest that coffee properly. In many cases like our example above, interfacing with Autocad™ would be intelligent, but for the sake of this series, let's say your boss wants to make a better version of the software and get into competition with Autocad™ so there's no way you can interface to, or borrow anything from that software to help shorten your time, you are on your own and it's time to get things started.

So here you, you have your work cut out for you to say the least, you've been basically put in high performance mode by your boss who relies on you to get the job done (that's why he's paying you the big bucks after all). So what do you first? Best thing to do is take a step back, and see what you can use to do this job. First thing to realize is that there will be many things to do to get from point A to point B here, many documents to write, and of course plenty of planning and organization. But lets take things one step at a time, this is an article after all, not a deadline so we have time here to take things slow and easy. The first thing is to review the software development cycle. It's broken down into 5 categories and they are:

THE ANALYSIS:

You still have that email ringing in your head, and you want to start the analysis as soon as possible so things can get started as soon as possible too. You are probably also starting to think about the programming phase too because you're a programmer and you want to start coding right away. Like I mentionned above, this type of practice is good for small projects, but virtually useless in a project this size. You'll just shoot yourself in the foot and the less analysis and preparations you have, the bigger the gun. There are many software analysis tools, each with their own special use that you can use to your advantage. The best thing to do is to enumerate them here so you know what they are and where they are commonly used. I'll also show some known forms of these methods here too. They are categorized in 6 categories. These are:

One of these 6 categories will offer you the best tool for the project at hand. Ultimately all these server the same purpose and that is to help you define the problem as well as defining the solution. So before you decide on which methods to use, you need to think about what you are being asked for and when you have them, take a good look at the user requirements. In a very general fashion, the user requirements, in our case, are defined by the program we are modeling our project upon. The user's manual from the Autocad™ software package should tell us everything we need to know except the financial side that we'd be adding as an extra feature. You're not always that lucky however. Even today, there are still many need for software that hasn't been created yet and in that case, you have no choice but to do it step by step, sit down with the users, ask many questions to get their version of the story so to speak. once you have the user's list of requirements, then you can go about using these 6 categories of methods to define what the solution can be. In some cases it gets more complicated as management might decide that some user requirements might not apply to the project, so it's more meetings, with management and with the users to arrive to a compromise between what the users want and what management thinks the users need.

To decide on which of the 5 last categories (as we already ruled out the first listed, the AdHoc methods) we simply need to ask ourselves the right questions. More than likely, the answers to those question will give you a really good outlook on which method is best suited for the project at hand. that can change from project to project of course depending on those answers. Note also that when I say "when you describe the project" that can mean when you talk about it to others and/or when you are thinking about the project to yourself as well. So then here's a list of questions that could get asked to get our answer:

And that's it, these three questions are usually enough to bring you project towards one of the 6 software engineering methods described above with a good degree of certainty. Just to be sure though it's always good to start writing about the project to be first. Start elaborating some details about the application to see if your answers to these questions stay consistent. With today's word processing software, you can allow yourself to start writing and rearranging later as needed so let's go ahead and start writing about our project. It's always a good idea to see if we can name our project too. Since we were asked to make a financial version of Autocad™ itself. Let's call it FinanceCAD. Throughout the rest of this series, I will be refering to our project by the name FinanceCAD.

DETAILING THE NEEDS:

With all this baggage of knowledge in our head, let's start describing FinanceCAD in a very general fashion and from that description we are going to see which method we should be using and why.

FinanceCAD is an Industrial Computer Aided Design (CAD) software application. The goal of this project is to reproduce the functionality of an existing software, Autocad™ in the features it will be offering the user plus allow to give the user an accurate list of materials, material quantities and the cost to build/create the design should the design be taking to the realization phase at some point in time. As such, it should have a given list of abilities (features) to make available to the user in some way, shape or form. As a general list of feature, it should allow the following:

Let's just stop right here for now and start analyzing what we've written so far. The description itself is pretty clear so far. Already we are talking about relationships (indirectly) between the different parts of the application. We are also talking about Entities. With these few lines of text we can already see which way the project is going. We are talking about an area where the user can create their designs, an independant list of shapes that the user can choose from to draw their designs. we are already talking about each of those shapes having the ability to assign a material to itself with the goal to use the length of the shape, with the material to create a cost for creating that shape based on it's length at the desired scale. We are also talking about the design arean having the ability to represent itself accuratly on a list of scales in relation to the actual scale the design should be created for. Already there is alot that tells us that we will be using an Object Oriented Method of somekind to analyze this project.

We've established all this from that small description we've written. You can think of this small description as quite unofficial however, you might have created this description in a notepad maybe after asking a few questions or even researching a few things on the internet. However, even at this very early stage, you already know which tool you'll need to get the job started. So there's no need to look any further.

IN CONCLUSION:

And this brings are first part of this series on Professsional/commercial Application development to an end. There's alot to digest in this first section so I hope you got yourself a big cup of coffee before you started reading this. In the next section we will be starting the Analysis of the project in much more detail working our way through the different documents you would typically need at the analysis phase of a project (described above) along with maybe other useful documents you can carry throughout the analysis phase. See you then.

MystikShadows
Stéphane Richard
srichard@adaworld.com
Download a copy of this tutorial: professionaldevelopment1.html


COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Two - The Details Behind The Problem

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Welcome to the 2nd part of this series. I'd like to start by doing a summary of what we talked about in the first part to get you situated. The first thing we did is define our problem (project) which is a financial version of Autocad™ we named FinanceCAD. We also looked at all the complete development cycle and the steps the entail. Next we described the different types of software engineering methods we had at our disposal to go about describing the problem at hand. Finally we started describing the project briefly and elaborated the right set of software engineering tools we'll be using to define the problem at the analysis phase of the development cycle.

In this second part of the series, we'll take it from where we stopped in the first part, we'll take the problem one step closer to it's solution by explaining everything that would happen in the analysis phase and see what documents are produced from that step.

WHAT HAPPENS NEXT:

Indeed, we can actually talk about what happens next because we now covered what happens first. So then, what does happen next? Do we jump right into the software engineering tool and get busy? The answer has to be no, for more than one reason. The main reason however is that you need to know what you'll be elaborating when you do use that tool. Going live into the modelling tool and starting to get everything into shape is like using the AdHoc software engineering method. You go in without a clear idea of what it is exactly that you are modelling so you model and create documentation after which is the backwards approach to software Engineering. At this point there are still things that need to be figured out before you can start the official modeling technique.

The Analysis Phase is defined by the documents that are needed. Indeed, Analysis means that you are at an unknown or unsure phase of the development. When you start this phase you don't even know if the solution you'll be proposing will be accepted or not and if you won't need to refine your analysis even more than you will be. Starting the modelling phase right away would be a waste of valuable resources at such an early stage. Therefore, let's detail the analysis phase documents so that we can create them. There are essentially 3 documents that should be produced here. These are:

As you can see, there's alot of work involved in the analysis. But when you think of everything that this work will bring to our project, it's very easy to see why this phase should not be overlooked and infact, investing the right time needed to accomplish this phase completely and successfully will help us a great deal in the rest of the development cycle. For the sake of FinanceCAD, we don't need the preliminary analysis since we already got the go ahead to produce the software right in our original email from the boss. So then, let's go about detailing what we can for our detailed analysis document.

Just remember that in the solution proposal document is where you should mention any kind of time related or cost related constraints. These constraints should be made clear, usually in their own seperate and independant sections. These constraint will greatly affect what happens in the rest of the development cycle so they should be made known as early as possible. Such things that they could affect are, for example, the number of employees you might need to assign to the project to assure that the project is done within the time constraint. Likewise, to fit in a cost constraint, you might want to try to get the most oart of the project done by programmers of lesser experience (and salary) when the tasks are routine and repetetive. This will help fit the project within a predetermined budget. This is why it's important to consider these contraints this early in the development cycle.

APPLYING THE THEORY:

Looking at what we've learned so far in this second part, let's put this into practice. The following is a definatly more detailed explanation of FinanceCAD. Although this description will be detailed, you have to remember that the description, at this phase shouldn't contain specific programming concerns or issues but rather should server the purpose of describing FinanceCAD in all it's steps it makes available to the user in order to accomplish a complete task which is to produce a design and a list of materials, quantities and prices.

APPLICATION DESCRIPTION:

FinanceCAD will be an industrial design application that will allow the user to create house plans according to local design standards. The main goal of the design section of FinanceCAD is to offer a set of commands that the user can either type in using some sort of command prompt or select from a menu depending on his or her background. The application will need to fully support the mouse and the keyboard to accomodate how the user would typically work. This application will need to have specific functionality while and after the design of a house or part of a house is completed to allow to attach materials to the design and calculate prices. Because of the fast changing prices of many construction materials, FinanceCAD will need to allow to change the current prices whenever the user notices a change in the current prices. The design mode will need to work with design layers so that Items can be added to the different layers based on the user's discretion or some set of rules, this will allow for a design firm to establish design standards that their employees will be able to follow easily. Here are the major features of the application categorized in functional groups.

DESIGN MODE FEATURES:

Design mode features are features that are available to the user while he or she are in the process of creating a design. The design mode is the central part of FinanceCAD as in this section is where all other parts of the application can be accessed from. This would typically mean that the user would setup a new design or load an existing one as a first step. Then the rest of the feature would be available.

DATABASE FEATURES:

Database features are needed as many designers could have the need to work on the same design for whichever given reason. Hence Some database features are in order to allow for two users to work on a project in a very safe environment.

NETWORK FEATURES:

In most firms today, a network is present and used at the firm's best advantage. FinanceCAD should not be an exception to this. In a typical network setup, all employees have access to their user space on the main server as well as a shared drive or folder where anyone can have access (good to communicate files between users). Typically designs are file driven as in each design is saved under it's own filename. The database that works around the design file need to be centralized so that management can oversee production of the design from any given location on the network. Therefore, the following network features and considerations are required.

REPORTING AND PRINTING FEATURES:

Indeed, because of the nature of FinanceCAD, there is a definate set of features that are mandatory for the proper usage of the printers available to the users. These features are there to allow flexibility to the user when printing a design and it's report as well as save time (and consequently money) by not needing to wait for a printer if it's not currently available. These features are:

COMPATIBILITY FEATURES:

In todays world, it seems that if an application of any kind is to be made successful, it will need to be made to work with a broad variety of other applications that can help the user in his or her many tasks. For example, if a design is created for a client, but that client doesn't have the software and would like to see the design in the software they use, then an export could/should be made available to allow the customer to see the given design. As such, here are the major compatibility features that would be required.

OPERATING SYSTEM FEATURES AND ISSUES:

The selected target operating system for FinanceCAD will be Windows XP. However, many design firms work with PowerPCs computers and others with the Linux operating system. Each of these work differently and are based on different sets of standards. Likewise, there is the strong possibility of porting FinanceCAD to those other operating systems. Because of these, the following features should be considered:

SYNOPSIS OF THIS ANALYSIS:

As you can see, this analysis is, as promised, more complete than the brief description I gave you in the first part of this series. It is not quite complete for a detailed analysis but I didn't want to bore you to death with a 200 page book to read. It's important that you take note that this analysis does cover alot of bases. It does give a good overview of things you might need to consider in your own projects when determining what the application can or should do. This is how this analysis should be taken. You'll find that in most projects of any considerable sizes you will probably find yourself covering the features and feature categories I've described here so you might want to take this list as a "check list" of things to watch out for, and things that will need answers in your analysis process. Everything but some of the reporting features listed here can apply to any type of development project so I think it's a good example even if it's not as detailed as it should be, it should still prove to be a great list to build the detailed analysis with.

In our case here, because we are creating a software based on another software, there are many questions that don't really need to be asked in this scenario. However in the case where you are automating a manual process of any kind, The sample analysis above should still give you a pretty complete list of things that you'll need to consider and elaborate on.

THE CONCLUSIVE WORD:

And this concludes the second part of this series. We've covered alot of ground so far and there's still alot to be done in the rest of this series. In the next part of the series, we'll conver everything there is to know about the conceptualization phase in all it's glory and details so to speak. this way you'll know what to expect at that phase too which is the purpose of this series to prepare you in the case such a big project is assigned to you so you don't loose your nerves and your last meal in the process. Happy reading, and see you then.

Remember that I am always open for suggestions on everything that I write, if you have ideas and suggestions about this series, drop me an email and let me know about it so we can make sure that you get the best documents and techniques that you can get.

MystikShadows
Stéphane Richard
srichard@adaworld.com
Download a copy of this tutorial: professionaldevelopment2.html


Final Word

Well folks, that was the APRIL issue of QB Express. Never mind that it's May. That doesn't mean I'm going to forgo the May issue just because I've already released one this month. The real May issue will be out by the end of the month. I know it's a short turnaround time, but even if I don't get a huge amount of submissions, I think I owe it to you guys for making you wait so long for this issue. We're gonna get back on schedule.

If you're interested in submitting something -- anything -- for the next issue, please get it in soon. I'll post the deadline at Pete's QB Site forums in a few days.

Thanks again to all our contributors for another great issue! Let's repeat it next month!

Until next time...END.

-Pete


Copyright © Pete Berg and contributors, 2005. All rights reserverd.
This design is based loosely on St.ndard Bea.er by Altherac.