Entry 2018: The Crimson Tower

[+DZ-Jay]

The 56 card maximum would fit nicely into GRAM, and still leaves 8 cards for sprites like user-defined markers.

 

You're welcome!

 

I agree only one map should be displayed at a time, but there should be some way of tracking and storing the explored area of every floor. I think destroying the previous floor map to generate the new map defeats the purpose of generating maps in the first place. There will be a lot of back-tracking in the final game and if the player isn't drawing their maps by hand, saving them will be necessary.

 

I don't understand what you mean by "destroying the previous floor map to generate the new map." I think it would be reasonable to limit the auto-map to show only the map where the player is in. I mean, just a day ago we were talking about not having an auto-map at all, so why couldn't a single floor auto-map be sufficient? It still beats the pants off mapping by hand.

 

Moreover, even if you plan on allowing the player to view all floors (one at a time) in the auto-map mode, I still do not see it as a problem to destroy and re-generate as the player switches levels. Let's be honest, what are we talking about here? 10... 15 frames? Even if it took you 120 frames to compute (which I find excessive, clocking at several hundreds of thousands of cycles), that's still only 2 seconds!

 

A player surely can spare 2 seconds switching map screens, and I will be willing to bet that he would be happier to do so rather than mapping it by hand.

 

Lastly, let's consider the purpose of the auto-map. In my opinion it's not necessarily a crib for overall world strategy, but an aid in navigating the labyrinth and orienting the player within that plane. That, I believe is the #1 most frequent use case for it.

 

To use the auto-map as a means to coordinate strategy in the overall game world, by knowing where everything is at any point in time, is in my opinion, secondary and less frequent. So waiting even a couple of seconds to switch between levels is not such an imposition, I think.

 

As for tracking the exploration, you can keep track of that in a 144-bit structure (12 x 12), a bit per room, to tell you whether it has been visited or not. You know, 12 x 16-bit variables would do nicely. You could get away with nine if you pack the bits in. Again, unpacking shouldn't be a problem since (in the context of the auto-map user experience) you have all the time and CPU cycles in the world to generate your map lazily.

 

I think the one word per room idea is great. This would greatly simplify my current code and also make it more versitile. It would also solve the exploring/tracking problem but still requires extra RAM, even just for one floor.

 

If you currently have a data structure to store the state of the world per room (which I suppose you have), then yes, one 16-bit word per room will do great, as long as you can spare a bit for the "visited" flag. (I don't know what else you need to track per room in your game, but perhaps even an 8-bit byte would help! It's not like you have so much going on in a room at a time.)

 

However, if you can't spare the extra bit right now, then spending 12 x 16-bit words (or nine) just for the auto-map "visited" state, doesn't sound like such an onerous addition.

 

The message box is not a bad idea either. I could display text on the bottom row of the border.

 

I personally would recommend the message box rather than the message row at the bottom. To me those "message lines" feel like a cheap cop-out, and steals valuable real-estate from the actual game world.

 

You can do the pop-up the "old fashioned way" we used to do back in the micro-computer days: you read the BACKTAB rectangle, store it in a buffer, draw the frame and text, then replace it with the stored buffer when done. If you limit or standardize the size of the pop-up so that all of them are the same, you can make the routines very simple.

 

Again, in this kind of game of lazy and methodical exploration, there is no need for ultra-fast-twitchy-reflex rendering. If it takes you a couple of frames to generate the pop-up and to tear it down, then that's still only a few milliseconds. Hardly a nuisance.

 

It's just more work, of course, so it's up to you. It will surely give your game a very nice shine.

 

-dZ.

[emerson]

As I said before, I agree that displaying only the current floor map is good. I never wanted all floor maps on screen at once.

 

It makes sense to re-calculate the background cards for the map each time it's loaded on screen instead of storing the actual background cards.

 

I interpreted your suggestions as using the same RAM locations (for example, a single 144-bit structure) to store the explored areas for every floor. Therefore, when the player changes floors, the explored areas of the previous floor would be overwritten and lost. That's what I meant by "destroying the previous floor map". I'm not talking about graphics here, but rather the visited flags. Without storing the explored areas of each floor, it would be the equivalent of hand-drawing a floor map and throwing the paper away as soon as you change floors.

 

What I'm trying to describe is using four separate 144-bit structures, so one per floor. This way when the player leaves a floor then returns, the explored areas of the floor are saved.

[+DZ-Jay]

Oh, I see. Noooooo, I wouldn't want to lose the explored areas when switching floors. I guess I forgot to say 144 bits x 4 floors, so we are both talking about the same thing.

 

Not knowing how you track room definition and item/monster state in each, I will naively ask the following: can't you use a spare bit per room for the "visited flag" in the current structure you already have in place today?

 

dZ.

[+Tarzilla]

As I said before, I agree that displaying only the current floor map is good. I never wanted all floor maps on screen at once.

 

It makes sense to re-calculate the background cards for the map each time it's loaded on screen instead of storing the actual background cards.

 

I interpreted your suggestions as using the same RAM locations (for example, a single 144-bit structure) to store the explored areas for every floor. Therefore, when the player changes floors, the explored areas of the previous floor would be overwritten and lost. That's what I meant by "destroying the previous floor map". I'm not talking about graphics here, but rather the visited flags. Without storing the explored areas of each floor, it would be the equivalent of hand-drawing a floor map and throwing the paper away as soon as you change floors.

 

What I'm trying to describe is using four separate 144-bit structures, so one per floor. This way when the player leaves a floor then returns, the explored areas of the floor are saved.

nanochess can correct me but I believe you are allowed to use the --cc3 or --jlp to access the 8k-words of RAM feature of those boards, thereby making the 4 floor visited tracking easier for you (and add more floors,) though it might impact you on code space due to not being allowed to use bank switching.

[Kiwi]

I played it more last night. I was thinking time progress slowly as it turn day to night, so my clock idea is out the window as I found the key and the bell tower. I did see the musician

 

I'm going to play more and keep note where the treasure chest are by using the coordinate information. And try to complete the game.

I believe the extra RAM mapping is at $8000 and up.

[+nanochess]

Using the --cc3 option allows you to access 8000 extra words. These are available for 16-bit arrays.

 

If these days there are 3 ready options for hardware support: LTO-Flash, LTO boards and 5-11under boards.

 

If you know you're using LTO-Flash you can use the --jlp option for hardware multiplication and division.

[Kiwi]

I've finished the game. Really well done. I just kept note where the treasure chests are and what they contain. I guess the keys are to unlock the door to the next floor in the future version. Looking forward to the finished game.

[artrag]

Emerson I think you could do even better than what I have suggested

Exploiting the fact that each cell has to have south walls and doors in the same place of the lower cell has north walls and doors, and that the same occurs on east/west, you can use just 2 bits for wall and door north and 2 bits for wall and door west = 4 bits per cell + a frame of extra cells for south and est limits

[+nanochess]

Each map could use a random seed of 16 bits, this could pass to an internal random number generator.

 

So each of the 4 maps could be taken from 65536 combinations and regenerated when neeeded.

 

The visited map of course would continue to be same 144 bits x 4. (72 8-bit variables or 36 16-bit variables)

[artrag]

He has to generate and store just a seed per floor and regenerate the floor each time player enters in it.

The generated level can take 144 bytes, 4 bits for doors and walls as above and 4 bits for room type + 144 bits for visited/not visited.

 

144 bits are 18 bytes per floor, so you could keep in ram the state of all floors as 18*15 bytes (you have 15 floors, have you?)

Edited July 26, 2018 by artrag

[emerson]

Emerson I think you could do even better than what I have suggested

Exploiting the fact that each cell has to have south walls and doors in the same place of the lower cell has north walls and doors, and that the same occurs on east/west, you can use just 2 bits for wall and door north and 2 bits for wall and door west = 4 bits per cell + a frame of extra cells for south and est limits

 

You mean something like this:

 

%0000

| | | Lnorth/south wall bit (0=north, 1=south)

| | Least/west wall bit (0=east, 1=west)

| Lnorth/south door bit (0=north, 1=south)

Least/west door bit (0=east, 1=west)

 

Lets say that was the northwest corner room, I would use the east and south bordering rooms to define the other possible walls, right? Also, I only have 4 floors, not 15.

 

If these days there are 3 ready options for hardware support: LTO-Flash, LTO boards and 5-11under boards.

 

Good to know, thanks!

 

 

I've finished the game. Really well done. I just kept note where the treasure chests are and what they contain. I guess the keys are to unlock the door to the next floor in the future version. Looking forward to the finished game.

 

Thanks, I'm glad you enjoyed it!

[+DZ-Jay]

Emerson I think you could do even better than what I have suggested

Exploiting the fact that each cell has to have south walls and doors in the same place of the lower cell has north walls and doors, and that the same occurs on east/west, you can use just 2 bits for wall and door north and 2 bits for wall and door west = 4 bits per cell + a frame of extra cells for south and est limits

 

Oh, yeah, that is true! Great idea!!!

[+DZ-Jay]

Each map could use a random seed of 16 bits, this could pass to an internal random number generator.

 

So each of the 4 maps could be taken from 65536 combinations and regenerated when neeeded.

 

The visited map of course would continue to be same 144 bits x 4. (72 8-bit variables or 36 16-bit variables)

 

That's kind of what Elite did back in the C=64 days: they didn't have the space to store all those galaxies, so they generated a random seed, fed it into a fibonacci sequence generator, which allowed them to re-calculate planet information every time the player visited them by just following the same sequence.

 

Just like with a PRNG, the initial seed just marks to the entry point in the sequence, and since the number space is so large, each sequence selected at the start of each game is essentially random.

 

-dZ.

[artrag]

 

You mean something like this:

 

%0000

| | | Lnorth/south wall bit (0=north, 1=south)

| | Least/west wall bit (0=east, 1=west)

| Lnorth/south door bit (0=north, 1=south)

Least/west door bit (0=east, 1=west)

 

Lets say that was the northwest corner room, I would use the east and south bordering rooms to define the other possible walls, right? Also, I only have 4 floors, not 15.

 

 

I was thinking to this

 

%0000

| | | Lnorth wall bit (0=no, 1=yes)

| | Lweast wall bit (0=no, 1=yes)

| Lnorth door bit (0=no, 1=yes)

Lweast door bit (0=no, 1=yes)

 

if you have

C11 C12 C13...

C21 C22 C23...

...

 

while plotting C11, use C12 to plot the east wall (read its west bits) and C21 to plot the south wall (read its north bits)

Edited July 26, 2018 by artrag

[emerson]

 

I was thinking to this

 

%0000

| | | Lnorth wall bit (0=no, 1=yes)

| | Lweast wall bit (0=no, 1=yes)

| Lnorth door bit (0=no, 1=yes)

Lweast door bit (0=no, 1=yes)

 

if you have

C11 C12 C13...

C21 C22 C23...

...

 

while plotting C11, use C12 to plot the east wall (read its west bits) and C21 to plot the south wall (read its north bits)

 

Ahh ok. So for the west-most column and south-most row of rooms just know that is the last column/row and force a wall there? So for this 3x2 layout:

 

C11 C12 C13 <

C21 C22 C23 < (forced walls at arrows since they are perimeter rooms)

^ ^ ^

[artrag]

Yes

[artrag]

Consider also that you have 16 possible situations but not all of them will be meaningful

E.g. you cannot have doors without walls.

If you assume in your code that if you have a door, the wall is implicitly there, you could use 'invalid' codes for marking opened doors.

 

1111 means 2 walls (at north and west) with 2 closed doors

0011 means 2 walls (at north and west) with 2 opened doors

1100 means 2 walls without doors

0000 no walls or doors

Edited July 27, 2018 by artrag

[+DZ-Jay]

 

Ahh ok. So for the west-most column and south-most row of rooms just know that is the last column/row and force a wall there? So for this 3x2 layout:

 

C11 C12 C13 <

C21 C22 C23 < (forced walls at arrows since they are perimeter rooms)

^ ^ ^

 

Yes, that's your "effective map." That's how I track the virtual tile map in Christmas Carol as well: You do not need to track the outside perimeter wall, since it is implied.

 

 

Consider also that you have 16 possible situations but not all of them will be meaningful

E.g. you cannot have doors without walls.

If you assume in your code that if you have a door, the wall is implicitly there, you could use 'invalid' codes for marking opened doors.

 

1111 means 2 walls (at north and west) with 2 closed doors

0011 means 2 walls (at north and west) with 2 opened doors

1100 means 2 walls without doors

0000 no walls or doors

 

What does that save? Don't you still need 4 bits per room to track the door arrangement, no?

 

But I'm curious to know why are we discussing this? I thought the game already did all the map construction in its own way. I thought what was left was only to track exploration which is barely one bit per room... What am I missing?

 

-dZ.

[PuzZLeR]

Full credit - very ambitious and brave undertaking. Good work.

 

As well, IMO, it's always nice to see some inspiration from a previous, or classic, Intellivision cart brought forward today.

[artrag]

 

Yes, that's your "effective map." That's how I track the virtual tile map in Christmas Carol as well: You do not need to track the outside perimeter wall, since it is implied.

 

 

 

What does that save? Don't you still need 4 bits per room to track the door arrangement, no?

 

But I'm curious to know why are we discussing this? I thought the game already did all the map construction in its own way. I thought what was left was only to track exploration which is barely one bit per room... What am I missing?

 

-dZ.

While in a floor you can store the door status in the map without extra bits. In this way you can represent opened doors also in the map by using only 4 bits per cell.

Leave the floor and the door status is reset to default since the game will deal with one map at time.

Edited July 27, 2018 by artrag

[+DZ-Jay]

While in a floor you can store the door status in the map without extra bits. In this way you can represent opened doors also in the map by using only 4 bits per cell.

Leave the floor and the door status is reset to default since the game will deal with one map at time.

Ah yes that will be good to have. Persistence of the door status is something that is currently missing.

 

dZ.

[emerson]

But I'm curious to know why are we discussing this? I thought the game already did all the map construction in its own way. I thought what was left was only to track exploration which is barely one bit per room... What am I missing?

 

It does, but very inefficiently. Each room currently uses 4 bits for walls and four bits for doors, so 144 bytes of RAM just for the floor layout. With the methods discussed here I could fit a lot more information into the same amount of space.

 

Plus, this is the first time I've attempted to program a game with this level of detail. Having the input of people who have more experience then me is very much appreciated and I thank everyone for their feedback.

[+DZ-Jay]

 

It does, but very inefficiently. Each room currently uses 4 bits for walls and four bits for doors, so 144 bytes of RAM just for the floor layout. With the methods discussed here I could fit a lot more information into the same amount of space.

 

Plus, this is the first time I've attempted to program a game with this level of detail. Having the input of people who have more experience then me is very much appreciated and I thank everyone for their feedback.

 

Yes, all good reasons. I was just wondering because the conversation changed focus and I thought I missed some context -- yup, I did.

 

-dZ.