Jump to content
IGNORED

Dungeons of Asgard - game under development


Asmusr

Recommended Posts

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. :)

Link to comment
Share on other sites

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..."

  • Like 1
Link to comment
Share on other sites

 

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
  • Like 1
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

I kind of forgot about this, because the reception seemed luke warm. But here is what I had done when you suggested we pause and look at file size. If this becomes an interest / priority I can obviously do it much faster.... It was essentially done when we first talked about it. Just let me know what you need. You can see if space is an issue, then we wouldn't need 6 different types of Mephits, but unlike some others I do actually think monster variation adds a lot to a dungeon crawler. I don't want to kill the same 7 guys for 30 hours on end. If you like this, I can certainly finish the rest of the monstrous manual. If you want more stats added (str dex int con wis cha), I can certainly do that, etc. etc. The goal here is to be helpful.

 

 

monsters.a99

text.a99

  • Like 2
Link to comment
Share on other sites

I kind of forgot about this, because the reception seemed luke warm. But here is what I had done when you suggested we pause and look at file size. If this becomes an interest / priority I can obviously do it much faster.... It was essentially done when we first talked about it. Just let me know what you need. You can see if space is an issue, then we wouldn't need 6 different types of Mephits, but unlike some others I do actually think monster variation adds a lot to a dungeon crawler. I don't want to kill the same 7 guys for 30 hours on end. If you like this, I can certainly finish the rest of the monstrous manual. If you want more stats added (str dex int con wis cha), I can certainly do that, etc. etc. The goal here is to be helpful.

 

 

 

After a bit of label renaming I managed to assemble a new version with the large monster list. I had to move some data around to make it fit into memory, but it's all there and a few hundred bytes left. I reintroduced the Villain monster because it's special for the town. I noticed there are two Gricks.

 

What's missing, as you can see if you try to run the attached version, is that each monster should be mapped to its graphics via the pattern number. There are currently only 16 different patterns to choose from, as you can see from the attached screen shot, and the pattern number is the 0 based index into this list, .e.g the Villain is 12. If there is no longer a monster fitting each graphics, e.g. the mushroom, I think some of the old monsters should be reintroduced.

monsters.a99

text.a99

post-35226-0-83728200-1553420656_thumb.png

doa8.bin

DOA.dsk

Edited by Asmusr
Link to comment
Share on other sites

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.

 

I'm interested in taking that project on. I've had a SAMS card in my PEB for for almost a couple of decades and it's only use is to act as a 32K memory expansion... A crying shame if you ask me. Having a set of assembly routines for XB to trivialize the use of the SAMS card particularly for array storage will be of immense value to the XB programmer as arrays take up a huge chunk of program space in that environment. I'll see what I can come up with in the next few months time permitting. I know absolutely nothing about SAMS access in assembly, so I will have to get up to speed on that. What's the best reference out there?

  • Like 3
Link to comment
Share on other sites

 

I'm interested in taking that project on. I've had a SAMS card in my PEB for for almost a couple of decades and it's only use is to act as a 32K memory expansion... A crying shame if you ask me. Having a set of assembly routines for XB to trivialize the use of the SAMS card particularly for array storage will be of immense value to the XB programmer as arrays take up a huge chunk of program space in that environment. I'll see what I can come up with in the next few months time permitting. I know absolutely nothing about SAMS access in assembly, so I will have to get up to speed on that. What's the best reference out there?

 

Cool. I suggest to move this discussion to the SAMS thread http://atariage.com/forums/topic/252171-1-meg-super-ams-discussion-thread/

which I should have done myself in the first instance.

Link to comment
Share on other sites

Awesome. You want me to make the new sprites? Looks like they are 16x16 with 16 possible colors? Any other limitations? Any max number you want me to make?

 

Perhaps start by mapping the monsters to the existing graphics to identify gaps? I do not want to lose any of the existing graphics because they have taken me many hours to draw.

 

If you want to draw new graphics there are two versions for each monster graphic: 8x8 and 16x16. The limitation is that each 8x1 pixel line can only use 2 of the 16 colors. I use Magellan to draw them, which understands this limitation.

 

Unfortunately there's only room for 8 more monster graphics before the 32K is full.

 

In order to use more SAMS memory I would have to split the game into multiple disk files, which is perfectly possible but not something I have time for now.

doa-monsters.mag

  • Like 1
Link to comment
Share on other sites

Roger that, I will work on the mapping then. I am definitely no artist, so it's a good idea to keep your sprites. One idea I had (knowing nothing about programming), could we artificially increase the amount by using color changes for the same sprites? Like for example have a red and white mushroom and then a blue and green mushroom? The identically mapping but just different color field values? I feel like a lot of old school RPGs did this.

 

Edit: I think this is called a palette swap?

Edited by budz2355
Link to comment
Share on other sites

 

After a bit of label renaming I managed to assemble a new version with the large monster list. I had to move some data around to make it fit into memory, but it's all there and a few hundred bytes left. I reintroduced the Villain monster because it's special for the town. I noticed there are two Gricks.

 

What's missing, as you can see if you try to run the attached version, is that each monster should be mapped to its graphics via the pattern number. There are currently only 16 different patterns to choose from, as you can see from the attached screen shot, and the pattern number is the 0 based index into this list, .e.g the Villain is 12. If there is no longer a monster fitting each graphics, e.g. the mushroom, I think some of the old monsters should be reintroduced.

 

Nice graphics! I'm doing bitmap mode 16x16 and 32x32 monsters myself. I have 8x8's for travel mode, but they don't have a unique one per monster, just a general "green lizard" that can be a dragon, a lizard, etc.

 

Right now I got about 60% of my monster graphics done. I have 170 16x16 patterns and 24 32x32 patterns.

Link to comment
Share on other sites

Roger that, I will work on the mapping then. I am definitely no artist, so it's a good idea to keep your sprites. One idea I had (knowing nothing about programming), could we artificially increase the amount by using color changes for the same sprites? Like for example have a red and white mushroom and then a blue and green mushroom? The identically mapping but just different color field values? I feel like a lot of old school RPGs did this.

 

Edit: I think this is called a palette swap?

 

The graphics consist of a pattern part (whether pixels are foreground/on of background/off) and a color part (foreground and background colors for each line). It would be possible to only change the color part whereby you could save up to half of the space, but neither Magellan or Dungeons of Asgard currently supports this.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

How's that?

 

Much better. There are two MOGRICs. For now I have disabled this one:

 

MOGRIC DATA TXVILL

DATA 12 ; Pattern number

BYTE 10 ; Level

BYTE 270 ; HP

BYTE 22 ; AC

BYTE 50 ; Damage

 

Also added the Villain again, and there was a TXWATE that should be TXWAEL. Fixed file attached.

DOA.dsk

doa8.bin

monsters.a99

Edited by Asmusr
  • Like 2
Link to comment
Share on other sites

Oops, yea that was my attempt to put the villain back in overwriting the duplicate grick. Thanks for catching that. Anything else I can help with? I have no skills, but if you wanted me to recolor some of your existing monster sprites or really anything else you need me to do that is helpful and too tedious for you?

Link to comment
Share on other sites

 

I'm interested in taking that project on. I've had a SAMS card in my PEB for for almost a couple of decades and it's only use is to act as a 32K memory expansion... A crying shame if you ask me. Having a set of assembly routines for XB to trivialize the use of the SAMS card particularly for array storage will be of immense value to the XB programmer as arrays take up a huge chunk of program space in that environment. I'll see what I can come up with in the next few months time permitting. I know absolutely nothing about SAMS access in assembly, so I will have to get up to speed on that. What's the best reference out there?

Hmm since 2000 RXB has had SAMS support for lower 8K and I have posted a ton of demos using SAMS and even my only game IN THE DARK.

Link to comment
Share on other sites

  • 10 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...