Making A Text Dungeon Crawler On the Commodore 64: Part 4 A Brief Interlude

Welcome to video four in the series. This is getting to be an enjoyable series for me!

As I get deeper into this project I wanted to take a few moments and fix a variable that I may have problems with in the future. This project is reminding me of the many pitfalls I had on my BASIC game projects when I was in high school. The most noticable to me is the fact that I didn't plan out the projects that well. So, as a result, I'd either work my self into a corner and have to start the project over and better planned or I'd have to implement a feature poorly because I didn't think it out well enough. There were also times I'd get so fed up with a project I'd abandon it. I find that is the case here.



The game play "state" of the game is turning out a little more advanced than I thought it would. Actually I knew it was going to be pretty advanced for a simple text game. Most of it is due to the fact that certain things have to happen at a certain time. Old past me would just plowed forward and implement everything ad hoc. New, advanced current me knows this is futile so I am working with another copy of the project at the same time so I can get the gameplay stuff down pat and make an enjoyable game and make the videos better. Current Dan also knows that divying these things up into small blocks makes the process a lot easier. Of course the danger of breaking everything into chunks so small that the videos are boring is very real too. I guess I'll have to play it by ear and see how it goes...kind of like how I'm already doing.

I'd also explain a little about using the following code:

10 on s gosub 1000, 2000, 3000, 4000

As opposed to:

10 if s = 1 then gosub 1000
20 if s = 2 then gosub 2000
30 if s = 3 then gosub 3000
40 if s = 4 then gosub 4000


I guess it could be argued the second way is more readable but it could also be argued that the first way is smaller thus easier to implement. It also might be argued that the first way takes less CPU cycles to perform. But, since this really isn't a time critical application that is a moot argument.

When I was younger and  made games on my Commodore 64 the first line of code was hard for me to understand. I don't know why it was hard for me to get my brain around it but it was. As a result I'd use the second example and always felt it was a less than adequate just because I really didn't understand the first way.

Another thing that just occured to me is how structured my code looks. At least compared to what I did when I was in high school. After using languages such as C, C++, Pascal, Java, Python and C# where you have to be structured in some fashion it is now easier for me to lay out the program in line-numbered, 8-bit BASIC to where it's fairly easy to implement and follow the code. I think when I wrote the Christmas Candle I layed the code out a lot better than I'm doing now but this project is heads and shoulders above the spaghetti code I used to churn out in the 80s.