Skip to main content

Level Design: Simple DnD Map v3

  • Who played your map on its final iteration? (Player names and their chosen class)

  • What went right?

  • What went wrong?

  • How did implementing doors/keys help or hurt your level?

  • How did the players respond to the items introduced?

  • Notable changes that you made from your first iteration.

On the final iteration, the players of my map were Anish and Jewel. Sadly, Kafka was sick on the final iteration test day and so they did not play. Anish chose Warrior and Jewel picked Mage.


Lots of things went right in my playtest! Although having one less player did greatly alter the experience of the level, the playtest still went very well. With a brief explanation, my players were able to fully make use of all the macros/character abilities I had implemented in order to streamline the gameplay, and they were a massive time saver since I didn’t have to calculate the damage numbers myself. The new elements I added to the game like the hares also provided some fun surprises to the players!


Not a lot went wrong in the playtest, however there was a secret item hidden in my level that ended up not being found, although the unfortunate nature of hidden secrets is that they will stay hidden for some players, so I think whether or not that part of the level needs changing would require multiple tests to see how many players are finding it and how many aren’t.


The implementation of doors and keys was pretty smooth in my level. My first iteration had gates that had to be opened with switches, a mechanic that functions very similarly to doors and keys, so my level was already built to support locked doors and keys to open them. While similar, the two mechanics both have different niches, so having both of them in the same level was useful!


When implementing items in my level and removing skills, I knew that I still wanted to have some of the skills still regularly usable by my players, in order to achieve this, I provided my players early on with one healing staff that doesn’t break. This allowed the party to still have reliable healing, but also meant they would have to decide who would be best suited to carry the healing staff. I also had lots of single use items, like health potions that would heal the user to full, and a lucky dice that let you re-roll any undesirable D6 roll. My players were able to make strategic decisions to use these items at the best opportunities!


Probably the most notable change from my first iteration would be the art style. The first version of my level was drawn within the Roll20 editor, but it’s kind of bad. So the next version I used Aseprite to draw my map and all my assets. I decided to go for a simple pixel art style that made it easy to make lots of tokens very quickly! One of the other notable changes was the implementation of macros. My second iteration was the first to use them, but they were a little strange to use and that led to some confusion. In the third iteration, I redid all macros and abilities to be much more intuitive so that I didn’t have to calculate any of the battle numbers myself!

Comments

Post a Comment

Popular posts from this blog

CAGD 373 Blog Post 4

This sprint I was assigned a modular set to create the basic interior rooms out of, with three different textures for the walls. (a Square Brick Texture, a Cement Texture, and a Metal Wall Texture) The actual modeling itself was as basic as it gets, I just made a few different shapes and sizes of wall along with a doorframe, with a couple floors and ceilings to complete the set. The interesting stuff this week was the textures, all of which I made in designer! The brick texture was probably the most complicated, and the one I’m most proud of. Starting with a brick generator, I used some gaussian spots to add some variance to the shape of bricks (using the spots to “cut out” chunks of the perfectly square bricks) and that worked pretty well! After that, I used a grainy looking noise map to fill in the black part of this mask to add in the noisy texture of mortar between bricks Next, to add some color variation to the bricks, I used a flood fill node, which was able to identify all the...
Post a Comment
Read more

Video Game Production Sprint 1

  After a long time spent away from Unreal Engine, I’m getting my hands dirty once again as a programmer for the Kill Everything in Sight team! KEIS is an endless action FPS roguelite where you play as a killer robot tasked with exterminating the remains of the human race. Despite your incredible movement and combat abilities, you are severely limited by a timer ticking down during the entirety of your run. Killing enemies will add precious grains of sand to your cruel hourglass, so the player must focus on speed just as much as precision! I was brought on the team as a programmer, and I started off very nervous since it's been a while since I last programmed in Unreal. On top of that, my first task was to create the foundation of our enemy AI, probably the most critical gameplay element after the player and level design, and I haven’t touched AI in Unreal outside the absolute basics! However, I was determined to make my team proud and confident in my ability to learn quickly...
Post a Comment
Read more

Idle WitchCraft Sprint 4

  This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line. Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm! This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate inf...
Post a Comment
Read more