How hard is it to learn basic and acembly?

[John Chow Seymour]

On 2/14/2021 at 12:51 AM, SlithyMatt said:

A game engine would not work very well written in BASIC. It's already an interpreted language, and adding another layer of interpretation would be too much for the X16.

I get where Matt's coming from, but I disagree in this case. I think you can make an 'engine' for the kind of game you describe, right in BASIC, without really adding another 'layer' of interpretation or slowing things down too much. (Keep in mind, speed doesn't matter much for a text-based game like this.)

In BASIC, your 'engine' would be a bunch of subroutines that handle the common tasks of your roleplay system.  For example, if your game has combat, you might have some subroutines that handle what happens when a player attempts to attack an enemy.  One for handling how the player selects what kind of attack to do, another for handling how the player selects which enemy to target, another that resolves the attack and assigns damage, etc.  Other subroutines might handle buying from a shop, equipping armor and changing the player's stats accordingly, branching with dialogue trees, navigating from room to room, etc.

Then when you go to write a new chapter of the game, you re-use all those same subroutines, but have new enemies, equipment, room descriptions, etc. Admittedly this may not be what's typically meant by an 'engine'.  But it would be a set of tools that you could use over and over to make new games in this genre.

Of course, this is exactly how you would do it in Assembly as well, but BASIC will be easier to learn as a programming language.  The downside to BASIC is that it will always run more slowly compared to Assembly, but for a text-based game like you describe, speed really won't really matter.  Speed starts to matter when you want to have graphical gameplay.

[SlithyMatt]

I guess I missed the part where it was strictly text-based. If you don't need to have graphics or responsive gameplay, sure you could do it in BASIC. Just be aware that it is difficult to scale and maintain a large BASIC program, especially when you are required to use line numbers and need to use 2-character variable names and unnamed subroutines. BASIC may be easier to learn at first, but it is anything but an easy platform for significant development.

 

 

 

 

[Karrgoot]

On 2/14/2021 at 5:32 PM, SlithyMatt said:

It does assume you have some experience with programming in at least a high-level language before.

Thax, but i have not done eny programming realy, i played around whit a cracked rpg maker in the mid 90's and made a game, every action had to do with a sex act, every weapon was a sex toy, the goal was to cum the hardest and the enemy's wer a variation of fatt pigs in different color. 

Not high-level programming, but thax ? you ment well.

[Karrgoot]

Thax all for responding to my question

[The 8-Bit Guy]

For a text adventure, I'd definitely go with BASIC on the X16.  It should be plenty fast.  There were plenty of text adventures written for Commodore systems in BASIC and those were only 1 Mhz.  BASIC is certainly a lot better for dealing with strings.

[Nero]

As I was hoping to 're-learn' BASIC not too long ago, I was planning on porting one of those old 'book games' into BASIC. Actually began doing that in an old Apple II emulator, since it was the computer I learned BASIC on, but now I'm more or less inclined to do it in the X16's emulator and see what happens. I have never even seen a real C64 in my life, let alone programmed in one. Is there any place where I can check the differences between Applesoft's and X16's/Commodore's BASIC? Or... is there any practical difference? Sorry for the newbness, but we gotta start somewhere ?

[Elektron72]

Although I have never used an Apple II, one significant difference that I am aware of is that Commodore BASIC lacks most commands for controlling the screen (no VTAB, HTAB, etc.). Instead, many aspects of the screen are controlled by printing special control characters. If you have never used a Commodore computer before, you may want to find an online version of the C64 manual to learn how exactly this works (I believe it is discussed in chapter 4). Anything that could not be controlled using these special characters would be done via POKE statements. Luckily, the Commander X16 has added commands to control several things that used to require POKE statements (a list of new commands can be found here).

[kelli217]

11 minutes ago, Elektron72 said:

Although I have never used an Apple II, one significant difference that I am aware of is that Commodore BASIC lacks most commands for controlling the screen (no VTAB, HTAB, etc.). Instead, many aspects of the screen are controlled by printing special control characters. If you have never used a Commodore computer before, you may want to find an online version of the C64 manual to learn how exactly this works (I believe it is discussed in chapter 4). Anything that could not be controlled using these special characters would be done via POKE statements. Luckily, the Commander X16 has added commands to control several things that used to require POKE statements (a list of new commands can be found here).

There's a KERNAL function called PLOT that allows someone to either get, or set, the current cursor position (depending on whether or not the carry bit is set in the status register), and it's not all that difficult to call it from BASIC.

When you invoke the 'SYS' command in BASIC, the registers are loaded with the contents of locations 780 through 783 ($30C through $30F) for the accumulator, X and Y index registers, and status register, respectively. So any KERNAL routine that needs arguments or returns results uses the values in those addresses when you SYS to the function's jump table entry point. When the function returns, those addresses will contain the return values.

POKE 781,RO:POKE 782,CL:POKE 783,0:SYS $FFF0

The above takes RO for row and CL for column and clears the carry bit, before calling PLOT to set the cursor position.

POKE 783,1:SYS $FFF0:RO=PEEK(781):CL=PEEK(782)

The above puts the current cursor position into the variables RO and CL.

(Do note that the X16's version of this function uses X for row and Y for column, while other computers using the Commodore KERNAL use X for column and Y for row, so any online documentation resources you find for those computers may be confusing if you don't take this into account.)

[TomXP411]

If you're looking to write a text adventure engine in BASIC, let's talk more. Go ahead and open a dedicated forum topic. I have some ideas, as I was thinking of doing something similar.  What you don't want to do is try to write the game as a series of IF/THEN statements. Instead, it needs to be a data engine, with the data itself composing the game design and logic. 

I actually wrote a simple prototype a couple of years ago that stored the map in DATA statements, but now that we have access to the file system, it would be easy to rebuild that to use random access disk files for the game data. 

Your Rooms file, for example, would have a description of each room, along with the exits and a list of items contained in the room. It might also have some simple flags to create a rules engine, so you can (for example) require a specific Item to unlock a door, or have performed an action somewhere else to make an item visible. 

An Actors file might contain information about the enemies, NPCs, and interactive objects in the game. 

A Conversation file would contain the conversation tree, which would be part of all of your interaction with NPCs. 

... and so on. 

 

[Ffin72]

On 2/11/2021 at 3:46 AM, Karrgoot said:

And the game is originaly a pen and papper game, and the rule system it is played in, is called Basic rollplay system. 



I wana maintain the way you play the game in the sens you throw dices but make the program do it for you oviusly. But how hard is it to program.

Here is a book on writing RPGs in BASIC, it includes code for VIC-20 and C64 so should be suitable for the X16.


Write_Your_Own_Fantasy_Games_For_Your_Microcomputer.pdf