Issue #9 ~ May 10, 2005
"A magazine by the QB community, for the QB community!"
In This Issue
- Pete (Editor)
- Lachie Dazdarian
- Vincent Peters
- Jonathon Wallace
- Adigun A. Polack
- Jorden Chamid
- Joseph Burke
- Mike Wechsler
- Joseph Burke
- Regular Columns
- Articles & Editorials
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.
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 email@example.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!
Letter From Joseph Burke
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
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
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!
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.
Letter From Lachie Dazdarian
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.
Letter From MystikShadows
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:
- The reader base is definitaly growing like you mentioned. I don't need
to see the traffic stats of the magazine to know that.
- 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
- The users are reaching programming directions (in their projects) that
need more and more specialized knowledge at hand to help them complete their
- The community is definitaly more alive than ever, and more kicking than
ever before too.
- 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.
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 :) ).
Letter From Lurah
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
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
And of course, as you probably can guess from url, it's a ASCII-Demo
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
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.
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!
Letter from Rattrapmax6
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..
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.
Have a letter for the editor? Send all your rants, raves, ideas, comments and questions to firstname.lastname@example.org.
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 email@example.com 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.
- 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.
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.
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:
- New alien race attacks earth. Larry must stop them!
- 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!
- 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.
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.
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.
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).
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.
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?
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.
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.
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
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).
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.
It's catchy. It excites me.
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:
More ingenuity is required in this area.
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.
The idea draws it up, excecution takes it back down again.
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.
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:
It doesnt have any, but it would've been nice if it had.
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.
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?
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
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
A> At what point did you notice a community of programmers who called Future
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
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
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
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
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
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
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
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.
"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:
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. :)
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. :)
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 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'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 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)
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!
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.
- Theme must be summer related in one way or another
- All Basic Dialects are welcome (DOS and Console Windows or Linux)
- Maximum Compiled size must be 1 Mb or under
- You can include sound and music files (not part of the compiled exe)
- All ASCII / Text only, no graphics mode (ASCII Graphic characters allowed)
- Maximum Demo Length should be between 2 and 3 minutes.
- Demos are demos, not games, tools, utilities or applications, but
- 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.
- Music and sound don't have to be original creations, but they could be.
- 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!
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. :)
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...
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.
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.
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.
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.
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.
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.
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.
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.
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. :)
- Plan small - its easier to start too small and have it grow, than to start too big and be forced to cut
- Keep it simple - Both you and I know that some of the funniest games(still!) are quite simple in every aspect.
- Keep it fun - For every thing you plan/implement, you should keep in mind why its vital to the fun of the game.
- 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.
- Send all proceeds to my address at......no, just kidding, actually send any and all comments/thoughts/counter-rants/and insults to my email firstname.lastname@example.org.
Thanks for reading! (Look below for a challenge based on this article!)
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 - email@example.com (no, an RPG won't score you brownie points =P)
This article was reprinted from this address.
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
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 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!
Written by Rattrapmax6
Rattrapmax6 returns this month with another Horse Humor Comic.
I.F. Games Chapter 4:
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.
Declare Sub prntStr(a As String)
Sub foo (a As String)
Sub prntStr (a As String)
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:
- 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.
- 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:
Const MAXEXITS = 10 ' Max number of exits in a location.
' Type for exits:
w as String * 2 ' Exit name ("n", "nw", "up", "dw", etc...)
go as integer ' Which location this exit connects to.
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.
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!"
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
f% = -1
' 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 = ""
' Clear fixed objects: (see notes below)
' 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 + " "
' 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
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
f = -1
' 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
f = -1
' And we are done! Close the file:
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
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? ;)
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
LM.GetExit = res
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.
' * 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:
' Testing the location manager
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:
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.
Wet and somewhat muddy.
Populating all over the place.
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.
Made of stone.
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?
Your house is very small but really comfortable.
A thick, wooden door made of old oak.
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 ;)
Visit Los Monos del Obús or contact Na_th_an.
ACCEPTED DOS/CONSOLE COLOR USAGE
Written by Stéphane Richard (Mystikshadows)
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?
- Free Style Text Editing Screens: [7 - White / 0 - Black or 1 - Blue]
Here you have your text editors, word processors and other application that would allow any type of free styled text entry.
The suggested color combination above was selected because they are not to harsh on the eyes. Since chances are the user will produce
fairly large files from these applications a soft combination of colors like those suggested were best due to the long amount
of time that would be spent by the user in front of his computer.
- Tabular Data Screens: [7 - White / 0 - Black or 1 - Blue]
Here you have your spreadsheet programs, database applications and the likes. In many database applications the user will find himself at a list of things when he or she starts the application. For the same
reasons as the text editing screens, the same color combinations were accepted mainly due to the amount of time, in a day, that the
user would find himself in front of that tabular data screen.
- Data Entry Screens: [0 - Black / 7 - Gray]
Again in the database applications mainly. Typically, users, when they select something from a list, a screen showing all the details
of the given selected record would appear allowing them to view or edit the contents of the data itself. This color combination was selected
because mainly it gave good contrast with the main tabular data screen while still remaining fairly easy on the eyes. Specific fields would
have a Gray or Cyan Background color to visually show the user where data entry is expected on the screen. The main keyword here is that
Data Entry screens were screen that affected the physical data in a database file.
- Database Interrogation Screens: [0 - Black / 3 - Cyan]
These screens would typically give the users a means to search for a specific information in a database. They would offer different
fields where the user could enter his or her search criteria. A cyan Background was selected to help the user differentiate a screen that
affected the data with a screen that did not even though the same field names would typically be used when inquiring for a search criteria.
- Generated Report Screens: [0 - Black / 7 - Gray]
Accounting Software, Financial Analysis Tools, Statistical software, Mathematical software and database reporting software. When an interrogation
to the database was made, or when a specific business report was asked for by the user, the results would usually be shown in this color combination
because it was a good immitation of a printed report on paper. That was the main reason and it had the intended impact on the user in that they
assumed that the report they were seeing would be something they could view as if it was print.
- Help And Information Screens: [15 - Bright White or 14 - Yellow / 3 - Cyan or 2 - Green]
Pretty much any applications but mostly database related applications. Help and user feedback were usually in these colors as well as a Magenta
background because again of the contrast with the blue or black background of the typical Main Tabular Data Screens but also because these colors
seemed to give the impression that help is on the way. Note that these screens only gave somekind of information to the user and were usually mean
to make the user correct his mistake or change the whole field values to the valid expected possible values.
- User Assistance Screens: [15 - Bright White or 14 - Yellow / 5 - Magenta]
This particular type of screen wasn't found very often. But it did exist. Assistance screen typically instruct the user into the steps to follow
and direct them through the given process. For example, this color was used in interactive tutorials that used the given environment or program
to show the required steps live in front of the user. Purple known to be a color of wisdom and knowledge and I personally believe that it's the reason
why it was selected for such a role.
- Error Message Screens: [15 - Bright White or 14 - Yellow / 4 - Red]
Red was the chosen colors mainly based on the traffic light principal of Red means Stop. This combination stands out from
any other color combinations quite easily and can definitaly catch the attention of the user very easily.
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.
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.
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:
FOR a = 1 TO 10
FOR x = 1 TO 10
aa = sin(a) * a ^ 3 + x * 2
FOR a = 1 To 10
suba = sin(a) * a ^ 3
FOR x = 1 TO 10
aa = suba + x * 2
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
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:
IF … THEN
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”
Save it as “C:\TEST.TXT”
Now we start for real. Open your favourite FreeBasic editor and start to type the following code:
SCREEN 12 ‘Yes we work in an old dusty/trusty screenmode
OPEN “C:\TEST.TXT” FOR INPUT AS #1
LINE INPUT #1, LineOfCode$
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:
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
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:
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:
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$
PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8);
PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8)
Since our code must run more than one line we have to add a loop. So now our final code looks like this:
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$
PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8);
PRINT MID$(LineOfCode$,8,instr(8, LineOfCode$, CHR$(&H22))-8)
LOOP UNTIL EOF(1)
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.
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: firstname.lastname@example.org
Download a nice Word version of this tutorial, or email BazookaSquirrel.
Effective ASCII Development
Written by Stéphane Richard (Mystikshadows)
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
- What kind of program am I really making?
Believe it or not, many people make a common mistake at this question. To give you a good example
Take the Pascal language. Borland created a pascal programming environment that was based on speed
of use and high compilation process. On the other hand you have Brad Templeton's Personal Pascal who's
main goal was to provide an environment that also teached Pascal and Assisted in the development of
pascal projects. Both resulted in a compiled executable file, both offered a very different means
of getting from a source module to a compiled application using the same Pascal programming language. For
this reason, this question warrents time and reflection to make sure we know what we want to create.
- What does the user expect to see?
This is, of course, based on the tpe of program or game you are making. Since computers have been around
for a while now, you can safely assume that people might want to see certain things based on the type of
application or game you are making. For example, let's say you are making a text editor. Regardless of the
user interface you want to give your application users will ultimate want to see some means of copying, cutting
and pasting their text to rearrange them at will, they would also hope to find a menu option or a button that
would allow then to open and save files. You just have to sit down and write down these things that people
would expect to see in your program. That's a great way to start your programming project the right way. Also,
don't be affraid to ask around. There's forums all over the place filled with potential users of your program
asking them what they want to see is a good means of knowing what to include in your program and raising the user's
interest in what you are creating.
- How would the user expect things to work?
This questions is sometimes easier to answer for a given type of programming project. Today it's safe to assume that text
editing program should have mouse support and pull down menues. But if you are creating a game, the type of game can have
a huge impact on the way that they options should be presented to the user. This is usually answered based on the context
of the programming project and the general style you'll be giving your application or game. In some types of game a simple
option to save the game directly available to the user is great. In other games you might wnat to user to make it far enough
in the game so that they need to discover where the game saving option is. As in, put the game saving option in a given room
or area of your game. Both these methods can work effectively but in some games, the last method (to let them find the place
where they can save their games) can definitaly add to the game play.
- What kind of colors would be good to use?
Ah yes, colors, what do they do? What's the best way to use them? This is always a big question because for alot of reasons
potential users of your application will include color schemes into their evaluation of your game or application. Is everything
easy to read and understand or do some parts of your project seem to strain the eye? I would say this is a good way to start
evaluating your color combinations. Asking directly is definitaly another. Users will tell you what they like or don't like about
the colors you chose for your program and this way you can quickly make corrections to your colors as needed (the earlier in the
development process the better because you can make those changes quicker). Just remember one thing, consistency is the key to a
successful color combinations. If your menu is white on a blue background it will be a great idea to keep all menues in a game white
on a blue background.
- Would the programming project benefit from some kind of standarization?
In 80% of the cases, maybe more, this question would typically apply to applications more than it would to games because games are usually
100% creativity. The type of standarization I'm talking about here are more on the user interface part and well let's face it, today,
with IBM's S.A.A. (Standard Application Architecture) with it's C.U.A. (Common User Access) standard that was created in 1985, most business or other types of applications
would usually benifit alot from such a standard if not for anything, for a very shortened learning curve. I don't remember the game,
but I've seen a game that really took 100% advantage of the S.A.A. standard and that game was quite fun to play. So I have to mention
that indeed, in some cases, games could benefit from a standard. Therefore you can definitaly take the time to think about what such
a standard would add, or take away, from your games as well as your applications.
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.
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
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
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.
- What kind of program am I really making?
Remember the discrepencies between Borland Turbo Pascal and Personal Pascal I mentioned above? The same could applu here as well. For example, we
could decide that the main purpose of the game is to destroy a swarn enemy's fleet and ultimately his planet to really rid yourself of him and his kind. You could decide
that this game would only offer exploration and scientific missions. In the case of Starfleet 2 - Krellan Commander you are not the good guy, but the enemy (the Krellans)
and your objective is to invade planets that have an atmosphere you can breath. In the process, if you encounter the good guys, you can and should destroy them especially
if they are planning to intercept and stop you. As your exploring and invading you will encounter allies and enemies as well as all kinds of space related items like stars,
planets, black holes and others. All this will need to fit in the gaming concept.
- What does the user expect to see?
Let's see now, being a space game, space things are more than likely what the user will see. They might also expect to find unknown planets that could be inhabited or not. They would
typically probably like it if they could get a sense of familiarity as in knowing if they've been somewhere or not. I believe they are the bad guys, they might expect to torture the enemy
being they are probably more cruel then us evolved humans. They'll want to take over worlds just because they have the power and the technology to do so and their home world is vastly
over populated. There's more to it. But in essence, this is a good description of what could be seen from the user's perspective. It certain seems to have been the intension of the author
of the Starfleet 2 game as well.
- How would the user expect things to work?
Here the first thing you'd probably need to remember is that this is a "Futuristic" strategic space simulation. As such, the first thing they would probably expect is a futuristic user
interface, an new way of doing things they've never seen before because it hasn't been invented yet. So when you give the user his options, you'll need to keep that in mind. If you took
a look at the screenshots above you can see that although all in ASCII the interface presents some pretty inovative ideas and functionalities. This is one of the main reason I selected
this game, it really lives up to it's gaming concept. All the screens, and all the required user input is all based on the fact that this game happens in the future but it is dealing with
today's human player. This is a perfect combination to give you the impression that you are in the future but almost instinctively know what to do next.
- What kind of colors would be good to use?
Again keeping in mind the gaming concept, it seems that for this game, the trends won for the color combinations used in Starfleet 2. For example, looking at the majority of futuristic movies
the likes of Alien, the Startrek Movies, Star Wars, and other space related movies, everything you'd see on a computer screen seems to be shown on a black background color with red text for
red alert situations, blue for standard operations and the likes. Starfleet 2 is no exceptions, everything is on a black background however a bit of intelligence was used where the current item
being used is in highlighted colors and the rest of the interfaces are in darkened colors. This is a visually easy way to tell the user where he is on the screen and therefore help him know where
to go next. This combined with some great ASCII futuristic ASCII computer consoles gives the game a very futuristic look and feel that the user would definitaly expect from a Futurist Strategic Space
- Would the programming project benefit from some kind of standarization?
As I mentionned there are indeed standards, and many programs, even games, can benifit from those because these standards have been created for a distinct purpose. However, for the reasons I explained
above (with the game being futuristic and therefore almost needing to present a never before seen operational system) Starfleet 2 would not benefit at all from any such standards. In fact, given a game
of this type a standard user interface would probably kill the game because users could not associate a futuristic game with a "contemporary" user interface. It's just human nature to expect these kinds
of things when engaging in a futuristic game. So for those of you wanting to really revolutionize the futuristic game industry. This is the perfect kind of game to really let yourself loose and go wild
on how you create your user interface. Be as creative as you want, be sure to ask for feedback too, that's always important because the players are the ones that will be using your game, not you. No matter
how creative you get, remember to be consistant however. Create a radically new concept but keep it the same concept throughout or you will loose your users, at least some of them.
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
- A Title Screen:
Indeed this is usually the first screen to appear when the executable file is started. It presents typical information about the program
such as a game logo (if any), the name of the game, the version, copyright information and the likes.
- A Main Menu Screen:
This is, as the name implies the central place where other options, including playing the game itself are usually offered. Presentation here is
just as important as presentation in the rest of the game. Styles and standards should be respected here as well as being consistent with the rest
of the game.
- A Main Game Screen:
Just like it says, this is the main screen. This screen usually offers a general view of what's happening at the moment in the game and gives access to the
other screens of the applications.
- Alternate Gaming Screen:
These are other screens, acessible from the main screen that can present new types of information or require user input before the screens can be exited.
Each screen here are usually organized by tasks, it's a widely spread technique that has been popular for a good long while. In starfleet, an example would be the navigation screen which severs no purpose other than to
travel from point A to point B. There are others too.
- User Interaction Screens:
These are like the Alternate Game Screens as they are usually accessible from the main menu or the main game screen. These screens are screen that "require" input from the user, in one form or another, to perform a given
- A Multiple Endings Screen:
I say multiple here because typically there is at least two endings to any game. There is the ending where the player successfully completes the game and the screen where the player dies from unforeseen circumstances.
- A Credits Screen:
Scrolling or not, this screen is probably the most important of all screens in a game. Don't forget the hard work you, or your team put into the creation of your game, and don't be shy to brag about it either. it will get
you known and people looking at new games you release will remember how your past games were.
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
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.
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:
Print "Debug Value"
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
'Turn off debugging
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:
Print "Production Version"
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:
Print "Test Version"
Print "Production Version"
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:
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)
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
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
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:
This first step is where you take the time to gather the information you will
need to get things started, usually it involves meetings with the potential
users to gather the user requirements. I've been to a place where the users
wrote their own requirements in a standard document format. It allowed them
to really detail what they wanted and how they wanted things to work. In other
cases you need to ask questions if you want to get answers. At this stage, you
will be creating a preliminary analysis, a detailed analysis, and a solution
proposal as well. All these will be covered later in this first of the series.
- Software Conceptualization And Design:
You have your detailed analysis at hand, the proposed solution has been accepted, you are
now read to begin the project. Does your project need database capability, if so, what
capacity, which database, elaborate the table structures from the detailed analysis that
you built in the Analysis phase. does it require special hardware requirements, which
operating system will you be developing this for. There are many software engineering
methods available to help answer these questions, and more. we'll see what they are
later in this document.
- Software Development And Implementation:
This where the actual programming begins. In the two steps above you would usually have time
to determine which programming language you'll be using and can start developing the application
itself. This entails screen designs and the programming of these designs. Typically the scren
designs can be defined with the help of the screen layout, the navigational specifications and
the functional specifications. We will cover those elsewhere in this series but the names might
already be ringing a bell in your head right now.
- Testing And Debugging:
Ah yes, the dreaded testing and debugging phase. feared by many among us. This phase in
unevitable. However, there are tools to help us out here too. There are different types
of problems that can occur and each should be treated differently. Alot of this phase depends
on how the first 3 phases of the project went. With good planning, and good software design
methods, many of the bugs can be eliminated at an early stage. However there will always be
a testing and debugging phase nonetheless.
- Installation And Integration:
There are always nightmares about what will happen when you install the application on the
user's machine. Time and time again I've installed a program on the user's machine only
to find that the machine couldn't boot anymore because of the program I installed. This
is a grey region as it's called because it can influence what the user thinks of the
application and you. With the right tools and preparations you can ease yourself of this
useless stress quite easily just by taking the right precautions. We'll see what I mean
elsewhere in this series as well.
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:
- The AdHoc or Improvised Methods:
This methods consists of no particular methods per se. Everything is done almost seemingly backwards
where code is created so testing can begin, design is created based on the code created and everything
is seemingly burried in documentation. You can clearly see that this method cannot be used in this
project of ours.
- Functional Decomposition And Structured Methods:
This entails the methods that are based on functional decomposition and stepwise refinement; the
breaking down of complex systems into single-function tasks and subtasks. These were the first of the
analysis methods to be developed. The analysis (data flows) tended to concentrate on the business
flow (which was generally manual in the beginning). The data was simple (integers, float/real, and
characters were the only data types to worry about) but the processing (the work being done with or on
the data) would typically get very complex. Some extensions were added later specifically for real time
embedded systems and concurrent processing. A few examples of these methods are: CSD (Composite Structured
Design), CORE (COntroled Requirements Expression), DARTS (Design Approach for Real-Time Systems),
DCDS (Distributed Computing Design Systems) and SADT (Structured Analysis and Design Technique).
- Data-Structured Methods:
These are methods which are based on the decomposition of complex data. Used usually for systems that tend to be
mostly databases and the modification of how that data was presented to the user. Data-Structured methods evolved
pretty early in the history of software engineering and basically overlapped the Functional Decomposition methods.
Depending on the project at hand engineers usually used one or the other of these two methods. This
techniques tend to start with the desired output and work backwards to the desired input. Data-Structured methods
were prefered by developers of Management Information Systems, where the data is more complex than the processing
on the data. A few examples of these are: DSSD (Data Structure System Design), JSP (Jackson Structured Programming)
and LCP (Logical Construction of Programs).
- Modelling Methods:
These techniques treat all system functions as parallel processes as in they could all theoretically happen at the same time.
They were first developed for controlling trains, elevators, and other controlling devices. Originally, the techniques created
a concurrent conceptual model, which then had to be converted into a sequential implementation model (to simulate concurrency) because
of the available computer technology at the time as computers became able to multitask and computer languages began to support concurrent processes like Ada tasking models
this methods could be used more and more often. there's two well known examples of the Data-Structured Methods which are: JSD (Jackson System Development) and
PAMELA (with the PAMELA II to follow shortly after).
- Formal (Mathematical) Methods:
As you might have guessed, these techniques build on the early math foundations of computer science. Mathematical proofs are used as a
form of verification of the system. Because of this, they are frequently used on safety critical or security critical systems such
as nuclear power plants, life support system and national security systems). Although mathematical in it's roots, these techniques
don't only rely on mathematics, they offer a wide range of analysis tools that allow you to do your job the right way. Examples of these
techniques include: CSP (Communicating Sequential Processes), HDM (Hierarchical Development Method), HOS (High Order Software), RAISE
(Rigorous Approach to Industrial Software Engineering) and SARA (Structured ARchitect's Apprentice) to name a few.
- Object Oriented Methods:
These Techniques tend to go about describing a solution to a programming project in a very different but somewhat more familiar fashion.
Everything in the process is an object entity. each object has properties (that describe the objects) and methods (that define what
the object can do). Objects also have relationships to other other objects in a hierarchical fashion. There are many different types of Object Oriented Methods, some more renouned than others. Here's a few examples
of these methods: HOOD (Herarchical Object Oriented Development), OMT (Object Modeling Technique), OPEN (Object oriented Process, Environment
and Notation) and of course UML (Unified Modeling Language).
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:
- What Is The Common Denominator Of The Project:
A denominator, in this context, is merely trying to find what the smallest unit of description that can
be isolated from the rest. when I describe the many features of the application software to be, do I
talk in objects or entities, in functions or actions to take, in expected results or do I usually describe
concepts more than actual physical concrete steps. Do I describe the project as modules (parts of the
whole picture) or do I push the description more towards the bigger picture? When you get to the smaller
steps, what type of description do you use to explain them?
- What are the Sub Items Of The Common Denominator:
The combination of this question and the previous one will guide you alot. For example, if we would talk about
entities being the common denominator as in, when you talk about each general concept of the project you usually
describe the as something you can describe and something that can do things. Then chances are Object Oriented
Methods would be the way to go. If the common denominator is more of an expected result with an idea on how to
get that result, then functional decomposition might be the direction we should be taking. However at this
question in particular, you might still be talking about a module to module basis where each module would have
a set of specific procedures and functions. The next question can clear that up for you.
- Is There A Relation Between Each Common Denominator:
This is what splits the methods one step further. If each module tends to work in an independant way and you
don't foresee any module needing to communicate directly to any other module or being dependant on another
module for any reason then perhaps you are not talking Object Oriented after all. In this case a Data Structured
or Modeling Method might be better suited for the task. If however you always endup talking about how each
module can be composed of other modules, or each module are part of another "bigger" module. Then Object Oriented
Methods would be the direction to take.
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:
- To allow the user to specify the scale of measurements to use in the design.
- To draw the generally known basic shapes such as circles, lines, rectangles, triangles and others.
- Allow to calculate the length (in the selected scale and in the realistic scale) of any parts of the design being worked on.
- Allow to define what materials are to be used on each part of the design, the standard length and width the material comes in and the price that material currently cost to purchase.
- All this should be accessible easily and quickly regardless of where, in the application, the users currently finds themselves.
- A printout of the design, and optionally, the list of materials and costs should be available at any time.
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
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.
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)
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:
- The Preliminary Analysis Document:
this is the shortest of the 3 documents. The preliminary Analysis Document is created in order for you to present
the problem, or the project in this case in the way you see and understand it. You might have talked abit about the
project to a few potential users of the application to be, you might have done research to find out what Autocad™
really is, get details on the features offered by the program as well as it's limitations. You might have played with
the program to reproduce to get a feel of how things work, how things are presented to the user how to get to the functionality
the user could want to accomplish and so on. Once the research is done you start to write what you've discovered about the
project. What you believe (at this early a stage of analysis) would/could be needed to create the project. However this is
an early stage and you shouldn't go into to many details here as far as what language you'll use, what software engineering tools
you'll be using and other specific details such as cost of the project. These will need to be supplied but they are presented in the
Solution Proposal Document typically. This first document is typically presented to administration in order to get the
green light to really get started the project. Hence create the Detailed Analysis Document Explained below.
- The Detailed Analysis Document:
In a typical situation where you start with a manual process and attempt to automate it with a software solution. This document explains
the flow of information between the different parts of the manual process. A good way to go about collecting information for this document
is to talk to the users first. Many times, in a manual process, people at different steps of the process might carry notes with them, custom
list of things depending on the job they are assigned to do. You have to think in a 3 step process at every step of the manual process. the steps are:
Once you have asked all the questions and decide that you have all the information you need to explain the process (or project in our case) in all it's infinite details, you can
go about the creation of the detailed analysis document which consists of taking all this information and presenting it in a chronological and organized manner. you can selected
the type of organization you'll need for the detailed analysis as they may vary depending on the type of process you are automating. The best way to go, usually, is to take the
manual process, detail it as detailed as what you have accumulated required inputs, work and desired output. Starting from the beginning of the process, the first steps and working
your way towards the end of the process explaining how the information travels from step to step, what each step does with the information it needs or how each step affect a central
piece of information and what it needs to create for an output before the process can go to the following step. It is at this phase that you can start using the software engineering
tool you selected if not for anything, to organize all the information you'll be collecting into functional groups or entities (in our case). Another thing you'll need to consider
when selecting the software engineering tool to use is how far into the development process that tool will take you. Some tools won't take you very far in the development cycle as
they are design to document more than cenceptualize a problem. Others can take you all the way to the conceptualization phase and even beyond in some cases. For our sake we'll be using
UML since it does take us right down to the conceptualization phase easily.
- What information is needed prior to executing this step of the process?
This is where the "Flow Of Information" comes into place. you can use tools that allow you to draw Data-Flow Diagrams
to help illustrate the flow of information in a given process. Typically, for a process to go smoothly throughout it's many substeps, clear information
is needed to travel through the process, something in different forms, and arrive at the end of the process with the right results.If you cannot
define this clearly enough in one set of (Input, Work, Output) you might want to consider breaking the step into substeps. In a typical example, employees,
before creating a shipment might need to know what exactly a customer is buying (an invoice typically). You'll find that in all types of manual processes, there
is usually always somekind of information needed to perform a step in the process. Sometimes it's one document that travels as is throughout the steps, sometimes
that documents gets transformed into another with specific information needed for the next step of the process. In our case, the input needed might be what kind of
house to create the design for, for example.
- Does the process change or perform work on the information it requires?
You have your required information, the next logical thing to explain is what exactly your are doing with that information. You have an invoice for example, you
are in shipment, you'd usually gather the products of the invoice and get them ready for shipping, if something is missing you'll notify someone so they can decide
what to do about the missing items, etc etc. In another situation, you might want to take that same invoice in order to call the customer (if you're in the sales
department for example) and ask them what to do if an item is missing. No matter what the situation, there 's work to be done with the information you needed or
the information is irrelevant to the process and should be discarded right away. In our project's case this could be, as an example, the designing of the house based
on the description of the house we received from the customer.
- Does the process produce an output that is needed at the end of the step for the next step?
Still staying in our typical example, when you have an invoice, you gathered the products of the invoice, what output could be produced? How about a packing slip
so the customer can verify what they ordered (with their invoice) compared to what they received (the packing slip) to make sure everything is in order and that
nothing is missing. This is in a typical scenario of course, there are definitaly changes depending on the specific manual process to automate. In our case, this would
typically be the designed house with the list of materials and costs.
- The Solutions Proposal Document:
Sometimes there can be only one way to solve a problem. Other times there are several ways to solve a problem. Part of the analysis, especially towards the end is to define all the
possible solutions to the problem (since we have all the details of how the problem or process currently works) and analysis what the pros and cons are for each of those solutions (you can
determine the pros and cons yourself or with the help of management and/or the users depending on the process. When you have weeded out the the best solution you mught want to include the
2nd and 3rd of those solutions explaining the different impact each of these solution has as far as time lines and costs are concerned. This is, in essence, what the solution proposal
document is for. To give management (in most cases since they will be the ones to accept the solution or not and give you the go ahead to it's realization) so that they can, in a very informed fashion,
with the help of the detailed analysis, decide upon creating the solution, maybe bringing a few changes to the proposed solution, and make the ultimate decision to create the solution or not.
Remember that as a consultant and the "specialist" of this project, you need to make sure that there is no existing solutions to your problem already available somewhere that might save your company
time and money. In our case we're developing a commercial product that will be sold so there is no existing solution unless you could buy the rights to using the Autocad™ source code directly. in the
example we talked about above, there are hundreds of billing software available that also produce a packing slip so maybe one of those could fit the needs perfectly and it's your responsibility to inform
your boss that it exists and how well it does answer the needs of the problem at hand.
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.
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.
- The unit of measure and the scale of a design could be set at the beginning of the design and/or changed anytime throughout the design and have all measurements recalculated according to the new scale and/or unit of measure.
- Allow the direct design of parts of a house or the whole house using primitive geometric shapes such as circles, ellipses, arcs, squares, rectangles, triangles, and other basic geometric shapes.
- Each item added to a design (simple shape or complex built shape) can have a specific color scheme. This can be either set as the design is built or in a general fashion from a screen to allow to build color standards for all designs.
- Should allow to "script" commands to build specific more complex shapes and give it a name for future reference. This way, enormous time will be saved as typical components can be directly loaded instead of created each and every time.
- Each shape or complex shapes should have the ability to have a material applied to it's design thus allow for length calculations and ultimately prices as well.
- the system should allow for both mouse and keyboard input as some users are used to using the mouse while other may be keyboard driven in their operations.
- Assuming the design of a complete house, bricks, insulation, wood frames, electricity, plumbing and other categories of components such as these should be put on different layers, as needed, for the sake of clarity of the pricing report.
- standard symbols should be provided to the user for items that need to be according to some specific local or global standard that must be applied to designs that use these standards.
- The user should have some means of creating custom, often used shapes and symbols. For example, in an interior design firm, furniture of all types could be designed and simply inserted into new designs recalculation Units of Measures and Scales according to the scale and unit of measure of the design itself. The time gain of such a feature would be tremendous.
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.
- Through the use of a design table, design files could be made locked by a user so that when a 2nd user opens the same design, he is warned that the other user has locked the design. This would make the design opened for read only purposes and could not be saved under the same name.
- Database query feature could be used to allow for flexible search criteria to be applied to a query and return valid designs for the applied query only.
- In the corporate world, not many things happen without a customer somewhere in there, so a list of customer to which design can be assigned to would prove a valuable feature for obvious reasons.
- Each design should have an optional field to give itself the need to be approved prior to allowing to print the design and send it to the customer. Many firms work this way and they have good reasons to work this way.
- The material and items pricing list should be independant since in most cases they are treated independantly and typical purchased from different suppliers as well.
- When a design request is created in the database system, the option to directly assign the design to a designer should be made available. This option could be changed at will should the need to change the designer occur.
- The designers should have the ability to add notes and work progress to a given design in such a way to give feedback on where the design currently stands.
- Once a design is given the status of closed or completed, it shouldn't be allowed to be changed unless mamagement or an appointed employee makes the design available for editing once again.
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.
- The database will be centralized on the server at a location decided upon by the management.
- FinanceCAD will need to connect the user to the central database with the user's name and password.
- In the case of network failure, the user will be able to work locally with his own copy of the database.
- Database synchronization methods will need to be in place so that the central database can be update with new information as soon as the network is made available to the application.
- The detection of the network presence and the database presence on the network should be invisible to the user unless the application cannot connect to the network or find the database where it should be located.
- The principal of semaphores should be applied to allow a control of network traffic from the users to the central database.
- If a firm works by confirming or approving designs before printing can occur, the verifier should be notified (by email or other means) that a given design is ready for verification.
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:
- A typical firm will have printers for reporting and plotters for design printing, this should be configurable from FinanceCAD.
- Different parts of a complete design and pricing report should be selectable to be included in the final printing as not all the parts may be required to be printed.
- Because of the different modes a printer can be set to via software, each printing session should start by resetting the printer to it's default settings so that there is no mode conflicts.
- The ability to select one or more design and reports to be printed should be available to create print jobs that could get printed overnight to save time.
- The ability to change the prices used in a cost report should be allowed at the design level or at the general level. This means prices could be changed just for the given design, or changed for all the designs as a new pricing list standard.
- Although printers and plotters to be used can be set globally or specifically for a design, the option to change which printer or plotter to be used should always be made available (in case of printer failure for example).
- The user should have the ability to create himself or herself custom reports on the fly to help them in the design process whenever the need is felt.
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.
- Although are native file format will be proprietary to FinanceCAD itself, imports and exports to all "popular" design software file formats should be provided for added flexibility. these format should atleast include Autocad™ and Key Software's 3D Home Designer which is what is currently being used inhouse.
- Databases and tables should be exportable to standard comma seperated format for usage in the customer's other applications needed for their own purposes.
- Reports should be exportable to Excel format, Lotus, Quattro Pro, All popular Word Processor table formats and PDF.
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:
- Wherever possible in the development phase, we'll need to avoid creating operating system dependencies if at all possible, this will minimize the work involved when porting FinanceCAD to the other targetted operating system.
- The use of a higher level, multi-platform GUI library is strongly recommended. There are 3 highly recommended choices, the are the Qt library, the GTK library and wxWindows, all capable of creating similar GUIs for different platform in a very independant and self sufficient way.
- The local space for the database will need to be set globally on a per operating system as linux, for example, won't allow access to some parts of the harddrive unless the user is logged in as administrator which is usually and typically not the case in a typical linux system scenario.
- When saving a design, because of the text command nature of the file format, the user will need to be able to select the text file standard to be used when saving. Carriage Return plus Line Feed for Window based systems and just Carriage Return for Linux based systems at the end of each line.
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.
Download a copy of this tutorial: professionaldevelopment2.html
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.
Copyright © Pete Berg and contributors, 2005. All rights reserverd.
This design is based loosely on St.ndard Bea.er by Altherac.