The Legend of Beryl Reichardt

[Opry99er]

Really interesting stuff. I am encouraged by the progress I have made so far in the program, but I know I am taking "the long way 'round" on some things. While it works well and is completely functional, I DO want to become a better programmer in the process of development. For the sake of keeping to my schedule, I want to finish all menu functionality and plug in all my new map data and input the first level of condition handling before I stary re-coding all the stuff I've already done. Hopefully, like my TIdBiT conversion, it will simply be a matter of developing an understanding of the new methods and then the work will be second nature.

 

Where the game sits now:

 

The first world map is complete, half of the elements of menu functionality are in place and working splendidly, I have a skeleton in place for condition handling, there are a few display bugs in exploration routine and some unneeded clears and redraws in the menus that are off-putting.

 

Next steps:

 

-Complete the menu functionality (close on this one)

 

-Write quest condition-handling routines

 

-Clean up buggy-looking displays

 

-Simplify variable handling with arrays

 

 

It is mostly background stuff, but it is much more important than writing the music or coming up with a flashy title screen. Hopefully I can find some time this weekend to knock all this out.

[+InsaneMultitasker]

I just did a review of DEF, CALL, and SUB. I did not realize XB has subroutines with static local variables! For some reason I had it in my head that all XB variables were global. You can even go so far as passing by reference or value. Owen, I think you should spend a little time understanding the use of SUB, although I better check that TidBit supports that keyword. Doh!

 

Subroutines and local variables are the bread and butter of almost any language and helps make your programs modular and manageable.

What's really nice is that the local variables retain values from one call to the next. You can also force XB to only pass a variable's value to the subprogram using parenthesis, to ensure the calling program's variable value is not changed.

 

One of my BBS subprograms uses a local array to capture logged events that are dumped either with a forced dump flag or when the array is full. You can perform file IO and all sorts of good stuff in subs including error trapping, so long as your trap and return reside within the subprogram.

[JamesD]

Exactly. I was referring to your mirror analogy which is infinite (there is no stopping condition or result that unwinds the process), and simply commenting that the use of recursion with computers is typically not infinite.

You mean like what I said in my original post?

 

 

The non-Computer Science equivalent of recursion is a mirror image of a mirror image.

You see reflections of reflections of reflections...

The reflection of one mirror is passed to the other which is passed to the other which... you get the idea. The image is reduced in size each time it's reflected

....

Unlike the mirrors, computer recursion is limited by available memory.

An iterative (non-recursive) implementation of an algorithm requires a fixed amount of RAM where use of recursion requires allocation of RAM for new local variables with each recursive call as well as the return address

...

Actually, I made a mistake on the last sentence.

The memory usage of the iterative algorithm would depend on the algorithm used.

Memory does need allocated for data structures like binary trees and such.

The key difference is that recursion requires additional storage on the stack the iterative method doesn't.

 

Edited April 4, 2015 by JamesD

[JamesD]

I just did a review of DEF, CALL, and SUB. I did not realize XB has subroutines with static local variables! For some reason I had it in my head that all XB variables were global. You can even go so far as passing by reference or value. Owen, I think you should spend a little time understanding the use of SUB, although I better check that TidBit supports that keyword. Doh!

 

Subroutines and local variables are the bread and butter of almost any language and helps make your programs modular and manageable.

I think they are global in most BASICs. Looks like I need to do some testing.

[Opry99er]

Exported/Imported the finished map to the game... Nearly all unique tiles are now recognized by the program and generate a response when examined. First wave of condition handling is complete (status flags for once inventory is polled for specific items) and I am ooooh so close to having STATUS debugged. Got alot done tonight in two hours, I think.

[Opry99er]

Funny... Just did a quick playthrough and my "(", ")", and "/" are all white instead of dark yellow. I razzed something somewhere in the COLOR def segment of my LOAD program but I cant figure out what. It all LOOKS correct... Ill post the chunk and a screenshot before work if I can.

[Opry99er]

Some significant progress has been made behind the scenes. All exploration code is complete, including the zapping of a very annoying bug on scroll.

 

STATUS menu is complete, including graphic SPRITES for character identification.

 

Preliminary inventory control is under development.

 

Examine function has been re-written to include a number of strings for all possible tiles that can be examined.

 

New screenshots and potentially a short demo video forthcoming tonight or tomorrow.

 

What is proving to be the most difficult thing is proper implementation of quest state and quest item handling... I need to put some more thought into it.

[Opry99er]

BIG PROGRESS!!!!!

 

Quest-state handling has been completed... It is currently getting a thorough run-through by the massive Beryl Reichardt beta-testing team. LOL!!

 

Anyway, here are some screenshots of some of the updates. Enjoy!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Willsy]

This is looking fabulous!

[JamesD]

That does not look like BASIC!

[Opry99er]

Thanks guys.

 

It is BASIC... of the Extended variety.

 

Only trickeration is an assembly subroutine matthew180 helped me with to display the maps quickly and scroll to the next map on a tile basis.

 

Other than that, it is all XB. I use Magellan to design and export my map data, then have a LOAD program that assigns all the character data and color tables... Then it runs the program.

 

It is really quite unsophisticated still, as far as quality of code. I am currently working to convert all my strings and party variables into arrays which should cut down on my code size quite a bit... It should also make saving and loading the game progress a whole lot easier.

 

Thanks for looking in!

[Opry99er]

Small victory, I was able to convert 3 of my variable sets to multi-dimensional arrays and I didnt break anything!!!

 

Based on the PROGRAM BYTES difference, I have saved 868 bytes. Good news!

[JamesD]

Small victory, I was able to convert 3 of my variable sets to multi-dimensional arrays and I didnt break anything!!!

That you know of.

[Opry99er]

^^true that... Minimal testing of the STATUS, ITEM, and SPELLS menus is what leads me to that (potentially premature) conclusion.

What I was doing (seems silly now) was asking for player input to determine who was going to be acted upon. Then, based on the keyboard input, I was routing program fynction to a subroutine that loaded a completely different set of variables with all the statistics for the character selected... Then, returned back to the primary menu function where I would use the new temporary variable set to display and modify.

Once the modifications were done, I would reload the original variable set with the modified temporary variable values, then return to the root menu.

Thanks to some help, I realized that a multidimensional array would solve this whole thing.

Because of how my menu is set up (where the user selects 1-4 to determine the character to modify) I simply needed to use the input variable of K to select the first dimension of each array... Then, the second dimension of each array remains static...

CALL KEY(0,K,S) :: C=K-48
DISPLAY AT(1,1): HP(C,1), etc.

Saves a metric sh**ton of code space.

Edited April 12, 2015 by Opry99er

[Opry99er]

For some scope. This world in the current demo is in the central->eastern the map... Forestia. The entire game takes place in the Northeastern section of this map... No exploration takes place south of Eolis, or west of the easternmost region of the Upper Kingdom.

 

When this game is complete..... nah nevermind... I'll just leave it at that.

 

Edited April 14, 2015 by Opry99er

[Opry99er]

Got a few bugs worked out this past week. Currently working to get all party data into arrays, loaded from disk.

 

Got a LOAD and SAVE routine almost worked out.

 

Also one cool thing that should be done tonight, the "SEEK COUNCIL" function is just about done.

 

This will allow the user to seek council with an NPC who can give guidance during the quest. If you get stuck and do not know what to do next, you can find this individual, select "SEEK COUNCIL" and based on the status of your quest, receive info on what to do next.

 

Good things... Very good things, indeed. Hoping to have a new version out to the testers soon, with the ability to load and save game status in place.

[Opry99er]

 

 

 

 

SEEK COUNCIL is in place and functioning as expected.

[Iwantgames:)]

This game looks awesome!!!

[Opry99er]

Well, it is still just demo at this point, but becoming more and more like a game.every week... Once the SAVE/LOAD routines are in place, I will feel alot better about calling it a game.

[Opry99er]

One thing I did want to mention on the development front, my routine for loading game data from disk is just about done... I am doing it just fine in a separate tester program, but now I need to finish the array conversions... The main game program is currently close to 500 lines of code, not including character definitions or map data.

 

I haven't counted exaxtly, but with the new array setup and surrounding improvements, I should be able to eliminate roughly 40 unnecessary temporary variables and about 30 lines of code.

 

This should clear a good chunk of my program space... I will need every byte I can get for my EQUIP and Encounter routines and my Battle engine.

[+Vorticon]

Keep chugging along Owen. This is looking absolutely awesome!

[Opry99er]

Thanks Walid.

 

This game project has been riddled with fits and starts and it is tough to see how I got "here" from "there." Lots of excellent advice, much help, and a ton of encouragement. I am nowhere near done, but with disk routines now in place, things are looking very bright.

 

I need to do a video of all the new updates. I watched the last video I made and we have progressed so far past that point!

 

I will wait until the SAVE/LOAD routines are official, then I will do another video.

 

Thanks so much for your encouragement throughout the course of the development. Wouldn't be anywhere without community interest.

[Opry99er]

No huge update, but I now have a working skeleton in place for handling EQUIP (which has taken the place of ARMOR and WEAPONS in the Main Menu.

 

Also I have re-added "PARTY" into the Main Menu...

 

This works similarly to "STATUS" in that it is a static information screen which shows the following information:

 

1) Party Status (Healthy, Weak, Critical) based on combined health and Indiviual member Status

 

2) Gold

 

3) Scrolls

 

4) Non-potable items (keys, etc) *The ITEMS menu handles items you can use in Peace-Time to alter a member's stats like Elixir*

 

5) Quest Items (Collected components of the Wooldridge Armor Set) *The set cannot be equipped until it is complete.

[JamesD]

You are so going to run out of memory.

[Iwantgames:)]

Everytime I look at those screenshots I wanna play