Week 1 Devlog (posted later)

Please note this post was accidentally hidden and never posted when it was supposed to be (June 2024)
I only noticed when checking my itch.io profile and saw an unshared post

Intro

For the One Game a Month game jam I have been working on a new project - building a triple triad inspired card game. This is a devlog for the first week of progress on what I’m calling Masquercarde.

During this week I learned, or rather, cemented, three things that I think every game developer should know. The importance of information, the importance of getting it done, and the KISS principle. I’ll talk more about these things at the end of the video but let’s get to what I’m building.

Inspiration

Triple Triad was an absolute addiction of my childhood, a minigame present in Final Fantasy 8 which I probably spent more time playing than the actual game. It’s a relatively simple game where two players take turns placing a card on a 3 by 3 board. These cards then flip previously placed cards based on their relative attack values. There are a bunch of ‘extra’ rules in the game as  well, from causing chain reactions to modifying how attacks or tied scores are resolved, but those aren’t my focus.

I’m looking to take that basic mechanic and then expand on it as much as I’m able to in this one month constraint. The game jam has a theme for the month of ‘celebrations’ so I’ve decided to theme the game around a masquerade ball, a fancy party full of nobles who try to charm, intimidate, or deceive each other to ‘their side’.

Day 1

On my first day I kept getting very distracted - every time I sat down something popped up to take my attention away from development. By the time I’d actually finished all I had was the initial board, which was much bigger than I initially planned. It took a couple of revisions to end up with something I like, and I definitely over complicated things to begin with. In the end I ultimately ended up using Godot’s inbuilt grid-container to automatically arrange things in, well, a grid. This was much simpler since I was already using user interface control nodes for everything, and prevented a bunch of edge cases by trying to arrange everything myself.

There’s a lesson to be learned when working under time constraints - stop trying to future proof every thing. It’s alright just to build what you’re looking to build right now. Get it done, then get it perfect later. Time is the most valuable resource a solo developer has and you will never have enough to do everything you want to do. Game development is typically a very bespoke field and many game developers make the mistake of trying to reinvent the wheel (and I’ll confess I’m often doing that myself) when existing solutions are just as functional. Get it working, everything else comes later.

Day 2

Moving into the second day I was determined to make up for lost time spent building the game board. By the end of the day I had working test cards and even a card preview window that would display when the cards were highlighted on the board. I revised the board size to be slightly smaller than originally planned, but still much bigger than Triple Triad’s board.

My reasoning for the larger board is that Triple Triad games are usually very short, and I’d like a match of Masquercarde to take a little longer. In addition, my cards have eight directions they can potentially attack, rather than just four. That means you need a larger board space to actually make those eight directions tactically entertaining rather than constantly just attacking everything at once. The board size will possibly need some revision after playtesting, but I’m happy with where it is right now.

Even though I had a lot more time, I did get distracted somewhat on day 2. This game jam is the first time I’m using Godot 4 however, as my personal project is still on Godot 3.5, so the framework I built for prototyping doesn’t work with Godot 4. This meant that I had to quickly build a barebones version of some of my logger functionality so my muscle memory didn’t keep typing ‘GlobalLog’ everytime I wanted to store a debugging message. This took a little bit of time 

Day 3

Into day 3 I started thinking about the player hud. I’d already put in a preview window but I wasn’t sure where I wanted other hud elements to go. This game was actually my second idea for the game jam and somehow I managed to sketch a game layout for the first game, but not this one. There’s another lesson, because I spent quite a while thinking about proper layout and whether I should move or change the game board again. A lot of the early days were spent second-guessing things and eventually I had to just cut myself off and say ‘nope, this is what we’re trying, change it after testing if you don’t like it’.

Key features for day 3 included a proper turn system and turn order, giving the cards the ability to attack each other to steal cards, identifying who owned which card with a coloured border, and a score system that tracked who owned the most cards. I was pretty proud of how the capture animation played, giving the appearance of flipping the card just by inverting the x axis of the texture and adjusting the position, but a notable bug here is that the attack behaviour isn’t checking for who owns the card. I didn’t catch this until a couple of days later, but players can attack their own cards. It doesn’t make any gameplay difference, they still own the same number of cards, but it does look a bit silly.

Day 4 & 5

Day 4 & 5 might as well be the same day because this was one of those annoying times when real-life got in the way of development. Throughout two whole days I was solely working on the cards that went in the players hand, and the animations that went with them. I started looking at other solutions for managing cards but I found most card game frameworks too complicated for my needs. Animating things myself was actually the faster solution this time around, and I was very pleased with how it turned out.

Adding in dragging and dropping functionality really helped start making the game feel like the game I wanted to build, and I was finally able to remove the ‘click to place’ test behaviour.

Day 6

Going into day 6 I had a big game design problem.

Something that hasn’t really been shown so far is that cards are going to have an attack type. Every card is going to attack through either charm, intimidation, or deception. Unlike triple triad the cards aren’t going to flip each other by comparing attack values, but rather comparing their attack values to a defence value that applies in any direction. This originally felt necessary to add tactical flavour, but by the time I’d gotten a semi-functional prototype, it just felt confusing.

I started brainstorming what changes I could make to make things simpler, but everything I devised just seemed to have its own problems. Should I get rid of defence and attack types entirely, switching back to a purely triple triad version? That seemed to be less of an homage and more of a direct clone. Triple Triad already exists, and a larger board wasn’t enough difference to make my game stand out. Should I make attackers have different attack types per attack direction? That immediately seemed too confusing. The game board would be a blur of differently coloured numbers and difficult to discern at a glance. I discarded that idea but it did lead me to the question I should be asking.

Why does it feel confusing? My key basis for the game seeming confusing was that the defence numbers were somewhat obfuscated. You could see them in the preview window but the attack numbers were present when you moused over the card. I’d already added a small preview on the board cards showing each defence, but it was small and not overly useful when trying to place cards - it showed every defence type when cards only had one attack type each.

The answer was actually really simple. Just improve the visibility of information for the player. I added a larger defence value that appears when dragging a card to place, and a sword icon that shows which nearby cards will be captured if you place a card on that cell. I then improved the drag preview to actually show attack numbers. These three relatively minor improvements to communicating game information transformed how it felt to place cards. Suddenly I could place cards accurately and quickly without having to think too deeply about where. You could still use the hotkey to show all attack values, mouse over for detailed previews, or read the on-card defence values, but if your goal was just to place a card as quickly as possible you could do that too.

Conclusion

My key takeaways from this week were three things that I think every game jam developer should know.

1. Firstly - keep it simple stupid. Aggressively de-scope anything that doesn’t fit the core game loop when you’re building that first prototype. Originally I wanted to have special cards played directly from the hand, and a yu gi-oh style system of placing cards face-down on the board. Those things still might make it in, in future, but they’re not relevant right now. Trying to complicate the game, adding multiple attack and defence types, cost me nearly a day in design pontification.
2. Secondly - get it done. I spent a lot of time wondering about the best or perfect solution, the solution that would require the least work overall and be the most adaptable in the long-run. This is the mindset of an engineer working at a big company, when you’re developing a game, particularly if you’re a solo developer, you need to adapt to start-up company energy. Build whatever you need as quickly as you can, and if there’s a problem later you’ll fix it when it becomes pressing. Make peace with the fact that this one day might cost you more time in implementing something overall, because in the long-run you’re going to save a whole heap of time overall if you’re just building things. Iteration is the path to mastery after all.
3. Thirdly - the importance of information. Perfectly understandable ideas become impossibly complex if you aren’t communicating the correct information to your players. Make sure you’re giving players the information they need in an easy and quick to digest manner. Unless you’re building a deep 4x strategy game players won’t go hunting for how to play your game, particularly early players. Reduce the resistance that players have to actually playing your game.

This was just the first week of game jam development, and there are three more of these videos to come. Hopefully you can see the game starting to take shape, and I’ll be aiming to put a prototype online in the coming week if you’re interested in playing.

I want to give a big shout-out to the one game a month discord, who have been a really fantastic environment for nurturing game developers. If you’re at all interested in game development I encourage you to check them out.

If you got this far, thanks for watching! Subscribe to get notified of future dev logs.