The Legend of Beryl Reichardt

[matthew180]

Hey Owen, just some thoughts...

 

This thread is getting long and it is hard to distill the details from all the posts, especially when trying to determine what the latest requirements are for the game. I'm pretty sure you are looking for input and code help on this, so I'd like to suggest you put together some sort of design document that gets updated as things progress. Kind of like Codex does with Magellan where you can get the latest version from the first post in the thread.

 

I know design docs are boring and hardly read by anyone, but beyond the story line and various features, a comprehensive description of the game mechanics is needed to start making the code a reality. Initially it could be a description of what the player can do and how it should happen. Kind of like "use cases", I hate that term but it fits I guess. Something like:

 

Chest:

When the PC (player character) is touching a chest (or on top of a chest? which is it?) they can attempt to open the chest by... (pressing a key, hitting the fire button, how?) Chests may be locked or have traps (can they?) The PC must have a key to open a locked chest (do they, or can they bash it with certain weapons, etc.?) Keys can be bought from ... or found as drops (can they?) The PC can attempt to detect a trap (can they?) If the chest can be opened and has a trap, the following formula will be used to determine if the trap was disabled: x=y+z. If the trap is triggered, the amount of damage is determine: a*b+c/d. The loot in the chest is based on: ((q+r)+*s)/t^u+kitchen sink...

 

Combat:

 

Movement:

 

Light Radius:

 

MOB Size Determination:

 

MOB AI:

 

NPC Interaction:

 

Inventory Management:

 

Skill and Levels:

 

Map Goals:

 

Map Animation:

 

Sounds:

 

Music:

 

Map Loading:

 

Game Save / Restore:

 

Re-playability and Random Items / Loot

 

There are 10 zillion little details that simply go into something as seemingly simple as interacting with a chest, and when coding you have to know the answer to every single possibility. Also, what interaction with items is the same for all items and what needs to be unique. Stuff like that can make or break the code. You can have a unique subroutine to interact with every single object in the game, unless you plan to only have a few objects. So you need to distill the commonalities, which will also help the player understand how to interact with the game.

 

I'm just kicking out ideas here, but basically anything the defines and describes the exact mechanics of the game. This is not the place to define any story line or things like that. You should be able to think of any scenario that the PC can perform and look at this document to see how it will look, feel, interact, sound, etc.

 

The last two, i.e. saving and random loot can be very challenging. I read about a classic RPG where the chests were always randomly generated and were not tracked in the save data. So, you could clear the chests on a level, save, load and loot them again, repeat until you have tons of gold / items, beat the game easily... This kind of stuff can add a lot of challenge to the programming. People will always be able to cheat if they put enough effort into it, but you don't want to make it an accident of the game itself.

 

Anyway, food for thought... or not.

 

Matthew

[Opry99er]

This is a marvellous idea Matthew!!! I have much of this info ready to rock already--- I'll just put it into a single doc and post it to the first post in the thread. This way, I can check off or highlight the completed tasks and tag the stuff I'm currently working on. Update it once a week or Whenever progress is made.

 

James--- thanks--- I'll look into your suggestion when I get down to more detailed graphics. I suppose now that the viewport is complete I could really start putting a little more effort into the graphics---it's all skeleton at this point. I tell ya though--- this particular landscape-type is rough.... There aren't many cool "native" landscape ideas in an underworld lava map... The Forest world is what I'm looking forward to.

[Opry99er]

By the way... I'll post the updated .mag file for this world... If any of you care to add a few graphic tiles for fun to help the look of it, please do!!!

[JamesD]

James--- thanks--- I'll look into your suggestion when I get down to more detailed graphics. I suppose now that the viewport is complete I could really start putting a little more effort into the graphics---it's all skeleton at this point. I tell ya though--- this particular landscape-type is rough.... There aren't many cool "native" landscape ideas in an underworld lava map... The Forest world is what I'm looking forward to.

You can implement this similar to a color cycle but it's not as fast. Instead of cycling colors, you cycle through a range of characters. The cycle data can be part of the level. It should include timing info (how many interrupts to count between cycles), and the range of characters in the character set to cycle.

 

An interrupt handler counts frames between cycles and when a cycle is supposed to take place, just scan through the display looking for characters in that range. If you find one, check to see if the next character is in they cycle range, if so change the character to it, if not you change it to the first character in the cycle. If you keep the cycled characters to the end of the character set, you just have to test with a greater than.

 

This allows you to have moving water, bubbling lava, turning windmills, flowing fountains, burning fire, waving flags or whatever as long as it's not too big.

 

You'll have to learning how to use interrupts eventually anyway. The same interrupt is also used as a timer for controlling speed of movement, music and complex sound effects.

 

<edit>

Hmmm... got to thinking about what happens when you scroll the screen. If you copy data from the original map the character cycle works but you might get jumps in the animation. Perhaps a counter that is added to the map character should be used so the cycle can move steadily. It could add complexity to the scroll routine as well if you want the effect to appear to run during scrolling.

Edited June 2, 2010 by JamesD

[sometimes99er]

Sogar ein paar kleine Änderungen

 

http://sometimes.99er.net/beryl.html

 

[sometimes99er]

An interrupt handler counts frames between cycles and when a cycle is supposed to take place, just scan through the display looking for characters in that range. If you find one, check to see if the next character is in they cycle range, if so change the character to it, if not you change it to the first character in the cycle. If you keep the cycled characters to the end of the character set, you just have to test with a greater than.

 

This allows you to have moving water, bubbling lava, turning windmills, flowing fountains, burning fire, waving flags or whatever as long as it's not too big.

 

You'll have to learning how to use interrupts eventually anyway. The same interrupt is also used as a timer for controlling speed of movement, music and complex sound effects.

 

<edit>

Hmmm... got to thinking about what happens when you scroll the screen. If you copy data from the original map the character cycle works but you might get jumps in the animation. Perhaps a counter that is added to the map character should be used so the cycle can move steadily. It could add complexity to the scroll routine as well if you want the effect to appear to run during scrolling.

I would animate characters simply by updating their patterns.

[JamesD]

An interrupt handler counts frames between cycles and when a cycle is supposed to take place, just scan through the display looking for characters in that range. If you find one, check to see if the next character is in they cycle range, if so change the character to it, if not you change it to the first character in the cycle. If you keep the cycled characters to the end of the character set, you just have to test with a greater than.

 

This allows you to have moving water, bubbling lava, turning windmills, flowing fountains, burning fire, waving flags or whatever as long as it's not too big.

 

You'll have to learning how to use interrupts eventually anyway. The same interrupt is also used as a timer for controlling speed of movement, music and complex sound effects.

 

<edit>

Hmmm... got to thinking about what happens when you scroll the screen. If you copy data from the original map the character cycle works but you might get jumps in the animation. Perhaps a counter that is added to the map character should be used so the cycle can move steadily. It could add complexity to the scroll routine as well if you want the effect to appear to run during scrolling.

I would animate characters simply by updating their patterns.

Du-Oh! <slaps forehead>

 

<edit>

You have to remember I grew up with a machine that didn't have definable character sets.

Edited June 2, 2010 by JamesD

[Opry99er]

Thanks James and sometimes. I had this planned for the forest world, if you look at the early screenshot videos, I have water flowing under a bridge. I did as sometimes suggested--- I learned that trick from studying his brick scroller routine.

[Opry99er]

I just updated the first post in this thread to contain a textfile. It's bare bones, but I'm working on it. I had a bunch of stuff I wanted to do in the beginning and I made up a big long list and whatnot of what I wanted the game to contain. Sadly, I've changed my mind on almost all of it. What's left is what I posted for now. I also added a little video of the new updates offerend by the esteemed Mr. "180". =) Here's the video I posted there.

 

http://www.youtube.com/watch?v=7TzyIM1r044

[matthew180]

Actually (sadly), by the time all the game logic is in place, the movement may already be slow enough. Also, unless you changed the code, the joystick is only polled every 50ms or so. Thus, currently, the movement could be about 2 or 3 times faster. :-) If you want to slow it down a bit more, it only takes adding a new DATA statement and changing a label.

 

Matthew

[Opry99er]

I gotcha. Well, just to let you know, I would want the scroll to be slower

than it currently is. . So if we are able to build this game logic and it slows the scroll down past it's current speed, even when optimized, that would be okay. I will post a video of a similar speed and motion to what I want here in a minute.

[Opry99er]

This is a little example of the type of speed I want and pattern too. I like the way this character moves and how the SPRITE changes by direction.

 

http://www.youtube.com/watch?v=kEkJheh-nZo&feature=PlayList&p=58BB227E7547D14E&playnext_from=PL&playnext=1&index=1

 

 

[Opry99er]

Matthew, I'm having some ideas on how to store all the necessary data for all my enemies, party members, etc... Many of the necessary variables will apply directly to the party as a whole... Such as gold, items, etc... These are not individual statistics, but party ones. However, for my individual players, Here are the statistics we need to keep track of:

Health (current/maximum)

Magic (current/maximum)

Experience

Armor

Weapon

 

This can be done in 4 words, I think.

 

**Health: >78C8 (120 out of a possible 200) ** The MSB contains the actual state of affairs--- updated as things go.

-Give this a label (BHLTH) and update it as necessary

-The maximum health for any party member is 255 (FF)

 

 

**Magic: >324B (50 out of a possible 75) **The MSB contains the actual state of affairs--- updated as things go.

-Give this a label (BMAGC) and update it as necessary

-The maximum magic for any party member is 255 (FF)

 

 

**Experience: >1B58 (7000)-----(Label this one BREXP) Levels are based on 1000 experience points gained, so the highest level you can reach is 65

 

@@@The next two stats are kept in single bytes, the two make up a word@@@

 

*Armor: >04 (4th armor in list... (ronze armor))

*Weapon: >13 (This byte is unique. It uses the left nybble to show which TYPE of weapon it is (axe, sword, bow) and the right nybble to show what "grade" the weapon is. In this case, it is an iron broadsword. (1 being the code for sword, 3 being the grade--- "3" happens to be iron when it comes to swords. =)

**Together, armor and weapon make up 1 word, >0413, of which the MSB is the Armor, the LSB is the weapon. Label this BEQUI

 

So Beryl's individual statistical data looks like this

 

BHLTH DATA >78C8

BMAGC DATA >324B

BREXP DATA >1B58

BEQUI DATA >0413

To edit it, just MOV @BHLTH,R1 and modify. =) When this was going to be an XB project, I had a pretty cool plan to keep all my character data on diskette and it would be loaded before battle sequences and right after them. Codex helped me come up with a coding method and a parser to take my XB strings apart and put them back together. His ideas are pretty much spot on... I will have to consult our email logs carefully and study what I can. But does it make sense to keep variables this way?

[sometimes99er]

Love the video. Almost forgot to read your inline comments. Owen, you've come a long way.

 

 

Por eso hemos venido a la versión cuatro ...

http://sometimes.99er.net/beryl.html

[marc.hull]

Matthew, I'm having some ideas on how to store all the necessary data for all my enemies, party members, etc... Many of the necessary variables will apply directly to the party as a whole... Such as gold, items, etc... These are not individual statistics, but party ones. However, for my individual players, Here are the statistics we need to keep track of:

Health (current/maximum)

Magic (current/maximum)

Experience

Armor

Weapon

 

This can be done in 4 words, I think.

 

**Health: >78C8 (120 out of a possible 200) ** The MSB contains the actual state of affairs--- updated as things go.

-Give this a label (BHLTH) and update it as necessary

-The maximum health for any party member is 255 (FF)

 

 

**Magic: >324B (50 out of a possible 75) **The MSB contains the actual state of affairs--- updated as things go.

-Give this a label (BMAGC) and update it as necessary

-The maximum magic for any party member is 255 (FF)

 

 

**Experience: >1B58 (7000)-----(Label this one BREXP) Levels are based on 1000 experience points gained, so the highest level you can reach is 65

 

@@@The next two stats are kept in single bytes, the two make up a word@@@

 

*Armor: >04 (4th armor in list... (ronze armor))

*Weapon: >13 (This byte is unique. It uses the left nybble to show which TYPE of weapon it is (axe, sword, bow) and the right nybble to show what "grade" the weapon is. In this case, it is an iron broadsword. (1 being the code for sword, 3 being the grade--- "3" happens to be iron when it comes to swords. =)

**Together, armor and weapon make up 1 word, >0413, of which the MSB is the Armor, the LSB is the weapon. Label this BEQUI

 

So Beryl's individual statistical data looks like this

 

BHLTH DATA >78C8

BMAGC DATA >324B

BREXP DATA >1B58

BEQUI DATA >0413

To edit it, just MOV @BHLTH,R1 and modify. =) When this was going to be an XB project, I had a pretty cool plan to keep all my character data on diskette and it would be loaded before battle sequences and right after them. Codex helped me come up with a coding method and a parser to take my XB strings apart and put them back together. His ideas are pretty much spot on... I will have to consult our email logs carefully and study what I can. But does it make sense to keep variables this way?

 

If I might stick my fat head in for a moment...

 

If health, experience and magic have known limits then there is no need to store the limit in the LSB. Using the whole word would allow you to increase the current limits and get a "finer resolution" by allowing larger values to be added or subtracted without having such dire consequences on the whole. For example it would seem unfair to have events that happen early in the game to have the same impact as events that happen later in the game when your health and magic have increased. If you want the ability to change limits then add another word for that.

 

Your armor weapon scheme may actually take up more room in code and definitely operate slower than if you separate them into words of their own. You will find yourself possible spending more time and bytes on masking out the individual pieces for comparison (especially when using nybbles) than it's worth.

 

 

One of the advantages the TI has is the fact that it can manipulate memory directly. No need for an accumulators, stacks or other overhead inherent in other processors. This feature causes a performance hit but if you take advantage of it, you can work it in your favor. Sooooo..

 

modifying your variables can have their overhead reduced if you take advantage of the mem to mem architecture (which everything basically is anyway.) Instead of moving a value to a register, modifying it and moving it back you could define modifiers before hand and do it all with one statement....Example.....

 

D001 DATA >0001

D010 DATA >000A

HEALTH DATA >0000

 

A @D001,@HEALTH (3 steps reduced to 1)

 

----- OR ------

 

S @D010,@HEALTH (is that the correct order ?)

 

The machine basically always works with words anyway so moving bytes around has no positive influence on speed. Now if you are planning on Carting this game up without MemEx you will most likely have to use VDP or whats left of scratch pad RAM at which point most of what I said is moot I would hate to see you limit yourself to that forum though...

 

 

Just food for thought.

[matthew180]

Owen, as Marc pointed out, there are many alternatives to how the game data can be stored and used, but you should not be thinking about the technical implementation while you are building the specs or the feature list. Obviously you have to keep the limitations of the platform in mind, but the exact details about how to store a player's hit points will come later. You can't even answer that question until *all* of the possible uses for the various data have been identified.

 

The only limitations I would suggest you consider at this point (regarding stats anyway) is whether or not a particular value can be represented in a byte or a word (16-bits in our case), or if the data needs something more exotic. Also indicating max values for various parameters and how those will affect any decisions or calculations, etc.

 

Matthew

[matthew180]

This is a little example of the type of speed I want and pattern too. I like the way this character moves and how the SPRITE changes by direction.

 

Well, it works in that game for a few reasons:

 

1. They have pixel scrolling which means you can animate the character with steps that look reasonable. We are jumping a whole tile at a time, so your character's "steps" will look odd.

 

2. They are using a perspective map, albeit "front-on" (as opposed to isometric), but still perspective none the less. So seeing the character's back as it moves "up" seems logical. Your map is more of a "looking straight down" and you don't have as much of a sense of perspective. You could make it more perspective by making features of the map bigger, like trees that are taller than the character, structures like houses, rocks, or whatever else being bigger, i.e. taller than 1 tile and giving them perspective. Basically scale the world up to match the character's size. Right now the character is like a giant.

 

The other thing is, you're comparing what you want to do with a platform that has more CPU, RAM, speed, sound, and capability. Use those things for inspiration, but make sure you can still scale back to what is possible on your target platform.

 

Did you notice how the character in that game is always in the middle of the viewport / screen? When you get close to the edges there is extra map for the border. Unfortunately doing that is not practical on our little 99/4A.

 

Matthew

[Opry99er]

Thanks Marc, that is good stuff! To your first point, though--- the player's experience level will be part of what determines the players max HP and max MP. If the player has a current max of 200, but only has 180--- then that's one thing. If you defeat a boss and gain the necessary experience

points, your new max could become 230 or something. And while Beryl's max health may be 230, Reptoslicer's

may be 170. All different. But you're 100% right on the armor and the weapon thing. I was trying to get too cute. In any case, I'm taking all your suggestions into mind. I really have NO idea how much memory I have left after the mapdata for each world is in RAM. See, I really don't know what features I can use or how cute I have to be with compressing my variables and stats. I've seen these brilliant methods for storing data and whatnot, but how much if any of that is necessary for THIS game? How many features will I be able to put in?I just don't know this stuff so I'm really blind about it. That's why I rely on you and Matthew to lern a country boy in the ways of the 9900 magic.

Edited June 3, 2010 by Opry99er

[+adamantyr]

Have you written out that design document yet? If so, you should post it here. Trust me, it will help you a LOT with keeping focus on what you need.

 

I'm a little concerned you're not sure yet if you're doing cartridge or disk. They're very fundamentally different environments, and it should be your first major decision.

 

Let's compare the two here:

 

Disk:

-----

- Full 32k RAM available for code space, buffers, and data, 16k of VDP available

- 90-360k of disk space available for data storage, possible code segmentation (NOT recommended)

- Potential sluggishness due to disk access fetches

- Not difficult to test on actual hardware

 

Cartridge:

----------

- 256 bytes of scratchpad available for RAM, 16k of VDP available

- Either ROM (8k pages) or GROM (6k chips, nominal limit of 5, but could be more with an exotic design) space for fixed static data

- Tricky to test on actual hardware

 

I'm starting to understand, really, why a lot of the Databiotics games that Triton/TM Direct sold were absolute crap. The lack of a decent amount of CPU memory in the TI console is really a hindrance to development.

 

Adamantyr

[Opry99er]

Love the video. Almost forgot to read your inline comments. Owen, you've come a long way.

 

Thanks sometimes. . Problem is, I don't know where I am. . I've come far enough to know I ain't at home in comfy XB land.

 

 

Por eso hemos venido a la versión cuatro ...

http://sometimes.99er.net/beryl.html

[Opry99er]

Adam, with cart, though--- and knowing my map data can be stored on disk--- my cart will simply require the 32k memory expansion, similarly to Marc's Never-Lander (as it currently exists). That way, I'll have access to all the features of both---for the most part. A cart with a disk--- ToD anyone? I understand there are differences.... I wish I knew more. The reason I may not have alot

of this stuff decided is because I really don't have the knowledge on it as I need to. I'm just working on stuff in the dark, to be honest. My feature list right now is very short and thin... I had a big one with a bunch of stuff in it, but so much has changed...no longer doing it in XB and whatnot. Look at the first post of this thread to DL the first skeletal outline of some of the things I want to implement.

[marc.hull]

Have you written out that design document yet? If so, you should post it here. Trust me, it will help you a LOT with keeping focus on what you need.

 

I'm a little concerned you're not sure yet if you're doing cartridge or disk. They're very fundamentally different environments, and it should be your first major decision.

 

Let's compare the two here:

 

Disk:

-----

- Full 32k RAM available for code space, buffers, and data, 16k of VDP available

- 90-360k of disk space available for data storage, possible code segmentation (NOT recommended)

- Potential sluggishness due to disk access fetches

- Not difficult to test on actual hardware

 

Cartridge:

----------

- 256 bytes of scratchpad available for RAM, 16k of VDP available

- Either ROM (8k pages) or GROM (6k chips, nominal limit of 5, but could be more with an exotic design) space for fixed static data

- Tricky to test on actual hardware

 

I'm starting to understand, really, why a lot of the Databiotics games that Triton/TM Direct sold were absolute crap. The lack of a decent amount of CPU memory in the TI console is really a hindrance to development.

 

Adamantyr

 

 

 

 

Very good point!!! I think I may have found an ally in the 32K world

[matthew180]

Well, let's make some stuff up so you can lay down your design document.

 

We have:

 

16K VDP RAM.

24K Hi mem

8K Lo mem

8K Cart ROM

128K Per disk (right, 128K?)

 

We need to keep some space open in the upper VDP RAM for disk buffers. But, I don't think you will be using the hybrid Graphics Mode 2, so there is still a good deal of VDP RAM available. That is actually a good place to store sound data since we only needs a few bytes every VSYNC. Assuming you use all 2K for pattern data and separate the sprite patterns for another 2K, plus the SAT and SIT is another 1K. So 6K for the screen and patterns. I don't know the details on the PAB's for disk, but let's assume 1K at least, what the hell, let's say 2K. Thus:

 

Screen image table and color table: 1K

Tile patterns: 2K

Sprite patterns: 2K

Sprite attribute table and animation patterns: 1K

PAB's: 2k

Sound Data: 8K

 

So that's the 16K VDP RAM used up.

 

 

Now let's just say the 8K low mem is going to be 100% map data. The square root of 8192 is 90.5, so a 91x90 map would be 8190 bytes. So we can do any variation of that which fits in 8192 bytes:

 

15x15 (smallest is what ever the viewport is set to)

90x90 (largest square map)

100x81

150x54

200x40

546x15 (widest map)

15x546 (tallest map)

 

Map Data: 8K lo mem

 

 

That leaves 8K of ROM for program code and 24K hi mem for internal data structures, generated maps or data (in case you want random dungeons or something), swapped out character data, etc. If there needs to be cart ROM paging of code, then it would also go into the 24K hi mem.

 

Program: 8K cart ROM

Program swap: 8K hi mem

Runtime data: 16K hi mem

 

 

Program "swap code" can come from paged cart ROM or disk.

 

Speed critical variables: 256 bytes scratch pad.

 

 

I think that pretty much covers the platform limitations. Code that always has to be in memory (can not be paged):

 

* main state machine and basic game logic

* paging code

* keyboard scanning

* disk access

 

Code that could probably be paged:

 

/ combat screen rendering

\ combat logic

 

/ world viewport scrolling and navigation

\ world logic

 

/ interior locations

\ associated logic

 

/ random generated dungeon screen rendering

\ dungeon logic

 

Of course maps and sound are disk loadable. Also, I have never really done this swapping so I don't know how long it takes to read 8K from disk or what parts of the code are actually swappable. Obviously no swapping is the desired way to go.

 

Maybe this will help you put some limits on the features and get some things defined.

 

Matthew

Edited June 3, 2010 by matthew180

[Opry99er]

That's great!!! Thank you very much!

 

Also--- graphic upgrades are certainly in the works. I will be increasing the size of many of these features, since the language had changed. My initial designs were kept very minimalistic because of character set limitations in XB and because this was never intended to be a scroller with animated PC motion. It was to be a screen-by-screen segment-loaded world---similar to Zelda. But now that I have so much more stuff to play with, these worlds will be getting very tasty.

[Opry99er]

I could just use a 512k EPROM and a 1GB Flash RAM card in my cart and we would never have storage or memory problems again!!!

 

<<joke>>

Edited June 3, 2010 by Opry99er