The Legend of Beryl Reichardt

[Opry99er]

I have begun work on some updates for the lava and under worlds here recently, and have come to a few realizations/decisions.... To properly facilitate the speed required in jumping from "battle" mode to "exploration" mode in any of these environments, I'll need a quick way to re-define character sets so that the elapsed time between the end of a mode and the beginning of the next mode isn't more than a moment or two. I then need a way to re-place the PC on the map in the same location it was before the battle mode was entered. This shouldn't be too difficult--- I think just saving the current "screen" and X,Y coordinate should work... There are many ways to accomplish this--- but I'm looking into many of these as I come up with the BEST route for Beryl.

 

One thing I've been contemplating is having a "stat-file" on the diskette which will hold all PC and enemy stats as well as multiple temporary values and such. This would allow me to keep everything compartmentalized, but I'm not sure how long the disk access would take to retrieve or update stats and values. More on this later. In the meantime, DL the zipfile in my last post.

[the.golden.ax]

This is looking awesome.

AX

[Opry99er]

Thanks Golden Ax! I am trying to move this project along as quickly as I can, but when I'm away from home for months at a time, it really becomes difficult to maintain any consistency in my development. Much of my "Beryl Reichardt" time when I DO get home is re-teaching myself what I already knew and catching up on the current status. As any developer knows, that kind of schedule plays hell on any project.... Even moreso when it's something as complex as an RPG. Out if pure necessity, the direction my RPG is taking NOW is much less complex and deep than the original mission statement for the game. Kind of an "RPG lite" if you will. I have streamlined my goals and prioritized them so as to allow steady progress within the confines of my less-than-steady schedule. In short, I've lowered my expectations.

 

However---- I believe in the game concept and in the storyline.... Whatever the final product looks like, I am sure it will be an enjoyable game. . Thanks so much for posting. Feedback is what makes me want to work on this game whenever possible.

[Opry99er]

Semi-official trailer for the game... This is something I threw together... Kinda like it. =)

 

http://www.youtube.com/watch?v=8GE7-nqsTfo

 

Beryl Reichardt forever.

[sometimes99er]

Very nice, my friend.

[Opry99er]

Thanks, Sometimes... =) I'm really hoping that generating a bit of outside interest will help the TI community. I posted that link to several different forums online to help get some folks over here to Atariage to look at our computer. =) We shall see if it bears fruit.

 

 

In the meantime--- I've been trying to adapt the lava level to the new standards implemented for the section-by-section scrolling you and Matthew helped develop. When it's done, I'll post another vid.

 

Really hoping to get some work done on this project in the next month. I'm home right now for this week, and then I'm on the road for another month. Lots of traveling. =) In any case, my schedule kind of sucks for working on my game. But I hope to be done by the Faire. We shall see. =)

 

 

[+OLD CS1]

Semi-official trailer for the game... This is something I threw together... Kinda like it. =)

 

(snip)

 

Beryl Reichardt forever.

 

Cool video, neat looking game. I left CRPGs a long time ago, but this looks to rekindle my interest.

 

Where did you obtain the rendition of "The Riddle of Steel" you used in your video? It sounds different than the one from the "Conan the Barbarian" sound track.

 

EDIT: The music is actually "Anvil of Crom." I was mistaken, but none the less a great sound track.

Edited January 16, 2011 by OLD CS1

[Opry99er]

Thanks for your words. =) I've been spending the last couple days getting re-acquainted with all my code and graphics... Attempting to develop a gameplan for finishing it up. When I have a solid plan, I'll start cutting into the mountain of work that's left.

 

As far as the music--- I downloaded that off Limewire years ago. =)

 

 

A bit on the game... ::

 

I have had some cool ideas lately about the battle engine. I'm not a fan of the Legends game flow, but the battle engine isn't bad, really. It's a bit weak graphically and it can be tedius at times, but it's straight turn-based. I think I'll go with this concept (but with my graphics)--- but with the twist I've talked about before. Interrupts. Essentially, a stat will determine how often an enemy can interrupt the flow of your party's attack order. I think I talked about this in my blog, but for the sake of continuity, I'll post it here too.

 

It's not a NEW concept, but it it is one thing that will differentiate my battle engine from that of Legends. Basically, you have a set order of battle, but enemies can "interrupt" the sequence based on a statistic.

 

Regular Flow:

Skeleton 1
Skeleton 2
Beryl
Markus
Reptoslicer
Skylar
Skeleton 1
Skeleton 2
Beryl
.
.
.

 

So, let's say a skeleton has a high statistic for interrupts. The following could happen:

 

Skeleton 1
Skeleton 2
Beryl
*interrupt* Skeleton 1
Markus
Reptoslicer
Skylar
Skeleton 1
Skeleton 2
.
.
.

 

So, this CAN happen--- doesn't HAVE to though. It depends on, basically, a roll. So, I'm working on it---

 

 

[Opry99er]

I'm driving to Tampa FL for a weekend gig and having many programming thoughts--- as is usually the case on long trips. Here's some stuff I've been working on in my head.

 

For Battle Artificial Intelligence:

 

-Give a list of 4-6 possible moves for the enemies you face-----moves listed in order of most effective to least effective

 

-randomize the move, weighting it for level (higher level enemies pick more effective moves)

 

-the list re-orders each "turn", giving each enemy a fresh list.  

 

*For instance, IF the enemy party's status is "slowed by magic," then one of the best moves the enemy could make is to "Dispel" that curse.  Other moves could be "Attack", "Magic Attack", "Heal", "Defend".  If you face 3 McElwain monks and they are slowed by a "Slow" spell cast by your party--- the first monk could cast "Dispel", and then the move list is re-ordered... The next monk wouldn't want to cast "Dispel", so that might not even be on the list.  The new list would have different priorities, and the next monk could roll "Attack.". This is just an example of how the system is shaping up.  

 

**High level enemies may "know" the HP of your characters, causing them to direct more attacks toward a weak party member.  

 

What if you're facing 2 low level reavers?  One is on the ropes and the other is healthy.  Reavers can cast "Heal" which allows one party member to heal himself or another member of his party.  Therefore, if the injured enemy doesn't roll to heal, but rather to attack, the second one may still cast "heal" on the first enemy.  10-15 lines of code should be able to handle the artificial intelligence for lower level enemies.... It will be limited, but efficient.  

[JonArkanix]

The trailer looks great, good work so far!

 

This brings motivation for my own projects and some coding I should have finished two months ago.

[Opry99er]

Polished up some code... I've have made some really good progress today and I'm excited about it. I have to make some final adjustments to my work, but now the border checking which calls up the scroll is much cleaner. I've also added the border around the viewport and started working on the alternate character strings for when battle is engaged. I've also begun working on a semi-random battle initiation sequence which takes a few variables into account and initiates battle sequences.

 

Since I'm focusing on working with the Forest world right now, I have a total of 6 different monsters which need to be handled by our program. Each are numbered 1-6 and "which" enemy you face is essentially a roll of a 6 sided dice. Each enemy has unique characteristics such as:

 

-Name

-MAX HP

-"can this enemy cast magic or not"

.

.

 

I have been going back and forth on whether to store all this data on diskette to be pulled up at battle time, or whether to have a string in the XB program which holds the info. I was working on something earlier and here's what I came up with.

 

*MCELWAIN MONK.0014401143013F7F393121010303071F009481C461C0FEFFCEC6C2C0E0E0707C.100

*GIANT SPIDER .0040700F057F47070A1264080808000000020EF0A0FEE2E05048261010100000.150

 

As you can see, these strings are the same length... 13 characters for the name, 64 characters for hex, 3 characters for HP. Any inconsistencies will be taken care of using "space character" pads. In the above example, the names are padded in this way. These can be pulled out of the string with SEG$ within the XB program or the segments can be pulled off diskette fairly easily as well. Thinking about it, since all my "worlds" are their own XB program, there would really not need to be file records for this information--- unless my program becomes massive and I run out of room. =) Any thoughts?

Edited February 3, 2011 by Opry99er

[Opry99er]

I read some interesting information on data parsing... The author apparently had some experience with vintage machines, or at least with memory-restricted machines.... He discussed how using one long string variable and parsing the data can be more memory-efficient than carrying multiple variables in your program. He notes that it is less speed-efficient, but that in byte-restricted machines, it can save you alot of space.

 

I'm currently mentally processing all this info and working on testing this theory. If I'm using 3 pieces of info... Let's say:

 

HP-100

MP-150

Gold-450

 

And let's assume that the most gold one can own is 9999 and the most HP/MP is 999.

 

CP$="1001500450"

 

Then if we needed HP, we grab the first 3 characters... (100).... If we needed gold, we grab the last 4 characters... (0450). So.... Which actually takes up more space here?

 

100 CP$="1001500450"

 

OR---

 

100 PHP=100
110 PMP=150
120 PG=450

 

I am looking strictly for memory used by these different methods.... I would test this myself, but I'm on the road to Georgia.

 

This test is really because I have several statistics for each party member to account for and then multiple enemies per world. In the Forest world, there are 7-8 different enemy types---- each enemy has different stats (see previous post for more info).... When battle is called up, the program will randomly select an enemy for me to face (let's say 1-7.... Skeleton through Soul Reaver) and a number between 1-3 for how many I will be facing at one time. If each enemy has 4 stats and a name, that's 35 permanent variables to carry in my program just for enemies... Another way to do it would be to have a string from which the stats are pulled and then dropped into temporary variables for battle. If the most enemies I will face at once is 3, then I will need 12 temporary variables and a "name". 12 temporary numeric variables plus 7 string variables for storing the data for each enemy type means I am using 19 variables instead of 35. How does this translate to memory savings? Can anyone test and report for me?

[Opry99er]

Got the answers I needed at the Y! list and I'll be carrying all the variables throughout the program.

 

I've got a very clean looking implementation right now, and I plan to post it when I get some Internet. We have been on the road and without wifi for a couple weeks now. I am really excited to share my progress with you all--- I'm almost ready to start testing the "encounters" and "battle" sequences. Next step--- get the battle screen tiles implemented into the code and write the assembly routine to write the data to the VDP----. Should have all that done by next week.

[Opry99er]

I started working on a GCHAR-type assembly routine for Beryl... It's something Matthew suggested I work on a month ago or so.... So basically my XB program does something like this:

 

CALL GCHAR(PX,PY-1,Q):: IF Q>104 THEN GOTO 100

 

Pseudo-code of course.... It's all implemented right now on my laptop and working beautifully, but I have no Internet service and I'm posting this on my iPhone--- so I can't paste my code or a zip file.... Here's where I'm reaching a problem.... I have 2 more tiles that are outside the range of "<104", so to make those extra checks inside my loop means eating up my speed--- not that there's much speed there to work with. It's going to be a slow goer, I'm afraid--- but I'm hoping the music and ambience will make up for it.

 

So I'm working on the assembly routine to replace all that lengthy GCHAR stuff. I have checks like the one above for all 4 directions and it's just a bit of a stretch to add in additional tile checks.... I'll post some code when I get some wifi....

[Opry99er]

I have been slugging through several re-writes of this code and I'm trying to squeeze speed out where none is available...  This guy moves at this pace... And that's what it is.  . I will consider animating him a bit later, but there's so much to do before I get there.  In the meantime, here is what is actually workable in the game code so far:

 

-You can walk the map on all available tiles

 

-So far, You can interact with one item on the map--- a sword.

 

-You can instigate a battle, but you can't battle.  To pull up the battle screen, hit the "B" key.  To return to exploration mode, hit the "B" key again.  

 

To interact with any item or "UMP" (unique map position), simply be touching it from any side and hit the "SPACE" bar.  The program prompts you to select a direction, at which point you are given information on the item and further info on whether you can carry it or not.  

 

Speeding up exploration a bit::

 

I kind of fell into a nice little side effect of a mistake I made.... I accidentally left the CALL LINK to draw the screen inside the main game loop when I started working with the exploration routine.  It is in this way that the existing player character is removed from the screen just before the new one is drawn.  I never had to "erase" the existing player graphic before re-drawing it one tile over.... This was done as necessary by the re-draw of the screen each time a valid key is pressed.

 

Here's a thought.... 

If I moved that CALL LINK outside the main loop and simply used SPRITEs for the player character... This would eliminate the need to LINK my assembly routine each time my character moved one position.  It's something worth trying, anyway.  

 

I'm on my way Home from Lyons, GA right now, and when I arrive home, I'll be posting the newest code and a zipfile of my current progress.  I'm a bit excited to see what you guys think about how it's progressing.  I've been working pretty hard in my real life lately, so most of my computer time is reserved for watching episodes of "The Office" with my bandmates.... I have to get up early in the AM to get any TI time.  I am glad to say I've made a couple strides this week and have something to show for it.  

 

Meanwhile, (as I wrote in my previous post) I'm contemplating writing an assembly version of my big messy GCHAR routine I have in this program right now.... I would be using the hand-rolled equivalent of VSBR.... Matthew suggested this in an earlier post, and it seems like that would speed things up a bit.  . I have the basic premise worked out--- just need to implement it.  I could do it in assembly pretty easily, just need to get all the XB linking stuff worked out along with the offsets.... I already wrote something similar for my lava world scroller.... 

 

"Left and right" keyboard inputs call for a +1 -1 check respectively, and "up and down" call for -32 and +32....  A quick VSBR of those respective locations would return the necessary ASCII codes for comparison--- which is exactly what I have done in XB, only using an X,Y axis system vs. the linear concept in assembly.  So, I'll need to convert the X,Y coordinate into a number between 0 and 767, then pass that number to my assembly program to run the necessary VDP read.  Working on it in my head now... Riding through Atlanta and having great coding ideas.

[Willsy]

"

 

Thanks for posting, Tim. Yes, you are absolutely right, and just such a thing is certainly the FIRST thing I would do. Here's the only thing though... how many of us have hardware and emulators? A hundred? Two hundred? Of those two hundred, how many are interested in playing video games? Of those interested in video games, how many RPG gamers are there out there? A person willing to play a game for 10-20 hours to beat it.... We're essentially limited in most part to THIS FORUM!!! We're the ones who love games, love programming, and love supporting others to do the same."

 

All true. But it didn't stop me working on Turboforth for 2 years! I wrote it for voyage of discovery that it has taken me on. It's made me a much better programmer. That's the motivation.

 

I've never played a CRPG but would I play one on the TI that my mate across the pond wrote? Hello yeah!

 

Mark

Via Android

[Opry99er]

I'm in agreement. I would never stop programming for the TI as long as there were those who play my games. Mark, you've inspired me time and time again, and I'm really glad to see you posting regularly again.

 

I've been planning and designing this game for the better part of two years now.... Every time I look at the project as a whole, I'm always initially frustrated that I'm not further along. However, your recent flurry of activity and the momentum of TF has really stoked the flames again.

 

Still want you to do the speech for this game, Willsy. I wanted an English accent for the narrator, and I happen to know an Englishman with distinctive knowledge of LPC speech coding. Luck? Or something else?

 

Love this forum, love you guys. Even if this forum was the only place you could get and play with TI stuff, I would still work feverishly to keep the computer alive. I am so glad to hear TF is almost done, Mark. It will truly be amazing, and I HAVE to have a first-run copy, man.

[Opry99er]

Okay, below I have posted the section of the XB code which is giving me difficulty... This is the entire game loop (as it sits right now)... I had the battle screen up and running, but I'm going to have to cleverly write a "character pattern and color re-definition routine" so that I can go back and forth quickly between the two. The battle screen is done in assembly-- I pulled it back out because I'm still not happy with it taking 7 seconds between the two environments. I'm working on that on my end, and I'll show it when it's ready. =)

 

Really, I'm wondering if anyone can help me check Q=136 inside the GCHAR section of this loop (9100-9400) without it dragging me down even slower... =)

 

Also, I omitted all the setup lines (100-8500) and all the subroutines following the game loop(10600-12100). The code below is JUST 20 lines of straight game-loop exploration code with some REM statements (which will be stripped out later).

 

!!!!!!!!!!!!!!!!!!!!!
!!!BEGIN GAME LOOP!!!
!!!!!!!!!!!!!!!!!!!!!

8500 REM     Beginning of main game loop
8600 CALL SETMAP(MX,MY)

8700 REM     CHARACTER ON SCREEN
8800 DISPLAY AT(PX,PY):CHR$(42);

8900 REM     KEYBOARD SCAN
9000 CALL KEY(0,K,S) :: IF S=0 THEN 9000

**REM NEED TO CHECK FOR 136 AS WELL... IT IS ALSO LEGAL
9100 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q>104 THEN 9000 ELSE PX=PX-1 :: GOTO 9800
9200 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q>104 THEN 9000 ELSE PY=PY-1 :: GOTO 9800
9300 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q>104 THEN 9000 ELSE PY=PY+1 :: GOTO 9800
9400 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q>104 THEN 9000 ELSE PX=PX+1 :: GOTO 9800
9450 GOTO 9000

9500 REM     this determines the boundaries onscreen and sets the map to be drawn by assembly routine
9600 REM     PX, PY are the current player's position on the screen
9700 REM     MX, MY are the designations for which map will be drawn
9800 IF PX<11 THEN PX=22 :: MY=MY-1 :: GOTO 10200
9900 IF PX>22 THEN PX=11 :: MY=MY+1 :: GOTO 10200
10000 IF PY<1 THEN PY=28 :: MX=MX-1 :: GOTO 10200
10100 IF PY>28 THEN PY=1 :: MX=MX+1 :: GOTO 10200
10200 IF MX<1 THEN MX=1 ELSE IF MX>2 THEN MX=2
10300 IF MY<1 THEN MY=1 ELSE IF MY>6 THEN MY=6
10400 GOTO 8600

10500 REM     **END MAIN GAME LOOP**

 

Please DL the zipped DSK1 FIAD file for use in Classic99 below if you want to try out the rough exploration routine... I need to re-order a bunch of this code and optimize it... so bear with me, as this is just a tester as of right now. Since I stripped out the battle linkup, all you can really do is explore the world while following the paths... there are multiple screens... 12 in total, so try to make your way to all of them. Graphics are still very preliminary, but getting better gradually. I'll have the demo ready in a week or so... you'll be able to walk the whole map, even on the grass (which is ASCII 136) and call up the battle sequence-- interact with the sword (pick it up, etc.)

 

I have all these features coded, but not implemented into this particular program... That will come out with some fanfare as the first demo. For now, we're just exploring and optimizing. If anyone has any ideas for optimizing the game loop, please do. Also, let me know if you notice any unusual behaviour while exploring the world... so I can fix it. =)

 

THANKS A MILLION!!!!

FORLINK.zip

Edited February 13, 2011 by Opry99er

[Opry99er]

BTW--- I'm looking to make the following changes before I release the actual demo:

 

 

1) Get it running at a speed somewhere between the normal speed and the CPU Overdrive mode in Classic99

2) Get the battle screen to load faster into and out of...

3) Implement the SPRITE-based player character (probably 3 SPRITEs just for the PC, overlapped)

4) Animate the player character (using a thread-- the character will look like he is walking)

5) Finish the "examine" routine.. which basically lets you examine objects and act on them

 

 

Should have it all done by the first week in March. =)

Edited February 13, 2011 by Opry99er

[Willsy]

Instead of:

 

**REM NEED TO CHECK FOR 136 AS WELL... IT IS ALSO LEGAL
9100 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q>104 THEN 9000 ELSE PX=PX-1 :: GOTO 9800
9200 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q>104 THEN 9000 ELSE PY=PY-1 :: GOTO 9800
9300 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q>104 THEN 9000 ELSE PY=PY+1 :: GOTO 9800
9400 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q>104 THEN 9000 ELSE PX=PX+1 :: GOTO 9800
9450 GOTO 9000

 

It's worth trying the logic the other way around:

 

9100 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q<104 THEN PX=PX-1 :: GOTO 9800 ELSE 9000

 

You get the idea... It *might* speed things up a little.

[Opry99er]

Thanks Mark... I'll give that a try! I think my biggest speed killer, though, is the fact that I use "SUB SETMAP" each time through the code. That is an assembly routine to draw the screen.... While the routine itself is super fast, the brief delay caused by linking up with assembly is adding up when called each time a key is pressed. If I can get rid of that by using SPRITEs for the PC and leave the CALL LINK out of the main game loop, it will speed it up a bit. I would like to LINK the GCHAR calls too, and I've started work on that routine.... This way, I can do checks for whatever tiles I need in a split fraction of a second. However, if the LINK is what's causing that slight delay, doing another one wouldn't make much of an improvement.

 

Fun fun fun stuff, mate.

 

If you get a chance to DL the file and run it on Classic99, you'll get a real sense of what it's all doing. Thanks again for chiming in!!

[Opry99er]

Updates on LoBR demo 1.0

 

Last night, I made some significant changes to the code... below I've listed what is now done and what must be finished before I put the first demo (1.0)

 

**WHAT HAS BEEN COMPLETED SINCE LAST POST**

1) Moved ALL initial character definitions to the LOAD program
2) Rebuilt the "examine" routine
  (you can now examine the sword and pick it up)
3) coded all the character definitions for battle screen and converted BASIC tiles to assembler data for CALL LINK 

***WHAT HAS NOT BEEN COMPLETED**

1) CALL LINK for battle screen
2) implementation of enemy and player variable statistics
3) implementation of battle engine (in progress)
4) music (maybe)

 

I'm working pretty feverishly on this stuff because soon I won't have much time. =) Wish me luck

Edited February 15, 2011 by Opry99er

[Opry99er]

Okay... made a decision here, and I might need to do some testing...

 

Since I'll be switching the character patterns from 96-142 each time the battle sequence is engaged (and then again when it is disengaged) I will need to carry those initial definitions in the main code, and not in the LOAD program. I'll definitely keep the font in the LOAD program, but the other character patterns will need to be on hand in my main program so that I can easily switch between them. Surprisingly, the 46 character re-definitions required don't take very long at all. =) maybe a second or so.

 

I would really like to be able to keep the program space for PROGRAM stuff, but I fear that accessing a disk to load in the new character sets would take too long and throw off the flow of the game. More updates forthcoming. =)

[Opry99er]

Question for Matthew (or anyone who can follow)

 

I have the MAP data CALL LOADed, as you know... When my character picks up the sword on the second screen down, I'm not sure how to "edit" the map data... Once the sword is picked up, I need it to be a different tile and not look like a sword anymore... So, it needs to be there until picked up, then disappear for the rest of the game...

 

I know I can CALL LOAD a value into the proper location, but in looking at the source code, I can't really figure out the best way to accomplish this. Basically, I'd like to change the byte in the MAP data at row 18, column 17. So basically I need to change the 1025th byte of my map data to the space character (ASCII 32). I'm trying to determine the best way to do this... any ideas?

[Opry99er]

I suppose I could leave all the non-landscape stuff completely out of it and just display them when necessary. Something like:

 

(SC is the flag to check if the sword has been picked up)

 

IF SCREEN=2 AND SC=0 THEN DISPLAY AT(7,9):CHR$97

 

In this way, since SC (the flag) is set to 0, the sword will be displayed... if SC=1, then the sword HAS been picked up and the sword will NOT be displayed.

 

The only issue with this is that when the next screen scrolls in, the items will not be there. They'll show up AFTER the scroll occurs... won't look all that great--- but it's much easier than LOADing a new value into memory... anyone have any other suggestions?