Main:Geek Quest

Geek Quest

Geek Quest, Clone Quest, or whatever I wind up calling it, is basically a prototype for some ideas I have for something similar to, but more configurable than, Kyle's Quest. This is not my main mission in life, I have a full time job and family, so it may not get finished before I get bored with the idea, but I'm pretty sure that at a minimum, there will be enough of a framework for someone else to take over and finish it.

The basic idea is to increase the limits of the game (map sizes, etc), make events much more flexible, and allow for a few new features.

New Features/Ideas

• More reasonable limits. I think Adventurama has really pushed KQ almost as far as it can go, as it has used all available talking events, and almost all of the regular events, tiles, special monsters, etc. My plan is to allow for a maximum of 65535 events, items, monsters, flags, and maps, and all maps can be up to 255x255 spaces. Obviously, you can't have 65536 255x255 maps, but I'm including map compression to make larger maps more feasible.
• Events will actually be subroutines made of subevents, complete with branching, looping, local and global variables, including arrays, parameters, and calling other events. There will be a GUI IDE so that quest authors have the option of drag-and-drop design, or coding the events directly in the event language, which is similar to a subset of C. Events could modify the SP/HP recovery rate, or even the cost of spells, if you wanted to have an area magically "dead" to make spell casting more difficult.
• The subevents will have read access to almost all adventure information, and write access sufficient to cause map changes, modify character stats, modify object stats, or affect combat. Subevents can even use character stats or the presence of an inventory item to affect how the event executes.
• Triggers will not be part of events, but will invoke events. There will be two types of triggers, those based on movement, and those based entirely on flags or global variables. With each move, only the first trigger with a movement condition will trigger. At any time that flags or global variables are modified, any appropriate non-movement trigger will be checked, and several of those can fire.
• Much of the game will allow author-created events to modify or replace the default game behavior, allowing for custom combat formulas, spells that can affect much more than combat, etc.
• Additional attributes can be defined in the quest, so a Cthulean based adventure could have Sanity as an attribute.
• Quests can be allowed to define optional grey scale images, and even color images, when it gets ported to a platform that allows it. Animation will be allowed for, and at this time, looks like it will make it into the first version of GQ. Basically, a quest would define monochrome images, and optionally include info for 2 and 4 bit greyscale, and 4 bit color(?).
• Rather than have several types of events, as KQ does, GeekQuest will have one type of event, with the subevents determining just what the event causes. This should allow for better event interaction, as an event could trigger any other event, be it a store, guild, monster, message, or question, and everything, including stores and guilds, could have that event's accessibility and post events controlled as well as any other event.
• Rather than having two types of monsters, this would also allow for one type of monster, and have that monster evoked either as a wandering monster, or as a scripted monster.
• Items will be quite versatile, and include spells and skills. Each item would have various attributes, such as if it could be warn as armor, used in a fight, uses charges, uses spell points, counts against the spell limit (and for how much), counts against the weight limit (and by how much), attribute modification (including AGL modifications for attack/defense only, STR modifications for carrying capacity only, etc). In particular:
  • Armor would be broken into two types of defense, absorptive and defective. Since any item could have any item property, a set of heavy plate could also have a negative modifier on the character's agility.
  • Weapons (and attack spells) would specify what attribute to use for to-hit and damage determination, as well as if it is modified by armor (or how much), if there is a dodge-attribute (AGL for physical attacks, INT for spells, etc).
  • Spells could set flags or invoke events, allowing spells to interact with the plot line. Using items could have the same effect.
• More compact quest storage. For example, in KQ, all questions (except the first, but only because there is always space for at least one question set aside) take up 1606 bytes in the initial .pdb, regardless of how much text is presented, how many flags are used, etc. I suspect that a GQ quest will be noticeably smaller than an identical KQ level, even given the greater limits of the GQ quest format. NOTE: The GQ Basic layout seems to be half to one third the size of the same adventure done in KQ.
• The ability for events to manipulate counters and set flags based on the results, including a possible time-of-day counter.
• The quest author would determine the rate of HP and SP recovery.
• Dropped items can be found and picked up again. The quest author could prevent this from happening.
• Monsters can have multiple attacks, with biases towards certain attacks. The quest author could even create a monster that has a one-use spell, and always runs as soon as it has used its spell.
• I want to make sure that the events are flexible enough to do some interesting mechanics, like making backpacks.
• Part of a quest can be exported then reimported into another quest, to allow for modules. A backpack would be an example of such a module. The module would contain the item and all events responsible for moving other items into and out of the backpack.

Steps

1. Decode the KQ .pdb format, to make sure I'm not missing any features. I haven't found the format documented anywhere.
2. Figure out what information isn't in the KQ .pdb format. At this time, I'm aware of:
   • Wandering Monster probabilities.
   • How many uses does it take for a spell to increase in level?
   • How fast do SP regenerate? It seems to average 1 point every other move, but I've seen rates as high as 1 point every move. Why?
   • What constitutes major damage for the Fear factor?
   • What are the odds of escaping, and how much damage is taken if you fail?
   • How does self training work?
   • How does the game determine what stats get lowered when you die?
3. Define the GQ structures and .pdb format.
4. Code a GQ interpreter, probably in Java for maximum portability. This way I can get some play testing done, and be sure that the format really does have all the necessary features before I go any farther.
5. Code a KQ level to GQ quest converter, again probably in Java. Since GQ is intended to have a superset of the abilities that KQ has, this should be possible for all games, though I wouldn't stake my life on it. This is to bootstrap the game, so that it will have most, if not all KQ levels available to it as soon as it's released.
6. Code a Palm based GQ interpreter in C, Java, or asm.
7. Find someone to do the WinCE port.
8. Make a quest-compactor, so that end-users can get rid of graphic formats that they can't use or don't want, so that we're not wasting storage with a 16-level greyscale image on a P1000. Maybe even make it so that the game itself deletes any graphic formats that exceed the current hardware abilities.
9. Write a Quest Editor. Would probably have a basic and advanced mode for object/event editing, since those are going to be quite a bit more complicated. Basic mode would be intended to allow quest creation as easily as KQED and still allow more features, advanced mode would be for allowing the greatest flexibility.
10. Find someone to do some graphics. I am not an artist.
11. Offer to contribute much of the code back to Kyle (actually, for some credit in the documentation I'd be happy to let him call it KQ 4.0). This is, of course, assuming that my vision comes to fruition, and it's as good as I hope it will be.

Status

• As much of the KQ .pdb format is decoded as is relevant. There are bytes in the .pdb file that are unexplained, but even after playing with every option of KQED32, they remained at zero, so they are either reserved values, or unused features. Decoding was made quite simple because KQ uses fixed-width objects, so there's no need to guess about delimiters, or which bytes represent the size of the object, etc. Unless Kyle objects, I will be placing the decoding on this site when it's nearer completion, so that no one else has to duplicate the effort.
• At a high level, all of the GQ events have been determined as well as their parameters. The basic organization has been determined as well, and the exact layout of much of the database has been determined.
• Graphics layout has been determined, including animation and multiple representations (for different depths), and I'm coding some custom blitter routines to draw directly to the screen, since the OS still doesn't have drawing support for greyscale. So far, it looks like graphics are going to be much smaller than the same graphics for KQ, ranging from 60% for normal, non-redundant graphics, down to 23% of the size for Adventurama, since it doesn't use much of the space reserved for graphics.
• Map representation is also laid out, with two different types of compression (bitcopy and RLE), and possibly more to come later. Since most quests don't have that much in maps, I don't plan on doing higher compression types until I've got at least a beta out the door. Maps smaller than 24x24 are compressed whole, larger maps are broken up into 8x8 tiles, so that there is no need to decompress the entire map on each character move. NOTE: Changed the compression, found a very simple algorithm that compresses much better. It's a three-stage compressor, involving RLE, then move-to-front, and huffman as a final stage. This compression reduces the map data in a typical KQ level to 27% of it's original size. It also has the added bonus that increasing the number of tiles doesn't significantly increase the size of the maps unless you actually use more tiles per map. For example, all of the Adventurama maps compress from 26K to 8.6K total as is. If the same maps were done using a variety of tiles picked from 65535 tiles, the resulting maps would total about 10.1K.
• On paper, the design is looking good, so now I have to teach myself Palm Programming.
• Learning is going well, but Las Vegas just got hit with what one newscaster claimed was the worst flooding in 25 years. Nothing's missing, but the next week is going to be lost to cleaning up.
• Sorry, got seriously distracted writing some VPN software for a consultant friend of mine. Hope to be back to this project soon.
• Doing a major rearchitecting of the game, to make it more versatile, to the point that you can define your own combat system, so those that want combat systems where you always hit can create quests that do just that.
• Splitting the project into GQ Basic, and GQ Advanced. GQ Basic will be easily ported, easily written and easily understood. It will be based on linked structures, so there will be no variables, just flags. GQ Advanced will be more flexible, as it will be based on a qcode interpreter, but writing the database format will be much more complicated and the quest editor will be a nightmare, as it will have the equivalent of a compiler built in.
• I've translated Adventurama into a few different GQ Basic database formats (depending on just how much compression I use), and the 394K file reduces down to between 185K (no compression) and 115K (compressing strings, maps, and graphics). Even with the compression, there's little runtime memory overhead, since I'm compressing each item individually. Additional improvements can be made as the translator doesn't check for null subevents (events that grant nothing don't need a grant subevent, for example) or other optimizations.
  The one trick that saved the most space, over 160K, has already been forwarded to Kyle, so if he hasn't already figured out that trick, or something like it, maybe we'll see it used in the next version of Kyle's Quest anyway.
• Talked to Kyle, and many of my ideas already have equivalents in the next version of KQ, so this project will probably never see the public. It's been fun anyway.