The past week has been pretty crazy for me. This game, Mead & Might, is my entry for my first ever gamejam. I have always wanted to participate in a gamejam since I started learning game development a year ago, but sadly never had the opportunity due to my work-life over the past year. While I was working on another roguelike game that was supposed to be my first commercial game, which is now scrapped due to way too many issues that would require the game to be rebuilt from the ground up, I discovered the 7DRL... and man, was I excited to get my feet wet.

I have to admit, I was lucky enough to take the week off from work to focus exclusively on the developing this game. I couldn't imagine what it must be like to participate in a gamejam while working full-time hours. Even after an estimated 70 hours put into developing this game, I was working up until what felt like the last minute.  Although, I blame scope creep for some of the features I added. But I got it done! and I'm feeling pretty good about the game I made in such a short time.

Inspiration for the game, and why I scrapped my first idea

In the month prior to the gamejam I was playing a lot of Bauldur's Gate 3, and I felt really inspired by ttRPGs and the cRPG genre in general. I loved the feeling of having combat mechanics that were resolved by rolling a d20, let alone the strategic, turn-based combat in BG3. I was feeling pretty inspired to make a roguelike with ttRPG mechanics. Something like D&D, even though I've never played D&D and the closest I've been to it was BG3. So my plan was simple, or so I thought. I want to make a turn-based dungeon crawler with ttRPG mechanics. Like a bite-sized BG3. Buuuut I later realized that the scope I had for this game was way too big to be completed in a week. My ego nearly got the best of me, because I was trying to convince myself that it was possible. And... maybe it is? But there had to be a better game that was more manageable in that timeframe.

So one night I was playing some Bauldur's Gate and finally reached the 3rd act. I won't spoil anything here about the story, but lets just say I went to a tavern and suddenly, that medieval tavern music started playing, and the idea of which direction I should go for the gamejam hit me like a ton of bricks. "What if I made a board game? But the game made you feel like you were playing a board game in a medieval tavern?"

I loved the idea so much I couldn't stop thinking about it. I immediately began brainstorming of how I would make this roguelike board game that was fitting for that medieval fantasy setting. The first game that came to my mind was Triple Triad from Final Fantasy 8. I'm not sure why. I haven't played FF8 since I was a kid, but for some reason that little card game has always stuck with me. But I obviously couldn't just copy the game. I needed to twist it into something unique.

If you don't know what triple triad is, the rules are quite simple. The game is played using cards of various characters and monsters from final fantasy 8. The board is a 3x3 grid, kind of like a tic-tac-toe board, and each card has numerical values on each side of the card. If you place a card that has 6 on the right side, it's compared to the number on the left-side of that card to see if your card can beat it. If your card has a higher number, that card is then flipped and considered to be "under your control" so to speak. The player who has control of the most cards on the table at the end of the match, wins. And the coolest part was that if you won, you typically got to choose one of your opponents cards to add to your collection. And of course if you lost, then your opponent gets one of your cards.

So building from this I decided the 4 different values on a card might have required too much coding. So to keep it simple I decided that my units would have an attack stat and a defense stat. And, if your unit had higher attack than the defense of adjacent units, you take control of those units. The defense stat was later changed to health to make things more interesting. I wanted to give the player a chance take control of a unit by attacking with multiple units of their own, if for example it was a tougher unit. 

I also decided to make my grid hexagonal because having to think about 6 different directions of attacking and defending added to the strategy. And from that shape I imagined using D&D-style tokens instead of using something like a card. Seemed simple enough, since we were able to use asset packs or assets from other games. To make the tokens, I took my basic chibi model, which looks like trash but it will do, and modified it over, and over, and over again until I had about 28 tokens. Seemed like a good amount for a small gamejam.

On to phase 1 (Setting up the assets and basic mechanics)

Day 1 was full of making the art assets for the game and getting all the tokens and the tavern set-up in Godot. I get to do much for coding the first day since the process of setting up 28 individual scenes for the tokens was pretty time consuming. But the next day I was able to get some of the game fundamentals established. I wrote some code to choose and move some tokens, then a script to resolve their damage to adjacent enemies based on their range. This was pretty simple since I was able to use the same scripts for all of the tokens. 

While I didn't have any AI or turn system established at this point, I was able to test out the vision for the game by playing for the AI. So I fired up the game, fought with myself, and realized there was a glaring problem... the game was dreadfully boring. Majority of the time, the tokens were just trading with each other. I place a black token down, then kill it off with a white token. Then my black token kills that white token, and so on. Basically, whoever went first was the loser. 

Need more substance (Expanding classes and the terrain)

At this point, there wasn't much substance to my plan. It definitely felt very flat in terms of strategical depth, which wasn't quite what I was hoping for.  Luckily for me, I already had the tokens organized in this sort of class system. I wasn't planning on doing much with it originally. It was just there to help me design enough tokens with different rarities, or strengths. At this point, I basically had the class systems divided between defensive, glass cannons, and balanced tokens. However, it gave me the idea to expand on the class system a little further.

While I didn't have any special abilities, per se, like a normal RPG, I felt like the classes needed to resolve their attacks differently from one another to add some strategical depth. For example, the "humans" class, seemed to all be sort of healers anyways, even though at this point there wasn't any healing mechanics in the game. And the elves, were all modeled after assassins and dexterity-based characters in an RPG. The "warrior" class I wanted to be a defensive unit in the first place, used to protect your units on the board. And so on so forth, I'll spare you the details of how each class works in the final version, but basically, I expanded the gameplay to give more strategic depth.

Next, I decided to change up the board using perlin noise to give each tile a little more significance. I had been playing around with some "minecraft clone" tutorials prior to starting the gamejam to learn about voxel world generation, which originally was going to be used in my gamejam idea that I scrapped. But this seemed like the perfect place for it. Like minecraft, I added some terrain and objects on the board. I decided to have one noise map that impacted the height of the grid cells, which was later adapted to the damage modifier as well. And then created a secondary noise map for the terrain, which I also adapted to the health modifiers of each grid cell. The main node generates a random number for a seed, then that seed is passed through each function within the cells to create a smooth looking terrain.

This also worked out perfectly, because when the grid was completely flat, the modifier numbers visible on each cell was incredibly overwhelming. I didn't realize I was doing this at the time I hooked those numbers up to the noise maps, but it made the board easier to work with. Since the attack modifiers were based on the height map, it became clear that the higher the cell was the more of a damage buff it provided. Likewise, the terrain made it easier to follow the health buffs. Dark grass provides buffs to the health and sand hurts your tokens. 

The system worked out really well for balancing out the assassin class as well. Since they return to the owner's collection at the end of the turn, it made it impossible to kill them. However, if you are worried about an assassin one-shotting your valued legendary token, you could put them in a space surrounded by sand. Assassins, since they only have 1 health, can't be placed in the sand, or they will instantly die. Gotta love when a game balances itself out without you even realizing it.

AI, AI, and AI (AI turn mechanics and proc gen collections)

At this point I've got a decent game going. The AI was pretty basic just for testing purposes. I wrote a simple AI script that randomly selects a prepared enemy unit, then searches for any grid cells within 1 unit away from your placed tokens. All these grid cells are shoved into an array then chosen at random for the AI to choose which grid cell to move to. If there aren't any of those grid cells available... well then the AI just chooses a random grid cell on the board and throws its token out there. This led to some pretty funny moments when the AI would move it's legendary assassin token to a tile in the sand. Keep in mind, assassins die instantly in the sand. So... free assassin for me. Thanks bro!

One of the biggest challenges I had to face with the AI was increasing the difficulty of each opponent. Since the tokens are divided into different rarities (common, uncommon, rare, and legendary), each rarity has higher stats than the tokens of lesser value. So, I wanted the AI to randomly generate a collection of tokens, while creating this bell curve overtime like you would see in TCG games. That is to say, overtime, the AI should be progressively drawing more tokens with a higher rarity, and less tokens of the more common rarity.

I'm not quite sure if I established the bell curve but I did something. The solution I came up with is to check the probabilities of each token rarity at the start of each match. If, for example, the probability of drawing an uncommon token is less than a common token, some of that percentage is removed from the common token probability and added to the uncommon token probability. This creates a sort of trickle effect where the rarer probabilities are gradually being filled up, while the more common probabilities are being depleted.

That might sound a little confusing, so let me put it simply. Imagine stacking four plastic tubs in the sink on top of each other. Each container has a hole poked in the bottom so that when filled up with water it gradually leaks into the container below. This creates the trickle down effect that will eventually leave the top container empty, and the bottom container full given enough time.

Or to explain it in coding terms:

if a > b: 

 a - 0.1 

b+ 0.1

and so on...

At this point I'll mention that I later improved the AI to use units correctly, as well. The AI script is broken down into different functions that act differently for each class. For example, if the AI chooses a healer, it searches for a cell space within 1 unit of distance of an ally token. If no allies are on the board, it chooses a new token. Likewise, if the AI chooses an elf, it will search for a grid space within 1 unit of your tokens that has a health modifier of 0 or above. If no option is available, it chooses a new token. Since these tokens are only played under certain circumstances, I created some booleans that are like switches to tell the AI that it's already tried to move an elf or healer. If both of these bools are true, then it just places a unit on a random cell to prevent the AI from getting stuck.

Overall though, all the other classes are pretty much the same script. The AI prioritizes objectives, and if there aren't any grid cells available within range, it will look for a grid cell within range of your tokens. If neither of these options are available, it will just randomly pick an available cell to place the token.

Side objectives (IE: the run progression)

At this point I had the foundation of the game laid out and... it was quite fun. But there was another slight issue with the game. Most of the fighting and battles seemed to stay around the same area, depending on where the first token was usually placed. This was a little... boring... to say the least. So I needed something else on the map to pressure the players (IE: you and the AI) to place tokens in other areas for other battles to take place. This is where I came up with the four objectives that randomly spawn on the map. 

The goal for the objectives was to create multiple battles happening at once. Plus, increase the stakes a little bit. Seriously, I've lost runs due to the opponent getting the last hit on the vanquisher. Also, I needed to make the game feel a little more roguelike besides procedural generation and the token trading mechanic. Most roguelikes that I've played had some sort of reward system. You clear out a room, and maybe you get a potion? or some gold? Either way, I didn't quite like that idea for this game. I'm not sure why, it would have worked fine but I wanted something more impactful. 

So instead of giving the player rewards after each match, I decided to work the rewards into board. The catch is... the player who last hits the objective gets the reward. So, you could, possibly, miss out on a new token if the AI last hits the chest. By now, you've probably realized I'm a masochist. But aren't all roguelike players? Anyways, the system felt really good. There's no saving a potion or scroll for later use. There's a sense of urgency to get these upgrades before the AI does, otherwise your run could be over. I'm hoping to expand on these upgrades in the future, but for the gamejam, I kept it simple.

The paint (final touch ups)

There's not much more to say about the game I don't think. At this point I had the foundation of the game and it was down to the coat of paint and tightening up some loose screws. I did everything I could to make the game "feel" like you were playing a board game in a tavern. The music, the ambiance of the crowd talking, the 3D assets of the tankards, tables, and chairs in the background. All these try to capture that feel of actually being in a tavern. Also, the crowd clapping when you win.

I also added some game juice to the game to make it a little more exciting. I put some screen shake affects that trigger when a token is defeated, and added some particle effects and floating damage text that instantiates when the attack is resolved. Also, some more sound affects for placing the tokens that differs for each class, which I thought was pretty fun.

The last 24 hours was basically spent adding some unnecessary, but fun quality of life stuff. I added the leaderboard which I've never done before, but was a lot easier than I had imagined thanks to the SilentWolf plugin for Godot. I also made a kick-ass options menu to adjust the volume of all the sound buses. And I say kick-ass because I love the d20 dice I used to display the values of each sound bus. I also added some graphics options, like turning off the fog and shadows, so that there wont be any issues, hopefully, for older systems to run the game. If there are, then I'll work on addressing this further.

If you made it this far into the devlog, I appreciate you. I know this devlog was pretty long but I did a terrible job at documenting the process  while making the game, so I tried to recapture all the thoughts I had during the development process. Overall, I'm incredibly happy with the game, and hope that everyone enjoys it. I plan on expanding this game in the future, but I want to move over to Unreal Engine moving forward, which means this game will need to be rebuilt when I learn more C++.

Thank you to anyone who supports the project,

Nauti