Roguelike?

[Opry99er]

I have been working on some cool

assembly stuff.... Once I complete development of these assembly routines for Beryl Reichardt, this roguelike will fall right in place!!!

[Opry99er]

Been thinking on these lines again... I don't know if it is possible to accomplish this for the BBS scene, what with the display limitations and all, but perhaps InsaneMultitasker could chime in. Rogue, Nethack, and a few others are available to play in BBS environments, but I think they are all primarily IBM Telnet BBSes...

 

If this is possible in the S&T framework, I'll be focusing on this as my next BBS project. Any thoughts, Tim?

[Willsy]

I've been thinking recently about adding support for BBS development to TurboForth. I was thinking about a suite of words that allow things like setting colours and cursor position on the terminal, waiting for a keystroke, echoing keystrokes to the user terminal, support for building and displaying menus etc.

 

Of course, it would all be fully integrated into the Forth language. For example, you could just use a block in a disk file for menus, and type your menus into the block editor, and then you could send that block via the serial port to the user in a single line of code.

 

In terms of implementation, it would be a mixture of Forth and assembly language (I assume some assembly language to directly manipulate the serial port).

 

However, I'm not sure of some of the finer implemenation details. In the main, how to determine when a call comes in, how to determine if a caller has hung up - that sort of thing.

 

And anyway, does *anyone* use dial-up modems any more?!

[Opry99er]

All the primary calls and standard routines are built in to the S&T software... All I need do is add the proper CALL LINK into my program wherever a BBS-specific function is required. It's fairly "plug--and-play" as long as you are using the S&T software on the Geneve or TI... The damn assembly subroutines are already written and ready to call up!!!

[Opry99er]

Ahh.. After re reading your post, I see you are thinking of developing an entirely new BBS environment... Very cool... InsaneMultitasker would be the guru here... I'll let him take this one.

[Opry99er]

Hey Insane... would this be more likely if I were to write a custom display routine in assembly for the screen? Of course ours would be monochromatic...

 

The video here is of the gameplay of Rogue. I would like to try to do a similar style. We could probably do a custom VMBW at 768 bytes directly in the loop in order to achieve the screen movement, but the problem there is that the screens of the users who would be using the BBS would not all, necessarily, be in that range...

 

I know the display stuff is unique in the BBS environment, but if we specialized enough and pared the display down to a small enough window, could it be done? Perhaps a 30x20 window?

 

http://www.youtube.com/watch?v=I_nMmHeHUKs

Edited May 3, 2013 by Opry99er

[+adamantyr]

On the subject of roguelikes, I was sidetracked from my CRPG around a year ago on procedural dungeon generation for a roguelike on the TI... it's shelved at the moment.

 

Here are the threads on the subject:

http://atariage.com/forums/topic/202007-binary-trees-in-tms9900-assembly/

http://atariage.com/forums/topic/202121-random-dungeons-in-tms9900-assembly/

 

Adamantyr

[Opry99er]

Well those are fascinating threads. =) I love the direction you're going there! =)

 

My interest here is in creating a BBS-playable Roguelike--- if that's possible, I'll be turning my attention here after I get some music stuff done... Marc's ASLP and the new work senior_falcon is doing with the XB256 has me all bothered to start coding some tunes!

[+InsaneMultitasker]

I've been thinking recently about adding support for BBS development to TurboForth. I was thinking about a suite of words that allow things like setting colours and cursor position on the terminal, waiting for a keystroke, echoing keystrokes to the user terminal, support for building and displaying menus etc.

 

Of course, it would all be fully integrated into the Forth language. For example, you could just use a block in a disk file for menus, and type your menus into the block editor, and then you could send that block via the serial port to the user in a single line of code.

 

In terms of implementation, it would be a mixture of Forth and assembly language (I assume some assembly language to directly manipulate the serial port).

 

However, I'm not sure of some of the finer implemenation details. In the main, how to determine when a call comes in, how to determine if a caller has hung up - that sort of thing.

 

And anyway, does *anyone* use dial-up modems any more?!

 

telnet to heatwavebbs.com -- is this the sort of thing you are going for?

 

There are still people dialing-up to both of the active TI BBSs.

 

Carrier detection is usually done via the modem's Carrier Detect line. Hangup is usually performed by dropping the DTR signal. The rest is really just serial IO.

[+InsaneMultitasker]

Hey Insane... would this be more likely if I were to write a custom display routine in assembly for the screen? Of course ours would be monochromatic...

 

The video here is of the gameplay of Rogue. I would like to try to do a similar style. We could probably do a custom VMBW at 768 bytes directly in the loop in order to achieve the screen movement, but the problem there is that the screens of the users who would be using the BBS would not all, necessarily, be in that range...

 

I know the display stuff is unique in the BBS environment, but if we specialized enough and pared the display down to a small enough window, could it be done? Perhaps a 30x20 window?

 

 

Hi Owen. Keep in mind that the BBS simply spits out characters and text for the caller to see on his or her terminal. With ANSI, this type of game is possible if you have the patience and desire to make it happen. You could even add color without any problem. It's just that you have to produce all of the ANSI control sequences necessary for the color and screen positioning. You are right in saying that a video routine won't do any good for the caller - because the video routine is only for the computer running the program.

 

As an example, you could recode the text in your baseball program to use ANSI. The scoreboard could be located in one section of the screen with the text displayed on the screen in a fashion similar to DISPLAY AT. No scrolling would be needed. It takes a little extra work, but I suspect it would be fairly simple to construct a subprogram that would accept a string, row, and column that would be converted to the proper sequence.

 

Log into Kyle's BBS and play Reno Keno. There is no color but it is all ANSI display sequence driven. I wrote it long ago when color wasn't really something I was into. I have considered adding color to spruce things up.

 

And if you wanted to get really fancy there is ANSI music. You only get one voice but you can create a tune.

 

Aren't you glad you asked?

[Opry99er]

Oh yea, man!!! That stuff sounds awesome... I don't really need color for the game, but certainly ASCII in a DISPLAY AT type format... Essentially, you would need to be able to move your piece ("@" in this case) around a board containing standard ASCII characters without the need to scroll each move. Imagine a static display with a moving piece within that displayed framework... There may need to be something like a GCHAR call in there, but that could be worked around just using the MAP DATA itself... Might require a deeper array set, but certainly do-able.

 

The idea of having a tune in there... that's definitely intriguing... I could code up "Take me out to the Ballgame" in 5 minutes, using one voice. =)

 

Owen

[Opry99er]

Would adding this music be as simple as creating a soundlist and an assembly sound player? We have that capability already. Mathew's sound list player, Marc's ASLP, and now XB256 all do soundlists.

Edited May 4, 2013 by Opry99er

[+InsaneMultitasker]

Would adding this music be as simple as creating a soundlist and an assembly sound player? We have that capability already. Mathew's sound list player, Marc's ASLP, and now XB256 all do soundlists.

No, for ANSI music you construct a sound list which is sent to a terminal emulator for interpretation. The only terminal program for the TI or Geneve that can interpret and play this music is PORT, which I wrote for the Geneve. I'm pretty sure Qmodem (PC) will interpret and play, beyond that I have no idea how wide-spread music was with the other 8-bit/16-bit computers. Here's some technical info if you are interested.

 

http://artscene.textfiles.com/ansimusic/information/ansimtech.txt

[Tursi]

ANSI music was not very well supported. I can't remember if I've EVER heard it...

 

[Willsy]

It was also not very well *appreciated* - it just tended to piss people off! It would alert your parents to the fact that you were using the modem again!!