Asmusr Posted February 10, 2019 Author Share Posted February 10, 2019 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. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted February 10, 2019 Share Posted February 10, 2019 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..." 1 Quote Link to comment Share on other sites More sharing options...
budz2355 Posted February 10, 2019 Share Posted February 10, 2019 (edited) 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 February 10, 2019 by budz2355 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 11, 2019 Author Share Posted February 11, 2019 (edited) 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 February 11, 2019 by Asmusr Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 12, 2019 Author Share Posted February 12, 2019 (edited) 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 February 12, 2019 by Asmusr 4 Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted February 12, 2019 Share Posted February 12, 2019 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. Quote Link to comment Share on other sites More sharing options...
budz2355 Posted March 23, 2019 Share Posted March 23, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 24, 2019 Author Share Posted March 24, 2019 (edited) 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 doa8.bin DOA.dsk Edited March 24, 2019 by Asmusr Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 24, 2019 Share Posted March 24, 2019 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? 3 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 24, 2019 Author Share Posted March 24, 2019 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. Quote Link to comment Share on other sites More sharing options...
budz2355 Posted March 24, 2019 Share Posted March 24, 2019 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? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 24, 2019 Author Share Posted March 24, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
budz2355 Posted March 24, 2019 Share Posted March 24, 2019 (edited) 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 March 24, 2019 by budz2355 Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted March 24, 2019 Share Posted March 24, 2019 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 24, 2019 Author Share Posted March 24, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
budz2355 Posted May 4, 2019 Share Posted May 4, 2019 How's that? monsters.a99 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 4, 2019 Author Share Posted May 4, 2019 (edited) 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 May 4, 2019 by Asmusr 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted May 4, 2019 Share Posted May 4, 2019 Thank you for continuing work on this one. It is an outstanding bit of work--and it is turning into a really great game! Quote Link to comment Share on other sites More sharing options...
budz2355 Posted May 5, 2019 Share Posted May 5, 2019 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? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 6, 2019 Author Share Posted May 6, 2019 Has anyone tried to play the game with the new set of monsters? Quote Link to comment Share on other sites More sharing options...
iliketurtles Posted May 6, 2019 Share Posted May 6, 2019 It is next on my dad's list of test cartridges to build. I'll test it this coming weekend (or earlier if he finishes it sooner). Quote Link to comment Share on other sites More sharing options...
RXB Posted May 6, 2019 Share Posted May 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted April 3, 2020 Share Posted April 3, 2020 is the mystery still a mystery? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 3, 2020 Author Share Posted April 3, 2020 24 minutes ago, arcadeshopper said: is the mystery still a mystery? The mystery is: which mystery are you talking about? Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted April 3, 2020 Share Posted April 3, 2020 10 minutes ago, Asmusr said: The mystery is: which mystery are you talking about? I guess the one in v.4 I was just playing and found a mystery tile but .. cant pick it up or interact so maybe i don't have the latest ver Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.