[Barok]

thanks bjorn. i'll remember that.

what's the book game?
_________________
Adosorken: I always liked slutty 10th graders...
Rhiannon: *Slap!*

[Modanung]

Yeah, Douglas Adam's book was better... I'm reading it at the moment. It's even more hilarious.
The book is called 'The Hitchhiker's Guide to the Galaxy', if that's what you meant with your question.

[Nephilim]

Sounds like you're starting to solidify what you want to do with the game.

First, just a few usability things. In your layout, I would put cell (4) immediately to the right of cell (2), so that all your command stuff is side by side. You could also easily make the interface clickable, by allowing them to click on the verb and then the noun to take their actions.

Second, one consequence of organizing your game as I understand it is that you will have trouble adding a puzzle solving dynamic to your game (which is the traditional strength of these text adventures). For instance, in your example, it will be patently obvious that there is a secret cave, because the commands in question will appear there for them. That means that players will always be able to approach your game with a trial-and-error approach, which is less difficult (and hence, less rewarding upon success and less frustrating upon failure) than with an open-ended parser like what you saw in HHGTTG. Not a value judgement on your game, just something you probably don't want to realize halfway through development if that's not what you want. Battle-driven stories would be fine with this setup, but puzzle-driven stories could have issues.

You could avoid this problem by having some commands that never show up in the verb/noun windows and which have to be typed directly into cell (5) to take effect. But then, you run into the same problem that you mentioned you wanted to avoid: trying to figure out what to type.

Anyway, I'm sure you'll deal with this stuff as necessary. Good luck with your game.

[Barok]

yeah. here's mor of what i'm putting into the game.

customization: the ability to customize the menu. will you hit people more than talk? put the hit command first. the default will be like this.

talk
goto
use
take
next
save
options
exit

that's the main commands. however, if you want to change things around, you go to options, and choose a command you want on, choose the default command it will replace, and make things easier that way.

if you prefer to type things in manually, press a certain button, and it'll disable the menu.

hiting next will bring up the next page of commands.

any of you guys play an old nes game called shadowgate? that's the way my game will sort of play.

as for battles, i decided that what i'd do, is first i'd GET the text in box 3, then erase it, then start up the battle. when the battle ends, it'll tell you, then with the press of a button the original text will be restored.

for every action, there is a chance to fight? that's right. if you decide to waste time by hitting yourself, you're increasing your chances of a monster stumbling upon you. not to mention hitting yourself will take away life ;)

i'd put in mouse support, but unfortunately, i'm not that advanced yet. maybe there's already prewritten codes out there.
_________________
Adosorken: I always liked slutty 10th graders...
Rhiannon: *Slap!*

[Flake1]

There's an ASM routine list (which includes interrupts for the mouse) at:

http://www-2.cs.cmu.edu/~ralf/files.html

And at:

http://members.aol.com/radiohands/tutors.html

Tutorials 12 and 13 talk about using ASM routines in QB. Hope that helps.
_________________
"Our water is poisoned, the ozone's in shreds, and the SUV's are advancing like a plague of locusts." - Michael Moore
Flakesoft Online

[Nodtveidt]

ya know, I was thinking about doing a web-page version of a text adventure...maybe I will look into it seriously...screw PHP though :P~

-nek

[Barok]

okay bjorn. i think i know what your talking about with pixel*tile.

1. you delete one row of pixels.

2. you move the map one pixel over, so it fills in the deleted pixel row.

3. you then fill in the row of pixels you left behind from when you moved the map.

4. repeat.


the only problem is that i don't know to put one row of pixels on. how would you do that? i read darkdread's pixel*tile scrolling engine tutorial, but darkdread obviously wasn't inspired enough. he never did a good job editing the code. not to mention he used a library (gslib), and i couldn't understand the code. too much work for me. i recall in another tutorial, someone used asc. could someone maybe point me to a good p*t scrolling engine tut, or maybe just put code down right here?
_________________
Adosorken: I always liked slutty 10th graders...
Rhiannon: *Slap!*

[Bjorn]

Why are you calling it pixel*tile? Is it meant to only scroll smoothly in one direction and per tile in the other direction?

Your method seems ok and variants of that way are used in many scrolling applications, like when scrolling through your files with the Explorer or when scrolling through a PDF document or an image. Though a problem with this method is that you'll probably have objects walking around on the map that are moving too so you'll need to figure out how to move those objects without messing up the map because you'll only ever draw the map again when it is entering the screen.

Of course, this could be done by somehow only repainting the small part of the map that includes the start and destination of the object. This can get complicated however when this area overlaps with another object's graphic.

Simply put, you can either make your engine a bit simple so that these mechanisms can be implemented in a straightforward way. Or you could choose the most simple approach which is to simple draw the map first and then all the objects on it, every frame and each time the map scrolls. The problem here could be performance, and flickering. But as Tenshi pointed out, both can be perfectly handled with but it will require a bit more skill into the more advanced possibilities of QB.