beginners text adventure problem

SYS 64738
User avatar
drpump
Member
Member
Posts: 7
Joined: Mon Aug 04, 2014 5:43 pm
Location: london
Contact:

beginners text adventure problem

Post by drpump »

First post here. Hi all :)
I was wondering if you might be able to help with this. I'm hopeless with programming in general. I’ve recently got a commodore 64 and wanted to program a simple text game with BASIC. I have done a test...

10 print "hello, what is your name?"
20 input name$
30 if name$="filth" then goto 40 else goto 50
40 print "hi"
50 print "bugger off"


When I type in filth it goes to 40 and prints “hi” , but the problem is, it also prints line 50. What do you think could be the problem? I want to be able to flick between different number lines throughout the game and it wont work if this keeps on happening.


ajordison
Developer
Developer
Posts: 59
Joined: Wed Apr 16, 2014 1:28 pm
Location: Hartlepool, UK
Contact:

Re: beginners text adventure problem

Post by ajordison »

Hi, and welcome to Melon64!

Well your programs doing exactly as it should, executing line 40 then line 50. The solution depends on what you want to do when you enter the right (or wrong) name. For example, you might want to quit if you get the name wrong and continue if you get it right:

Code: Select all

10 print "hello, what is your name?"
20 input name$
30 if name$="filth" then goto 50
40 print "bugger off"
45 end
50 print "hi"
60 rem rest of program
I swapped things round a bit - you don't need the 'else' part of your program as it's implied by executing line 40 if the test fails.

Hope that helps!

Arthur
Try out CBM prg Studio for all your Commodore development needs!
Stay a while...stay for erm quite a while!
User avatar
drpump
Member
Member
Posts: 7
Joined: Mon Aug 04, 2014 5:43 pm
Location: london
Contact:

Re: beginners text adventure problem

Post by drpump »

Thanks, but I think I want it to go more like this...

Code: Select all

10 print "you are in a dungeon what do you do?"
20 input thing$
30 if thing$="make fire" then goto 50 else goto 40
40 print "i dont understand"
50 print "you make a fire, what now?"
60 etc...
I want it to go on like a typical text adventure, without ending or stopping.
ajordison
Developer
Developer
Posts: 59
Joined: Wed Apr 16, 2014 1:28 pm
Location: Hartlepool, UK
Contact:

Re: beginners text adventure problem

Post by ajordison »

Fair enough, but you still need to add some code to change the flow of the program after line 40, otherwise it goes straight onto line 50. Something like this:

Code: Select all

10 print "you are in a dungeon what do you do?"
20 input thing$
30 if thing$="make fire" then goto 50 
40 print "i dont understand"
45 goto 10
50 print "you make a fire, what now?"
60 etc...
So now when you enter the wrong answer, the computer goes back and asks again.
Try out CBM prg Studio for all your Commodore development needs!
Stay a while...stay for erm quite a while!
metalfoot
Member
Member
Posts: 56
Joined: Sun Apr 13, 2014 8:22 pm
Location: Manitoba, Canada
Contact:

Re: beginners text adventure problem

Post by metalfoot »

There's no command 'else' in Commodore 64 Basic, which is part of the problem.
MarcWalters
Member
Member
Posts: 55
Joined: Wed Jun 11, 2014 2:33 pm
Location: Lake Macquarie, NSW, Australia
Contact:

Re: beginners text adventure problem

Post by MarcWalters »

Just some thoughts on adventure game programming in general:

Programming a simple text adventure game is a great way to learn the BASIC language and develop BASIC programming skills. Sometimes though, the quick results of BASIC programming can obscure the need for design. A carefully designed program will avoid unmanageable growth of size and complexity as gameplay logic is added.

For an adventure game, it is useful to have a "toolbox" of BASIC language knowledge, such as:
Conditional program flow: IF..THEN, ON..
General program flow: FOR..NEXT
Subroutines: GOSUB..RETURN
I/O: INPUT
Boolean logic: AND, OR
Comparison: =, <>, <, >, ...
Data access: DATA, READ, RESTORE
Data storage: Variables, arrays

BASIC has been around a long time, and excellent general reference material is available, including books and articles on design. The following points are some I think might be useful in the future as your programs get larger and more "adventurous".

1) Separate gameplay logic from program structure:
It's easier, in the long run, if gameplay logic is encoded as data, and not as procedural code. The program structure can be written first, and reused for subsequent games. Then the actual game is "simply" defined by adding data. There are trade-offs between readability, complexity, and so on, but experience will show where the sweet-spot is.

2) Use modular "building blocks":
Ideally, each distinct section of program structure will be unique. Where possible, access them as functions - they take an input, do some defined task, then return a result. They make it easier to test your game.

3) Keep program code clean and documented:
Use REM statements to document each module. Keep program code neat and simple. Use one or more colons to indent encapsulated code such as the inside of loops. Use spaces. Don't cram too much on a single line.

4) Think one or more levels above the actual problem:
Here's an example.
SCENARIO: The player needs to make a fire so that the room is lit and the player can see.
TEXT: The input "make fire" results in the response, "You make a fire. What now?".
REQUIRED CONDITIONS: Player has in his inventory a tinderbox and piece of wood.
CHANGES THAT OCCUR: A piece of wood is removed from the player's inventory. The room has a fire added to its contents. The room now has a light source. Everything in the room is now visible to the player.

The changes will affect other things.
The goblin sleeping in the corner of the room has woken up because of the light. A door in the North wall is now visible. The player no longer has a big heavy piece of wood with which to pacify the goblin.

One way to manage the complexity described above is to design the program so that conditions and changes are encoded as small, unique descriptive elements, and that each relevant state of the gameplay can be queried and changed.

Anyway, the ideas above are for the future, to be considered once you're more acquainted with BASIC and want to try a more involved challenge.
User avatar
Shaun_B
Member
Member
Posts: 179
Joined: Tue May 06, 2014 12:12 pm
Location: UK
Contact:

Re: beginners text adventure problem

Post by Shaun_B »

Hi,

If you're going to store the information for each location in a variable, you may run out of space in a single variable as each string will only accept a maximum of 255 characters. I put a quick example of how to negate this problem here:

http://www.melon64.com/forum/viewtopic.php?f=24&t=181

Regards,

Shaun.
BASIC Programming - making the mistakes so that you don't have to.
Circles and Squares.
Nothing I post here will stand up in a court of law.
User avatar
drpump
Member
Member
Posts: 7
Joined: Mon Aug 04, 2014 5:43 pm
Location: london
Contact:

Re: beginners text adventure problem

Post by drpump »

Thanks all, very informative stuff.
User avatar
Shaun_B
Member
Member
Posts: 179
Joined: Tue May 06, 2014 12:12 pm
Location: UK
Contact:

Re: beginners text adventure problem

Post by Shaun_B »

I wrote a text adventure for the Commodore PET and VIC-20 (unexpanded). I found that storing commonly used words in string variables and using these as constants saved memory, for instance:

Code: Select all

10 dim loc$(10)
20 t$ = "the ": d$ = " and " : y$ = "you " : n$ = "north" : s$ = "south" : e$ = "east" : w$ = "west"
30 loc$(0) = y$ + "are in a darkened room. to " + t$ + n$ + " is a door" + d$ + "to " + t$ + s$ + " is a broken window."
40 loc$(1) = t$ + "corridor leads " + e$ + d$ + "there is a staircase to " + t$ + w$ + "."
50 print loc$(0)
60 print loc$(1)
To save some more bytes, the spaces that append the variable to the rest of the string can be removed and I don't think you need to use + in strings (but I can't test that at the moment). Code clean first and minimise later though.

Regards,

Shaun.
BASIC Programming - making the mistakes so that you don't have to.
Circles and Squares.
Nothing I post here will stand up in a court of law.
metalfoot
Member
Member
Posts: 56
Joined: Sun Apr 13, 2014 8:22 pm
Location: Manitoba, Canada
Contact:

Re: beginners text adventure problem

Post by metalfoot »

Shaun... wouldn't all the concatenation of strings eat up memory from the top down and cause a lot of garbage collection too? (Maybe not as big a REMOVED the VIC because with less memory garbage collection would be going all the time...)
Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 6 guests