Issue #11 ~ June 21, 2005
"A magazine by the QB community, for the QB community!"
In This Issue
- Pete (Editor)
- Matthew R. Knight
- Lachie Dazdarian
- Sumo Jo
- Gianfranco Berardi
- Sebastian McClouth
- Regular Columns
- Articles & Editorials
From The Editor's Desk
Written by Pete
Hey hey hey -- so here we are again. Another month, another issue!
This month we have a particularly excellent issue. For the first time in a while, I think that the Articles and Editorials are just as strong as the Tutorials in this issue. Matthew R. Knight brings us a funny and interesting personal narrative about "How [he] got started with QB", we have reviews of ASCII Scrolling Map Maker 1.0 and FB Sokoban, as well as a review of Astral Worlds in Lachie Dazdarian's new series "Searching For The Unknown". We've also got Project Updates on Qbinux, RapidQ & Legend of Aquarius, and an extensive preview of Syn9's The Griffon Legend in the gallery. Finally, there's an editorial by mennonite on flaming, a Where Are They Now? article about GBGames webmaster Gianfranco Berardi, and an interview with Sumo Jo by yours truly.
As for tutorials, Deleter has brought us an extensive theory article entitled "Ecosystem Simulation Through the Use of AI", Moneo has created a spin-off of MystikShadows data validation tutorial entitled "Data Validation Implementation", dumbledore dishes the dirt on "Using WX-C In FreeBasic", and Pyrodap informs us on how he makes random Roguelike dungeons in his RMG Roguelikes tutorial. Also, MystikShadows has returned with the final two installments of his Professional and Commercial Application Development Series, Testing and Debugging and Installation and Integration.
Plus all of the regular columns you're used to seeing every month -- News, Awards, Rattrapmax6's Comic, and more!
A great collection of truly great articles -- that's what QB Express #11 is!
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 firstname.lastname@example.org. You can also PM me on the Pete's QB Site or QBasic News message forums. Or you can contact me by filling out this form on my website. If QB Express is going to continue to be so good, YOU need to contribute!
Letter From MystikShadows
Hi again Pete, I'm back as you might have noticed ;-). Not sure you wanna make a news item out of that though lol. But it's good to be back :-) finally. lol Come on, did you think i'd let a 10 day absence from the web stop me from having something to say here? LOL
First, I think you, once again, outdid yourself, you put QB Express #10 in a record time even if it was a big issue, I think you're developing some tricks of the trade so to speak cause QB Express is polishing itself with every single release. You sure know how to put your thoughts into words in such a way that we see and understand what you're talking about as clearly as you do ;-). that's quite a talent to have. The articles in #10 were great (no not just mine ;-)) everything in #10 was absolutely worth the read, even Anarky's apology ;-). Once again we can see people asking for what they want to see and that's good, shows again what I've been saying about FreeBasic users finding their niche and developing them and if they can't find information, they'll ask for it because they WANT to do their things. Good to see all that motivation running wild in the community. :-). I really enjoyed Na_th_an's "Teaching English to our computer" tutorial. Very well explained. I also Liked DrV's "The BASIC User's Guide to English and Grammar" as well. Made me question my own sentence formulation techniques a bit. :-). And since A.I. has always been a fascinating subject to me, "Artificial Intelligence, Real Intelligence and QBasic" by Robert Hambly really caught my attention :-). But I can honestly say that I learned something interesting out of everything I've read in #10 issue well cept for my own submissions ;-).
Second, to answer your reply :-). Ok, I'll shut up and accept that I'm a productive writer ;-). The reasons you mentionned are definitaly part of the reasons why I submitted the stuff I submitted. If someone is asking himself questions about what it's like out there in the commercial and professional software development field, they should get a good idea from my articles. The other main reason is that today, weather it's a game or a business application or a programming tool of any kind, users today expect more out the applications they use. They want that extra sense of stability. Today, INPUT A$ to get a string value from the user (or a MsgBox call) just don't cut it anymore, the text input should now be in a box, validated, formatted the way it needs to be shown, etc etc....They want attention to little details like that. They would rather pick a value from a list of values instead of just entering the values, and they "expect" the application to control itself properly even when things go terribly wrong. And yes, that goes for games as well as anything else that anyone would create. Of course in games like Quest for Opa Opa, where making mystakes as you discover what commands work is part of the excitement, so for those games, this does not apply except for that kick you out of the application part. But indeed, that's why I submit the kind of stuff I submit. If every reader of those articles can say (hey that's not a bad idea, and understand why it's good to go the extra mile in their games (like anything else) then I'll be happy with that :-). Even if they never let me know lol. Attention to detail is really what it's all about. :-).
Third, I feel responsible for alot of what happened on QBasicNews, I started by suggesting some of what I thought were good ideas and I kinda blew up a bit on another post, basically bluntly telling them they need to go back to forum management 101 classes or something. I'm not gonna repeat those ideas or that dreaded post. But I will say this, the way the board was handled showed me the reason why my suggestions were utterly ignored. But that's ok, at first all I wanted to do was help them out since I've managed forums that had huge amounts of members and Iv'e hosted chatrooms too (and in chat rooms, my suggestion really helped me make my rooms as successful as they could get :-)), until I found out they didn't want any help. I'm probably the most frequent visitor of QBasicNews and still am today (I'm glad it's still there). But that board has 1600 plus members, and at that amount, the ideas and suggestions I gave start to become quite necessary to keep the board healty and alive. So I'd like to take the oppurtunity here to publically apologize for the role I played in the closing of their forums. Even with that post, I didn't expect that to happen but it did and I feel I needed to apologize for that to the admins and mods at the time and to the other 1600+ members. So now that it's back online, I have no complaints and I hope it stays online for many decades to come :-).
Fourth, GUI seems to be the new old thing dare I say. People want to know about it how to make it, how to make sure it's good and efficient, basically how to not fall in the same holes Microsoft did when they created windows ;-). I for one welcome the idea of new GUIs with open arms. Who knows maybe I'll take a crack at it, not now though ;-). But the idea of having new GUIs to look at and learn from is quite important. It's one of the best subjects (right after games :-) where programmers can foster their creativity into a work of art without any limits imposed by the hardware it is executed on. I can't wait to see what people will create. :-). I always say that there's so many things yet to be created. Today still companies and people are creating things that they don't want to do manually, we didn't even begin to touch all things that the computer can do that we can't do. Plenty of room for new ideas and concepts to get created :-) and with the impressive benchmarks I'm seeing from freebasic it looks like it is "the" best language to use :-). I'll be looking for new things to see :-).
Fifth, I have to throw a word of encouragement to Mr. Adigun A. Polack here. I wasn't there back then...but I gotta admire his perseverance and determination to trying to make something worth doing for the QMunity. 3 failed attempts and still he rises from the ashes and gives the community yet another attempt (a good one from what I'm seeing) at making sure the community is being kept busy and active :-). There isn't too many people with that kind of perseverance and I'm sure alot of people would have stopped at 2 failed attempts, but he didn't, and that's the kind of determinationa nd motivate to contribute to the community that deserves, in my opinion, to not go unnoticed. I really hope this one is a big success for him. To me, he deserves such a success, he's been working hard at it and deserves to reap what he has sewn (DrV, this right too? ;-) ) DrV doesn't know it, but I now have a new English Mentor/spell checker and that is DrV...lol.
Finally, well what can I say. QB Express is quickly becoming my "encyclopedia britannica" (DrV is that right? lol) of programming of all types and active creativity at it's best. And I can see the evolution of everything (the magazine, the contributors AND the readers) with every release, no wonder I'm so hooked lol, can't get too much of a good thing I always say. The magazine in it's first issue was a field test, you could see that things were put in there just to see if they would work and well, obviously, they worked just fine ;-). After that, we could notice that things were changing, parts were added, subjects were varying and slowly, QB Express became what we can all enjoy and learn from today. It's been an awesome first 10 issues and I'm looking forward to many 10s of issues to come. :-). I tip my hat to you Pete and all the contributors...but also to all the community....it's amazing to see everything that's going on in the community and I can't wait to see more. :-). Ooops there's that "Johnny 5 is alive" mode kicking in again ;-). Where's Issue #11 when ya need it? LOL.
Keep up the awesome work man.
As always, I've got to thank you for all the compliments -- seriously man, you're spoiling me! But you're right, QB Express is really starting to hit a groove. For the first few issues, I had to keep on begging people to write articles...I had to send out reminders every few days...I had to dig to find content and contributors. Now, QB Express is at the point where it's almost running itself -- people come to me with great ideas for articles, and then they go out and write them. The content just comes rolling in. After I add a healthy dose of my own stuff and put it all together, we've got ourselves a phenomenal magazine.
Now as for your other thoughts, I'll cut right to the chase. (1) You definitely didn't cause the QBN shut down. I thought you were one of the only rational people on the forums that day, actually. And now you're a moderator at QBasic News, so I guess other people agree with me. :) (2) For some reason making GUIs has always been incredibly popular among the Qmunity (I'm not sure why exactly), but there's definitely a huge amount of people that are very interested in them. I mean just look at Jacob Palm's and Todd Seuss's GUI reviews sites. As long as there's demand in the Qmunity, QB Express will be there to cover it. (3) I agree that we've got to give props to Adigun for his persistence in starting a QB compo, but I think that he would have had a lot more success with his previous competitions if he had done them right in the first place. Competitions with too many rules always fail in this community. I think that's why the new FBTK Roguelike competition is doing so well -- it's simple and it's fun.
Anyway, nice hearing from you again! (I'm sure I'll hear from you again next month too, heheh.)
Letter From anarky
QUOTE FROM ISSUE #10:
- QBasic Network (http://www.qbasicnetwork.com/)
Anarky actually started this website a few weeks ago, but it's been little more than a forum since then. (It also has a bit of Legend of Aquarius info -- about an RPG in the works). But otherwise it's a new QB forum that has has a tiny bit of activity and an annoying default skin (Blue Steel). Hopefully this site will expand become more active soon.
That annoying blue skin is permanant, for now. When the site goes fully skinned, a visitor will be able to change it. I have had no prior experience with PHP until now, so I'm still learning it. When I jointly won the hosting package in the Space Invaders cometition, I really had no idea what to start with.
Legend of Aquarius is halted momentarily due to work on the site. I just haven't the hours left in the day after real life is dealt with.
QB forum: It's not just a QB forum. Why don't you go there and see for yourself? There's a FreeBasic section , C/C++, General stuff, etc. What more do I need? Besides, before the advent of FreeBasic, everything was QB. I'm a QB programmer by default. Say the two following addresses:
In my opinion, Q sounded better than F. So there. But regardless of name, a site is nothing if it has nothing to offer. Same could have been said about www.qb45.com for those new to the Qmunity. But those who have been around for some time, and/or know better, the site was and will be again a bustling community, simply because of its roots.
Yes, QBasic Network will expand and become more active. But I need the support of everyone in the community. Yes, you too. I see you hiding in that corner. THOU CANNOT FEARETH THEE WRATH OF THY MEGASITE-ETH!!!
On a lighter note, it's good to see some activity and postive comments and criticism. Good sites take time. There will soon be an archive of sorts to sift through. Not all of QB. Mainly games I have found enjoyable (and playable) in the past. At first, they will all be QB. Myself and Jatos are in talks about a sister site solely for FreeBasic.
By the way, why oh why, after all this time do people refuse to accept that my nickname is all lowercase? No caps! Lose them!
Until next time, adios!
Man, you really took offense to that one little news post, didn't you? Sorry if I offended you. However, I'll stand by everything I wrote last month; that's still my opinion.
A few responses --
(1) These days when I say "QB", I'm referring to QBasic, QuickBasic *and* FreeBasic. This magazine is called QB Express, but it's mostly about FreeBasic. I know your website also has other forums for languages besides QB, and I'm sure that all of the readers would have understood that too.
(2) You say that QB45.com has nothing to offer? It has 1,000 QB programs and tutorials to download! I wouldn't call that "nothing". (And that's not even mentioning an *active* forum.)
(3) The reason your name was capitalized in that one instance was because it was at the beginning of a sentence. Standard practice in the English language. If you look through the rest of the issue, you'll notice that your name is left in lowercase in all other instances.
(4) I still don't like the Blue Steel skin. It's ugly and makes everything hard to read.
Sorry if I'm critical of your site, but I really don't think another forum is necessary. There are already enough forums around the Qmunity that barely get any posts. I wish you luck with your site, but if you want to create a popular and successful website you need to get content first and then add a forum later when it's warranted. Read my article from QB Express #1, Does The World Need Another QB Forum?
Have a letter for the editor? Send all your rants, raves, ideas, comments and questions to email@example.com.
Every issue, QB Express holds a poll to see what QBers are thinking. The poll is located on the front page of Pete's QBasic Site, so that's where you go to vote. Make sure your voice is heard!
What's your favorite QB / FB forum?
|Pete's QB Site||16||38%|
|76 Total Votes|
I decided to ask this question shortly after last issue, during the chaos surrounding the QBasic News shutdown. At that point, everyone had begun flocking to alternate QB / FB forums all over the Qmunity, and nobody was sure exactly where the community would end up. Now that the QBasic News forums are back up, it's interesting to see where various people are posting. QBasic News's old FreeBasic crowd has mostly moved to FreeBasic.net, where the new forums have developed quite a following. A lot of the senior former members of QBasic News have headed to The Basic Network to hang out, and QB45.com had its relaunch, so a lot of people have begun posting there again. And then there's Pete's QB Site -- my site, with a fairly popular forum, but nowhere near the size of QBN, TBN or Freebasic.net. But somehow, my site's forum managed to destroy the competition. I guess there are a lot of people that like the forum on my site, though I think most of it has to do with the fact that my site was the host of the poll. So definitely take these results with a grain of salt. :)
News from all around the QB community, about the latest games, site updates, program releases and more!
QB Site News
- QB45.com Relaunches!
- Two years after the Qmunity hub was destroyed by a rogue webmaster, QB45.com has finally relaunched! Jofers and Fling-master have spent the last year toiling away on the new site design and its custom PHP database system, which has been gradually unveiled, piece by piece, through the QB45 forum. The site was finally finished and launched in late May, and was met with accolades from people all over the community. New features include a membership-based system which gives you access to the message board, file adding and commenting abilities, the ability to submit news, and more. Additionally, the redesigned site still has all of QB45's gigantic files archive, by far the biggest on the web. Unfortunately though, much of the other old content we remember from QB45 and Future Software has been lost due to the turmoil of constant ownership and server switches. With time the site will certainly grow, and hopefully it will one day be able to restore its former glory.
- QBasic News Returns
- By now, you're probably fully aware of the story. After last month's QBasic News shut down, Wildcard had second thoughts and opened the site back up just a few days later. Then he retired as owner of QBasic News and turned over possession of the website to the new owner Sumo Jo. This was also reported in the update to QB Express #10, and this month you can check out my Interview with Sumo Jo for the full story.
- QBXL Audio Editions 5 and 6 Released
- SJ Zero, editor of rival QB mag QBXL, has released two new editions of
his audio Qmunity news updates. QBXL Audio Edition
#5 covers the chaos following QBasic News shutdown, likening the
event to a giant war. SJ Zero acts as your imbedded correspondent,
bringing you the latest from the battlefield. QBXL Audio Edition
#6 is a more standard release, bringing us the latest project
and site news from around the QB community, with a healthy dose of
QBXL's trademark humor and wit. Worth a listen!
- FBTK Roguelike Competition is ON FIRE
- Most QB and FB programming competitions have very few, if any, entries, very little fanfare, and when they fizzle out and die, nobody really notices. That's definitely not the case with the latest FreeBasic.tk compo. The new FBTK Roguelike competition is HOT. It is so popular, in fact, that it has its own forum at FBTK, and already five "freelance contestants" and five two-person teams have signed up to enter the competition. The rules are simple: "Create a Rogue like using FreeBasic or QuickBasic." And the requirements are even simpler: "Have fun." Go check out the FBTK forums and read about this competiton -- and join if you have any interest at all. I expect great things to come from this competition.
- Mennonite's "No Broken Links" Project
QB Express contributor and member of The QBasic Forum (QBasic.com), mennonite, has begun a project to end the problems of broken QB links on the Internet. Recently he launched this site and began reviewing the links pages of QB sites, searching out both the working and the broken links. He has done four sites so far, and hopes to finish 100 links pages by the beginning of 2006. According to mennonite: "the premise is, there are far too many dead qb links online. While it isn't possible to fix them all, it's my hope that this page will put a more than just noticeable dent in the problem."
Already mennonite's project is starting to work. This month, he has helped me take care of the broken QB links on Pete's QB Site. In the year since I created my 350+ QB links archive, nearly 50 of them have gone down (which should give you a picture of how fast QB sites go down). He searched through my links section and sent me a list of all the dead links so that I could easily bring the section up to date. Hopefully other QB site owners will welcome the help he hopes to provide and the dead QB links epidemic will begin to subside.
- New x.t.r. GRAPHICS FreeBasic Site Launches
- Rattrapmax6 brought his x.t.r. GRAPHICS site into the 21st century a few days ago with a nice redesign and some much needed updates. Previously, the site had that distinctive look that I'd classify as 1997 GeoCities style. :) Now the Downloads section is up to date and organized, and the "Links Town" has expanded beyond just two buildings. Not to mention the new look. Sweeeeet.
- Data Components Reaches 100 QB GUI Reviews
- Todd Seuss's highly productive but often overlooked GUI Review site has hit a new milestone: this past month, Data Components passed 100 reviews. But that's an understatement. Todd didn't just pass 100 reviews, he tromped that number. With 123 GUI reviews, Data Components is by far the largest QB GUIs site anywhere. And it's definitely worth a visit.
- Hezoe Launches TGSite
- Hezoe opened up a new homepage that plays host to his various BASIC projects. It's called TGSite and it's mostly about RapidQ, though there's some QB/FB stuff too. Also make sure you check out the short little snippet he wrote about RapidQ this month, down in the Projects section.
- QBXL.net Gets Redesign...oh, and that Structure Compo thing
QBXL.net, home of QB Accelerator magazine and all of SJ Zero's projects, had a complete redesign this past month. Now it is managed entirely by a CMS, and has that distinctive "blog" look to it. Which is good, I guess, since it now doubles as SJ Zero's QBXL and FB programming newsblog. SJ also went through all the old QBXL articles and pasted them as blog articles (though he unfortunately left out all of the pictures that went with them -- tsk, tsk).
In other news, SJ Zero hosted another one of his marathon 48-hour FreeBasic programming competitions, this time called the "Structure Compo". As far as I can tell, only Xerol and SJ Zero entered anything (and I think both their entries were unfinished)...and no winner was ever declared. For the "full" story, check out the QBXL forums.
- TBN 1000 Line Platformer Compo
- The Basic Network began its first competition this past month, to make a platformer with 1000 lines of code or less. However, it looks like nobody entered by the June 20th deadline. That's a shame, because I was looking forward to the game Los Monos Del Obús was planning on entering: "Betty's Bodacious Day Out".
- Jocke The Beast's MirkWood ported to FB
- Jocke The Beast wrote: "Sotsvart (aka Jonge) has compiled Mirkwood under fb with good results. Only big changes are that it now uses fmod and has pixel * tile scrolling. Otherwise it's still the same crappy game. " If you've never played Mirkwood (or any of Jocke's Middle Earth games), check it out.
- Quest For A King Demo
- SJ Zero released a demo of the new FreeBasic version of his RPG Quest For A King. It's a cool game and definitely worth a look. I'd write more, but I don't want to be redundant...::cough, cough::
- ASCIIQUEST Editor v1.0 Released
- Jace Masula has released version 1.0 of his text mode game maker, ASCIIQUEST. You can find the new release at QBasic Lab. In the newest release, Jace "Added more featured including 15+ new scripting commands and background music and sound." If you're a regular QB Express reader, you should already know all about ASCIIQUEST Editor though, since we featured it in last month's Gallery article. Jace is currently using his editor to create a game called "Dragon Quest", and I encourage the rest of you to try to make your own games using this extensive game-making suite.
- ASCII Scrolling Map Editor 2.0
- Rattrapmax6 has been hard at work on his Scrolling Map Editor. You can find out all about it at this ASCII-WORLD post. Right now you can see some screenshots and read a list of features in that post, as well as check out the OpenGL Viewer for these maps.
- VERY Simple RTS Made in FreeBasic
- Irrit8or made this post at the FreeBasic.net forums to show off an EXTREMELY early sub-beta version of a real time strategy game he is making. According to irrit8or, "the game doesnt look so good, the reason I made it to learn how
to program a rts game. EVERY feature possible was striped, so only a
bare model of a rts was left. SIMPLICITY was more important, and the
reason it actually got finished..." Being a big RTS fan, I checked it out and thought it was kinda neat. Maybe you will too.
- Dmitry Smaghin Ports Some QB Games to FB...
- Over on the FreeBasic.net forums, Dmitry Smaghin released some quick and dirty ports of QB games to FB. The two games were: QB Mario, a Super Mario World clone by Dark Eye QBasic Entertainment, and Backman, a Pac-Man clone from May of '98 by SkurK/b. I like QB ports, especially when they're of relatively obscure games.
As for the games themselves -- QB Mario may look just like the SNES game, but it certainly doesn't *play* like the SNES game. The gravity is on overdrive, the control is spotty, and you can't kick the turtle shells (that's a fatal error right there, that's for sure). Backman is a Pac-Man clone played on a grid that's far too big for its own good, sucking all the challenge out of the game. Plus the ghosts kind of jitter back and forth rather than chasing you around. Meh. Try them anyway, maybe you'll like 'em.
- Zero_Divide Rolls Out CycloNe 2.5
- The last version of Zero_Divide's QB GUI library CycloNe has been released. CycloNe was written using the Future Library, so it works with many different screen modes. It now features more object-oriented code, runtime creation controls, and an entirely rewritten core. To download it, visit the official site.
- Light Bright!
- LoKing has created a FreeBasic version of everyone's favorite elementary school pasttime: Light Bright! You know, the little toy where you poke colored plastic pegs through a piece of backlit black paper to make colorful dot drawings? No? Well then, you better check out LoKing's site and give his Light Bright program a spin.
- Antoni Gual Hammers Out FB JPEG Loader
- FB guru Antoni Gual has been hard at work making JPEG-loading routines for the FreeBasic Gfxlib, which will be a godsend for anyone trying to make a game with a lot of big (ie: full screen) images. Games with cut scenes or point-and-click adventure games. Check out this post for the skinny.
- EzeeGUI: A FREE FreeBasic GUI Sample Designer
- Jerry Fielden has been doing some pretty awesome work lately on his FreeBasic GUI library EzeeGUI. This could come in very handy for some FB programmers looking to save some time on their menus.
In case you're wondering -- "Many Controls are supported, such as: Editbox, Buttons, ListBox, ComboBox, CheckBox, Radio Buttons, ListViews, RichEdit, ReadOnly, Static control, Progress Bar, Horizontal TrakBar, Vertical TrackBar, Messagebox maker, Rectangles, Round Rectangles, Circles, Ovals, Hatches, Horizontal Etched Lines, Vertical Etched Lines, Bitmaps in Buttons, Bitmaps in Static control, Style changes, Etc.."
There is an extensive tutorial and a lot of other information available on the EzeeGUI site.
- RelSoft Plays Around With 3D
RelSoft has made some very cool 3D FreeBasic demos this past month. One is his Quaternion Based Camera program, and the other is JeJunum, where you fly through a windy, endless 3D tunnel. Check 'em out!
- Z!re Resurrects The Qmunity
- The sometimes humorous inside-joke laden comic about the QB community done by that crazed berzerk Swede Z!re has returned for a second season. This past month, Z!re released three new comic strips making fun of various threads from the QBasic News forums. If you don't get the comics, then you should hang out at QBN more often! This thread has the goods.
Written by Pete
Every issue QB Express features a preview and exciting new screenshots from an upcoming QB game. If you would like your game featured, send in some screenshots!
The Griffon Legend
Syn9 has demonstrated himself to be a phenomenal QB programmer in the past few years, quietly releasing countless 3D demos, beautiful screenshots of his work-in-progress QB RPGs, as well as his acclaimed 3D racing game Zero G. At this point, there's no doubt in anyone's mind that if Syn9's coding it, it's gonna be good.
For his first FreeBasic project, The Griffon Legend, Syn9 is really pulling out all the stops. This old-school action RPG truly wows with its detailed sprite graphics, silky smooth animation, and simple but highly-entertaining gameplay. Even in its early development stages, The Griffon Legend is already exuding the video game "X factor" that sets great games apart from the legions of the mediocre.
The Griffon Legend takes place in a fantasy kingdom inhabited by Griffons, "500 years after the Griffons wiped out their Dragon oppressors." Unfortunately, the Dragons have returned to reclaim their lands. The player has landed in a city that has just recently been sacked by the Dragon Lords, unaware that the dragons have attacked, let alone that they still exist. The Griffon Legend gets its name from a story about a group of griffon knights that were the heroes of the Griffon-Dragon war 500 years before the game begins. While the story is remarkably simple, I'm sure it will suffice for this mini RPG. Keep in mind that this is a Zelda-style action game with a focus less on storytelling and more on ... well ... action.
And action is exactly what this game does well. Using a barebones control setup of arrow keys, one attack key and one other key to access an items / magic menu, The Griffon Legend adheres quite strongly to the K.I.S.S. philosophy ("Keep It Simple Stupid"). The battle commands are simple to learn and intuitive. Sword attacks are easy to perform and using the magic spells couldn't be simpler. Unlike many hobbyist games, The Griffon Legend's control scheme makes you feel like you're in complete control over your character -- not just "along for the ride".
The Griffon Legend uses Zelda-style magic system, where you collect spells (indicated by an icon in your inventory) either by defeating bosses or finding them (using a special "search" spell that you get early in the game). One spell sends an avalanche of boulders hurtling down from the top of the screen which can be used as an attack or to destroy barricades that block your path, and another spell allows you to hurtle a cross-shaped boomerang at your enemies. The spells in this game are a varied and useful addition to your standard sword attack. In order to heal yourself, you pick up "flasks" from treasure chests or from slain enemies, which you can use when your health drops. Even in just the short demo of The Griffon Legend, I found over a hundred flasks -- which is a good thing, since I also needed to heal myself on a regular basis (especially during boss fights).
This game comes with all of the standard features you'd expect in an RPG -- your character collects experience points and levels up as he defeats enemies, you can find upgraded weapons and shields, and every enemy has its own HP guage (indicated by an orange bar that floats just below their feet. Whenever you deal damage to an enemy (or vise versa), numerals indicating how much damage was done appear briefly on the screen. Despite the standard statistics-based RPG features, though, The Griffon Legend doesn't get bogged down with numbers. Enemy health, experience and your own health are handled elegantly with bar graphs. And instead of complicating matters with unnecessary numeric stats like "weapon strength" or "defense", these stats are indicated by an icon representing which type of sword or armor your character is wearing at the time.
So far in the demo that I played, Syn9 has created two dungeons, as well as outside town and forest areas. Maps are made up of single-screen rooms with exits on the edges of the screen, much like many NES games (Zelda 1 comes to mind). The overworld graphics are detailed and organic. The dirt and grass tiles have believable textures, and the stone walls look old, cracked and worn. Character sprites look great too and move realistically -- they look as if they actually have weight and must lift more than their tippy-toes to walk (a problem I have with the walk cycles on most QB RPGs).
The bosses in this game are some of the best I've seen in any QB or FB game. Not only are they large and intimidating, they also have varied attacks that keep the fighting interesting. One early boss uses torches on the walls as weapons, hurling balls of fire at you from key locations on the wall. Meanwhile, he also hurls a razor-sharp circling boomerang at you. Players must avoid the fireballs and the boomerang simultaneously (which is a bit of a challenge, but it is not so difficult that it becomes cheap). And then when the boss's wave of attacks subside, you have a few seconds to run in and attack him with your sword. This is the way that good boss fights go in professional games, but very few QB/FB coders ever capture that tension where you're running for your life, and then charging in for an attack -- and always feel perfectly in control. The fights are dynamic and interesting, and also neither too hard or too easy -- a delicate balance that Syn9 really nailed.
The current beta version of The Griffon Legend (build 14) is not for public release. Syn9 plans on releasing a full, completed version of the game around July 15th. He's forgoing demos, in favor of releasing only a finished game (like he did with his other hit, Zero G). The final version will include more enemies and new gameplay options, as well as original sound effects and music. I'm sure you're looking forward to it as much as I am!
Visit the Syn9's page for the latest updates.
How I Got Started With QB
Written by Matthew R. Knight
NOTE: This article was originally written for the January 2004 issue of QB Cult Magazine, in response to Wildcard's request for articles of this nature. Seeing as QBCM is dead however, I decided I'd send it to QB Express instead.
QB was a part of my life when it was my life, and the effort and time that I poured into QBCM in the early days, issue 2 in particular, reflects that.
The recent (and unexpected) resurgance in the QB scene reminds me of events gone past and things related to 2000. The scene I remember exists now only in my memory... a lot has changed, and yes so has the world, and much is no more now.
I started coding in QB in 1995. Everything I knew of the language at the time I had gathered from a very simple book I discovered in the school library. Unfortunately, it was written for Spectrum users, and so most of the information was incompatible. My programming persuits were therefore limited mostly to text adventures for a long time. In hindsight, it's a miracle I stuck with it.
My skills slowly developed after I started reading the help file. To childish eyes, it seemed rediculously terse. They might as well have written it in a foreign language. In frustration, I sold my computer for R600 and bought a motorbike from my friend Bradley, who had a lot of bikes just lying about. My friend Andrew and I used to ride about in the sugarcane plantation nearby my house (he paid for the petrol, and in exchange I let him ride my bike). This move was understandably met by staunch dissaproval from my father, and I was forced to sell the bike a few months later. I used the money to buy another computer: a 286 with 640K and a monochrome (well, amber) monitor, which costed R850. (So at least I made a tidy profit on the bike. :P Not that it means a damn thing now... I recently got myself a Linux box: P233 MMX, 32MB, 2.1 gig HDD, monitor... everything, it even has a LAN card. It only costed R350 (that's about equal to 50 USD). Times sure have changed.) I didn't really mind though, Andrew moved to Cape Town and I had no one else to ride with (barring a bunch of guys in their late teens and early 20's who I sometimes hung with, to the complete dismay of my parents. Some day I'll have to tell you about the one time when Douglas, one of the smokers among them, accidently set fire to the sugarcane ("hey guys, what's that crackling sound?") and we had to make a quick get-away on our bikes, heheh. Good times.)
It turned out that the guy who bought my bike didn't know that you have to mix two-stroke oil with the petrol (even though I told him many times), so the engine was soon ruined. What a waste.
In late January '97 I was introduced to the QB community through my friend Petar (yes, that is the correct spelling) from school, who had an internet connection (still something quite rare in South Africa back then). Petar was a dark, strapping Yugoslavian refugee, already 6 feet tall and built like a tank. Though barely a teenager, he had a gruff voice that would surely strike fear even in the hearts of grown men, he already shaved, and his legs and arms were covered in an immense mass of bushy black hair. The other kids were understandably terrified of him, so he was a good friend to have. :) He hadn't been in the country for long, and his English (or the lack thereof) amused me and my schoolmates to no end. In typical Eastern-European style, he would often swap his v's and w's, leading to hilarious wonders such as "my computer has a wirus." Every time he tried to say the word 'volley ball', laugher shook the high heavens.
Amongst the treasures he downloaded, I was shocked to discover such masterpieces as Dark Crown, Wetspot 1, and the awesome Legend of Lith 2. ("Are you sure this is QB?!") All brand new games at the time. I hurriedly pieced together 'games' (I use that term very loosely) such as UFO and Pacland, which Petar then uploaded for me. Both were text-based action games, though Pacland turned out to be more of a strategy somehow. It was based on the code for a similar game called 'Zombie', undoubtedly a name rife with single entendre, the listings for which I had found in some old C64 games book. I wasn't much of a programmer, and as mentioned, I did them in a hurry, so not surprisingly, the ratings they recieved were dismal at best. (Apparantly the owner of one QB site wrote a small comment next to my games in the margin... I'm told it was something to the effect of "WHY??????" heheh.) I must admit though, those old days weren't quite as gold as some of the other 'oldies' among us might have you believe. Tuturials were still few and far between, and often left much to be desired. That, coupled with the weak processing power we had available to us at the time, not to mention the fact that the pricing of new computers back then was something quite disgraceful, did not bode well for the QB community. So admittedly, a lot of the games from back then were, politely spoken, pure shit.
Of course, my own skills reeked of baby diapers themselves, so I was impressed all the same. I think we've all come a very long way in the last 7 years. Unfortunately, I couldn't run most QB stuff on my own box, being stuck with a monochrome screen and what all. All I could really run for at least half of '97 was Rockwars -- a game I eventually did a remake of in 2000 -- and Kenneth Green's Dungeon of Motion and Sound. But it was better than nothing, and I was surprised to find so many other people who also liked QB. Confidence restored, I formed a 'company' (heheh) with Petar and two other guys from school; Kevin, a quiet German boy with strawberry blond hair, and Liam, a rebellious towheaded Irishman, with a reckless grin to match his nature, and pale blue eyes that looked exactly like frozen ice.
Determined to make our millions and take over the world, our new 'company' (you know what I mean) would meet up at Kevin's house every weekend and on holidays, to make revolutionary PC games, in Qbasic, that would ultimately take the world by storm. Apparantly Kevin had a friend of a friend of a friend who's uncle's mom's dog once saw this guy who could get a demo of our game on the cover of PC Gamer, and as far as we were concerned, our futures as multi-million dollar game programmers were as good as carved in stone. Of course, we spent most of that time at Kevin's playing Mech Warrior instead (actually, Kevin would play, the rest of us just had to sit there and watch), or playing basketball outside.
Disenchanted with the progress we hadn't made over 6 months or so, we decided that we needed our own office, and that building this in Kevin's back yard was somehow the answer. Convinced that this latest scheme would assure our success, we worked day and night at this over the Christmas holidays of '97, and it actually turned out surprisingly well (although Petar practically built the whole thing himself). The roof leaked when it rained and it lacked electricity -- not exactly the ideal headquarters for our multi-million dollar games studio -- but it was our headquarters, and we were proud of it right?
I would often go to Petar's house first to use the internet, and then we'd lug our computers all the way to Kevin's place later on. The one day it looked like it might rain, and we could hear thunder in the distance. We weren't too keen on having our computers rained on, obviously, so we started to run. You can imagine what this spectacle must have looked like to the passing motorists, and we were concerned that we might be arrested as burglars.
Come to think of it, it's a bloody miracle our hard-drive's didn't get bad sectors.
We held meetings in our 'headquarters' once in a while, but this was not all plain sailing at first. An unruly element tried for a time to disrupt our meetings by throwing stones and fire crackers on the roof of our shack, and even jumping from a high bank on to the roof and dancing on it. We were very eager to dash out and try conclusions with the young hooligans, but Petar, the oldest and most sensible among us, guessed that it was precisely what they hoped for and encouraged us to avoid a confrontation. Instead we ignored them and eventually the interference abated.
We didn't use our shack much due to the lack of electricity, so eventually Kevin's dad claimed it, and used it as a place to store some of the excess junk in the garage. 1998 passed quickly and aside from some mini-games I made, no one did anything much really, and barring an incident where Liam demonstrated his leet throwing, catching (and ultimately dropping and hence breaking) skills with Kevin's wireless mouse, thus leading to him being kicked out the group, nothing really changed.
Petar and I eventually stopped being friends after he accused me of stealing his Duke Nukem CD (which he later found in his CD-ROM drive...), Kevin emigrated to America, and that was the end of that. Although Liam and I remained friends, neither of us were interested in starting another game company. At the beginning of 1999, I finally got the internet at home, and I suppose this marked my real entrance into the QB community, because Petar had always hogged the keyboard back in the day. I used this new opportunity to download as much as I could, especially tutorials or code I could learn from, and I made massive strides in a very short time. In December 1999 I started using the QB chatroom at qbasic.com and several popular discussion boards, finally making me a QB'er in the fullest sense. Not long later, QB Cult Magazine, otherwise known as QBCM, was founded -- a project through which I hoped to share my knowledge and love of QB, and in part, to fill the massive hole in the scene that Qbasic: The Magazine had left.
At around the same time, Terry Cavanagh (Traveller), William Moores, Svante Ekholm Lindahl (AlienQB) and myself formed Dark Legends Software. We were just a newbie group really, and we only managed a few mini-games. Although it's highly unlikely that anyone but us remembers our group or anything we did -- we weren't Enhanced Creations, we weren't Darkness Ethereal -- it was and still is important to me, as it represents one of the happiest times in my life.
I'm really glad that Wildcard wants to do this series on the history of the QB on the web, because I've always been really interested in QB history. But I'm going to let you in on a little secret seldom learnt and often forgotten... our community is built on the things we never see or hear about. It isn't the legends like Enhanced, or the classics like Dark Crown or Wetspot 2, that make our community what it is and was, what has kept it alive all this time. It's none of that. It's the friendships we make, even the enemies, the sleepless nights we spend finding that one last bug (for the tenth time heh), forgotten groups like Dark Legends, forgotten games like Rockwars 2000, like Black Hole, our forgotten flames and rants on our many forums, our impossible dreams, Dunric's quest to find a wife heh... so on so forth. These are things that you will never see mentioned in any magazines or articles, but lemme tell ya, this is the good stuff. It's the sort of stuff you'll still remember 20 years from now.
These are things that can exist now only in our thoughts... unless we put pen to paper (or fingers to keys, whatever floats your boat heh) and write them down. Behind the handles and (make-believe) company names there exists stories we know nothing about. In this article, some of mine have been revealed to you today.
I dissapeared from the QB scene a long time ago, and although I had always meant to return some day, I rightly know that I can't and never will. A month away became six months, then a year, and now four... that chapter of my life ends along with this article. Anyway, before I leave you poor bastards in peace once and for all (smile Mags), I would like to share with you the following programs from my early days. This is by no means a complete collection (many of my programs have unfortunately been lost), but it's something anyway. If this article didn't succeed in making you laugh, I'm sure these will. :)
RACER.BAS: The first driving game I ever made, though it hardly qualifies as one. I completed this on December 31st 1996, which makes it the oldest game in this collection. This is one of the first graphical games I ever made. Unfortunately, I was stuck using SCREEN 3 since all I had at the time was that black and white monitor. At around the same time I was working on an untitled graphical text adventure, inspired by Space Quest II - one of my favorite games of all time. If/when I find it, I'll send you a copy.
ROCKET.BAS: My first graphics demo. :) I can't remember when I made this, but based on the code, I'd say it's either January or February 1997.
STUNT.BAS: An incomplete Hollywood stunt driver typa thing, dating back to mid-1997. I thought the graphics were brilliant at the time... I have no idea why, heh. The setting's Hollywood, but I went and put up signs for exclusively South African shops (like CNA) heh. Some of the
names I just made up. (You can change the value of the S variable, anything up to 32, to affect which screen you're on.)
MONKEY.BAS: Monkey Shoot! Actually, this game sucks, maybe I should have called it Monkey Shit. I completed this some time in August, 1997. Kevin came up with the idea for this game in English class the one day, while some monkeys were playing on the roof. I think the fact that the first thing he thought of doing was shooting them speaks volumes about the mentality of the average schoolboy, heh.
DARK.EXE: Just a simple shooting in space typa thingy I completed on September 12th, 1998. It's the first game I made that my friends didn't think was crap. Their sentiment towards my ingenuity in making up names for my games was a little different though, heh.
F1RACE.BAS: Yet another racer that didn't get very far. I barely remember making this.
TC1.BAS: The first of the two Tank Commander games, completed on April 13th, 1999. Work actually started on this soon after the release of Wetspot 2. I originally had a much more ambitious game than this in mind, determined to compete with the likes of Angelo's masterpiece... In the end, I found that I had bitten off far more than I could chew, and after repeated failure, interest in the project was soon lost. The project gathered dust for almost a year, and then one weekend I
finally finished it off... Well, sort of. You may have noticed the complete lack of hit detection on the sides of the road? :) At that point I was so bloody sick of the game, I couldn't have cared less about doing a decent job, heh. I might have added it in if the game was a bit better, but it sucked, and I knew it - it was not the Tank Commander that was going to take the QB world by storm, as I had originally planned. An almost apologetic bit of blurb appeared in the
introductory text, a sort of half-assed attempt at passing the bug off as an exciting feature, heh. "...and the ability to demolish anything in their path. Even the tallest building is no match for these monsters!!!" There is no such thing as a bug in a videogame! To make matters worse, the credits screen smacks of irony... "Concept: About a million other un-origional programmers ;)" Well... The spelling of that word is certainly very, ahem, origional, heh. :)
DESTROYR.BAS: A very simple mini-game, completed within 3 hours on May 3rd, 1999. Although it is outstanding in no way, I was very proud of it because the sprites didn't obliterate the background - a problem that had been driving me up the wall ever since I started programming.
3DRPG.BAS: An RPG engine (or at least an attempt at one) in a three-dimensional setting, which... Well, it didn't work very well did it? :) June 1999.
3DTRI.bas: My first "real" 3d program. Again, June 1999. I was very, VERY proud of this back in the day. :) The two main inspirations for this program (and what motivated me to try and overcome the seeminly insurmountable obstacle of learning 3d) was Xeno and Groov Buggies - the former in particular. I was determined to eventually make something similar, but ended up trying my hand at a Groov Buggies type game instead. This is where all the problems started. :) The engine had
no perspective, and no backface culling. I didn't even know where to start with the backface culling, but on September 21st I finally managed to implement perspective correction, and came up...
DOOM.BAS: ...with this. Gosh but I was happy when I got this to work. :) At last work could begin on my driving game! Or not, heh. Being a clueless newbie and all, I didn't know that a pair of world coordinates may not be in line with or behind the camera - it took me until October 20th to figure that out. Self-confidence restored, I set out to solve the backface culling problem and... came up with bugger all, heh. At least until much later anyway, and by then I had other plans. So my driving game never got any further than Doom.bas. :) (Some of you might remember that I used this same program in my 3d tutorial in issue 3.)
TANK COMMANDER V2.ZIP: As the introductory text explains, it's just the same thing as before, but with much better code. August 15, 1999. I sent this to a bunch of QB sites later in the year. (I would have sent it earlier, but I couldn't get my e-mail to work. Eventually someone on qbchat told me about hotmail, and I've been using that ever since.)
DLS.ZIP: All my games from Dark Legends Software. I don't need to talk about them here, there's more than enough waffle in the documentation. (Regarding Qbasic: The Rpg, I've never understood why people didn't immediately get that GODQB was actually a thinly-painted parody of the young Liquidex (formerly known as LordQBASIC). Duh!!)
-- Matthew Knight
Download zip archive with this article and all of Matthew's programs.
Review of Rattrapmax6's ASCII Scrolling Map Maker 1.0
A review by Stéphane Richard (Mystikshadows)
In this review, I will be covering Rattrapmax6's ASCII Scrolling Map Maker 1.0, a great
tool for whoever needs to create a scrollable map for their games. To start this review off, here
is a screenshot of the designer part of this software.
This review will be broken down into review items to which I will bring my personal score and
opinion. I will try to remain impartial in my review in order to given a non subjective and fair
review. Finally I will total up the score and give it a final percentage.
Functionality and features: 8/10 points
By Functionality and features I mean what does the software offer me in terms of features and what
I can do with the software in relation with what the software was designed for. In this case I believe
the software successfully offers a complete range of functionality and features to allow me to quickly
and easily create the maps I need. It even has a renderer to get a global view of the whole map as a seperate
Another side of application development that shouldn't be overlooked is user feedback. What the program returns
to the user to let him know what is happening or what just happened. In that regard, the application gives
sufficient feedback to the user to let him know what tile he's using, where he is on the map, what type of tile
he is currently creating with and so forth. This is an important factor in the score I've given the features
part of the review.
Layout and Disposition: 9/10 points
Although some might argue a bit on this feature I describe Layout and Disposition the overall organization
of what I'm seeing on the screen and how it helps the usability of the application. As you can see from the
screenshot, everything is right there in front of you. No menus, just options that can be clicked on right
away. As far as tools and utilities go, having everything there and ready is a big plus as it doesn't hide
any features behind a hierarchy of menu or commands. It allows to do the job much quicker when intelligently
organized on the screen. That's why I gave it a score of 9 because everything can be done directly from the
Note that this particular part of the review is often a question of personal taste. I happen to like the
layout used here. Some might not. So the review is based on an unbiased statistically based evaluation.
As such, I put myself in the place of common mortals and attempt to see through their eyes how they would
like a map generator to look like and be used.
Suitability to the task: 8/10
Here I measure how well focused the programmer was in his way of presenting the features to the user in relations
to the category of the program. Here we have a scrolling map generator designed to create maps that will ultimately
scroll as any other text scrolling games. As such, I would say that the program itself is close to perfect for
the task at hand. The only thing I might have wanted differently is to be able to scroll through the map without
needing to select the tile to edit (scroll in it as I would if I was playing the game). And I would have integrated
the renderer right in the application. However, the renderer is there that's why I gave it a 8 out of 10 points.
Another aspect of the review, in regards to suitability to the task is the whole feel of the application in general.
When you open a word processor, you expect things to be in certain places, you expect certain features to be present
because it's a word processor. As far as a map generator goes, you can expect things to be there as well. In that
aspect, you can clearly see you are in a map editor so that too helped with the scoring.
Overall performance rating: 10/10
Those of you that have tried this utility will agree that this is a very fast application, I have noticed no hold ups
or any stalling while using the application and creating maps. Likewise because of the direct availability of all the
functions that too contributes to the overall performance of the application. Everything works quite fast and simply put
it's a map designer on steroids.
As I mentionned earlier in this review, the user feedback plays it's role here too in the performance score. Because it's
easy to see what's going on, no time is waisted trying to figure out what to do next. It's very straightforward which really
helps get things done fast.
The Final Word
All in all, the ASCII Scrolling Map Maker 1.0 is a great application to use to create your maps. It's a completely integrated
application that offers all the functionality you need to create your maps. Often the 200x200 is big enough for most mapping tasks
but perhaps an ability to change the size of the map might be a good idea. I know version 2.0 is in the making and I for one can't
wait to see what extra features will be added to that version.
I think that Rattrapmax6 did an excellent job in this first version of his scrolling map editor, it is a well designed program that really makes map creation as easy as it can get. He gets my 2 thumbs up on this project.
Check this thread for ASCII Scrolling Map Editor v1 info, this thread for info on version 2.0, or visit the x.t.r. GRAPHICS FreeBasic Site.
Making It Personal... A Thought On Flaming
Written by mennonite
Alright, I wasn't sure this article was a good idea, and I'm still not sure. If you have any problems with it, it's Pete's fault for running it.
I joke, I kid. Pete's just the messenger. Don't blame the messenger.
Those who don't like me probably aren't going to. Whatever incompatibilities we have, hey, that's cool. Incompatibilities are really just differences, and differences make us great... more often than not.
It's alright if you don't like me. You don't have to like people... You don't have to like anything you don't like. And that's pretty much what I'm looking for in return... I want to not like what I don't like.
There are lots of things I like as well, and I'm just as happy and likely to talk about them. but this isn't about me. This is about flaming.
I'm not against flaming. It's better for people to vent frustration online than to go blow each other up. It's better than quitting your job or fighting with your coworkers because you're stressed out at work. It's better than a lot of things.
But as of the 72 hour closing of the QBN forum, there are now 25 forums you can go to and flame each other, if you want to. I think it's TBN where they actually set aside a sub-forum for just this purpose. Great idea. From what I've seen, it's a good forum, too. Yay, TBN.
The two exceptions to this however, as far as I can tell (and I haven't seen them all!) are "The QBasic Forum" where all the newbies (and oldies too) go, and QBNZ, which has an anti-"RTFM" policy that I think is also cool. It's cool because there are, in fact, other places. I'm not advocating censorship. Hate it.
But you can flame all you want everywhere else you go. In fact, not much could stop you from doing it anywhere, if you're sufficiently inclined.
But it's just as nice to be able to have somewhere to not be flamed as it is to have somewhere to flame. I hope the two will stay separate. It's one thing if someone attacks you... I mean, hey, who's going to fault you for a counter? When I'm attacked, I counter. But if someone (like myself) says that they don't like the feature of something (and we're not talking about something you wrote, either) than maybe y'know, they have a good reason. Maybe they have a really good reason, but the explanation is lacking. None of this means that they're nuts or stupid... so why does it have to turn into that? Generally speaking, why would you attack someone just for having a different opinion, when it has nothing do to with you at all?
I know, it's just this kind of "Wouldn't it be nice..." stuff that gets me flamed. Here I am in a big audience of a relatively huge publication (how many hits does QB Express get?) and throwing my two cents at everybody.
Sure, I take a risk there. I'm not trying to paint myself as the ultimate example, either. Sure, I try, but I only succeed for the most part.
But in general, if I could go to a place where people don't attack me until they're attacked, then I'd go there. And usually, The QBasic Forum is perfect for that. Usually. That's why I like it. And for what it's worth, I'd like to see it stay that way. I'd like to see everyone have a place they like to go, whether they prefer flames or no flames or low flames. I'm not asking for anything that doesn't already exist... I just don't want it to go away.
It's just a thought... and if it does mean I'm crazy... well... hey.
Visit mennonite's site at angelfire.com/electronic2/mennonite.
Where Are They Now?
Written by anarky
Welcome to QB Express' 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, Gianfranco Berardo basically tells us his life story in a nutshell.
My first computer was an Apple II C+ when I was probably about 10 or 12
years old. My parents bought it when Apple computers arrived at my
grade school. For those who don't know it, this machine was as
powerful as the original NES. You used it similarly, putting in floppy
disks and turning on the computer to run programs. There was no hard
drive. The first game I played that got me to realize I could create
things was Bill Budge's "Pinball Construction Set". You can see some
info on it here: http://www.the-underdogs.org/game.php?id=826
It was one of the first games to use the joystick that I got with the
computer. I didn't have a mouse. I made myself a few crazy pinball
boards, and it was fun to make and play them.
Unfortunately I couldn't make anything else. I remember wanting to
make my own game but had no concept of what programming was. I turned
on the machine with no disk and got a command prompt. I actually
started typing in paragraphs along the lines of: "I want this game to
be like Troll's Tale, only with weapons like swords and stuff. There
should be blah blah blah..." until I hit the 255 character limit and
got "SYNTAX ERROR?" So much for making games.
I remember my mother was learning Applesoft BASIC and showed me my name
printed on the screen 10 times. The code was probably:
10 FOR i = 1 to 10
20 PRINT "GIANFRANCO BERARDI"
30 NEXT i
Maybe a few months later, my cousin came over and we somehow got
fascinated with the computer. I wanted to show him how to do the
program my mother did, but I didn't know how she did it. Luckily the
book I affectionately called "Apple's Beginners Guide to Beginners
All-purpose Instruction Code" was nearby. While my cousin was there, I
actually read the thing to find out what to do. I made my name appear
10 times, and then my cousin made the computer swear 10 times.
He left shortly afterward, but I stayed at the computer and started
making it do other things. Count to 10 (that was a standard number to
use, huh?), ask questions, etc. I don't know how long I stayed there,
but from then on I was a programmer.
Since I didn't have Internet access at the time (NOTE to children:
please try very hard to think about what life was like), I went to the
local library and took out books on programming in BASIC. I copied the
code out of the books. It would be months before I found a way to
save the code to disk.
In the meantime, I wrote simple text-based RPGs. The entire game was
hardcoded, so I had code that ran somewhat like this:
- display message about room 1
- display choices
- ask for choice
- depending on choice, GOTO appropriate section of code, which redundantly does the above again.
No functions. No subroutines. Just a long listing of code that
shouldn't have been so long. Learning how to program on your own is
fun, but you defintiely pick up bad habits quickly. B-)
Still, using those books and the Apple's Beginner's book, I found out
how to do graphics in lowres and hires. I wrote programs to draw
simple images, like words or circles. It was around that time that I
realized, like most programmers I'm sure, that if I could write a
program to draw pictures, I could probably write my own games! REAL
games, the kind with graphics and action!
My first attempt: a Pac-man clone. I learned how to program vector
graphics in hires mode. You could rotate an "object" and scale it,
which was really cool. So I drew Pac-man. I drew ghosts. I even made
Pac-man move from one side of the screen to another. But I couldn't
figure out how to make it play like Pac-man!
I moved on to easier projects, such as turn-based games. My first
complete game was called "Capture the Flag", and thinking back on it,
it wasn't even a clone of any games I played. It truly was an original
game for me. Essentially, you have a grid map. In the top-left and
bottom-right corners, you had two stick figures representing the
players. Each player took turns moving about the map trying to find
the opponent's flag. Each square on the grid was hiding something. By
the end of the project, I had bombs and multiple lives for the players.
My sister and my friends would actually play it with me without me
forcing them to do so! Definitely a success.
I didn't get my first PC until sophomore year of high school. It was
150MHz and ran Windows 95. There was no programming language on it,
but I was spending a lot of time trying to figure out how to use it
anyway. Then someone at school introduced me to QBasic, and when I saw
it, I realized that it was so much more powerful than what I had used
before. Hires? SCREEN 12 was REAL hires! Once again, I attempted to
I ended up scrapping it, working on other things first, then going
back. I made Pac-man a bit smaller on the screen since it flickered a
LOT otherwise. Now it only flickers a little. B-) I used INKEY$ for
the movement, which made it difficult to control, but I didn't know
better. The result is what I made in 1998. I even tried to write an
RPG, but managed to get a rather sophisticated walking demo. You could
walk across multiple maps, enter towns, caves, and castles, and exit in
a completely different area. I even had a fairly simple scripting
language to handle it all, along with conversation trees and the like.
And all before I knew what a scripting language was. Again, this is
before I had even heard about using the Internet. I really thought I
was pushing the envelope with QBasic then.
A couple of years later, I was online. One of the first things I did
was look up "QBasic" in a search engine. OH MY GOSH! There were so
many sites out there! AWESOME! And then I saw some of the projects
out there, and they put my accomplishments to shame. Still, I was
pleased to learn that I had reinvented things that were common
knowledge in programming, which has to count for something, right?
I started posting on message boards. I was probably one of those
annoying new-to-the-Interweb people. I may have even violeted some
Netiquette rules, but I can't remember how naive I was then.
Eventually I thought, "Hey, why not get other people to look at games I
made?" So I took Pac-man, combined it with Tic-Tac-Toe and Guess the
Number, zipped them up, and uploaded them somewhere. I asked people on
maybe 20 message boards to check it out. I also pleaded with them to
be nice because it was made two years ago in 1998. I was ecstatic when
it received a 70% on Pete's QBasic Site, and laughed at how WisdomDude
kept mentioning the fact that was two years old throughout the review.
I lived at qb45.com mostly, saying silly things like "I program in
QBasic 1.1 but run the programs in QBasic 4.5 because it is faster" or
"Microsoft just gets a bad rap because it's so big." I was fairly
unknowledgable. When WisdomDude had told me about a Pac-man clone
reviewed at VPlanet, I had to check it out. I remember the game got a
fairly decent review, but I was a bit suspicious about the "innovation"
of a ghost that goes through walls. Recalling my own Pac-man clone's
development, I thought, "Making the ghosts OBEY the walls was more
difficult!" I also saw that it used graphics from other programs
without crediting them, such as the famous PixelPlus256.
That's when I decided to start my own game review website. I already
had a really basic one page site on Angelfire called Pigeon's QBasic
Site: GBGames (my nickname at college was Pigeon, but I found that
simply calling myself "Gianfranco, GBGames" on the forums was a lot
easier. Eventually I shortened it to GBGames). Anyway, I gave that
game a 57.25%. In retrospect, I think I was a bit harsh on such games.
I mean, most hobbyist game projects don't get finished! It had to be
demoralizing to read "Interesting intro. Too bad the same couldn't be
said for the game." Ouch. I still can't believe how much of a jerk I
was in some reviews.
I tried to review a lot of games. I don't think I tried to get
anything different from what V Planet offered at the time, but I did
post on a LOT of forums, asking for submissions. Eventually my site
got so popular that I didn't have to ask anymore since I had such a
backlog of games to review. By the time I stopped updating the site, I
had 55 game reviews. I still have a directory on my hard drive of
games that people submitted.
The worst times were when I didn't write a review for months at a time.
I think most or all hobbyist webmasters have those dry spells, where
Real Life pulls them away. Homework, girlfriends, etc. I do remember
doubling my efforts, especially when V Planet would hit a dry spell. I
remember the panic when new game review sites would appear in the
community. Competition is a good motivator at times.
I remember throughout the years when major players in the QBasic
community would say good-bye. It was always sad, like when Pete
disappeared, or when Jordan (Jorden? Google says it is both) Chamid
left QB45. Still, I never thought I would be one of them.
At one point, I just couldn't dedicate the time to following the QBasic
world, let alone review games and update a website. People had
periodically offered to help maintain the site, but I always considered
it my own and didn't like the idea of others writing reviews. One day,
I realized that I wasn't really paying much attention to Qbasic
anymore, so I decided to stop. My last real update was apparently
January 31st, 2003. I think for some time the site was down, but on
August 25th, 2004 I updated the site and moved it to
What am I doing now? I actually still do game reviews, believe it or
not. I review indie games at GameTunnel and it was my
QBasic review site was what helped me get the opportunity to do so. I
also have aspirations to run my own shareware game business. I am
working with C++ and SDL (http://www.libsdl.org) mostly. I'm a huge
Gnu/Linux enthusiast, and for the record, QBasic runs just fine in
DOSbox. My Pac-man game still flickers in it. I maintain a blog
http://www.gbgames.com/blog where I focus on game development and tech
I still pop in from time to time to check on the community. I am
especially pleased with what has been done with Pete's QBasic Site.
I've been hearing a bit about FreeBasic, but not enough to comment on
it. Still, knowing that QBasic lives on in some form in an age when
DOS is mostly dead (I think people have been saying that when I was
still active too) is great. And I know that QBasic.com still has an
active online forum, which still amazes me! Who runs that site anyway?
For new developers, always keep learning. Always keep pushing what you
can do. There are named techniques and practices that you probably
don't know about, so make an effort to learn. And have fun. When
hacking out code isn't fun anymore, realize that you've taken a wrong
I remember talking to various people throughout the years, such as Phil
Lutas, Bud the Fish, Johan de Ruiter, Abstract Productions, Michael
Hoopmann, Merlin, Piptol, Typosoft, and many others. I haven't really
talked to many of them these days though. If anyone wants to, they can
drop me a line gberardi @ gbgames.com as I'd love to hear from
you. No, that was not an opt-in for spam.
Asking via email what to write in a form which could be converted to an interview was needless. Gianfranco of GBGames sent me this letter in reply. Well, who said my article HAD to be an interview?
Visit Gianfranco's QB site GBGames, or anarky's site QBasic Network.
Searching For The Unknown
Astral Worlds by K.D.A.G. 2004
Written by Lachie Dazdarian
Welcome to the first article in a new series by Lachie Dazdarian called "Searching For The Unknown". In these articles, Lachie will search out and review rare and unknown QB games that deserve much more recognition than they're getting. This month, he takes a look at Astral Worlds by K.D.A.G.. Enjoy!
About Astral Worlds
Astral Worlds is a very interesting game maker also featuring a very nice role playing/action game called Chief Dojoepa! but first I would like to start with a short prelude.
At the first glance I thought Astral Worlds was some sort of low quality and sloppy piece of work since the source code was not compiled and contained hard paths. For the program to work it's files supposed to be placed in c:\aws directory which is not a big problem itself since Astral Worlds was zipped as "aws" directory. But for someone who plays games on his D: directory and unzips games to directories he creates this can be quite a drag. Also, the user is not warned in any sort of documentation where the program has to be unzipped. Very user-unfriendly. Once I got rid of the hard paths and started the program my opinion about Astral Worlds completely changed.
Astral Worlds looks and feels very unique and unconventional. The graphic design is quite nice, featuring cool, mystic-looking menus and menu illustrations. Right from the main menu you will notice that Astral Worlds is different from most of the other QBasic games you've played. On the main menu you are asked to pick a world and since the original version of Astral Worlds features only one completed world/game(Chief Dojoepa!) you will probably click on it. After you enter a world you will be able to start a new game, load a previously saved game or edit that world. Simply the way editing of a world/game and starting a new game are interlined makes Astral Worlds special. Not that this kind of design is the smartest idea which I'll explain later.
I will start with the review of the world editor simply because Chief Dojoepa! is a product of it.
The World Editor/Game Maker
Astral Worlds is basically a game maker and Chief Dojoepa! only a game made with it and not an integral part of the program. I'm not sure if Chief Dojoepa! was planned from the beginning but Astral Worlds definitely benefits from featuring it. It shows the full potential of the world editor but also in some way hides it's flaws. On the end the world editor ends up being the weaker part of the Astral Worlds package which probably wasn't the original intention of the author.
To access the world editor simply click on "Edit This World" option once you pick a world from the main menu. Don't use Chief Dojoepa! world to test or play with the editor. Use one of the empty world slots(Untitled world).
The biggest positive aspect of the world editor is it's user-friendliness. It's a very intuitive and well designed game maker, easy and enjoyable to use. On the other hand, there are the numerous limitations. The main is that your game will be tile by tile scrolling and will feature Astral Worlds game screen design and the specific game mechanics. But I want to say something about the limitations of the very world editor first.
Each world you edit in Astral Worlds is consisted of four areas and each area is 50*50 tiles large. Each tile is 16*16 pixels large and each area features it's own 240 tiles. That's the most notable world editor restriction and this can't be changed, nor the tile size nor the map size. You might feel that it's impossible to create any kind of serious game with four 50*50 tiles large maps but if you try out Chief Dojoepa! you'll realize how mistaken you are. I really don't consider this to be the biggest problem of the world editor.
What you will notice first, after you access the tile/sprite editor("Edit Pictures" option in Area menu), is that all of the 240 area tiles have an already preset type(they are categorized). Tile slots are reserved for things like character sprites, objects(items), colliding and non-colliding tiles or animated tiles. You can change the tiles but not their type. So you can't use one animated tile to create an inanimate wall since it will be ALWAYS animated inside the game with it's other preset animation tiles(4 tiles make one animation). To prevent animation you would have to paste that wall tile in the remaining 3 tile slots used to create that specific animation. Same thing with using item tile slots to store your non-colliding tiles or anything else. You simply can't do that. You must draw your game items in those slots. And the number of non-colliding tiles is by my opinion too small. Also, you can't be sure which tile is colliding or not since you can't always decipher that from the "name" of the tile type. Half of "Land" type tiles are colliding while the other half is not. The fact that each world already features all the sprites and tiles drawn(mostly cool) you will be able to figure out, according to their look, which tile does what when put into a game. You will be mostly annoyed with the already mentioned tile categorization.
The very designing of the world you should start from the "World Properties" menu. In it you can change the title of the world(game), new game information(starting position, character's strength, items he caries, ...), start and end game book(text and pictures shown on the beginning and end of the game), world items, bombs and weapons. Start and end book feature is quite cool and allows you to create text and illustrations which are displayed in a form of a book on the beginning and end of the game. "Edit Intro" option allows you to edit a book displayed before each new game and "Edit Ending" option to edit a book displayed after the game ends. To create illustrations you can use one of the 240 tiles reserved exclusively for the start/end book graphic and don't have anything to do with the area tiles(you don't have to worry about tile types; we are talking here about non-interactive illustrations). This is a really cool feature in the world editor and I can't say nothing bad about it. What you will notice in "Edit Items" menu is that one world can only feature 6 different objects(items). This was a big disappointment to me. I should mention that items don't include keys, weapons or bombs. Keys have reserved slots in the tilesets and are used with a specific type of event(Key Lock). I'll explain implementing events later. Each item you can connect with one of the events you create. It can be from increasing player's health(food and similar items in your game) to player being transported to X, Y position(items like magic stones or teleporting devices). You will also notice in "World Properties" menu that your game can only feature 3 types of weapons and 2 types of bombs. I didn't find this too restrictive as the small number of items you can implement.
Inside every area menu you can edit the area map, add new events or edit the old ones, edit enemy characteristics, edit NPC characteristics, edit tiles/sprites and name tiles/sprites. Map editing is quite simple and does not require much comment. You pick tiles with right mouse button and place them with left mouse button. I should mention that you put movable objects, NPCs and enemies in the maps the same way as static tiles(no layers). By implementing movable objects in your game(they have a reserved place in the tilesets) you can create various Sokoban type of puzzles or even orient your game completely toward that concept. This easy way of implementing movable objects and characters into your game doesn't come without a price. Your sprites(from items to characters) and movable objects cannot feature a transparent background color.
Events are the heart of the world editor an allow you to put life into your game. Events range from change location/area, display text to neat events like small shops. Placing events in your game works the same way as placing tiles in the area map. Another cool feature is chain option which allows you to chain events. This is very useful if you want for an action or a place inside the game to trigger more events in the same time. Like if you want for some text to be displayed before you enter a dungeon(display text + change location or area). Although the event editor is powerful and well designed I found it lacking in some aspects. While working on The Unknown, a game demo I created while testing the world editor, I failed to find a way to prevent my character to use the communicator while he is inside the space ship. So the events you can implement were obviously not meant to suit complex adventure type of puzzles. Events are global for all the areas. What's good in the event placing and map editing menu is that you can switch to any area map while being in that menu.
Each area can feature 2 types of enemies and 6 types of NPCs(non-player characters). Inside the "Enemy Info" menu you can edit enemy characteristics(strength) while inside the "N.P.C. Info" menu you can edit the NPCs. Each NPC can feature up to 4 text messages given to the player if the player bumps with that character. You can also set if a specific NPC moves or not.
If we ignore that all tiles are categorized the very tile/sprite editor is ok. I only felt that a fill color option was needed. What is useful to know is that you can scroll through colors and tiles with arrows keys if you don't like using arrow icons inside the tile/sprite editor. "Name Pictures" option allows you to give a name to each tile in your game. This is important because the name of each object you bump into inside Astral Worlds game is displayed in a small text box in the right-bottom corner of the game screen. Unless you want for the word "Untitled" to display ever time you touch something in your game name your tiles and sprites.
Each game made with Astral Worlds world editor cannot be exported from Astral Worlds in any way which is another restriction. Like I said before, a game made inside the world editor is limited to tile by tile movement, Astral Worlds game screen and the game mechanics(way of using and equipping items, character features, text box). It would be cool if the user could change the look of the game screen(edit the borders and the shape of icons). Changing sprites and tiles in the "Extra" section inside the tile/sprite editor doesn't have an effects. This doesn't lower the quality of the world editor as much as the restrictions inside the very editor(number of items each world can have, tile categorization and similar) and the fact you can't export your game outside Astral Worlds. I just don't feel comfortable with my game being open for editing and butchering with an option right next to "Start New Game" option and with the fact I have to distribute it as part of Astral Worlds.
Astral Worlds is meant to be used for creation of RPG-like games but Astral Worlds is not your typical RPG maker nor a game made with it can be a typical RPG. Battles in Astral Worlds are real time and you can't implement any kind of long range weapon in your game(like guns). Astral Worlds doesn't feature the typical RPG experience based concept of character growth. Main game character only has maximum health, offence and defense points as changeable characteristics.
Overall, a very nice attempt. Might be suitable for kids who want to learn the basics of game design and can't code. The world editor is well designed and I doubt it can ruin anyone's sense or talent for game design. As for serious usage this editor simply fails to satisfy a more demanding user. I'm not saying you shouldn't use it. I just can't imagine someone being willing to cripple his game so much and leave it open for editing. But I doubt the designer ever had big expectations with this editor. The concept and the design of the editor show a lot of potential and this is something that really wouldn't be bad to remake and highly advance in FreeBASIC.
A note: From time to time, while working in the world editor, program might interrupt and return you to QBasic IDE. Don't worry, this happens very rarely and only upon entering a certain menu. Each time you leave any menu your changes are saved so no fear for your changes to be lost. You can usually return to the editor by pressing F5 in the IDE but not always.
The Game - Chief Dojoepa!
Chief Dojoepa! is a game made inside the Astral Worlds world editor and it really shows the full potential of the editor.
Being an Astral Worlds game Chief Dojoepa! features a specific design of the screen, controls, battle system and tile by tile movement. The very in-game screen is well designed. It does feature a rather small map space, placed in the left part of the screen, but this only adds a certain charm to the game and I don't consider it to be a notable flaw. In the top-right part of the screen is the game inventory, item equipping controls and the status screen, with information about character's health, offence and defense points and score. In the down-right part of the screen is the text box, an important part of the gameplay. Text box is used to display various messages, from objects you bump into to dialogues. Also, this box is used in small shops and other places where you need to pick between few options.
Game graphic is one of the best parts of Chief Dojoepa! featuring well drawn and designed sprites and tiles. The graphic does seem a bit EGA-like but absolutely nothing negative you can say regarding it's quality. Not a single tile seems out of place or wrong. Astral Worlds doesn't allow for walk animation to be implemented in a game but you really don't miss it in Chief Dojoepa! All the characters are well and skillfully drawn and the attack(swing) animations are flawless. Since Astral Worlds allows four different areas per world this game features four different tilesets. On the very beginning of the game, after you leave your house, you might feel that the animation feature of the world editor was slightly abused since the village looks a bit like a carnival.
Chief Dojoepa! story is quite cool with not so common theme in computer games. It starts with a story about ancient Hiktite Indians who lived on a group of islands long time ago. They've built sacred giant pyramids and inside these temples drew upon secret knowledge from the astral world to protect their people. They've lived in peace and prosperity for eight hundred years until evil and malicious spirit Volgare pillaged the four Sun God temples and started creating monsters to enslave all the Hiktites. You play the role of Dojoepa, the protectors of the last Hiktite tribe, and have to stop the evil Volgare and save your people. Some people might find the story too cliché but it reminds me on the good old days when the stories were sweet, simple and, pardon my French, bullshit-free.
Chief Dojoepa! gameplay is pretty much the result of the world editor features. You will learn very early in the game that your goal is to find the 4 sun stones and to restore them on the sun altars in the sun temples. Uh, the Indians and their fixation with the sun. To accomplish that you will have to explore over 10 temples spread over 4 islands. To enter the sun temples you will have to find golden idols(they look like masks) in order to unlock them. Sun temples need from 1 idol up to 4 idols to unlock them. You start the game inside your house and you shouldn't leave it before getting the spear. Unfortunately, Dojoepa is drawn like he already caries a spear which might confuse some people. Just don't leave the house until you solve this "get the spear" puzzle and equip it. Battles in Chief Dojoepa! are real time. The very fighting is not rocket science nor it requires some skill. You simply need to meet with a monster and tap on the SPACE key. Not with some crazy frequency but reasonably fast. Not all prefer this kind of battle system but I found it more amusing than those typical RPG, turn-based battles. A matter of taste. Items that help you in your quest are berries, potions, coins and rune stones. With coins you buy or pay various things in the game and it's good to have them. I recommend you to collect and drop coins in one or few places inside the game since you never know when you might need them. Potions and berries help you to restore your health. I don't recommend using berries and potions unless you really need them(you are in the middle of some nasty temple) since they are more useful when used with various wells. Rune stones are very useful objects which have the power to bring you back home from any location but don't use them for that! Rune stones are crucial in making your character stronger. By dropping them in Wells of Offence or Defense you can increase your offence or defense points. Also, this is important, the well in your village restores your health for free! You just need to keep bumping with it. I missed that with my first two attempts to finish the game and almost gave up on it since I thought it was too difficult. It's impossible to finish Chief Dojoepa! if you don't use the well in your village to restore the health now and then. Chief Dojoepa! gameplay mostly consists of exploring various temples, finding golden idols to unlock the sun temples, finding sun stones and restoring them on the sun altars. You will also find keys which are crucial and rune stones which should be used to make your character stronger. During all that you need to avoid or kill monsters. Chief Dojoepa! is not terribly linear like Elysian Fields or Dies Irae(ugh!) but there is a certain order you need to follow to be able to finish it. It's advisable that you visit the sun temples by order(first the one that requires one idol to unlock it, then the one that requires two idols and so on). Still, Chief Dojoepa! allows a lot of freedom in sense of character growth, items usage and ways of exploring temples.
Another important part of the Chief Dojoepa! gameplay are movable objects, in this game stones and pillars, which on quite few places form Sokoban type of puzzles. What some might find annoying is that you can block a path to a certain important location, like a temple, and only find out later in the game that you can't finish it because of that mistake. This can be very frustrating but makes the game very challenging. You need to be very careful when pushing stones in this game and to save before doing that. There are two areas on the islands map which are tricky but not difficult. Read the strategy guide I wrote if you need help in that department. What makes Chief Dojoepa! even more challenging are secret passages and temples are full of them. You simply need to bump into a wall where you suspect for a secret passage to be. Another thing that some might find annoying while other a great feature which adds a lot to the challenge value of the game.
Two things I didn't liked in the gameplay. First, locked doors. There is no any logic in which door requires which key so in the later temples, with every new door you encounter, you have to try out every key you carry to find out which one opens it. Even one "puzzle" in a certain temple is based on a door labyrinth that requires nothing but patience in key switching. Second, monster reviving. On most of the locations, after you revisit them, monsters will be revived. This is also a matter of taste. I simply don't like this kind of feature in games. I want for monsters I kill to remain dead. By the way, monsters you kill don't increase you character's strength in any way, only your score.
You will meet a lot of NPCs inside the game which are a source of more or less useful information.
What K.D.A.G. really succeeded with Chief Dojoepa! is to create an illusion of space and diversity and you really feel that this game is much larger than four 50*50 tiles large maps. I can only applaud him for cramping so much content on so little space.
The spelling in Chief Dojoepa! is not that good and on few place slightly amusing. A small minus.
I found Chief Dojoepa! very immersing and addictive and finishing it a very rewarding experience. Not all might feel like I do and might consider Chief Dojoepa! too difficult but I can't say nothing else but recommend it. Over 10 hours(if not much more) of playing it and 3 attempts to finish it must mean something. Just have in mind that Chief Dojoepa! is a tile by tile scrolling game, without Sound Blaster effects and music and without spectacular graphic. Chief Dojoepa! is excellent gameplay in it's purest form.
Astral Worlds is definitely something worth being downloaded. If for nothing else, then because of Chief Dojoepa! I hope I made someone curious enough to check out this interesting piece of work.
To download slightly edited version of Astral Worlds(some annoying bugs removed and few notable corrections like the removal of hard paths) with a strategy guide and a game demo made by me(The Unknown) inside the world editor click here: Astralworlds.zip
To download the original version of Astral Worlds(untouched by my dirty hands) click here: AWS1.zip
Both version run only from Windows 95(I think) and above(it works in Windows XP) and not from DOS since K.D.A.G. used spacing in names of his program files and DOS can't read that kind of files.
That was it for this first issue of Searching For The Unknown. Astral Worlds really took more time than I thought it would. For the next issue something more obscure, Star Trek: The Capture. I only played it for 30 minutes so far so can't tell what kind of game it really is. Stay tuned if you dare! :P
Visit Lachie's website, KENTAURI.
Qbinux, RapidQ and Legend of Aquarius
I had several extensive updates on various projects submitted this month, so I've created this new section for these articles. If you would like to share information about your project in the next issue of QB Express, send it along and your program can be featured in the next Projects column.
Qbinux - Sebastian McClouth
This is my first article and English is not my native language, so excuse for any mistakes I might make.
What is qbinux?
It's just a simple UI (UserInterface) based upon Linux written (obviously) QuickBasic (editorial note: version 4.5). I call it a platform OS because it needs DOS to run, so it's some what similar to 4dos. The name of qbinux is, just as linux, the name of the main core.
To answer this question we have to dig back in time. When I started getting interested in programming in C (which I stopped, to start once again, a little time back), someone told me that MS-DOS (when everybody was using windows 3.11 or just fresh windows 95) was programmed with C. From that moment the idea of building an OS started to grow.
A couple of years later we got connected to the internet and I started browsing for programs made in qbasic, then I found some gui's.
But it wasn't until I read in a PC magazine about Linux, and actually getting my hands on a Linux version (Red Hat 5.1), that the old idea came back to build an OS.
The first attempts had gotten the name qbinux. A name which I thought of in a minute due the fact that I was trying to build a linux-clone in quickbasic.
qbinux core: a short explanation:
After having read several documents and the linux source code (and ofcourse several building attempts) I found on www.petesqbsite.com in the tutorial-section/magazine section 4 tutorials which I found really resourceful:
- the first one, called "Making libraries" by Alan Copeland. With this tutorial I was able to build a library which contains all the needed core code, e.g. for the setup-program and even the UI.
- the second one, called "Compiling" by WisdomDude. I used this one to build the qbinux.bi to contain all the module statements used in the qbinux library.
- the third and fourth ones are called "QB scripting" by Chaoticmass and "Writing a simple BASIC interpreter" (part one, part two) by Vincent Peters. I have combined these codes in order to read the configuration files and qbinux scriptfiles.
I've been writing for over hour now so this is where I leave you all wondering about qbinux. If you want a copy of qbinux, you can mail me at firstname.lastname@example.org..
When you download the zip-file somewhere, you'll see I've included some part of these tut's in case you need to recompile/rebuild the whole thing.
RapidQ - Hezoe
Hi all. Today I'm going to tell you all about RapidQ. Please note that this is my first submission as I am relatively new to the QB (and FB) community.
RapidQ is a free multi-platform BASIC programming language. It can create text-only console, GUI and CGI applications.
RapidQ is very easy to use and great for beginners but can also create powerful applications. The integrated develpment enviroment (IDE) includes a useful form designer, requiring little coding, and syntax highlighting. A more advanced RapidQ file editor called Jens' File Editor is also available.
Unfortunately, the RapidQ was last updated by its develper, William Yu, in August 29th, 2000 and the source code has been old to REALBasic. The community for RapidQ is restrained a Yahoo! group which I am (in fact) not yet part of. The official RapidQ page is currently down, as is basicguru.com. So it quite hard to find support for RapidQ but a very detailed documentation is available.
Distributions are available for Windows, Linux, Solaris and HP-UX. The latest Windows version (BETA, .zip, 1.126Kb) and the documentation (312Kb) should be available on my website soon, if not already. I strongly encourage you to try RapidQ. Any comments can be sent to email@example.com .
TGSite is at: http://sitepalace.com/tgsite/.
Legend of Aquarius - anarky
Official Site - http://www.qbasicnetwork.com/loa.htm
There has been no real progress since the game's announcement in issue 9. Real life issues have forced me to work harder and longer than I have ever done before, and as a result, 90-100 hours a week on the job for weeks on end is finally starting to take its toll. I guess I'm not cut out to milk so many cows AND run a site AND make a game. A web presence is a priority, so the game was thrown on the backburner.
Right now I believe you are thinking "Just another vaporware product." I beg to differ. We have a functional scripting engine, the storyline complete and pre-scripting is underway.
You know the part where you start writing out the scenes, and all possible paths a character could take? But not writing it in a form the scripting engine can take? That's what we define as pre-scripting. (Stage 6)
To explain it better, here is our process:
- Preliminary plans - the stage where the idea is written down before it's forgotten.
- Mental building - where the game is played as is written.
- Flaw removal - tweaking the global story until it can be worked.
- Repeat 3 and 4 as necessary.
- Pre-scripting - the process of writing the scripting out as if you were watching a movie.
- Profiling - for each character in the game, profiles are created, generally based on concept and scripting
- Engine building phase 1 - we make a basic script engine.
- Scripting - take the scripts from stage 6 and modify them to suit the engine.
- Engine building phase 2 - modify the engine to suit the demands of the scripts.
- Storyboarding - taking the scenes and drawing how we want them in the game. This helps also with a graphical representation of how it will look, thus highlight the demands for certain features.
- Engine building phase 3 - taking the ideas from the storyboard and implimenting them.
- Sprite and tile design - we draw basic images to be used, generally not animated or well drawn.
- Testing stage alpha - testing the engine with some scenes written.
- Engine building phase 4 - modify engine to include all features, bug fixing etc.
- Artwork and music - adding the finishing touches...
- Demo - strip the full game to demo and beta test.
- Bug fix - meh.
- Announce release in 2 weeks - ah the suspense is killing me!
- Release - and be done with it.
I am itching to get in and start coding. But there is so much planning involved. I have an expected finish date of Christmas. It's good in a way that no one has hounded about the game, but just thought I'd give you an update anyway.
And who is the main character named after? One of the few little surprises we have cooked up for you!
Review of Sokoban by Peter Bakota (Sorel)
Written by Zap
This is Sokoban - It hardly needs an introduction. Or rather, it's Sokoban redone in FreeBasic, with a few new features. The download is 67KB, which includes over 300 maps (both the classical and other ones), well-written and commented sourcecode, and ofcourse the compiled game. You can download the game from this url.
I'm going to refer to this Sokoban as FB Sokoban throughout this review.
The gameplay of FB Sokoban is well-known to everyone who have played computer games for more than 5 years, since it is exactly the same as classical Sokoban, hence the name. There is no changes in gameplay from it, and there need not be.
To those of you who have not have the chance to play the classical Sokoban (or any other port here of), I'm going to explain the concept, which is very simple yet entertaining: You control a character who has the abilities to walk around, and push at the boxes scattered around the level. Your sole purpose is to push all of those boxes onto specified positions in the level. This may sound easy, but very often you will find that you have made a mistake that will prevent you from completing the level. Sokoban requires you to think, and you will likely spend most of the time you play starring at the screen, wondering how the heck you are to complete that level!
Here enters a flaw of FB Sokoban: If you can't complete the level, one keypress will take you to the next. This might or might not have existed in the original Sokoban, I don't know that, but I definitely think it's ruining for the gameplay. Once you find that feature, you stop trying to complete the level; you stare at it, see if there's anything obvious, and if not, you just skip it. It removes any sense of completion, since there's no showing how many levels you've actually completed, and which you have skipped.
If that feature was removed, it would be natural to add a highscore aswell, since there would then actually be something to brag about in reaching level 50.
The gameplay is not original, but that doesn't make it any worse, except for a single ruining feature.
FB Sokoban has huge bunch of levels included, actually more than 300 of them. They will keep you busy for hours - if not days. There are all sorts of variations, for example a whole set consisting of only very small maps, and ofcourse there's also the classical map pack. The game works seamlesly whichever map pack you choose, and you can download new packs off the internet (the file format is a commonly used one for Sokoban games); check the readme file for more information on that.
I don't know if any of these map packs are made by the author himself, but I like the fact that he included them for playing.
Level Design Rating:
They are good, challenging and there's a big bunch of them to keep you entertained.
The graphics in FB Sokoban is pretty simple. The player is represented with a circular smily-like creature, the walls are gray and well... wall-like, and the boxes also look abit like boxes. With that said, I have a few points where it could be improved.
First off, the player representation could use a loving touch. The smily creature gets boring to look at after a while, also because it has no real interaction with the boxes it pushes. There's no walking animation either, the smily just warps from position to position, and same goes for the boxes; not even a slide.
Secondly, the "inside" of the levels are just as black as the blackness that sorrounds them. Some floor tiles would have been nice.
However, even if these features would make the game more interesting to play, there's nothing wrong or gameplay-limiting with the current graphics, I'm just giving advice on how to make it better.
Simple, it works, but could be more interesting.
SFX & MUSIC
This often ignored side has been ignored once again. Considering how easy it is to add music and sound effects with FreeBasic, I'm really dissappointed that there is none. While this doesn't destroy the game in any way, it would definitely make this game even better. Some fitting background music, and effects when pushing blocks, moving, and so on.
None, it would improve this game very much if there were.
I havent rated this game for originality or anything like that, since I'm just glad to see a well carried-out port of this game - and this one definitely is. It does have several points that could be improved on, however, for example actually having sound/music would greatly improve the game, and smaller things like animated player graphics would be nice too.
Well carried out port, hours of gameplay, but has a number of points to improve on before this game is anywhere near perfect.
Visit FreeBasic.tk, or download FB Sokoban!
Interview With Sumo Jo
Conducted by Pete
A few weeks ago, I sat down with Sumo Jo, who among many other things is the new owner and administrator of QBasic News. We had a discussion (I wouldn’t quite call it an interview) about the state of the Qmunity following the traumatic shutdown of QBasic News last month. Hopefully it will answer some questions that you have about the details surrounding the event.
Here it is in all its glory.
Welcome Sumo Jo, and thanks for the interview.
Glad to be here. With the last issue of your mag casting a bit of negative light on QBasic News, I wanted to write something or be interviewed in the next issue to restore people's faith in QBN.
How do you feel about QBN?
Well, there was absolutely no reason for Wildcard to pull all that crap. He may own the site and server, but the content definitely belonged to the community. If he wanted to shut down the site or give it away to a new owner, that’s his decision – but deleting the site without warning was just a low blow.
I agree, but sometimes people don't do the right thing when reacting to emotion. I understand how a lot of people feel as if they've had something taken from them. (I felt that way too.)
But I think Wildcard’s recent moves show he's able to make more mature decisions (even though they don't completely redeem him). Everyone makes wrong decisions. It just so happened his got to be in front of everyone, and affected many.
What kind of effect do you think it had/will have on QBN and community?
Well, Wildcard ruined his and QBN's reputation in the mind of a lot of people – a great reputation that took him four years to build up. I think it's going to take a long time for QBN to return to what it was last week…let alone three months ago.
Or a year. :-) (Although when Freebasic debuted it seemed to be at its most active peak since its earlier days.)
Unfortunately for QBN, most of the mature, intelligent FB coders have moved to V1ctor's new Freebasic.net forums, and all of the colorful, opinionated people have moved to The Basic Network. The only people left at QBN as far as I can tell are people that don't hold grudges, a few newbies and... AAP. (heheh)
Haha, yeah. I'm noticing that too.
Freebasic.net unfortunately was probably the best central location for FB community as that's where it came from. Although it spread fast on QBN, it never made sense that an unofficial site was the central hub for it. I’m not saying that it bothered me, it just seemed odd that it worked that way.
So I have a feeling now that it's set this way it'll be hard to change that back -- if possible. The TBN loyalty will stay as long as Nekrophidius convinces people that QBN is evil and he knows all. Not to bring back up the argument between Nek and Plasma on your board, but Plasma made the good point of how Nek who had left the community for all his home responsibilities was more than ready to reopen TBN within in minutes of QBN closing.
Nek is a big hypocrite. He's "left" the Qmunity at least a dozen times since I've known him.
He also rarely finishes anything he starts, but he starts about a dozen projects a week… (cough...V Planet!, Gaming Golds, FBXL…cough)
Haha – another point agreed upon.
Nek has to have someone to cast stones at, or things don't work with him. Whether AAP, Wildcard, QBN or Plasma. Someone who "sets off his bullshit sensor". The all-knowing Nek already knew what would happen at QBN because he can predict all.
Somehow though he's never gotten pissed off at me. I'm surprised. (Ed: He might after this!)
I thought I'd get to see some Nek wrath after disagreeing with him about his crazy conspiracy ideas on QBN. Instead though, he agreed with me.
I try not to get into flame wars with people... plus I do like Nek.
I think he has a lot of potential but many downfalls. But who doesn't?
Mike Doise. All downfalls there. Heheh.
Haha. That was the only thing I made Wildcard promise when he said he would be transferring QBN. I said "even if you don't choose me, don't give it to Doise."
Was there anyone else in the running to take over QBN?
It was given to Dav who gave it to me to officially own. He's staying as admin but doesn't want full ownership. Jatos was also trying to get it very hard, he was actually going around to different people in the community wanting a partnership with them, but when he would talk to the next person he would explain that he didn't really want to partner with the last and really wanted just to partner with them. I think even though I told him many times that I had no intention of partnering with him, he seemed to think I did. He decided to PM Wildcard saying that he had partnered with me, Z!re and some others. Even though he told me he didn't want to partner with Z!re and he told Z!re he didn't want to partner with me, and didn't want me to get it.
I'm sure Wildcard would have been glad to give the site to Z!re anyway, judging by their spat on the day that QBN shut down. ;-)
Haha. Actually Wildcard and Z!re both have sent PMs back and forth forgiving each other and apologizing. Wildcard said he incorrectly took out his anger on Z!re and felt very sorry for doing it.
So was their argument the reason why Wildcard shut down the site?
He was frustrated and felt overburdened, and the logical idea of passing on the site didn't occur right away. So he reacted out of anger and closed it. Upon thinking about it for a few days, he realized he needed to leave this open with all it's information for the community
Now that's the thing I don't understand -- how can you feel frustrated and overburdened running a forum? He could have just abandoned it and it would have continued on just fine.
He had been letting it go. And in the moderator forum they all posted how they hadn't been around much, and how they were noticing more and more personal attacks. They were getting PMs from many users asking why it was being allowed. Wildcard took the tone of some of the suggestions in the "personal attacks" thread as angry and got angered. The reason he never posted a thread about what he did or why he did it was that he felt he should just back out and leave without it looking like any more of an attention stunt.
Personally, I don't really mind personal attacks … I think flaming is hilarious. And if you don't like it, don't read it and don't reply.
Haha, I like flaming, but believe that there are places for it, I guess. I mean I like more lax rules – that's why I opened QBasic.tk originally. Just to have fun and post whatever I wanted. People joined that liked that idea. But I think the reason QBN worked so well was people felt safe from those attacks there, and felt it was more structured. It's why nothing ever came of the first launch of TBN and why QBTK/FBTK has never gotten huge. They're just places for people to release. But places with rules (even though most people don't seem to like them) seem to do better. Must be a human want for rules. I guess if what people wanted was a more lax environment, TBN or QBTK would have taken off.
Yeah, I guess you're right.
Though I do get so angry when anyone gets disciplined for breaking rules -- like bannings, posts deleted, censorship (even of swears and stuff) -- everything except for deleting spam / accidental posts. That's why QB Express is an "open" magazine...(though the free speech hasn't been taken to its full potential.)
I agree with you and probably will never delete a post. We never have at QBTK or FBTK. But QBN is set up with rules for those to follow and that's what has seemed to help things move there. It sucks doing it for me because I've always been more lax…going from FBTK Sumo Jo to QBN Sumo Jo. I actually thought about creating a separate admin account at QBN that I could use to keep things going, but decided against it. I originally though the separate account would keep from there being confusion of me having to play the two extremes. I mean, in the most recent AAP birthday thread there were a bunch of flamebait posts posted. I posted a bit after asking for them not to continue. But a few months ago I was posting those flamebait posts.
The other reason I want to keep QBN rules intact is I've already heard rumors (even before I knew I was owner, when there was just rumor) that people were worried I'd turn QBN into a QBTK or QBTK – and kill it. I can’t let that happen.
So, do you have any big plans for QBN?
I don't really have any huge changes in mind for QBN as I feel it has worked the way it is for so long that the system it needs seems to already be in place. Maybe a few mods and some site redesigning (and addition of moderators) but other than that, I think QBasic News worked well with what it had.
I see. So what do you plan on doing to attract new users / get the old ones back? Just keeping QBN the same as it always was?
That's the question I don't know how to answer yet. Right now I'm letting things stabilize seeing what happens. But I know if something needs to be done to bring people back, it needs to be done now before it's too late.
Alright, on a different note – do you have any other big QB / FB projects in the works?
No big QB/FB projects, but more site projects with Zap. We're redoing much of QuickHost now (turning it into FileaAchor) and adding features. Zap's working on writing a forum that we'd host for people that want forums. Something like freehosting mixed with free forums.
So you're planning on offering free hosting for QB & FB sites?
We already pretty must host any site that asks us that is QB/FB related. This will be a forum hosting service where anyone can create a forum. But it will not be limited only to QB/FB sites; it'll be open to everyone just as Fileanchor is. When we redid QuickHost the first time (to make version 2) we decided that we could offer everything we had to everyone, to help everyone that needed it.
Sounds great. How long does the free hosting last on the new FileAnchor?
3 months, then you have to renew it. Same as QuickHost now. If things take off with FileAnchor like we hope they will, we'll move to offering more space and more time allotted for files.
That's very generous -- but how do you finance all of this free hosting you're providing?
Haha, work more. :-) We have Google ads placed on FBTK and FileAnchor, but they haven't generated enough money to pay for it. Or to pay me anything at all yet.
So you're basically paying entirely out of your own pocket?
Yes. For now everything is out of pocket. If FileAnchor expands, then I'd probably move to a different ad company with banners to help support larger servers.
Well, hopefully you find out some way to make a profit on it – or at least make it pay for itself.
That'd be nice, but it wasn't why I did it, so it's not a worry to me now.
Well, that’s all I have for now. Do you have any final comments?
The only thing I'd really like to make known is that I wanted to get QBN to make sure it stayed open for the community – whether it's used or not. I have no intention of letting it turn into QBTK or FBTK, for those who have that belief.
Oh, and that I'd like to see more people drink milk. It's good for you :-)
Alrighty, thanks a lot for the interview! I wish you luck with QBN...and FBTK and FileAnchor.
Thanks. Seeya later.
QBasic News is here, but you already knew that.
Written by Pete
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. We will bring you these awards on a monthly basis to help give credit where credit is due.
Site of the Month
Webmasters: Fling-master & Jofers
It's been ten years, but QB45.com (formerly Future Software) is still alive and kickin'! For as long as most of us can remember, QB45.com has been one of the biggest and most important QB sites anywhere. Its ENORMOUS QB files archive has always been (and still is) its main draw, though original creations by Future Software and its active forum community have kept people coming back.
The site was started as Future Software in 1995 by Jorden Chamid -- it was originally an FTP site if I remember correctly, and then evolved into a full-blown website shortly thereafter. Jorden headed Future Software during its golden years, getting together a huge programming "company" that made many very useful programs including the popular Future Library. Jorden also built up FS's collection of QB files to the largest anywhere, and added other content including reviews of QB sites, the QFinder search engine, the shared Qmunity chat room that he started, the QB Times magazine, and a whole lot more. Eventually Future Software got too big to be hosted on a handful of free Hypermart accounts, so Jorden moved it to a private server and registered the QB45.com domain name. He officially changed the name of the site and expanded it into a multi-language hub that became the center of the Qmunity.
When Jorden Chamid no longer had time to keep QB45.com updated, he sold it to Wildcard who kept it running as-is for quite some time. It looked like QB45.com would continue on, and continue thriving, without the guidance of its founder. But the continued prosperity under Wildcard wasn't to last. When Wildcard decided he no longer had time for QB45.com and wanted to sell it, the death knell sounded. A fellow named Mike Doise bought it, and decided to "upgrade" the site by installing the PostNuke content management system. But the script was poorly implemented and Doise decided to leave out a lot of the old content when he redesigned the site. And then shortly after Doise's redesign, PostNuke crashed and the site went down. Many people thought it was down for good.
Fortunately, the QB45.com domain name expired a short time after the PostNuke crash, and a former member of the QB45 community snatched it up. Working together, the QB45 fans created a new forum at QB45.com domain name. And then a redesign effort began, headed by Jofers and Fling-master. The process was slow-going, but it has FINALLY been completed. Late last month, the new QB45 launched. And it is good. Awesome, in fact. And that's why the site gets the award this month.
What's most amazing about QB45 is its longevity. Despite constant ownership changes, server switches and crashes, the site is still up and -- for the most part -- doing what it's always done: hosting hundreds of QB files and acting as a Qmunity forum hub. This site has been through far more than most sites could endure, but its core fan base is so strong and active that they just won't let the site die. And that's really a great thing. QB45.com is an indispensible cornerstone of the Qmunity, and everyone can now breathe a sigh of relief to know that it's back up and in good hands.
Programmer of the Month
SJ Zero has been pretty busy this past month. Not only has he released two different FB game demos, he has also done two more QBXL audio editions and redesigned the QBXL.net website. That's pretty darn productive, if I do say so myself!
SJ Zero released beta v0.5 of his space shooter, Star Phalanx late last month which you can see in the screenshot to the left. It's still in early development, but the demo is very playable and worth a look. SJ's other programming accomplishment was the latest demo of his RPG, Quest For A King. Version 1.5 of QFAK has improved graphics, and all the features you'd expect in an RPG (this is no walk-around demo -- it has a story, a battle system, music, menuing systems, items and all that jazz). This release is the first version of the Windows / FreeBasic port, and I highly recommend it. You should definitely check out the demo. SJ Zero says: "Quest for a King is in constant development. It will be the longest, most intricate, and best of my projects." I wholeheartedly agree.
Rattrapmax6 is back this month with another QBasic Horse Humor comic!
Ecosystem Simulation Through the Use of AI
Written by Deleter
This way of doing things is called Gray Matter Simulated Intelligence Systems. GMSIS aims to make the probability for any given set of outside inputs gray, or non-specific. If you want a realistic ecosystem feel, GMSIS is probably what you want. It supports system dynamics and has the function to create your own ecosystem. This provides a new type of immersion for your games. Interested? Read on.
Absolute Deterministic Systems will always fail.
Read that statement and then read it again. Think it, breathe it, and realize it. Now, turn it on itself. That’s right, apply its own message to itself. Isn’t it contradicting itself? Because aren’t you, by seeing an absolute deterministic system and saying it will fail, doing that by an absolute system of logic? So, what does this statement have to do with AI, if it appears to contradict its self?
To understand the relationship, you first have to understand what AI, in the current sense of the term, implies. Artificial Intelligence is basically any mechanism, or system, designed and created to take a set of circumstances, in the form of variables, and then make a decision and carry that decision out. The first game AI, which was in a pong game, simply told the paddle to follow the ball. It took in the single variable, and did its best to match it.
So, now I have showed the statement contradicts itself AND given an example where it is flat out wrong. "What’s up here?" You’re probably wondering (or something along the lines of, "What’s this crazy bastard saying now?!?!"). Technically, the above statement is a paradox, in invalidates itself. Its existence demands its non-existence. One word takes this paradox and flips it around to become the main idea behind a better AI. Since it can’t be true in all cases, it obviously depends on the system. Before we continue, I need to define a system.
A system is basically a construct of elements that is self involved in such a way that the loss any particular element of the system suffers is corrected by another element. Elements need to give and receive, the system cannot be stagnate. This system will reach a stabile flow from one to another given sufficient time. If you have ever had a chemistry class, just think of equilibrium.
In a two element system, it has failed, if it has lost one of its elements through neglect, in other words, an element spends all of itself (or all of itself is spent) and not sustained. By losing this element, the system has failed, for the remaining element cannot receive what it needs. If a three-or-more-element-system loses an element, but manages to reach stability despite the loss, than it has not failed. In fact, the loss of an element can be necessary to the survival of a system. For example, an element that consumes too much, while releasing little can be lethal to a system.
Intelligence deals with systems. Life requires systems to survive. Food Chains demonstrate this in that the individual elements require something other than what they produce, and thus make a large loop when all the needs are coupled with products. Example: Zebra’s need grass and plants and produce meat (among other things). Lions need meat and produce fertilizer for the grass (when they die). Although it is more complicated than this, since elements couple with a variety of other elements, this shows the basic relationship of a system.
So, where is AI in all this? That’s easy, to simulate intelligence you need to implement a system. The difficulty of implementing a system, on the other hand, can be as hard as you are willing to work on it. So now the question becomes, "Where do I start, how do I do this?"
Step 1: Pre-visualization
With such a complicated topic, it is a necessity that you sit down and think before writing that SCREEN (or TYPE, DECLARE, ‘$INCLUDE, etc...) command. First and foremost, get an idea of how you are going to handle inputs, outputs, and needs. These three things are vital to the success of your project. Next, start defining possible I/O and Needs (ION’s). Example: Hunger, Energy (needs). Food (In). Go Eat (out). How many you have is up to you, keep in mind both that for each one you add, you are adding one more level of complexity in your code, and also that the more you have—provided that you implement them right—the more realistic and life-like your system is going to seem. You can also get an idea of what types of creatures you are going to create, as it will help with defining ION’s, but this isn’t really necessary since you aren’t actually creating the system yet, just the handling of systems.
I would suggest that before you move onto the next step, you have all the ION’s you want written down and have a simple idea of their relationship and how they will interweave your system.
Also, know how complicated you want it, and stick to it, expansion or contraction with imprecise systems (simulation AI) can be very messy.
Step 2: Translation
Now that you have the system handler down on paper, its time to get that into code, i.e. translate it into variables. Although you can do any type of variable system you wish to define your ION’s in your code, the best move is to combine everything into a TYPE. This way, you can easily get multiple creatures and debug your code. Within a type statement, it’s a good idea to use statements such as "Health as DOUBLE" rather than "H as Double" or something even more cryptic. This way, you don’t have to keep referencing the TYPE code because it is easy to remember. Also, use (‘)’s or REM’s to segment the different variables into the different groups of related items.
You should make another TYPE for inputs (should include location variables, var’s for type of input, source of input, and amount/degree of input). Inputs are just as important as outputs and needs, since your input system is what the AI uses to get a ‘grip’ on its world.
Needs are usually translated to stats such as Health, Energy, etc. as I mentioned above. To help simulate real life better, it’s a good idea to include variables that modify the rate of decay for these stats. These modification stats usually are static, or very slow to change. To clarify, the counterpart of Hunger would be Metabolism because a faster metabolism would cause the Hunger stat to decrease faster. You can use a random number for this, or if you are doing something as complicated as breeding, you can combine the stats of the parents.
Step 3: Processing
So far we have a clear plan of attack and we have set up a structure that will support our AI. Now we have to set up the grand calculator, the gray matter of our AI creatures, if you will. It is difficult to explain this calculator in definite terms, since your stats can vary to such degrees. Therefore, I will tell you an all-encompassing description of what you need, and you will have to divide that up into your own individual AI processing core (AICP).
Before dwelving into the depths of this mechanism, you need to understand what fuzzy logic is, read this entry from wikipedia.com first to understand it. To make it specific to what I was saying, I will show you one of the parts that is most relevant.
IF creature.hunger THEN eat
IF creature.hunger is great THEN must eat
IF creature.hunger is alot THEN really should eat
IF creature.hunger is avg. THEN ought to eat
IF creature.hunger is low THEN eat if convenient
IF creature.hunger is no THEN don’t eat
This example adds varying levels of needing to eat which could be translated into your world as whether its worth taking a risk to eat.
This example is only two variables, allowing little variation. As you add more and more variables, your logic can grow exponentially, adding variety (read: flavor, interest, re-playability, etc...) to your creatures actions.
Although the definition of fuzzy logic has no room for random variables, our code can fit it in. By adding slight randomness to the statements before but not after the THEN, we can add even more randomness. Note that by doing this, we are adding instability to the system and completely unpredictable elements (unstable) will ruin a system—or themselves. It will probably take a lot of testing, but basically, you have to make sure the system will stabilize (balance).
Ok, so how do we calculate this moshpit of needs and inputs to determine outputs? We need an equation that finds the importance of each need that takes into account how much its needed, how much it will cost to get it, and risks.
A need is easy to get: it is just the direct variable perhaps multiplied by an importance factor (thirst is most important, then hunger, then sleep, etc...).
The second is not as easy. For this part, you will need a simple memory system, how complicated you make it is your choice. Basically, this just has to hold a value that tells the cost to get there; for example it takes five energy due to the walking, which then takes 2 hunger, etc. This will use memory based on your AI’s current area and destination area. Areas will be discussed later on.
Risk determines the integrity of the data. Think of it like this: You would rather go to a restaurant 2 miles away that you’ve been to 100 times as opposed to the strange new joint that opened up 1 mile away. This is easily implemented, just define a variable for the average of the data, and a variable holding how many trials have occurred. Every time you get a new value, add it like this:
Integrity = Integrity * (trials – 1) / trials + new value * 1 / trials
Then, take the integrity, multiply it by an importance factor and then divide cost by that product. This way, the lower the integrity of the situation is, the higher the cost becomes. The importance factor determines how much your AI will risk. In other words, how cautious your AI is.
Risks are also the situations of getting hurt or killed. To calculate the chance of this, your AI has to keep track of areas. I will talk later about dividing maps/game worlds into areas. For the current moment, we will just assume that the AI keeps track of area’s in which it got hurt. This will be sort of like the integrity formula. Each area shall be remembered as a whole, so for any given area, there will be a risk factor of getting hurt. Although an AI may get hurt in an area that is really safe for the most part, it still would prefer this area than in an area that is more dangerous and has hurt it more times. At first, the AI is weak and more prone to danger, and getting hurt. But, just like a child, it will learn after more trials.
Now that you have the need, cost, and risk, you have to calculate them. Since the risk value is calculated into the cost variable, it is just the processing of cost and need. You will now have to compare the different values to come up with an output. Use fuzzy logic to compare the practicality of choosing each stat. Then sort them in order of best to worst and choose the best.
Because of the limitation of current household computers, giving the AI the ability to learn and distinguish certain areas as groups is impractical. It is also 100x harder than telling him. Basically, in the I/O –intensive way that I do things, each object in the world would have to have an output of some sort with which the AI could sort. This is quite impractical considering the size of an average level and the average amount of objects. If you want to do this, go ahead it’s your game, and you might pull it off. Otherwise, what you should do is include a variable in your map TYPE that holds what group each tile/map segment belongs in.
It would also be good if you separate it two ways: General and specific. General would be water, specific would be this particular river. By dividing your map this way, you are in essence cutting the AI’s food into bite size pieces. AI’s will then chew it the rest of the way. I.e. they will take your separate objects and learn them through experience. Example: The AI jumps into water and drinks (general). It know knows that water is where drinking is best served. This particular river (specific group) contains water serpents that attack the AI. Since the water does NOT generate the output, the damage is remembered in this particular stream and will be calculated in the future in this fashion.
Moods and Emotions. These can be used to affect an output directly. Basically, if a creature is angry, it might not care about wasting energy and taking bigger risks than usual. If a creature is depressed, it might sit on its butt instead of going and eating. This either overrides or heavily influences the output. To moderate emotions/moods you can have an importance variable. This would be maximizing emotions for an emotional creature, or minimizing their affect on a controlled creature. Emotions will give your creatures a human feel, because it seems that animals don’t show emotion, at least not in a magnitude even close to that of humans.
Dynamic Memory size. This is more of a fantasy than anything else, since it would be so hard to implement. Basically, although the variable would be configured for the maximum, you would have a limiting value that would limit how much it can remember. This wouldn’t apply to the memory of costs and such, but rather it would affect the number of specific locations an AI could remember.
Periodic Influences. Humans’ moods, minds, and bodies can be measured in sine waves. These are separate it into Emotional/Spiritual, Mental, and Physical categories. The period between the three is different, thus making repeats rare. You may want to use this to simulate life. Another example can be seen in animals. They usually have mating season which, when you think about it, is periodic.
Group Dynamics. Add an input/output that establishes a leader of a group. This would be the leader of the pack. For a more herbivore feel, add a need for community and have each give an output that basically says, "I'm here". Thus they would tend to flock together, following the creature most in need.
There are so many options when creating AI that no one can tell you which one is right for your game. Unfortunately, GMSIS is processor heavy and requires sacrifice of graphics to be truly effective. On the flip side, you can manage a different type of immersion into your game that someone was looking for. If you want unspecific yet directed AI, GMSIS is designed to fit just those specifications. The unspecific nature of GMSIS itself allows you to customize it to fit your needs. In the end, you are going to have to compute all the values in your extremely superior gray matter and see if the Gray Matter Simulated Intelligence Systems is what you want.
Thank you so very much for reading all this, I really want criticism as well, since 2.5K+ words is overwhelming for one person to perfect.
Always remember; send all comments & questions to firstname.lastname@example.org
Download a MS Word version of this article, or visit Deleter's site, Random Musings of a QBasic/FBasic Game Programmer.
DATA VALIDATION IMPLEMENTATION
Written by Moneo
How many times have you heard the old saying “Garbage in, garbage out”? Some programmers use this line when their application doesn’t work correctly because of invalid data. Most of the time, the invalid data is a direct result of improper or no data validation in their programs.
This document will focus on defining the data validation procedures required for the most common data types, which are:
- Values or amounts
- Names and Addresses
At the end of this document, you will find suggested functions and subroutines which are referenced by the procedures for data validation.
1. VALUES OR AMOUNTS
Values or amounts are data fields which will normally be used in arithmetic calculations. The following are the most common considerations for this data type:
- Is it numeric?
- Can it be zero?
- Can it be negative?
- Can it contain a decimal point?
- Is there a minimum value, a maximum value, or both?
The above considerations can all be covered by the following pseudo-code procedure:
SIGN = 1
DECIMALPLACES = 0
READ OR GET THE VALUE INTO AMT$
IF IT CAN BE NEGATIVE THEN
IF THE FIRST BYTE OF AMT$ = “-“ THEN
SIGN = -1
DELETE THE FIRST BYTE OF AMT$
IF IT CAN CONTAIN A DECIMAL POINT THEN
DECIMALPLACES = THE NUMBER OF DECIMAL PLACES ALLOWED
Rem Perform the function NumDecimal
IF NOT NumDecimal(AMT$,DecimalPlaces) THEN
DISPLAY AN ERROR MESSAGE (NUMERIC OR DECIMAL PROBLEM)
IF THE VALUE CANNOT BE ZERO AND AMT$ = ZERO THEN
DISPLAY AN ERROR MESSAGE (ZERO VALUE NOT ALLOWED)
IF THE LEADING BYTE IN AMT$ IS A ZERO THEN
DISPLAY A WARNING MESSAGE (VALUE WITH A LEADING ZERO)
Rem A leading zero could be an indication of a keying error.
IF SIGN = -1 THEN INSERT A “-“ INTO THE FIRST BYTE OF AMT$.
IF THERE IS A MINIMUM VALUE, INSURE THAT AMT$ IS NOT LESS THAN MINIMUM.
IF THERE IS A MAXIMUM VALUE, INSURE THAT AMT$ IS NOT GREATER THAN MAXIMUM.
Values and Amounts - Edit for Reasonableness
Some poorly designed data entry forms create situations which must be edited for reasonableness.
|Input the number of days worked last week.|| ||Input = 1|
|Input the total hours worked last week.|| ||Input = 35|
The number of days worked of 1 is valid, as is the total hours of 35. But, they don’t coincide with each other --- they’re not reasonable when considered together.
In this example, the program determines that the two figures are not reasonable, but cannot determine which, or both, of them are wrong. The only alternative is to issue an error message and re-capture both figures.
After regular numeric validation, values and amounts may require additional editing for reasonableness. Here are some examples:
- Is the Cost Amount of an item greater than the Selling Price?
- Is the Selling Price minus the Discount less than the Cost?
- Do the number of years seniority of an employee exceed his age?
- Do the number of weeks accrued vacation for an employee exceed his total number of weeks of seniority?
Codes are data fields which are not used for arithmetic, even though they may be numeric. They are used as identification or reference.
The following are some common codes: Social Security Number, EAN or UPC article number, ISBN book number, telephone number, zip-code, etc.
100% validation of this type of code requires an updated file with the latest codes, provided by the organization responsible for its maintenance. Beware of copies of these files which are not issued by the responsible, official organization.
Your application may not require 100% validation of these codes if it is only going to use the codes for general information. Example: If your application is storing the user’s Social Security Number, but never uses this number for any official document like a W2 or 1099 form, then the number can be considered for general information only.
Codes like EAN, UPC and ISBN can be partially validated to some extent by verifying the check digit, the algorithms for which are readily available.
These are codes unique to your application, like: Inventory Number, Member Number, Status Code, Transaction Code, etc.
If the user is providing one of these codes as input, you must validate it. Here are some considerations:
- If the code is unique to this program, that is, it is not referenced by any other program, and there are only a few combinations, then you can validate the code with some IF’s or CASE statements, or by using an array containing the valid codes. Keep the validation code as simple and straightforward as possible, so that future modifications to the codes can easily me made. If there are many combinations of the code, then you should maintain them on a file, otherwise you will be modifying your program on every update of the codes.
- If the code is not unique to your program, that is, it is referenced or maintained by another program, then the valid codes must reside on a file.
- If you are designing the codes, keep them simple, and without any specific meaning. For example, if you were designing the part number for an inventory system, don’t fall into the Industrial Engineering type trap of designing a meaningful code, like: 2 digits for department, 2 digits for style, 2 digits for size, 1 digit for color, etc. The code might look pretty that way, but remember this old axiom: “The more intelligence you put in a code, the quicker it will corrupt.”
Why? Because things change. You now have 85 styles which fit nice into 2 digits. Next year you discover that the inventory has to handle 110 styles. What do you do? Convert the entire inventory system to add a third digit to style? Or, keep to the 2 digits and make all the new styles an alphanumeric code, having to change a bunch of programming? You get the point.
One argument for intelligent codes is that the users can remember them better that way. In reality, the users will get to know and memorize the codes anyway. So, if you have let’s say 100,000 part numbers, I suggest that, allowing for expansion, you start assigning 7 digit part numbers in the range of 100000c to 300000c with your favorite check digit “c” on the end. You can assign these part numbers in any order that you like, preferably random.
If valid codes, common or proprietary, are provided on a file, then every time you go to use one of these external code files in your application, first run the file through a small format verification program to insure the following:
- If all the codes are supposed to be numeric, check them. You can do this as follows:
IF NOT NUMSTRICT(CODE$) THEN DISPLAY CODE NOT NUMERIC MESSAGE …
- If the codes are supposed to be fixed length, check it. If not fixed length, check the minimum and maximum code size defined.
- Does the file contain an expected number of code records?
- If the code records are supposed to be in sequence, check it. Be careful, some variable length numeric codes may be appear on the file left justified in the code field.
- Watch out, codes are not values, they may contain leading zeros.
- Note: Finding an invalid input code on an external code file is just as bad as not finding a valid code.
Proper validation of date fields can be a real programming challenge. Watch out for the common pitfall of using a two-digit year --- remember the Y2K problem. The validation of the actual digits of the date is compounded by required input formats, such as: MM/DD/YYYY, DD/MM/YYYY, YYYYMMDD, and many others.
Some programs circumvent the format problems by having the user select the day, month and year from combo boxes. But even using combo boxes, after the date is obtained, the program still has to validate the days per month and the leap year for 29 days in February. It is possible to implement sophisticated, dynamic combo boxes, processed in the order of year, month, day, which would handle the mentioned verification.
After we have processed whichever the input data format was required of the user, we end up with an eight byte string containing YYYYMMDD. This is usually the most common format required by date validation routines.
An example of using a date validation routine:
From the Suggested Functions and Subroutines at the end of this document, setup the Date Initialization Section at the beginning of your program, and include the Date.Check Subroutine in your program.
Z$ = the date string in YYYYMMDD format
IF DATE.OK = 0 THEN PRINT INVALID DATE MESSAGE …
Dates – Edit for Reasonableness:
Here’s an example of a common edit for reasonableness:
The input program for a university entrance application asks for date of birth. The user enters 12/23/1855 which is a "valid" date, but is not "reasonable" for this particular application, since the entrance of a 150 year old person into a university is not reasonable. Thus, a warning message should be issued.
Other common problems occur when the user is asked for a range of dates.
- Is the from-date less than the to-date?
- Can the from-date be equal to the to-date?
- How far into the past can the from-date be?
- Can the to-date be into the future?
- Can the from-date be less than an already provided date?
- Can the to-date be greater than an already provided date?
Additional needs for editing for reasonableness are often brought about by poorly designed input forms.
Example: The program requests the user’s date of birth, and also his age. This is not simple to validate. Does the program really need to store both fields? Probably not, especially since his age is subject to change. Request the date of birth only. Then, if your application requires it, your program can generate the age value. (The code for this is available upon request.)
4. NAMES AND ADDRESSES
At first glance, names and addresses seem to be very simple to capture. Much depends on how the application is going to use these fields. After we store this information on a file, here are some of the issues:
- Do we want to produce reports in Last Name sequence?
- Do we want to produce reports in City and State sequence?
- Do we want to produce envelopes in Zip Code sequence?
- Do we want to do a lookup by Last Name?
If we need to do any of the above, we need to format and validate the names and addresses. Here are some recommendations:
- Determine the maximum field size, and set aside separate fields for input and file storing of the fields, as follows:
- First Name
- Middle Name or Initial
- Last Name
- Second Last Name or Mother’s Maiden Name (optional)
- C/O (Care of – optional)
- Street Address Line 1
- Street Address Line 2 (optional)
- Street Address Line 3 (optional, only allow if have Addr Line 2)
- Country (USA or other full country name in English)
- State Code (optional if Country not USA)
- State/Province/Etc. Name (mandatory if Country not USA)
- Zip-code (optional up to 10 characters if not USA)
- Special characters allowed in names: Only allow ‘.- and blank unless you determine otherwise. Also, do not allow accented vowels or other diacritical marks, or you will have never-ending headaches.
- Preferably, use SOLID CAPS for all name and address fields. This avoids names that begin with lowercase letters, especially in last names. It also makes sorting and searching much simpler.
- If the user’s name and address information is critical for the application, I suggest you find a way of delivering the information to the corresponding user, by report, email, or other, and having him sign acceptance of the information.
- If the zip-codes are to be used for mass mailing, I suggest you obtain a validation file from the United States Postal Service.
I did not perform an exhaustive analysis on the subject. Most of the recommendations are based on recent experience. I am certain that as you browse through this document, you will think of other circumstances which require data validation considerations.
An IT manager once said to me: “You cannot do things 100%.” This may turn out to be true in general, but if you start out developing an application with this predetermined, erroneous attitude, then you will never achieve 100%. You must “go for the gold”. You must shoot for 100%.
SUGGESTED FUNCTIONS AND SUBROUTINES
REM | D A T E I N I T I A L I Z A T I O N S E C T I O N |
DECLARE FUNCTION NumDecimal (Z$,DecimalPlaces)
DECLARE FUNCTION NumStrict (Z$)
DECLARE FUNCTION IsLeapYear% (Z)
DIM DATE.OK AS INTEGER 'Valid date indicator: -1=True, 0=False.
DIM ZYY AS INTEGER 'Value of the 4 digit year.
DIM ZMM AS INTEGER 'Value of the 2 digit month.
DIM ZDD AS INTEGER 'Value of the 2 digit day.
rem Setup days-per-month table.
DIM ZMO(1 TO 12) AS INTEGER
FOR ZMM=1 TO 12:READ ZMO(ZMM):NEXT
REM (Application specific code goes here)
REM **************** DATE.CHECK SUBROUTINE **************************
REM *** VALIDATE A DATE IN YYYYMMDD FORMAT.
REM * INPUT: Z$ = Given date in format YYYYMMDD.
REM * OUTPUT: DATE.OK = -1 if input date is VALID. (true)
REM * 0 if input date is INVALID. (false)
REM * (if VALID):
REM * ZYY = Value of 4 digit year.
REM * ZMM = Value of month.
REM * ZDD = Value of day.
DATE.OK = 0 'preset to false
IF NOT NUMSTRICT(Z$) THEN RETURN
ZDD=VAL(RIGHT$(Z$,2)) 'Set day
ZMM=VAL(MID$(Z$,5,2)) 'Set month.
ZYY=VAL(LEFT$(Z$,4)) 'Set year.
IF ZMM<1 OR ZMM>12 OR ZDD<1 OR ZDD>31 THEN RETURN
IF ZMO(ZMM)+1*(-(ZMM=2 AND ISLEAPYEAR(ZYY))) < ZDD THEN RETURN
' If expression (month=2 and is leapyear) is TRUE which is -1, then
' taking the negative of this issues a plus 1. Conversely, FALSE
' always gives a zero. Multiplying the +1 by this result of 1 or 0
' will either add 1 or not to the number of days in the month.
' The logic wants to add 1 only when it is February and leap year.
DATE.OK = -1 '-1=valid (true)
REM ***** D A T E F U N C T I O N S *****************************
' ====================== ISLEAPYEAR ==========================
' Determines if a year is a leap year or not.
FUNCTION IsLeapYear (Z) STATIC
' If the year is evenly divisible by 4 and not divisible
' by 100, or if the year is evenly divisible by 400, then
' it's a leap year:
IsLeapYear = (Z MOD 4 = 0 AND Z MOD 100 <> 0) OR (Z MOD 400 = 0)
FUNCTION NumStrict (Z$)
REM *** CHECK FOR STRICTLY NUMERIC (NO NULL, NO NEGATIVE, NO DECIMAL)
NumStrict=0 'Init to False
IF Z$="" THEN EXIT FUNCTION
FOR X = 1 TO LEN(Z$)
IF A<48 OR A>57 THEN EXIT FUNCTION
NumStrict = -1 'True
REM ***** O T H E R V A L I D A T I O N F U N C T I O N S *****
FUNCTION NumDecimal (Z$,DecimalPlaces)
REM *** CHECK FOR STRICTLY NUMERIC (NO NULL, NO NEGATIVE, ALLOWING
REM * SPECIFIED DECIMAL PLACES)
REM The validity of the DecimalPlaces parameter is the responsibility
REM of the programmer using this function.
NumDecimal=0 'Initialize result to False.
W$=Z$ 'Save original input, may modify.
IF W$="" THEN EXIT FUNCTION 'False if null.
ZZP=INSTR(W$,".") 'Scan for a decimal point.
IF ZZP>0 and DecimalPlaces>0 THEN 'See if got one and decimalplaces
'is not zero.
MID$(W$,ZZP,1)="0" 'Replace decpt with a zero.
rem We found a decimal pt and replaced it with a 0. Now check if
rem the decimal pt is beyond the allowed position, or if there is
rem another decimal pt.
IF ZZP < LEN(W$)-DecimalPlaces OR INSTR(W$,".") THEN EXIT FUNCTION
FOR ZZ = 1 TO LEN(W$) 'The rest should be numeric, check.
IF A<48 OR A>57 THEN EXIT FUNCTION
NumDecimal = -1 'True
If you have any questions, comments or suggestions, contact:
Edward F. Moneo
Download a Microsoft Word (.doc) version of this tutorial.
Using WX-C In FreeBasic
Written by dumbledore
ok, for my first ever tut i'm going to show you how to use wx-c to set up a window in freebasic, and maybe do a couple things in it, aren't we all excited. so, to start off, you'll need a few things:
- freebasic (duh)
- the wx-c dll (download it at sourceforge.net/projects/wxnet, under the downloads page, there'll be a bunch of files in a zip, just grab wx-c.dll and toss the rest)
- fbide would be preferable
now, to get started, let's import the wx-c headers:
..and, to fix a couple problems with the current headers, we're going to add a couple #defines:
#define wxCLOSE_BOX &h1000
#define FALSE 0
#define TRUE NOT(FALSE)
option escape comes in very handy for when you want to multiline stuff, \n is invaluable, so is \t for menus, also option explicit comes in handy for debugging:
next, declare our init and un-init subs (more on this later):
declare sub App_OnInit()
declare sub App_OnExit()
now, we're going to make a few pointers, they're going to hold the return values of the wx functions:
dim shared wx_app as wxapp ptr,wx_frame as wxframe ptr
to make things a bit easier to explain, i'm going to do this next part here, but in the future it's generally better to put it at the very end of your code. so, the first thing we need to do is let wx-c know that we're creating an app, so make a wxApp constructor:
wx_app = wxApp()
now, we need to register it with our funcs for initting the app and cleaning up stuff when it closes:
wxApp_RegisterVirtual ( wx_app, @App_OnInit, @App_OnExit)
and now we run the app (the 0,0 are for args, but since we already have command$ we don't need them):
now, for our init func:
wx_frame = wxFrame()
wxFrame_Create(wx_frame,0,-1,"My WX-C Project",wxSize(440,312),wxSize(400,400),wxDEFAULT_FRAME_STYLE or wxCLOSE_BOX,0)
...making a new frame (aka the window that you actually see). note you have to add the wxCLOSE_BOX manually for now, otherwise the x in the corner won't work :(. the wxsize things create a constructor for a size. the first one declares the position and the second declares the size (width / height). now we're going to change the background color to the color you'd expect to see, there's another way to do this using wxpanel, but i decided to keep this simple:
color 15 from the system colors happens to be the color we want for some reason, we'd be able to use the headers for this but the defines weren't properly ported... anyway, on to the goods! let's make ourselves a nice lil clicky button:
dim as wxButton ptr m
wxButton_Create(m,wx_frame,-1,"here's a button\nmove your mouse\nover it to see\nthe cursor magick :P",wxSize(131,136),wxSize(-1,63),0,0,0)
notice how we use \n to make it multiline. the wxsize value of -1 means to take the default value, we had to hardcode the height since it doesn't automatically resize for multiline labels unfortunately. the -1 for the third parameter means to ignore the id for now since we're not going to wire it to any events for this. now we're going to do something far more complex in comparison: we're going to make it so when you put your cursor over this button, it'll change to something else. what, you ask? whatever you want, i'm not including the pic with this tut, change the path to some bitmap on your hd, preferably small unless you want your computer to go crazy on you. here's the code:
dim myimg as wxBitmap ptr
hopefully you understood all that, if not here's an explanation: we make a ptr for our bitmap called myimg, and for our constuctor this time there's actually one that lets us load the image right in the constuctor parameters, how nice, skips a step. change the filename to something that exists. wxBITMAP_TYPE_BMP is the format, bmp only unless you really want to bother loading all the other image handlers, takes longer. the next line sets the cursor for the button (aka m) to a constructor which takes an image, provided by the bitmap class's convert to image function. we're allowed to use wxwindow funcs on just about any widget, most are derived from wxwindow, what that means is that any func that says wxWindow at the beginning can probably be applied to our widget. so, now that that's done, we're going to tell our window that we're going to take care of the layout, otherwise it'd auto-maximize the button:
and the last thing to do is show the window
we let wx handle its own initting now, sometimes things'll crash randomly if we don't:
ok, now to make our un-init sub, we don't have to do anything, just tell wx to clean up and we'll be dumped back in our main code:
tada!! should compile fine, here's the complete source listing:
#define wxCLOSE_BOX &h1000
#define FALSE 0
#define TRUE NOT(FALSE)
declare sub App_OnInit()
declare sub App_OnExit()
dim shared wx_app as wxapp ptr,wx_frame as wxframe ptr
wx_app = wxApp()
wxApp_RegisterVirtual ( wx_app, @App_OnInit, @App_OnExit)
wx_frame = wxFrame()
wxFrame_Create(wx_frame,0,-1,"My WX-C Project",wxSize(440,312),wxSize(400,400),wxDEFAULT_FRAME_STYLE or wxCLOSE_BOX,0)
dim as wxButton ptr m
wxButton_Create(m,wx_frame,-1,"here's a button\nmove your mouse\nover it to see\nthe cursor magick :P",wxSize(131,136),wxSize(-1,63),0,0,0)
dim myimg as wxBitmap ptr
Roguelike RMG Tutorial
Written by Pyrodap
I started in QB about 6 years ago... Since then I've disappeared from the QBasic community twice... Both times it was the QBTK (Now FBTK) Rogue competition that brought me back.
During the first competition I developed what I believe is a relatively simple method to create random rogue-like dungeons. So... Basically I'm going to reveal it to the world in the hopes that it inspires a few more people to join this rogue-like competition. Since this is the first tutorial I've ever written I'm just going to get on to the juicy stuff.
Before I go into any code I'm going to explain the theory behind my RMG. First the RMG picks a random point on the map, then from that point a line is drawn. The line randomly changes direction sometimes, and occasionally a room is added. A wall is then added around the corridors and rooms, and BOOM. You have yourself a dungeon.
Let's start at what is always the best place to start, the beginning.
WIDTH 80, 50
DIM SHARED Dungeon(80, 40)
RH = 8
RV = 8
Alright, so that puts us in a screen 80 characters across and 50 characters high, DIMs the map array, randomizes the timer, and clears the screen. The RH and RV sets the maximum room size as 8*8 tiles.
StartX = INT(RND * (80 - 2)) + 2
StartY = INT(RND * (40 - 2)) + 2
X = StartX
Y = StartY
Direction = INT(RND * 4)
Our map is going to be 80*40. The outer edge of that map can't be floor, or else the floor is going to run right up to the screen and there won't be any wall around it. So we start by picking a random X and Y position between 2, 2 and 79, 39. Then what I do is have the variables X and Y equal StartX and StartY. X and Y are going to be the variables that change, but StartX and StartY are going to stay the same... You'll see why later. Anyway, then we choose randomly one of four directions to start traveling in.
FOR Steps = 1 TO 1000
IF INT(RND * 16) = 1 THEN direction = INT(RND * 4)
Dungeon(X, Y) = 1
LOCATE Y, X
Okay so we set up a FOR:NEXT loop to have 1000 steps. Then there is a 1 in 16 chance that the direction will change... If you don't know what the direction is for yet, don't worry, you will. Alright, then we add a floor tile to the map array and locate and print a floor tile at the current X, Y position.
SELECT CASE direction
IF X > 2 THEN X = X - 1 ELSE direction = INT(RND * 4)
IF Y > 2 THEN Y = Y - 1 ELSE direction = INT(RND * 4)
IF X < (80 - 1) THEN X = X + 1 ELSE direction = INT(RND * 4)
IF Y < (40 - 1) THEN Y = Y + 1 ELSE direction = INT(RND * 4)
This is where the direction comes in. This updates the X, Y position based on the direction. If it goes out of the 2,2-79,39 range then it randomly changes direction.
IF INT(RND * 60) = 1 THEN
RH2 = INT(RND * (RH \ 2)) + RH \ 2
RV2 = INT(RND * (RV \ 2)) + RV \ 2
FOR YY = Y - (RV2 \ 2) TO Y + (RV2 \ 2)
FOR XX = X - (RH2 \ 2) TO X + (RH2 \ 2)
IF YY > 2 AND YY < (39) AND XX > 2 AND XX < (79) THEN
Dungeon(XX, YY) = 1
LOCATE YY, XX
There is a 1 in 60 chance that a room will be created. RH2 and RV2 determine the size of the room to be created and are somewhere between half of the maximum size specified earlier and the maximum size. (In this tutorial the maximum size is set to 8*8, so the room can be somewhere between 4*4 and 8*8) Then the room is created around the current X,Y position. If the room goes outside of the 2,2-79,39 range then the tile is not allowed to be placed. If it IS allowed then the tile is added to the dungeon array and placed on the screen.
Alright, that next finishes the Steps loop. So... After 1000 steps of that the floor tiles are done. But... There's nothing stopping your character from walking off into the black abyss! Let's add walls!
FOR Y = 1 TO 40
FOR X = 1 TO 80
FOR YY = Y - 1 TO Y + 1
FOR XX = X - 1 TO X + 1
IF YY > 0 AND YY < 41 AND XX > 0 AND XX < 81 THEN
IF Dungeon(XX, YY) = 1 THEN
IF Dungeon(X, Y) = 0 THEN
Dungeon(X, Y) = 2
LOCATE Y, X
This basically goes over the entire map and checks to see if there are empty any tiles touching a floor tile. If there is then the empty tile is converted to a wall tile.
Oh I forgot to mention why I keep StartX and StartY's original values. In an actual rogue-like game there is a door or staircase hidden somewhere in the level that leads to the next level. I usually put it at StartX, StartY.
Alright so I think that covers everything... Now... Join the rogue-like competition at Fbtk.net!
COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Five - Testing And Debugging
Written by Stéphane Richard (Mystikshadows)
And here we are, you coded your big application project, you were prepared for it to, and today you are at your desk, patting yourself on the back on a job well done, you sit yourself back
and you are about to sip down a fresh cup of coffee. When suddenly you get an email. Not from your boss, from users, people that paid the big bucks for your applicaiton, clients in other
words. It seems you either forgot something crucial to the working of FinanceCAD, or they get an error when they try to run it, or install it. And you thought you were done with this
project didn't you? You start to stress like never before, you get dizzy and you almost choke on that sip of coffee you were taking when you got the email. Then, you wake up, in your
home, and you say to yourself, thank God I was prepared. But the big wheel doesn't stop at the end of the coding phase, far from it. Welcome to the official testing and debugging phase.
Don't worry, bugs as they are called, have been around for a while, no self respecting software had, at one point, a testing and debugging phase. So your project isn't the first, and it
certainly won't be the last. In this series we will look at this phase in all it's glory, some say the testing and debugging phase is the most important phase of the development cycle
and I tend to agree with that. The main reason is because it directly affects the overall quality of the resulting application and once again, if you've prepared for it (like all other
phases of the development cycle) in advance, you can go through the testing and debugging phase in an organized fashion. This is what this part of the series is dedicated to. We'll see
what you need to do in order to make this phase as smooth as it can be. So let's get right to it.
WHAT ARE THESE DREADED BUGS:
A bug is a problem, at any level of the application. Typically a bug is noticed first if it stops the normal execution of the application. But there are more than that too. There are
different levels of bugs and of course, fixing the bigger bugs is typically the way to go, then you work your way down the list of bug priorities from start to finish. Let's review these
categories of bugs, in order of priority, so we can see how bugs can be categorized:
- The Critical Bugs:
These are of course the highest priority bugs. Critical bugs will, for the most part abruptly stop the execution of the application or create errors in the files they save, or the data
they save in the databases. One way or another, these types of bugs will stop the user from using the application as he or she cannot go on using the application until that particular
problem is fixed. These bugs include general errors that force the application to end, problems when saving the files or database records, and other critical issues of the sort.
- The Severe Bugs:
These are pretty important on the priority list because they too, in most cases, will stop the execution of the application and report the error. The difference here is that when the error is
reported, the user could start his work over from the start or redo his or her last job. These bugs could include parts of the reports that simply do not calculate because of, for example, a division by zero error.
- The Design Bugs:
These bugs are usually detected by the people that know the business involved. This type of bug is harder to find for the programmer that got a form to do, did it, but something was missed
by the design people for some reason or the problem simply wasn't well explained or well understood. This type of bugs emphasizes the need to take the time and make sure that the design part
of the coding phase is present, and everything is understood by both parts before the design issue is approved. If you can do that, then this type of bug can be almost eliminated.
- The Business Logic Bugs:
This type of bug is usually detected by a tester or user that knows how the business side of the application is supposed to work and what the results of an action should be as per what the expected action or result should be. these are usually bugs in reporting functionality where the result are falsified by a calculation, or a missing result is not present in the report and should be.
- The Important Bugs:
This is the type of bug that is, as it's name implies, important as in they will need to be fixed, however they don't stop the user from using the application itself. For example, let's say you have a menu option to execute a report, and you also have a toolbar button for the same report and one of these two isn't connected to it's functionality. The user can still create his report using the other alternative so he or she is not blocked by that error.
- The Cosmetic Bugs:
Well the name says it all really. This usually entails that either a control is not in the right place on the screen, or a term isn't named right as per the design phase or the order of the controls on a form is wrong (when you press the tab key for example). Typically however these bugs do not stop
the execution of the program in any way and should be considered lower priority.
I can't stress this enough, but these categories of bugs have to be established before any "efficient" testing and debugging can occur. Users tend to consider any bug as critical, and this is why I am listing them here because there really is a difference between these bugs and their importance. When you receive a bug, the first thing to do is take
the time to categorize it properly, just doing that will help greatly with the testing and debugging phase.
Now, when is the best time to start preparing for the testing and debugging phase? As soon as the coding phase begins. Let me explain. There are certain things that can help you waste as little time as possible before you officially enter the testing and debugging. Remember that you have the visual aspect of your application and the non visual aspect and both will need to
be tested thouroughly. Let's take the forms to begin with. When you create a form, you should establish, right then and there, how the form should work. By that I mean you should know, from the design part of the coding project, what fields must be entered, what calculations should be performed what happens after the calculation is executed, and the order in which the fields
or controls should be accessed in. Once the form is coded, the first test to do is to make sure that the form can perform it's designated task in a normal usage situation (taken from the user requirements and the design part of the coding phase) for all used input devices (when using the keyboard only, or the mouse depending on what you are testing). For added testing, this
preliminary testing could be done by another programmer which didn't create the form or the code being tested. Remember that it's good to have a good way for the user to report their bugs, there are many applications out there that allow you
to manage the bugs that are discovered as testing begins. For example: There is BugZero™ which is an online web based bug reporting and management tool and BugCollector Pro which also offers a great tool to collect, prioritize and organize the bugs. These tools
are made to do just that and the do their job well.
If, in normal situations, you can go through the fields, enter the data, in the right order, and perform the task the form was coded
for, you have just created a preliminary test of the form. The preliminary test can help weed out, at the coding phase, almost half of the testing and debugging phase so it's crucial, when planning the project coding phase, to attempt to give enough time to perform this preliminary testing on everything that is coded. Again I can't stress this enough that preparation, at the right
time, will greatly affect the testing and debugging phase in a good way. This is true for forms as I've explained, for reports (to test the validity of the results returned by the report, for databases inserts, updates, deletion and querying too for obvious reasons. There are software that allow you to automate a series of tests to be applied to an application or parts of an application. One of the
most popular testing software available is called TestDirector™. If you take the time to visit and read about Test Director you'll soon see everything it allows you to do in a testing and debugging phase and you'll quickly see just how good it is at what it does. When a bug is first reported, it's important
to know some minimal information about the bug and the situation that caused the bug. In the next section we'll look at exactly what you need to know about a bug.
THE NEEDED INFORMATION ABOUT A BUG:
If a users reports a bug just by saying "the program doesn't work" it doesn't really tell you much about the type of problem that occured and where it happened. It also doesn't give you many clues as to what a possible correction to the bug could be. Just like the other phases of the development cycle, documentation is the key to a successful testing and debugging phase. If enough information is supplied
about a reported bug, the time to locate the bug and ultimately fix it finds itself greatly reduced thus shortening the testing and debugging phase. So let's review what type of information that can be provided about a bug that can help you in the testing and debugging phase.
- The Bug Category:
As mentionned earlier in this document, the first thing to know about a bug is what it's category is when it is reported, and what it ends up being. Like I said, users tend to categorize any bug as a critical bug when really it is not.
And since the whole testing and debugging phase is influenced by the type and category of bugs, the only way to gain control over the bug is to give it it's proper category so that it can be managed accordingly. Perhaps a meeting with the users
or inhouse testers, to explain the different bug categories, would be wise so that everyone is on the same wave length before starting the testing and debugging process.
- A Title For the Bug:
We're not talking about a Title or a qualifier for the bug here per se. But a one line, short description of the bug. For example: "Unable to save the design" or "Costing report won't print" and the likes. This helps everyone involved in the
testing process get a good clear idea of the problem without needing to go look at the inner details of the bug to figure out what the problem is all about. you, and your users/testers just need to be as descriptive as you/they can in a short sentence.
- Which Form Or Which Action Was Being Performed:
You'll find that most bugs reported by the users or the testers are at the visual aspect level (except for error in the calculations of a report for example). This means that the user typically selected an option from a menu, which brought a form on the display where the
user is expected to do something (this could be a dialog, the main application window and other types of forms too. And an error occured while the user was trying to enter the expected information and either save the information or perform the expected task with the information. When a bug cannot be reproduced, this type of information
becomes essential to attempting to track the bug and ultimately reproduce it so it can be corrected.
- Which Control On The Form Caused The Error:
In a typical scenario, an occurs once the user performed some task, pressed a button, left or entered a specific field, or did anything in his typical
normal use of the application. Because coding is typical done at the form level, you can imagine how useful it is to know which form was currently opened by the user. This could mean which form he was working in and which other forms of the application were also opened. Both of these would server different debugging purposes but they are both
as important as the other to know. An open form may affect the current form in some way and knowing that it was opened when the problem occured on the other form becomes vital information.
- Which Version Of The Application Was This Bug Found:
This should be among the first fields to look at. Often in my career I've come accross the situation where a user
reports a bug only to find, often after some time is spent trying to reproduce the bug, that it was actually corrected
in the current version and the user was using a previous version of the application. For this reason I thought it important
to state it here because if it happened to me, it can also happen to you and probably will at some point.
- Can The Bug Be Reproduced:
This is a very important piece of information to have. Bugs that can be reproduced can be corrected and it is false to assume that any bug can be easily reproduced. Of course, alot of bugs can be reproduced and by reproducing them you are, in some way, confirming the existence of the bug and can go about correcting it. This information means that
the user detected the bug, and retried the last actions he or she took to see if the same problem will happen again, if so, then the user should state that the bug can indeed be reproduced. In some cases an error occurs and the user has no idea where the bug came from and how it happened. So it's important to know that the problem did happen, but since
it can't be reproduced, we'll need to wait until it happens again to take a good look at it. These are bugs in the bank so to speak, we know they are there, but they have to happen again before they can be looked at.
- The Steps Involved When The Bug Occured:
This is where the user or tester can really detail everything that happened that he or she thinks is relevant to the problem that occured. If they were in a form, entered all the information pressed the ok button and that's when the error occured, then this gives the programmers a very big lead as to where the error resides and what part of the program
potentially caused the error. It doesn't have to be a 50 page explanation of everything that happened in the process of performing a specific task, but the more details that can be provided by the testers and users, the greater the chance of the bug being found, reproduced (even if the user couldn't reproduce it) by the programmer and ultimately corrected. This means
that you, your programmers and the testers should meet and make sure that the level of detail in this description be agreed upon by all parties involved. This will help the whole process greatly.
- The Steps Involved In Fixing The Problem:
This is filled out by the programmer that is fixing the given bug. This helps the programmers learn about the bugs and how they were fixed. In the future, if another bug similar to this one occurs, the programmer can refer to that bug for a possible solution to the problem. Again here the level of detail depends on the bug itself but should be clear enough to clearly understand the steps taken to solve
the problem. A bit of common sense is usually all that's needed to provide adequate information.
Of course, if you are managing more than one application, you can add "which application" as the needed information, but that goes without saying. Error reporting is also done from the application in the Error Management part of the code. There you can help yourself even more by adding code specific information to the error report. Code level information would be, for example, which routine was being executed, in which module is the routine found and other such relevant
information. This will definitaly help locating the bug at a much faster rate as well as correcting the problem too. Another important point to make is that if there is more than one programmer involved in the testing and debugging phase, these programmers should have some mean of reporting the bug they are working on.
So you have your bug categories, you have all the information you need about a given bug. What should you be doing? This is what the next section will talk about. There is a certain method in the testing and debugging phase, a certain
order of things so to speak and because I've seen this order tempered with at different levels in my career, I will explain them here, in the order they should be in for a better and quicker testing and debugging phase.
HOW TO GO ABOUT FIXING A BUG:
As I mentionned, having the information you need to look at a bug is only half the solution. As much as it's important to know of the existence of a bug, it is also important to know what to do with the bug in order to have it corrected hopefully as soon as possible. This is where a systematic method of dealing with a bug becomes important. Of course some types of bug can easily, obviously and quickly be fixed. For example, a cosmetic bug is usually fixed by moving a control to it's proper place,
changing the label with the rightful name of the field, or changing the tab order of the controls so that the expected order is achieved when the user presses the tab key to go from one control to the other. Those are quickly located and fixed. However, for the other types of bug, having a method in place can give the programmers a sense of control over the bug and help the whole testing and debugging phase go smoothly. Here is that method, that order of steps to follow when dealing with a bug. Hopefully
this will help you deal with the debugging phase in a much more organized and controled environment making it easier to manage.
- Make Sure The User's Environment Is Up To Par:
If your application takes advantage of specific functionality of a given target operating system and version. These should be stated as a minimal system requirement. So then, if your project is made to work specifically on the Windows™ XP platform and the user is running Windows ME or Windows 98, there isn't much that you can do. Of course if there is a way to perform the same task without requiring a specific version of the operating system, that should be weeded out at the design and coding phase and
would typically be prefered over a method that does use an OS specific functionality. This avoids this kind of situation and hence this type of bug. If there is no choice but to use the specific functionality provided by a specific version of the operating system then they should be stated in the system requirements so the users know that they should upgrade their operating system if they are to use your application.
- Reproduce The User's Environment:
Assuming the user's system does meet the system requirements of the application, it's good practice to have a system that you can continuously format and reinstall with the different operating system that you claim to be compatible with in your system requirements. This way, if a user is using a different but supported operating system you can reproduce his environment and see if the bug can be reproduced in the environment you used on your system and in the user's environment. This helps determine the true nature
of a bug and the different alteratives you can pick from to try and correct the problem. Hence it's valuable information to have.
- Reproduce The Incident:
The bug, as explained by the user, states that it can be reproduced. This doesn't necessarily mean that you can reproduce it on your machine, it means that the user can reproduce it on his machine. So, on your side, the first thing to try is execute the steps mentionned in the details to see if the error will happen for you as it did for him or her. You should always try to reproduce a bug first, it should be the first step to take because if the bug does happen in your system too, you will understand better what
the bug is all about. And again if you understand the bug clearly, you can correct it clearly too and probably explain your steps to solving the bug in a clearer fashion for all others to read and understand. The user's description will tell you if he or she used the mouse or the keyboard when the problem occured. If the bug doesn't happen as stated you might want to try it with the other input device just to be on the safe side.
- Locate The Bug In The Source Files:
This is where code level error reporting can come in handy. But if we assume that only the Error number and description is provided then you'll need to see, from where the error occurs, where in the code it could potentially be located. If you think that the programmer that fixes the bug might not be the programmer that created the faulty code, then it can become an investigative process that needs a minimal time for the new programmer to get
familiar with the code he or she will be dealing with to correct the problem, and then see where in that code the error is produced. If you happen to know who created the form or the report that causes the problem and can assign the bug to them, you can save alot of time this way.
- Fix The Bug:
This goes without saying that once you located where the bug occurs that you should fix it since it's the whole point of the testing and debugging phase. Needless to say that a quick recompile is in order to test to make sure your corrections truely fixes the bug in question. Depending
on the company you work for, some may have, in their daily routine a recompile of the whole application at the end of every day and no other compilation is allowed, this isn't necessarily a bad practice as it offers a controled compilation environment, but it does mean you may have to wait
until the next day to see if your corrections actually worked. In the mean time, you don't have to just sit there and wait, there are other bugs that you can fix and that means that the next day, when the compilation is done, you'll have more error corrections to check and if they are fixed
properly, to finish the debugging process for those bugs.
- Test The Correction thouroughly:
I've seen this time and time again in my career. A programmer receives a bug from a user, he thinks he knows how to correct it with a certain degree of certainty, fixes what he thinks is the problem and checks everything back into the finished product
assuming that the problem is solved. The user rechecks and reports the exact same bug again. When you or your programmers correct a bug, they shouldn't close the bug before they are sure that the correction they brought to the code really does fix the
problem. If it doesn't fix the problem on their system it will surely not fix it on the user's system either. Simple common sense again will minimize the number of reoccuring bugs in your application and will help the whole testing and debugging phase
move forward. For this reason I thought it important to mention it here.
And there you have it. As I mentionned, it seems that because of time issues, these steps aren't always respected and often it's the cause of a never ending testing and debugging phase that just seems to get longer and longer. So before you decide you should follow these steps or you think you don't need to, take the
time to think about it a while. Good testing and debugging practice will help the phase reach its end and in the world of software development, the end of the debugging phase should be of the highest priority throughout the development cycle.
Even if the size of the project is much much smaller than a big scale application, testing and debugging should not be neglected or overlooked at all. In fact, in many cases, not paying attention to this phase is often the cause of delayed releases, deadline that can't be met, and other serious issues of the sort. So
for these reasons, testing and debugging must be treated as a very important aspect of the development cycle.
AND NOW FOR A FINAL WORD:
And this pretty much concludes the whole testing and debugging phase. Needless to say there's alot of material in this phase too. Some of you might have discovered many things about the testing and debugging phase that you never knew existed. If this is the case, then I'm glad because it means that this series of documents
is doing it's job. This is the reason why I created this whole series of documents, to really teach you what you need to know about each phase of the development cycle and what exists to help you along the way at each and every step of the way. I also hope that I've made clear, in each part of the series so far, that preparation
is as always the keep to the success of each of those phases. Some of you may wonder if there is really a need to do absolutely everything that I am mentionning in this series. Well to that I can tell you that it won't hurt to do them all, it will make the whole project documented a lot better. Maybe, after a few projects you'll
think you're familiar enough with the process to start creating shortcuts to these steps. Well, what I can tell you about this is that I wouldn't if I were you. Just like any process you do in a job. If you have all the documentation you should have, then there is no guess work involved and in a development project, the less
guess work you have, the better it is for the life, and the success, of the development project.
There is one more part to this series, Installation and Integration. That part will talk about the last steps of the development phase, making sure your application installs itself and executes as it is supposed to. there's different considerations for a commercial and a professional application and we'll be covering each of them
in detail in the next and final part of this series. Until then, email me with questions, concerns, suggestions and ideas about this series of documents if you want to know more about a certain part I've covered in this series, let me know as well and I'll see how I can better the contents of this series. Until next time, happy
reading and I'll see you then.
Download a copy of this tutorial, or a zip archive with all six tutorials from this series!
COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Six - Installation and Integration
Written by Stéphane Richard (Mystikshadows)
Welcome to the Sixth and final part of this series. I don't have to remind you of everything we've covered in this series so far, If you've read them all, I'm sure you already know what you learned. In this final
part, we will be covering the installation and integration process, or whatever comes after the application is ready for distribution to your users and/or your clients. The installation process isn't a simple question
of creating the installation and running it on the users machine or having the client run the setup. The creation of the setup files is a process in itself and there are certain things to consider while creating the
setup file. Reason why I mention this is I've seen people create a setup for their application and when the client executed that setup, either some other program didn't work anymore, or worst, the whole system when into a
rebooting loop and couldn't complete the booting process anymore. All this could have been avoided with the proper set if precautions to take when making your application installation.
This is what this last part of the series will be about. We'll see what these considerations should be, we'll look at the tools we have at our disposal because just like the other parts of the development cycle, there are
tools out there specifically designed to help make the creation of an installation system straightforward while minimizing the risk of software conflicts like the two examples I mentionned above. Let's start from the beginning
and work our way down the installation process and see what happens.
WHAT IS AN INSTALLATION:
Well, there's two possible answers to this question and both of these entail a very different set of considerations and precautions to take. When you think about it, there's two types of development projects, as mentionned, in the
corporate world. There are the applications developed with the goal to be sold as a commercial product and there are the application that are created to be used either by the employees of your firm, or one specific client. Let's
take the time to review some specifics of these two types of application project. This will help us, later in the document, to see why they are so different and therefore require some very different sets of considerations.
- The Commercial Applications:
Commercial applications are applications that are sold in the stores or by the company. You can imagine that this type of applications need be able to install itself in many different operating system versions as well as
cause no conflict with any application the user might have already installed on their machine. As such, creating an installation for a commercial application needs to take all this into consideration. In this type of application
project, only one thing really matters and that is the application's capacity to coexist with anything else that might already be present on the system.
- The Professional Applications:
The professional application are either used inhouse or created contractually for a specific client. The first thing you can imagine from this type of application is that usually, thre will be a fixed number of possible circumstances
to consider. It will be more important to make the application work on the system where it will be executed rather than try to create a universal installation. In a very general point of view however you can use the same
tools to create the installation program itself as you would for a commercial application. What will change is everything you'll be taking into consideration for both type of applications.
Again here I can safely mention that preperation is definitaly the key. And to prepare yourself for an installation process requires nothing special. You need to know where the application is going to be installed, what could be
already present, and how you can avoid overwriting anything that could cause a conflict of some sort once your application is installed. Once you have all that information, creating the installation can be quite easy, and quick provided
you have, once again, the right tool for the job.
WHAT ARE THE TOOLS AVAILABLE:
There is more than one installation tool available, some companies offer different products for different types of installation needs. There's only two companies that I will
talk about here because they are the companies/products that I have had teh chance to work with and can give you enough information about them so you can make a choice on which. When you have all your installation specifications and the considerations
you are equipped to make the right choice when choosing the installation system you'll need. That is assuming your firm doesn't already use one and that you are limited to using that system only to create your installation.
- The Wise Family of Installation System:
Wise Solutions is the first installation system I've had to use in my career. Back then, Wise Installation System only came in one flavor because the operating system was pretty straight forward to get an application installed on it. Today, The wise family of products range from the
simple installation system (copying DLL's and the Executable essentially with the ability to gether specific information needed to run the application after the installation is completed) all the way to the full fledged online installation package. Wise products work based on an advanced scripting installation language that offer
a complete range of commands to write and retrieve information from the windows registry, create any and all custom dialogs your installation could ever need, allow to make copies of the files it may need to overwrite depending on copying conditions (very useful if the need to uninstall the application for whichever reason should occur). Prices
vary with the different packages available.
- The InstallShield Family of Installation System:
InstallShield is the second installation system I used. I think the preference of using Wise or InstallShield really depends on your personal experience. Me I prefer Wise because I had to get familiar with it first so anything else I used I tended to compare to how Wise does things. However
I don't want to bring down InstallShield, it is a power family of products that is based on the steps needed to perform the installation rather than a scripting language and offers unique features and possibilities. I say give both of them a good try and pick one once you are familiar with both. I might even push things a bit and tell you that for
a different type of application deployment scheme, one of these two packages, Wise or InstallShield might be better suited to perform that specific installation quicker than the other. I'll just let you decide for yourself.
- The NullSoft Scriptable Install System: [OpenSource]
NullSoft Scriptable Install System is an OpenSource installation system that is also based on a scripting language. It offers a very straightforward and systematic approach to the software installation process
which is the main reason why I included it in this list. The scripting language features commands to search for the target OS specific information and it also allows the creation of custom dialogs when the need for more specific information is needed in the installation
process. All in all, this OpenSource installation system provides everything you'll need for all common installation needs. I was amazingly surprised to see such a tool offered as a free installation system, it really is that complete. So I wouldn't just ditch it out
of the list in the count that it is free and OpenSource.
Tools like this really shorten the time to create an installation for your application even today. And for that reason alone, they should very seriously be considered, not just in commercial or professional applications but even if you are creating a game or other types
of applications. Their usefulness has been proven time and time again over the years not just for me and my installation experiences, but for every single one of my collegues. You'll see why later in this document. For now, suffices to say that they are great tools that
really fill a need that just wasn't met before.
Now that you know of the existence of these tools and all the time (and many headaches) they will save you. The time has come to officially start the preparations for the creation of an adequate installation system for your application. To do so, as I mentionned, you
need to know what you are installing exaclty, and what you will be installing on as well. Let's take the time to see the special considerations to take.
SPECIAL INSTALLATION CONSIDERATIONS:
It's important to note, right from the start, that these considerations should apply to both commercial and professional application projects alike. Whenever you install an application on any user or client machine, you need to be sure of what exactly the installation is supposed
to do as well as have some means of knowing what the installation process actually did once the installation is over. In a perfect world, the "what it should do" and "what it actually did" lists would be the same, everything that should have been there is, and nothing else, installed
on the user's machine has been tempered with by your installation. Here we will list the danger zones that you need to watch out for before you actually start copying the files and registering DLL's and ActiveX controls should the need be. As per our project, once again the considerations
will pertain to the Windows™ environment.
- The Presence Of An Older Version Of Your Application:
It seems that today, people still believe that everything works like the good old DOS days. Today, upgrading to a newer version isn't as simple as replacing
the executable file, at least not in most cases. Now you have to consider more than that when upgrading. Sometimes, if you didn't add any dependencies on the
current upgrade, replacing the executable file could be enough. But many times, upgrades exists because there are changes in the dependencies and that can
cause serious errors you never thought you'd have. So you need to be sure to know if there is a previous installation, and what it is exactly that you need
to upgrade in that installation.
- Dynamic Link Libraries:
The now infamouse DLL file. This is always a majour source of conflict, when you are unprepared. There's just so many of them on a typical user's machine that
it's very hard, maybe even impossible, to know what DLL files belong to what application. Rest assured there is a simple way to avoid conflicts, but you really
need to stop at the DLL issue seriously or you will ultimately create problems for your applications or other applications that were installed before your application
was. The truth is you don't need to verify every single Dynamic Link Library that you will see. Only the ones that could interfere with those you need installed
by your application.
- ActiveX Controls and Servers:
The controls are files that have the OCX extension whilst server objects are DLL files of a different nature than what is usually attributed to a DLL file. The same
conflicts that I explained for DLL files can also Occur for ActiveX Controls and COM objects. So, the same trick that works for DLL files will also work for OCX Files
and Server Objects. As an added precaution, most commercially available OCX controls need a license to be usable in a development environment. If you are allowing
those controls to be altered while the application is running (in the case of a form designing tool for example) then you'll need to contact the control vendors to get
a valid distribution license for that control to your users.
- Database Management System:
I am listing this one here in the case that you, for example, developed a database application and are trying to install it on a user's machine. I am assuming here, that
the database you used was Microsoft Access™ because it is a good example of the type of situation you need to watch out for. If you created your database with
Access 2000 for example, and the user only has Access 97, there may be a need for them to upgrade their database
to a newer version. Likewise, if you application opens their database and you are using Access 2000 to open them, when the user tries to open his database with his
older version of Access, he or she will get an error message because you have more than likely transformed the database to the newer version probably without knowing
it. You need to be careful when dealing with this type of database and database engine to avoid these types of situation.
- The Windows Registry:
Ah yes, the dreaded registry file. There's two things I've seen happen as far as the registry goes. The first is people often forget to enter the information they
need in the registry. I'm not talking about registering things that you application uses, i'm talking other types of information that you code reads from the registry
but your installation does not write. It's a common problem that can be very easily fixed. Whether you use one of the installation software I mentionned above or wether
you created a custom installation software, you need to be sre that the values you need are present when the application is executed. People forget this quite often
even if they know what they are reading from the registry by heart it's just a common mistake. You can create the values in the installation process or in the application
is code (the first routine that gets callled when the program is executed is usually a good place).
These are the main problem areas that need special attention as far as installation is concerned. When you create your installation script or decide on the list of files you'll need
to copy, you need to be careful about these areas. You can't be to careful when it comes to this because if you're not carefil the installation process can be responsible for many phone calls
or support emails that didn't really need to happen if those precautions were taken. Let's take each of these danger zones again, but this time we'll look at what we need to be careful about.
- The Presence Of An Older Version Of Your Application:
If you detect that there is a previous version of the application installed, you have a choice and that choice depends on
which of the previous version you detected, and what changed since that older version that would need to be upgraded as far
as copied files are concerned. Then you could either uninstall the old version (if no risk of lost of information or data
is involved) or unregister everything that your application will be registering again and copy your files over the old files
and let the rest of the installation do it's thing.You could be lucky and not have any conflict in registered components
in which case you could simply add the new components that weren't there and the installation process would be finished
right then and there.
- Dynamic Link Libraries:
We are a bit lucky as far as DLLs are concerned, everyone that creates a DLL for their application tends to be very careful how
they name it and rightfully so. All DLL files would typically go in the Window's System folder as it's called so you can imagine
that no two names should be the same since Windows doesn't allow to files with the same name in any folder. Ultimately you could
copy the DLL files right in the same folder as you are installing your application. But what if you select the Windows System folder
and there is already a file with that name (usually because a previous version of your application was installed). The best thing you
can do is detect the version of the DLL and copy your DLL only if it's newer (in version or in file date) than the one you found
in the folder you'd be copying to. If you take the time to do that, you can't imagine all the problems you'll be saving yourself
and your users/clients.
- ActiveX Controls and Servers:
As I mentionned earlier, ActiveX Controls and Servers should be treated just like DLL files. Typically their destination folder is
the Windows System folder as well and like DLL files you could decide to copy them to your application folder instead too. Typically
the only reason you'd want to copy an OCX over an old one is, like DLL files if your OCX control is newer in version or in file date than
the one already present in the folder. Of course if for any reason you had to revert to an older version of the OCX (to get back some
functionality that was lost in the newer version) you best bet is to add the missing functionality to the newer version and recompile it. Ultimately you
could unregister the OCX file, overwrite the user's OCX file with your older version and re-register the OCX if you really need to.
- Database Management System:
The solution to this problem, taking our Microsoft Access™ example of above, is very different for commercial and professional application. In the case
of a commercial application, the best thing to do is detect if the user has access at all on his system, if he does and it's an older version then you could warn them
that the Access database you are creating cannot be opened by their version of Access. If it's the right version, there's nothing to do, if their version happens to be
newer than the one you use, you should issue a warning ridding you of all responsibilities should they try to open your database with their newer version of Access. In the case
of a professional application, you'll need to contact the resources and see if they can be in sinc with the version you are using in the code. Of course, when you are programming
a project for a given client, you would probably find out long before the installation process that they do have Access or not and which version. You can then take care of this
problem long before you attempt to install your application. You could synchronize your application to use their version of Access or let them know they will need to upgrade
their Access long before you go ahead and install your application on their system.0
- The Windows Registry:
The programmer that does the start of the application, the initialization process if you will is usually the one that
knows what is being read from the registry. That person should, as soon as he writes code to read values from the registry,
Make a note of what he is reading and what type of information he is expecting to be able to read. If he knows the
installation system you use, he could even open a script up that does nothing but write the values he needs to the registry.
If the information should be typed in from the user at the installation, he should create a quick for that has all the fields
that he needs so the user can enter them right in the installation process. It's that simple to do yes. All installation
creation software has an option of some sort to create a dialog that will get the needed information from the user and some script
command or other option to save those values to the registry. To avoid all possible conflict between other applications' information
in the registry, your values should be saved under their own branch in the registry. Just making sure that it's done is all you need to save your
staff alot support questions.
As you can see, there's a possible and fairly easy solution to all problem areas. The biggest trick I can give you is to not copy a file if it doesn't need to be copied. You can't really tell yourself
"I'll copy it just to be sure" because in many case, doing just that is what will make you unsure and ultimately cause you support time that you could have easily avoided by taking the right precautions. Another good trick
is to copy the least amount of files as possible. This just help minimize the list of things to watch out for and shortens the analysis of a problem when it does occur. The less file the quicker you can go through them
and find the problematic file and correct the situation.
In the case of a professional application, other concerns will be how each of the user's machine will be accessing the database. Usually, the users or clients company helps you by making sure that each user's mapped drive
for the location where the database will be is called the same thing for everyone. There may be cases however where a user mapped his network drive as F: and another user, in the same company, has it's access through his G: drive
for some reason. When that happens, you can know about it in advance and instead of just adding a static path to the registry, you could offer a dialog that let's the user select the path where the network database is located. Simple
considerations like this at the installation process is easy to do and the time and issues it will save you is well worth the little extra effort to have a good installation process. Believe me, if you take the time to pay attention to
these considerations properly and give yourself the time to acommodate for these circumstances appropriately, you'll thank yourself in the end.
Another thing that is gaining popularity fast today is online updates. This is a situation where the client has the option, from the application, to check for the presence of a newer version and could select to install the newly found version.
For this all you need to know is what version the user currently has. Connect to the download area of your website and check the version of that file on the server. If they match, there is no need to upgrade. If they don't, you download the
version from the server and overwrite your existing version (if all there is is the executable to upgrade). If the upgrade entails that other files be downloaded as well, you'll need to unregister those files, overwrite the old version on the
user's machine and re-register the files. Aside the actual connection to the internet and the getting of the files you need, the rest is the same as a regular installation process. This means that the same precautions that i mentionned here
will also be the same for an online update.
AND FINALLY WE ARE TRULY FINISHED:
And this concludes our exhaustive series on commercial and professional application development. There was, once again alot of material to cover even in the installation process. Well my mentality stayed the same
throughout this whole series. Preparation is the key to the success of a project of any size (but especially for the bigger scale applications). As far as the installation process goes, the best preparation you can have is
if you take care of those precautions I mentionned and if you can get a list of files to copy along with their version numbers so you can compare them later in the installation process when you copy those files. To make a
long story short, the more precautions you take, usually, the less problems you'll have throughout the installation process.
As always, I'm open to comments and suggestions. This series represents a general point of view on the development cycle from start to finish. Perhaps in your professional experience, you've experiences things that were
quite different than I did, that's very possible. Maybe, in the analysis phase you used very different tolls or methods than those I have mentionned in this series. If this is the case, by all means, do let me know, the
real purpose of this series is to be as generic as it can so you can apply what you've learned to your projects so if your company uses totally different tools or methods in their development cycle, I'd like to know about them
so I can update this series to be as accurate as possible. I hope you found this series useful or insightful in some way and I hope you enjoyed reading it atleast as much as I enjoyed writing it.
Download a copy of this tutorial, or a zip archive with all six tutorials from this series!
That's it for this issue!
Issue #12 should be out sometime shortly after July 15th, the deadline for submissions for next month. And boy, do we ever need submissions! As of right now, I can think of only three articles lined up for the next issue. That's definitely not enough to fill up an issue, so YOU need to go out there and write up a tutorial, article, editorial or review and send it in. Whatever strikes your fancy -- we want to read it! After Matthew R. Knight's article this month, I'm especially interested in hearing other peoples' stories about how they got into QB programming. So if you're interested in writing your own Personal QB Narrative, that would be cool too. And if you're interested in writing but you don't have an idea what to write about, drop me an email and I'll help you think of a topic. Reader submissions are what keeps this mag going, so it's crucial that you write!
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.