Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / scrolling help

Author
Message
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 16th Jan 2007 02:36
really sorry, if this is my second post of this, im not shur my 1 post got through.

alright, so im completely new to darkbasic and im getting started on a text game. Everything was going along great, just alot of repeat until, and if then, commands. The first problem i encountered though is that while the game s running, the text goes past the screen? How do i make it so that, the screen follows the text? or you can scroll? remember that im new, so keep it simple... thanks!
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 16th Jan 2007 02:49
when your new here, posts have to be moderated and viewed by someone with the authority to allow it to pass into the public domain. eventually this procedure will wear off in time.

Just post once and be patient. You did make 2 posts and I had to delete one from the forum.
No dramas, now your aware of the newcomer status.

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 16th Jan 2007 11:55
The best way is to show us the code you have now so we can see what the code is doing exactly. You can use code snips and paste in your code.

[ code ]
Your code here.
[ /code ]

Remove the spaces between the brackets and we see this:


If it's a standard text adventure you can just limit the number of characters per line so that it can all be seen. Or you can print the text on a per word basis looking at the screen size to determine if the word will go off the screen (also known as word wrapping).

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 16th Jan 2007 23:12
Thanks grog, but I didnt mean that the text was going off the sreen to the right, I meant it was going off at the bottom. Should i just use cls and clear the screen? Any other suggestions other than simply clearing it?
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 17th Jan 2007 00:01
Oh, I was also wondering, what is the command to skip to a certain line of source code?

like
if a$ = "yes" then (go to line 10)
and if the command is like that, is there a command that tells you what line number is where?
I couldnt find these answers in the book.
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 17th Jan 2007 11:22
Quote: "Thanks grog, but I didnt mean that the text was going off the sreen to the right, I meant it was going off at the bottom. Should i just use cls and clear the screen? Any other suggestions other than simply clearing it?"


Np.

There are several ways but I need to see your code to see how your writing your text to the screen to best suggest a way... without code it's only speculation.

Here are some ways:

1. You can use "print" and it'll scroll on its own.

2. You can use "get image" to grab the text you have so far (minus the line at the top), clear the screen, and paste the image at the top.

3. You can have all text go into an array and each new line of text is added to the array. The screen is cleared and all text is printed on the screen from the current top line to the bottom.

4. You can make each section of text (paragraph) as a sprite and move each sprite up till theres enough room for the next sprite text. The sprite that goes above the screen is deleted and reused for the next paragraph.

There are probably more but I can't think of them right now.

Quote: "Oh, I was also wondering, what is the command to skip to a certain line of source code?"


I'll tell you but only if you promise not to use it.

< Don't read the rest if you don't promise out loud... don't worry there are better alternatives. >

The command your looking for is called "goto"... it is a command many of us don't like to use because it creates something known as spaghetti code:

http://en.wikipedia.org/wiki/Spaghetti_code


Instead of line numbers we use labels which are just text with a colon after it.

It's a heated debate among us about "goto"... some believe it's evil and should never be used (I'm in that group) and some love it and use it in every program.

There are 3 methods you can use:

1. "goto" goes to a label and does it's thing... it cannot go back to where it came from forcing you to "goto" another area. That's the main problem with using "goto". Also if you use "goto" it is very hard to track what your code is doing visually because you have to skip all over your code.

2. "gosub" is the happy alternative to "goto". It goes to a label, does whatever you want, then it "returns" back to where it came from. Which makes it easier to track because you can assume that any "gosub" will always return to the line under it (unless you forgot to add the "return").

3. Functions are like "gosub" but they are more powerful and can return variables to the line that called them... which makes them as if their your own custom Darkbasic commands.


Here's an example of "goto":



Now the same code using "gosub" instead:



Now using a function instead:


The method I like are functions. I steer clear of "goto" and even "gosub" now. I hate to say it but to be a more rounded programmer you have to use them all just to see how they work. You may like and use "goto" but as your programs get bigger you'll want to stop using it because it can turn into a real pain when trying to debug code.

I recommend using "goto" only for research and learning... then use "gosub" till your confident enough to tackle functions... then never look back.
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 17th Jan 2007 22:05
Wow... thaks a lot
I understand now why I shouldnt use goto, I can already see my programs getting extremely confusing, lol. Dont quite get functions though, time to go read some tutorials on em...
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 17th Jan 2007 22:21
Alright, read a small tutorial on functions, Still alll i really get is that you use them to make custom commands, and then call that command when you need it. Im not sure how to use that to branch off in my text game. Ill put my text game here, If you could read over it and tell me everything I have wrong that would be great I am aware that, some of the text has more than 255 characters in it, ill fix that later, you can figure out what im saying by looking at the souce code. Oh and you can see my expirementing with the goto command at the very end, I just dont see any other way to branch other than that command lol
If you could review it that would be great! youll see by the code im a real begginer, of course everyone has to start somewhere.



Image All
20
Years of Service
User Offline
Joined: 30th Dec 2005
Location: Home
Posted: 19th Jan 2007 22:55 Edited at: 19th Jan 2007 22:55
Program crashes: File does not exist at line 2. I don't have that midi on my harddrive.

TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 20th Jan 2007 02:06
A couple of problems which aren't major at the moment, but soon will be:

1. Your program is currently linear rather than modular. At it's current size it's not too bad, but later on it will be a nightmare.

Read up on program layout here:

http://forum.thegamecreators.com/?m=forum_view&t=96075&b=7

Once you have your program in a modular format, it will be a lot easier to manage and add to.

2. There's no indentation which makes it a lot harder to read. Take a look at your code indented to see what I mean:



TDK_Man

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 21st Jan 2007 07:38 Edited at: 21st Jan 2007 17:21
@ Image All

If you want to run it you can put a ` in front of that line. Remarking off lines work very well when we don't have non-vital media.

@ sirsiddy

Np.

Since this is a text adventure game one of the first things you want to do is research by playing the same type of games. One of the most famous text adventure game makers was a company called Infocom. They made the highest quality and smartest text adventure games.

Here's a wiki about Infocom: http://en.wikipedia.org/wiki/Infocom

Activision currently holds the copyrights to all Infocom games but they released free versions that can be downloaded here (I tried to get a page that was associated with Activision but they appear to not care about Incoms games anymore):
http://www.csd.uwo.ca/Infocom/

Download Zork 1 for Windows 95. It'll run in XP using DOS... just click twice on the .bat file so you don't see the ansi color codes (its the file with the gear on it). You can save your progress by typing "save" and load by typing "restore".

You won't get Infocoms quality right away (or ever) but you'll at least learn the fundamentals of making a good text adventure by playing Zork... and it's a really fun game.

Now that I see your code I can see why it can be a problem with text being too long. But that can be solved by just reducing the size of your text. The default size of text is fine for most people that play games (thats why it's the default size). I can see making text that big if your program is intended for only old people or people on the verge of going blind. Also if you want to make it better looking (instead of blocky text) you need to set the font too using the "set text font" command.

TDK is totally right. To make a text adventure non-linear you need to make a map (usually with graph paper) that shows rooms and lines going to each room. Making a map on paper shows you visually how to setup the data and if the room placement will seem logical to the player. In text adventure games you want the player to be able to make a map on his/her own (I've attached one of official Zork 1 maps to this message... the one you'll start on if you download and play Zork 1).

The way your game is (and with a non-linear style) you can use a set of commands that will make it easier. Their the select/case commands... they allow you to select one thing out of a list of many. With select/case you can easily use one place for all text and one single "input" command.



The way you do input is ok but you need to fix it so that when a person types in something it'll work no matter what. If I typed in "Look at man" it won't work because the string your looking for is "look at man". The difference is I typed in a higher case L. We know it's still the same but Darkbasic doesn't. To prevent things like that you can force the input to be lower case to match the strings your trying to detect. The command is "lower$(yourstring$)" as in "a$=lower$(a$)". To change it to higher case use "upper$(yourstring$)".

[edit]
Also to make it more modular you need to separate the words to verb and noun. One trick that'll make your game appear smarter than the average text adventure is to take the first word and the last word of the user input. That way "look at man", "look at ugly man", "look at the ugly 500 pound man" all work because "look" is in the front and "man" is at the end. You can use select/case to store all the verbs and have the checks for the nouns inside each verb case (using the noun and current room number).

Once you've made your map you create a text file with room properties, name and description (if you want it like Infocom games). Load that file into an array and use that to tell the user where he/she is by printing the room name and description every time they go into a room they've never been or when they type "look" or "l" without a noun.

Items are also in a different file with item properties (including starting room number), name, short description (for inventory), item on the floor, and long description when the user wants to look at the item.

To save on typing everything into code you can also make a file for look data for stuff in rooms that won't move around like items. The look data only needs object name, room number, and description.

For objects that don't move and to make the game more fun you can add a file for take data... for when the user tries to take stuff in the room that can't be taken (like taking live wires that shock you). The file should contain the same information name, room number, and description. The room number in both the look and take data can use zero to represent something that'll work in any room (like trying to look at or take "air" or "yourself").

The words the game knows can also be in a file so you can have many words that mean the same thing (like take, grab, pick all mean to take an item). The data only need to contain a word number and the word (take, grab, and pick all have the same word number).

Here's all the file structures I used for the text adventure I was making a while back (everything loaded into arrays):



Text adventures can get very complicated to make but once you get the structure down are fun to complete.
[/edit]

There is another option too. You can change it to a choose your own adventure style. Give the player multiple-choice options to do things or go to areas. That way you can pretty much force on them a set of options but at the same time appear to be a non-linear adventure.

It looks great... your on your way to making a really cool adventure.
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 22nd Jan 2007 00:05
Wow, thx grog. That helps a lot. I got interested in making a text game after playing colossal cave lol. so old... and so good. But anyways, I was wondering if anyone has a source code for a text game that they wouldnt mind me looking over. I think I will understand it more with a hole code in my hands, not just snippets.
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 23rd Jan 2007 10:43 Edited at: 23rd Jan 2007 10:45
Np. I've never played Colossal Cave but it sounds cool... especially since Zork was inspired by it.

I won't post my text adventure but I can help you on yours. The things you need to know are:

1. Making arrays
2. Loading from text files
3. Do/loops
4. For/next loops
5. Functions
6. All the text commands

The arrays store the data you load from the text files. You use text files so you can easily edit the data anytime you want. The do/loops you already know. For/next loops allow you to do the same commands multiple times without repeating those commands over and over. If you still have trouble with functions let me know. You might not use all the text commands but it's good to know them... especially when you want to write a text adventure. The help files can teach you all about the list above but if you need help just let me know.

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 24th Jan 2007 00:16
Is this what you mean by making the map with the functions?


I understand that to make it so that if they write in something wrong it will say something lik if a$ <> "hi" then print "what?"
but when I use it for more than 1 condition in a function
then it always types in at least 1 "what?"
heres an example

One more thing should I make it so that if you type in random letters than it prints what? but if you print in something logical like "say hi to man" then it print "you say hi to man" but if you say "kill man" then it prints "you cant kill the man" *sigh lol
at least I get functions(I think)
TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 24th Jan 2007 18:21
First of all, I've never written a text adventure, so I can't speak with specific experience. But, if I started one today and wanted to have a bash myself, I wouldn't do it the function way like you did.

I'd be tempted to create a series of multi-dimensioned arrays whose indexes match the room numbers. For example, if your 'map' of rooms is say a 20x20 grid then you could have:

Dim Description$(20,20)

You would then put all your room descriptions into this array.

As you move from room to room, your program knows the X/Y room position on the grid and stores them in RoomX and RoomY variables which would then be used to print the room description.

For example, say you are in room 12,10. The variable RoomX=12 and RoomY=10. If you go West you would go into room 11,10 and all you have to do is:

Print Description$(RoomX,RoomY)

You only have one line of code which handles the description for every room!

The same method would be used for items in rooms, characters or whatever - just moving data from one part of an array to another.

The most difficult aspect I would think would be the parsing routines which take what the user types in and decides what to do with it.

TDK_Man

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 25th Jan 2007 04:07 Edited at: 25th Jan 2007 04:18
Quote: "Is this what you mean by making the map with the functions?"


No. It's closer to what TDK said. The multi-dimensional array is used but not with roomx and roomy coordinates. "Dim Description$(20,20)" would be 20 rooms (not using zero) with 20 lines of text for that room description. "Description$(RoomNumber,TextLines 0 to 20)". Making several lines instead of one big line is easier to work with and edit. Also its best to keep away from a set x,y grid to allow more flexibility in the map, to not have to add a z coordinate to go up or down, and to not waste space with rooms that aren't used.

Quote: "I understand that to make it so that if they write in something wrong it will say something lik if a$ <> "hi" then print "what?" but when I use it for more than 1 condition in a function
then it always types in at least 1 "what?"

One more thing should I make it so that if you type in random letters than it prints what? "


Thats where select/case is useful. You have all the words listed in the select/case statements. If it doesn't find the word it goes down to "case default" and does that instead.

Quote: "but if you print in something logical like "say hi to man" then it print "you say hi to man" but if you say "kill man" then it prints "you cant kill the man" *sigh lol"


With all the words listed in select/case you can have checks under the word "say" and check to see if the man is in the same room with you for speech. If he is then it works if not it won't. Same with "kill". Under the word "kill" you do checks to see if #1 your carrying a weapon and #2 if the man is in the same room as you.

Quote: "at least I get functions(I think)"


Yup.

The following code snip is an example of a very small text adventure I threw together last night (5 rooms). I would of posted it last night but I tried it in Classic and had to change it around a bit... the first being the reason why this tread is here... text scrolling. Several things that Pro allows but Classic doesn't made it difficult (like using "inc" and "dec" on arrays isn't allowed in Classic) but I finally got it working in Classic.

Because Classic has a problem with multiple cases each direction is separated in this example (the Pro version I made last night had all directions together). Classic also has an inability to use multiple select/cases so I had to change the detection of nouns to if/thens and switches (rather than using select/case and "case default"). Another bug (maybe not a bug) was Classics habit of not clearing variables when going inside a function (so there are several variable=0's that you wouldn't need in Pro). I'm not against Classic... just really pro-Pro.

This has everything in it except items (which is easy to add later when your ready). It works in both Pro and Classic (the map is attached):



If there are any problems or questions I'll do my best to answer them. Let me know when your ready to tackle items.

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 27th Jan 2007 23:25
Wow thanks a lot grog , this REALLY helped me understand arrays, better than ayn tutorial I read. I was reading through the code and started kinda following your example and making my way down, chacking back here when I needed. I couldnt figure out what was with the dim player(5)..... debug? also I couldnt figure out what was happening at the showroom function?
sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 27th Jan 2007 23:27
aaaah dang it dont know how to edit a post so ummm srry for the double post... heres what I have so far
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 29th Jan 2007 04:56
Np.

The debug part is just a convenient way to get information about the game as its running. If you set "Player(0)=2" and you have this:



Any time the code gets to that point it'll send to the screen printing function whatever is stored in v$ and n$ to the screen (in this case it's the verb and the noun taken from the user input). I added this because when I was debugging it to work in Classic it would work fine but when I used two words then a single word it would repeat the two words over and over again. I knew what it was doing because of that code above (thats when I discovered that Classic doesn't clear variables before going inside functions) The fix was a single line "Space=0". Without that debugging code I would of been pulling out my hair for hours not knowing what was going on.

Most of us add things like this temporarily (without the if/then) and delete them later but doing it this way the code will only run if "Player(0)=2". So the code can remain there just in case there's a problem later and you want to find out if the verb and noun extraction are working properly. If "Player(0)=0" then no debug code will run and the game will appear the way it's intended for other people to play. In my text adventure I added "debug" to the word list and used that to set debug mode while playing. This is basically how "cheat codes" get into games. The programmers add ways to turn on/off things in the game, instantly add millions to players money, and/or set stats to max. They do this to test the game but leave them in for players to discover and use themselves as "cheats".

Quote: "also I couldnt figure out what was happening at the showroom function? "


I'll give you a more detailed description per set.



The function is called with only one variable the current room number. This part checks if "Player(0)=1". If yes it makes a string that adds the current room number (the one its about to print to the screen). This is like the debug mode for showing the verb and noun. It's just a way to quickly see what room number your currently in.

Looking at this code again I can see one reason why it may of confused you a bit. "Player(1)" holds the current room number but I only use it here and rely on "RoomNumber" instead. This function was called with "Player(1)" so both "RoomNumber" and "Player(1)" are the same. I should of removed "RoomNumber" and just relied on "Player(1)" any time I needed the current room number. They both work because "RoomNumber" is created when this function is ran and "Player(1)" is available throughout the whole program because it's an array. Now if Classic worked properly "RoomNumber" would be zero outside of this function... but because of the bug it probably keeps the variables number.




This sends the room name and Debug$ to the screen printing function. If "Player(0)" is anything but 1 Debug$ will be blank. In Infocom games each room has a name so they can be put on the status bar and printed first before the room description. This being separated also makes it easier to later color the room name text differently than the room description text. A colored text adventure is a lot better looking than a black and white text adventure.




This exits the function if the room has been visited before (stored in Room(xx,13). In Infocom games the default way the world is shown is when you've been to a room before it only shows the room name (which was done above). They decided if you've been to a room before there's no need to see the entire room description unless you ask for it with "look" or change the mode to verbose (which I didn't add in the example).




This part sends the room description to the text scrolling function. It uses one of the most useful things in all languages... the for/next loop. In this case it takes the variable "t" and starts it at 1. Every time it sees "next t" it adds 1 to "t" (the default without "step") and starts the loop again (the line right under "for t=1 to 10"). The 10 means the last number it'll go to is 10. This could of been "for t=0 to 10" but since I separated the room name I left off the room name from this for/next loop.

So knowing that "t" goes up per loop when it sees "if Room$(RoomNumber,t)>" "" the first loop it's "if Room$(RoomNumber,1)>" " the second loop if Room$(RoomNumber,2)>" " and so on till it's "if Room$(RoomNumber,10)>" "". By the way that just checks if there is actually text in that particular line in the description. If it sees a blank line it won't send the line to the text scrolling function with "ShowText(Room$(RoomNumber,t))" (so if the description is only 5 lines it won't print 5 blank lines after it).




This last part sets the room as being visited. If "Room(Player(1),13)" was already set to 1 this the code wouldn't of been ran because "if Room(RoomNumber,13)=1 then exitfunction" is several lines above it. Without this the other line to exit the function wouldn't be needed and every time this function is ran it would always show the full room description.


Quote: "aaaah dang it dont know how to edit a post so ummm srry for the double post... "


It's ok. I don't see the edit button either. It's probably a new forum bug.

Quote: "heres what I have so far"


Theres a few things that need to be changed but it looks great so far.



The above needs to be in rem statements. The ones I made were just as a reference. When you don't put them in a rem statement Darkbasic thinks you want to define the array. It thinks that "xx", "north", "east", "west", and "south" are all variables. They all equal zero (because they haven't been defined) so Darkbasic sees this instead:



It's ok because their all zeros but it's best to rem these off so you know it's just for your eyes and not meant to be code:






This part is ok but you skiped a line. "room$(1,1)" isn't defined. The way my example was set up it would always not print that skipped string. But if you want to change this later you may scratch your head for a while wondering why this only prints 3 lines yet takes up 4 in the array.




The room description is fine but you have "To the south there is the room you just came out of". That needs to be changed because the player isn't always going to come from that last room. The player may come from the other exit the next time they're in this room.



This is the exits for the room in the last code snip. In the description the exits are west and south. You set the exits here (using the reference) as east and south. Looking at the rest of the rooms it appears that only the description needs to change to say "east" instead.



The way the description is written you'll eventually die if you enter this room too much... well you won't in the game (unless you add it) but what would happen in real life if you threw up constantly? This is great writing but events that happen to your character need to be done outside of the room description. You can set it up so that when the player enters this room for the first time they throw up but you only want it to happen once... not every time they enter the room. And again you don't want to assume that the player comes from a specific direction because there are 2 exits.



The assumption here is acceptable because there is only one exit. You did good on this one.

All in all a great start on a text adventure.

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 1st Feb 2007 05:44
Thx GRog, wow I feel like a dumb a$$ about those descriptions, lol It was late when I made them, I should have thought about players entering from different locations. And lol about the throwing up thatd be funny in a text game...
"> go north"
"You have entered this room 20 times and each time your character has throw up, you begin throwing up blood, you die of blood loss"
"player- waa..... what?"

but thx for the question on the function,
this code is a little confusing but im disecting it.. and hopfully ill write my own version of this in a little, but ill definetly let you know when im ready to cover items
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 1st Feb 2007 23:00
Don't feel bad we all make mistakes.

Yeah that would be funny. You can still make them die from throwing up too much but it won't be a total shock if you add a health check and send them warnings every once in a while.

After 1 puke: Your stomach hurts.
After 3 pukes: You feel a sharp pain in your stomach.
After 5 pukes: Your stomach hurts and you have a headache.
5+ pukes: Death

You can add medicine that'll take the puke number down a bit or stop them from throwing up entirely.

Np and take your time.

Hobgoblin Lord
20
Years of Service
User Offline
Joined: 29th Oct 2005
Location: Fall River, MA USA
Posted: 3rd Feb 2007 15:40 Edited at: 3rd Feb 2007 15:43
I wrote this as a strting example for people to work from with the text adventure competition before. It is more for review of ideas then to run since it is DBpro code. Most of it will work in DBC except the types and array list functions, but again this is more for review and is a solid text adventure base.

You will notice that command words are truncated to 4 letters, this was a common practice in these games since most people can spell a word correctly up to the first 4 letters. They can still type in "North" but the program will read it as "NORT" and process it appropriately.



sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 5th Feb 2007 00:24
I tried again writing my own code, following your example, I tried to make it so that only north east south and west were directions, I finfished but when I try running it i get an error right at room$ (1,0) = 2

heres my code
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 5th Feb 2007 06:06
@ Hobgoblin Lord

When did they have a text adventure competition? I would of loved to enter that contest.


@ sirsiddy

You get an error because your calling that a string (the "$") and trying to store it as a number (rather than using "2" with the quotes). With those though you don't want a string so just remove the $'s from all the arrays that aren't meant to be strings.

Several times a space is between a command/function name and the first "(". The spaces need to be removed so Darkbasic knows it's a command or function. (examples "room$ (1,0) = 2" should be "room(1,0) = 2" and "ink rgb (255,255,255),0" should be "ink rgb(255,255,255),0"

The "blockmovement()" function needs to have both an "end select" and an "endfunction". Without the end of the function Darkbasic gets confused because another function is created before the end of the last.


Your code edited:


Looking good.

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 6th Feb 2007 00:27
Hey! text on the screen yippee lol thx, Im still a wee bit confused, but ill look over it some more. I was wondering if, since I have the text game I want to make all planned out should I go ahead and make the layout with arrays? when you add items and such are you able to just add it onto the code? and if you explain items too me, could you also explain, unlocking doors and such, like you cant enter this room unless you had pressed the lever? If you can add items right into the code, I think im ready for items. Ill be writing the arrays, for the game I have planned
Hobgoblin Lord
20
Years of Service
User Offline
Joined: 29th Oct 2005
Location: Fall River, MA USA
Posted: 6th Feb 2007 00:53
Grog it was in the game design theory board.

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 8th Feb 2007 11:35
Quote: "Hey! text on the screen yippee lol thx"


Np.

Quote: "Im still a wee bit confused, but ill look over it some more. I was wondering if, since I have the text game I want to make all planned out should I go ahead and make the layout with arrays? when you add items and such are you able to just add it onto the code?"


Well it's better to use files but you can use arrays till you learn about file loading.

Quote: "and if you explain items too me, could you also explain, unlocking doors and such, like you cant enter this room unless you had pressed the lever?"


Actually I've already covered it in the example. Room number 5 cannot be accessed at first because the direction for "in" is at -1 to block the player and give them the message "There doesn't appear to be a way inside the car.". Once the command "break window" is done in room number 4 the direction to get into the truck is changed from -1 to 5 so the player can access room number 5. The same thing can be done with anything at any location you want. You can make a button or switch teleport the player to another location, make the player 100 times stronger (carry more), open a door in any room (no matter how far away), create a stairway with vines, shrink the player, instantly kill them, or a slow painful death that kills them after 10 turns, anything you can think of.

Quote: "If you can add items right into the code, I think im ready for items. Ill be writing the arrays, for the game I have planned "


Ok I'll cover items... this is going to be long message.

Items are stored just like the rooms. All text is in one array and all item data is stored in another array.



Item$(xx,0):
The first string stored is the item name which is used to recognize the item and manipulate it in the game.

Item$(xx,1):
The second string is what the player sees if the item is in their inventory.

Item$(xx,2):
The third string is what the player sees when the item is on the ground.

Item$(xx,3) to Item$(xx,7):
The last 5 strings is the item description shown when you look at the item. This is often where clues to puzzles are found by closely examining the item. I put this at 5 lines but it can be any length you need.

For the item data it can be as complicated as you want. The following is the main data an item would have for Infocom games:



Item(xx,0):
The first and most important piece of item data is where the item is located (room number). Items that are in the players inventory can equal 1000... you can use any room number that wouldn't be used. Zero seems like a logical choice but zero should be used for destroyed and/or lost items (as the programmer you can add a way into room #0 to see all the lost or destroyed items). When an item is inside another item this number is no longer a room number but an item number... the way the computer knows its an item number rather than a room number is by using a negative number instead of a positive number (if this first piece of data is 1 the item is in room number 1... if it's -1 the item is inside item number 1).

Item(xx,1):
This determines if the item is movable or not ( 0 = No 1 = Yes). This gives you the ability to have item-like properties on things that cannot be picked up by the player for various reasons... like its too big, too heavy, or bolted to the floor. Non-movable items are not shown on the ground so the item must be mentioned in the room description where the item is placed. If it's not talked about in the room description the player won't know the item exists. All items you want the player to pick up and use will have a 1 stored in this piece of data.

Item(xx,2):
This stores the items weight. This really isn't vital but if you want containers its probably a good idea to keep it. When the player wants an item in a container it uses this number to determine if this item will fit in the container the player wants it in. This brings a bit of reality to the game. Without this a small sack can contain every single item in the game... no matter what the size.

Item(xx,3):
This stores if the item can be worn (0 = No 1 = Yes but not worn 2 = Yes and being worn 3 = Yes and permanently attached). Articles of clothing and jewelry would be the most common use for this stat. You can use this to only allow the player access to areas if their wearing a specific ring, gloves, hat, necklace, or something uncommon like orc skin. If you have an event where your player is knocked out and stripped of all items you can use this to keep what their wearing or only the items they can't remove. You can make it a puzzle to remove items that are "permanently attached".

Item(xx,4):
This determines if the item is a container (0 = No 1 = Yes and closed 2 = Yes and opened 3 = Yes and locked). This is given 4 options for the computer to quickly determine if this is able to hold items, if it's closed, if it's open, and if it's locked. When containers are in the players inventory if their open the contents of the item is shown. Generally if you have a container you always want it to start closed to give the game more reality. It gives the player something to look forward to revealing. The 4th option can be used to prevent the player from gaining access to the contents right away. Opening the locked item can be as difficult as you want or a simple as using a rock on it.

Item(xx,5):
This holds the weight limit of the container to prevent the player from putting any item they want in the container. This is vital for the next piece of data.

Item(xx,6):
This stores the current weight of the items inside the container. If the container starts with items you have to get the total weight of the items and put that number here. Without doing this initially for containers that start with items inside them a container that's technically full will still allow items stored in it beyond the max weight limit. When items are taken out or put into the container the item weight is subtracted from or added to this piece of data.

Item(xx,7):
This determines if the item is a light source (0 = No 1 = Yes but Off 2 = Yes and On 3 = Yes but burnt out). In all the Infocom games one of the best ways to prevent the player from going into certain areas is to require a light source. If they walk around too much in the dark they'll be eaten by Grues. This gives you the power to use the rooms light data "`Room(xx,12) = Light? 0=Dark 1=Lighted" or rather the lack of it to it's full potential.

Item(xx,8):
This is how many turns the light source will last if it's on. Every time the player makes a move with the light source on it'll reduce this number. To make the light source last forever make this -1.


Here are some items using the data structure above:


Now the first thing we need to add is a way for the items to be seen. In Infocom games the items on the ground are after the room description... so adding a check to show items belongs in the same function but under the for/next loop for the room description. Also if the room has been visited before the items are still shown so the function needs to be modified accordingly.

The function before the changes:


The function after the changes (I got rid of "RoomNumber" and used "Player(1)" instead):


Next the player needs two more pieces of data... current weight and max weight. The player also needs a way to see his/her inventory. In Infocom games thats with the "inventory" command ("i" for short). The words need to be added to the word list and the new command added to the select/case in the "DoCommand()" function.





The "inventory" command by itself isn't much without the ability to add to the inventory so we add the "take" command to the word list and add the new command to the "DoCommand()" function:





The above "take" command has two parts. One that will take an item if no noun is typed and if there is only one item in the room. The other part will take items when the item name is typed in. Both parts have identical checks to make sure the item is in the room or on the player already, if the item can be picked up, and if picking up the item will go over the max weight limit for the player. It's complicated but its made that way to mimic the way Infocom games treat items.

Once items are in the inventory we need to add the "drop" command to remove items and place them in the current room.





The "drop" command is less complicated because the only check thats really needed is if the item is on the player.

Well... that's items in a nutshell. I'll cover container opening, closing, and taking items from containers in another message in a few days. One thing I didn't cover that you might want to try yourself (before I show you) is looking at the items. If you have any questions/comments I'll be happy to answer them.


Here's the previous example with the new code:


Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 8th Feb 2007 11:39
Quote: "Grog it was in the game design theory board."


Thanks I'll do a search for it. I must of been gone when it happened. I don't go into that area much so I probably would of missed it even if I was around.

sirsiddy
19
Years of Service
User Offline
Joined: 15th Jan 2007
Location:
Posted: 8th Feb 2007 15:28
Wow thx again. Looks like youv covered everything! Im really begining to understand Thx for all that time you put in. If it doesnt take to long to make, Ill post the adventure I have planned here.
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 8th Feb 2007 20:35
Np. I'd love to play it.

Login to post a reply

Server time is: 2026-07-07 03:46:14
Your offset time is: 2026-07-07 03:46:14