Jump to content

Photo

Dungeons of Asgard - game under development


55 replies to this topic

#51 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 3,037 posts
  • Location:Denmark

Posted Sun Feb 10, 2019 1:53 AM

If you think this looks okay, just let me know and I'll finish out the remaining monsters in the manual and then move onto the next file -- if not just let me know what I need to do / what I need to change... my goal here is help out! 

 

It looks good but could you also update the text.a99 file with the monster names? I noticed there are now two ghosts, that will cause assembler errors when the labels MOGHOS and TXGHOS are not unique.

 

I realize that without spells or special attacks adding more monsters is not going to do wonders for the game play. If you could suggest a simple extension to the data structure that would support more variation between monsters I might be willing implement it, but no promises since I'm working on other projects now.  :)



#52 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,451 posts

Posted Sun Feb 10, 2019 12:41 PM

The easiest way to give monsters some variety of special attacks would be a byte-index look-up value that indicates a "special" ability. You would need to burn one value as a "none", -1 always works well since 0-based indices are used.

 

However, that won't get you monsters who have multiple special abilities. In that instance, you would want to define all potential specials, count them up, and then use a bit-wise set of bytes to store "has it/doesn't have it" values. For example, a ghoul's ability to paralyze would be one such value.

 

You are correct that adding more monsters doesn't significantly improve gameplay if they have no real discerning elements beyond a name and graphic. It would be better to have less monsters but a more complex monster definition. I'm dealing with that myself. :)

 

Also, if you are on other projects, I would suggest you take your time with those and come back to this one with a whole heart and don't try to just "dial it in" with monster statistics. It sounds like you hit a bit of a block and put it aside to consider the direction you wanted to go. As much as I want to see the game finished, I want you to feel good about it, and not like "I could have done more with it..."



#53 budz2355 OFFLINE  

budz2355

    Moonsweeper

  • 292 posts
  • Location:Minnesota

Posted Sun Feb 10, 2019 1:20 PM

 

It looks good but could you also update the text.a99 file with the monster names? I noticed there are now two ghosts, that will cause assembler errors when the labels MOGHOS and TXGHOS are not unique.

 

I realize that without spells or special attacks adding more monsters is not going to do wonders for the game play. If you could suggest a simple extension to the data structure that would support more variation between monsters I might be willing implement it, but no promises since I'm working on other projects now.  :)

 

Yup, I will get that all fixed up.  I removed the original set of monsters since I don't think they quite balance with this new set.  Also, D&D has levels 1/8, 1/4, 1/2 and even zero.  I have not been adding the level zero monsters, and all of the fractional monsters I've just been adding as level one.  I am over 100 monsters so far,  looking like my estimate of 150-200 might have been light, so there is DEFINITELY a lot of variation here.  Some monsters for example might be the same level, one has higher ac but low HP or one might have higher HP but lower attack damage.  Theoritically if the HP is high it should get in more attacks over it's life.  Anyway, I digress... you can see all the variation, just give me a little time and I will upload the finished product.

 

Also it seems like you used the D&D stats str, dex, con, wis, int (left out charisma) in the item file?  All of these monsters in the manual have those corresponding stats, so if you wanted me to add those if (for some future purpose?) I would be happy to.  The monsters all do have a size category if that is something you wanted to use, just let me know what you want.  I am not the best at being creative, but I am also a big believer in not re-inventing the wheel.  This data already exists so let me just convert it from paper manual to your files right?

 

I kind of see this file as evolving, as you decide you want to add more features that is awesome and I am happy to impliment the boring stats lookup part from monstrous manuals, just let me know what I can do to help.  I figured just getting all the monsters names and ac and damage and level is a good place to start?

 

I'll upload the files as soon as I get all the monsters listed.  I just wanted to give an update that I am still working on this.


Edited by budz2355, Sun Feb 10, 2019 1:21 PM.


#54 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 3,037 posts
  • Location:Denmark

Posted Mon Feb 11, 2019 10:46 AM

I'll upload the files as soon as I get all the monsters listed.  I just wanted to give an update that I am still working on this.

 

You need to be aware that even though I'm using SAMS for the map, all the other code and data are currently stored in the normal 32K RAM segment. So without changing the memory layout, which could be done of course, there is a limit to the number of different monsters. I can't tell you what the exact limit is until I try to assemble the game (looks like I have around 3K left), so before you go overboard in adding new monsters it would probably be good to test what you have so far. 


Edited by Asmusr, Mon Feb 11, 2019 10:47 AM.


#55 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 3,037 posts
  • Location:Denmark

Posted Tue Feb 12, 2019 12:38 PM

A bit off topic, but looking at this source code again made me think (again) about how difficult it is for a programmer to work with SAMS in terms of memory page switching, and how much more useful it would be to have higher level support in terms of arrays, for instance. For an extension to XB the basic set of commands could be expressed something like this:

CALL AMSDIM(ARR,N)              // Allocate an array in AMS of (any) size N. Return reference in variable ARR. 
CALL AMSGET(ARR,I,VAL)          // Read entry I of array ARR into variable VAL
CALL AMSSET(ARR,I,VAL)          // Set entry I of array ARR to value VAL
CALL AMSFILL(ARR,I,L,VAL)       // Fill L entries of array ARR from index I with value VAL
CALL AMSCOPY(ARR1,I1,ARR2,I2,L) // Copy L entries from ARR1 index I1 to ARR2 index I2
CALL AMSFREE(ARR)               // Deallocate array ARR

// Data types
CALL AMSDIM(ARR,"N",N)   // number (default)
CALL AMSDIM(ARR,"S",N,M) // string (fixed length M)
CALL AMSDIM(ARR,"B",N)   // byte
CALL AMSDIM(ARR,"W",N)   // word

// Same as above for 2 dimensional arrays
CALL AMSDIM(ARR,N,M)                    // Also with data types
CALL AMSGET(ARR,I,J,VAL)
CALL AMSSET(ARR,I,J,VAL)
CALL AMSFILL(ARR,I,J,L,M,VAL)           // Fill a 'rectangle' at (I,J) size (L,M)
CALL AMSCOPY(ARR1,I1,J1,ARR2,I2,J2,L,M) // Copy a 'rectangle' between arrays 

The reference to an array, e.g. ARR, would be a number that should not be changed by the XB program (or the reference would be lost). The XB extension would keep track of the references and the memory allocation for each array, and would take care of operations like garbage collection (depending of how advanced the implementation would be).

 

Edit: The idea is, of course, that it should be possible for an array to be of any size, only limited by the size of the SAMS card.


Edited by Asmusr, Tue Feb 12, 2019 12:53 PM.


#56 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,451 posts

Posted Tue Feb 12, 2019 2:42 PM

Yeah. The only attempt to make an actual linker/compiler system around SAMS that I'm aware of is Art Green's Ragtime AEMS assembler that was provided with the Asgard card back in the early 90's. I've looked at it, the most useful part is in the docs when he defines the new expanded header for loading data directly into pages. The assembler itself, I'm way past using the actual TI for compiling, so it's not so useful...

 

What you're really talking about honestly is memory management. For performance reasons, I decided to implement my own memory structure for my CRPG. I use the lower 8K as data pages, and the upper 24K for a root module and a swapped module for different modes. It's worked pretty well, if I was doing a new design I may break up some of the root functionality into single page function blocks that could be loaded as needed.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users