Jump to content
IGNORED

Entry 2018: The Crimson Tower


Recommended Posts

Here is my game for this year's contest. It's called The Crimson Tower, and it's a first person dungeon crawler. You navigate the maze-like hallways of a four story bell tower in search of instruments in which you provide to the musicians who will help you summon the Firewitch.

 

My goal is to make a cross between Treasure of Tarmin and King's Field, with the story and music inspired by the band King Crimson. Due to a few months of not being able to work on the game, it is very incomplete, but I wanted to get something out before the contest ends. There are no enemies, item shop, or side quests at this time but I plan to add them in the future.

 

What I do have is randomized floor plans, randomly placed treasure chests, and the musicians are also randomly placed on their turrets. Unlike Tarmin, you can freely navigate up and down the tower floors, and it is necessary to do so. Ring the bell and turn day to night (or night to day) and unlock special treasure chests. Musicians are also only visible in a certain time of day.

 

 

Please read "manual.txt" before playing. You will also find a file called "map_template.pdf". I highly advise you print it and brush up on your map making skills!

 

the_crimson_tower.zip

source_code.zip

  • Like 8
Link to comment
Share on other sites

I played a little bit and... wow! I'm impressed with what you have so far. I have some random feedback picked up while traversing the dungeon:

  • I love the opening-door effect. It took my by surprise the first time.
  • There should be some transition when turning around to give the player an indication that the change in point of view occurred. Sometimes, if I blink, I miss it and then don't know if I actually turned. This is especially confusing when the change between the old and new points of view is very minor, like this:
    post-27318-0-33817100-1532125455.gifpost-27318-0-78904700-1532125459.gif

    Here's another example: I'm facing North...
    post-27318-0-54653900-1532125474.gif

    Then East:
    post-27318-0-00922800-1532125479.gif

    Then South:
    post-27318-0-12617600-1532125484.gif

    Then West:
    post-27318-0-30106100-1532125489.gif

    I know that I can use the compass to orient myself, but this sameness without transitions affects my ability to build a mental model of the maze.
  • The scale of the doors on the flanking sides seems wrong; they are too large. This causes me to get disoriented when I change the point of view and the door looks smaller against a large wall.

    For example, notice the difference in size between the door on the left wall and the on in front.
    post-27318-0-10835000-1532125464.gif
    The door on the left looks like it takes the entire wall. This influences my mental model of the maze.

    Now, I moved forward and turned left to face the door on the left wall:
    post-27318-0-27208200-1532125469.gif
    The door is "normal" size and is aligned closer to the right side (what used to be in front, in my previous position). The empty wall space to the left of the door suggests to me that it is a long-running wall (like in other parts of the maze), but we saw on the previous point-of-view that it was just a short wall with only a door.
  • Would it be possible to persist the state of open doors, at least until you move out of range? If I open a door, then enter through it, I wish I could also back out without having to turn around and re-open the door.
  • Later versions of dungeon crawlers after the initial versions of Wizardry included an in-game map to aid you. Would it be possible to include that so that I don't have to map myself? (I like playing video games without non-computer equipment. :))
  • Exiting the menu leaves the screen blank without re-drawing the maze. It gets corrected after my first move, though.
  • I opened two chests (one yellow and one cyan during the day), but I do not know what is inside or how to pick it up. The instructions say "take item by pressing 2," so I do. I then hear a sound effect (which I am not sure what it indicates), but my Inventory still shows blank.
  • It is not clear by the instructions, but I suppose the instruments are in the chests, right?
  • From the 4th floor, I found a ladder going up and there was some yellow thing guy there. I suppose that's a musician, right?

That's it for now. I got lost a couple of times, but was able to find my way again using the ladders. I hope the above proves useful. :)

Great job! :thumbsup:

-dZ.

Link to comment
Share on other sites

Here are some answers for you Jay:

 

-Unfortunately I can't do transitions at the moment due to how the hallway view is drawn on screen. The only way I could think to do this is to pre-calculate the screen and write it to a buffer, then parse through the buffer (in the direction that you turned) and place the data on screen. This would give a nice horizontal scroll effect but would require extra RAM.

 

-The scale of the doors isn't the best. I spent too much time trying to get a decent perspective and needed to moved on.

 

-At this point only one door could remain open, say, if you were to enter and exit the menu. Once you turn away it will close. I have the beginnings of some code to handle this.

 

-I might be able to have pre-rendered maps, but that that would be last on my list... Until then, don't be scared to get out the colored pencils and draw a beautiful map!

 

-I'm not experiencing the menu issue, maybe you could provide a little more detail about when this happens? What exactly are you trying to do when this issue occurs?

 

-If a chest has an item in it, the item will raise up with the lid. So if the chest appears empty, it is. Only 8 of the 16 chests have items so far, four of which are the instruments.

 

-The yellow, purple, and white "thing guys" on the turrets are in fact the musicians. They look horrible, but they work for now. I plan to combine background and sprite overlaps to make some real nice images.

 

 

I found a minor bug where the screen wasn't immediately redrawn after opening a teleport chest. This will be fixed in the next release.

Link to comment
Share on other sites

Here are some answers for you Jay:

 

-Unfortunately I can't do transitions at the moment due to how the hallway view is drawn on screen. The only way I could think to do this is to pre-calculate the screen and write it to a buffer, then parse through the buffer (in the direction that you turned) and place the data on screen. This would give a nice horizontal scroll effect but would require extra RAM.

 

-The scale of the doors isn't the best. I spent too much time trying to get a decent perspective and needed to moved on.

 

-At this point only one door could remain open, say, if you were to enter and exit the menu. Once you turn away it will close. I have the beginnings of some code to handle this.

 

-I might be able to have pre-rendered maps, but that that would be last on my list... Until then, don't be scared to get out the colored pencils and draw a beautiful map!

 

-I'm not experiencing the menu issue, maybe you could provide a little more detail about when this happens? What exactly are you trying to do when this issue occurs?

 

-If a chest has an item in it, the item will raise up with the lid. So if the chest appears empty, it is. Only 8 of the 16 chests have items so far, four of which are the instruments.

 

-The yellow, purple, and white "thing guys" on the turrets are in fact the musicians. They look horrible, but they work for now. I plan to combine background and sprite overlaps to make some real nice images.

 

 

I found a minor bug where the screen wasn't immediately redrawn after opening a teleport chest. This will be fixed in the next release.

 

Thanks for the response. About the transitions, I understand. Maybe just a sound effect would help. It's just something to let you know that the change happened.

 

-dZ.

Link to comment
Share on other sites

A simpler option for giving a better idea of what has happened when you turn right or left is to have colored walls and avoid two adjacent walls have the same color

 

Yeah, that would work. I also think a nice "chirp" or "tick" sound would alert the user that something happened, in the case where he happens to blink or change his visual focus at the moment of moving. It's just additional feedback to the player. :)

 

-dZ.

Link to comment
Share on other sites

-I'm not experiencing the menu issue, maybe you could provide a little more detail about when this happens? What exactly are you trying to do when this issue occurs?

 

I found a minor bug where the screen wasn't immediately redrawn after opening a teleport chest. This will be fixed in the next release.

 

I think those are similar bugs. I can't seem to reproduce it now, but when it happened, I was already deep into the dungeon on level 3 or 4. What I saw was the screen not being redrawn after exiting the menu: The menu screen cleared (green border, black background), but the maze didn't re-draw.

 

When I try it now, the menu screen is cleared and then the maze is re-drawn, so perhaps there is a combination of conditions that prevent the last step from happening.

 

-dZ.

Link to comment
Share on other sites

Oh darn! I was playing for several minutes and had mapped out the first level completely and was ready to go into the second level when I started writing some notes and trying to reproduce the menu bug -- and I inadvertently shut down the emulator! :(

 

I'll have to start again from scratch. :_( Oh well, some other time.

 

I was able to reproduce the menu blank screen bug but not consistently. It happened once, then it didn't happen again. I do not know what triggers it, but it is definitely the case that the maze is not redrawn after clearing the menu screen.

 

Interesting game. Personally, dungeon crawlers were never my thing, so I am not accustomed to some of the conventions (although I am familiar with some of them). It's the initial disorientation and mapping requirements that kill me -- especially if all the investment in time and effort put into the map can be thrown away at the slightest bug, power spike, or inadvertent key press.

 

I wish there was more to do, though. I suppose all that will come with time, as some of the missing features you mentioned on your first post sound very enticing. :)

 

I can't wait to see what comes of this. :thumbsup:

 

-dZ.

Link to comment
Share on other sites

Colored walls is a good suggestion. Would that make my game look too similar to Treasure of Tarmin? It might be worth it if that helps define a proper user interface...

 

I usually don't play dungeon crawlers either. I find them intriguing but I get bored of them really quick. That goes for most rpg type games. It was fun trying something new though!

 

 

If anyone would like to play the game with consistant map, chest, and musician placement, simply comment out this gosub command found on line 34 of "crimson_tower.bas" and recompile the rom. This will skip the title screen and generate the same seed value for the randomizer on every game start. I usually comment out lines 34-36 but just 34 should work too. This works in jzintv.

'==========game start==========
	gosub LoadTitleScreen

Maybe a difficulty mode is in order? The player could select what is randomized and what is pre-defined. This would only be practical for tower layout and chest placement, but then you could reuse your maps.

Link to comment
Share on other sites

This game needs an automatic map.

You could activate it by pressing a key in the keypad

You have to show only the explored areas and the current player direction. No action while in map mode.

I agree. I really wish to play again, but just the thought of having to map the entire maze (again) tempers my enthusiasm.

 

The personal effort and time commitments grow significantly without an auto-mapping capability, which may limit the game's general appeal and replayability.

 

I understand that it may not seem like the most pressing feature at the moment, but consider that beta-testers and play-testers will have to play the game many times through to fully shake out any bugs or game-play issues. Just a thought. :)

 

dZ.

Link to comment
Share on other sites

I've been wondering how to go about generating the auto-map. I'm thinking out loud here so prepare for some ramblings...

 

Each room in the floor plan is represented by 8 bits, with the lower 4 bits being the room type and the upper 4 bits being the doorways. To map just the room type I would need one card per room (so 16 total) and place it on screen at the appropriate coordinate. Since the floor dimension is 12x12 rooms this fits nicely in the screen dimensions of the Intellivision. I would lose the green border but no big deal. Mapping the doorways would be more difficult since I would need one card for every combination and orientation of room and doorways and load them as necessary. This means I would have to design the quadrants so that no more than 12(?) custom rooms are used per quadrant. This would have to be done for every floor as well, so that's 12*12*4=576 ram locations needed to store all of the generated maps. A lot of rom space would be needed for all the cards as well. A color code would work for special rooms like treasure chests, item shop, and side quest rooms. Gray for empty rooms, green for treasure, etc..

 

Attached is a visual of every quadrant used in the game. The brown squares are doors and the thin grey lines define each room. All quadrants are drawn as if in the northwest corner of the floor.

 

 

What are your thoughts on my approach? Is there a simpler method?

floor_quadrant_plans.zip

Link to comment
Share on other sites

I think you can express all the permutations in only 56 cards, as long as you limit it to only those which are valid. For instance, a closed off room (all walls, no doors and no open corridors) is not valid. Likewise, a door floating in mid-air is not valid -- it must be on a wall.

 

In such a scheme, there are only 14 different types of wall patterns, where each wall could potentially have a door. Here's an example of the breakdown:

 

post-27318-0-38278700-1532536402.jpg

In that example, a square on the grid represents a map cell, and each line around the square represents a wall; a line with a dot represents a door; and a missing line on a side indicates an open corridor.

 

That should fit nicely in GRAM. :)

 

-dZ.

 

 

EDIT: Updated with a missing pattern.

  • Like 1
Link to comment
Share on other sites

Oh, and by the way, in case it wasn't obvious: in the interest of conserving memory, you could put all the burden on the CPU to compose the cards and translate the data structures into the visual map dynamically, on demand. Even if it takes you several frames to do so, that is still a fraction of a second -- certainly a player should be willing to wait that much for his map. ;)

 

dZ.

Link to comment
Share on other sites

Yes, no need to store the maps of all floors

One map at time, composed on fly is fine

If I understand correctly a floor is 12x12 = 36 rooms, and this would be the max amount of ram needed for map display

 

Without complex encoding I would use one word per room

 

4 bits for walls in the 4 directions

4 bits for doors in the 4 directions

4 bits for encoding the room type that could be shown by different colors

1 bit explored/unexplored (show black the unexplored areas)

2 spare bits for your needs

 

If you change floor the map resets

AR

Link to comment
Share on other sites

Yes, no need to store the maps of all floors

One map at time, composed on fly is fine

If I understand correctly a floor is 12x12 = 36 rooms, and this would be the max amount of ram needed for map display

 

Without complex encoding I would use one word per room

 

4 bits for walls in the 4 directions

4 bits for doors in the 4 directions

4 bits for encoding the room type that could be shown by different colors

1 bit explored/unexplored (show black the unexplored areas)

2 spare bits for your needs

 

If you change floor the map resets

AR

Er... 12 x 12 = 144... Or am missing something from your explanation.

 

I agree that only one floor should be displayed at a time (the one the player is in).

Link to comment
Share on other sites

Anyway, probably there is no need of extra memory at all if wall and doors are already represented in ram somehow.

The sole extra bit is explored or not.

You should represent in gram the 53 tiles dz computed and map them according to the inner floor representation

Link to comment
Share on other sites

If you do have automapping. Keep the floor map in ROM. Use a single bit to keep track of which room that you been in. So 12 room on a line, which is 12 bits, then the next line would be 24 bits. You can have 3 bytes per 2 rows, which would take 12 bytes of 8-bit RAM. The map image would be taken from the ROM that is already in ROM. Myself can't understand bitwise stuff.

I tend to try memorize the floor in this type of game because I didn't like writing stuff down for some reason. I got horribly lost in Phantasy Star for the SMS since there's no map in that game, however, I was able to find my way.

 

And, you should add message box routine in event if you open a chest, or the reason the chest not opening that it isn't the right time of the day. Or tell the player that the chest is empty. I was pretty confused.

 

I don't know if it is day time or night time. I need to see if I missed something.

I read the instruction provided. Just now, the color on top right represent the time of the day as I see in the instruction. Maybe have a time on the top of the screen between the floor number and the compass.

I will give this game a play later. I'm looking forward playing the full game.

Link to comment
Share on other sites

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

 

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

 

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

Link to comment
Share on other sites

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