Dice Battle Game Prototype with LÖVE
Creating a Dice Battle Game Prototype (open-source) with LÖVE and Windsurf (AI Agentic IDE)
Two weeks ago, I was reading up on LÖVE, a lightweight 2D game framework that's come back to the spotlight thanks to it being used to build recent indie successes like Balatro, Arco, and Gravity Circuit, and Moonring. It being the valentine's day week, I thought it'd be fun to make a quick prototype with the LÖVE framework to test out how good an agentic coding IDE can be at building games.
As with my last project, I used Windsurf IDE (models: Claude 3.5 Sonnet + Cascade Base). The game design is fairly simple. Two players battle each other on a hexagon grid. Each turn, a player rolls 3 dice, and move the 3 dice into Movement, Attack, and Defend slots. The core decision for the player is deciding how to allocate the numbers they get from the dice rolls.
After getting a basic scene running with a dice rolling mechanism. I used this initial prompt to start with the basic game design:
...I now want this to be a 2 player game. Here's how it should work:
- players are placed on a 6x6 hexagon grid board
- the player can use the dice roll for movement, attack, or defence
- there are 3 types of hexagon tiles. a normal tile that doesn't do anythin. an attack tile that doubles an attack if the player is standing on it. a defence tile that reduces an attack by half if the player is standing on it.
- there are about the same number of the different types of tiles on the board
- players start with 21 hit points
- on each turn, the player rolls 3 dies
- after they roll the dies, they can drag and drop each die into the movement, attack, and defend slots
- they can move the number of tiles equal to the number on the dice in the movement slot
- if they are next to the opponent after the move, they can attack the amount and apply the amount of damage to the opponent equal to the number of dice in the attack slot
- if they are attacked by the opponent in the opponent's next turn, the damage they take is reduced by the number in the defense slot
- not the attack and defense numbers are impacted by the tiles they stand onI like using bullet lists in my prompts. It helps me organise my thinking, and anecdotally it's been more effective working with language models.
As before, I ask the agent to keep a running changelog for both me to remember what's been worked on, and for the agent to remember what's been done.
I set up a .windsurfrules file to guide the AI agent with rules and links to documentations.
# Windsurf Rules for Love Dice Game
### Code Style
- Make sure to remove any unnecessary extra `end` statement to avoid Syntax error: '<eof>' expected near 'end'
- Make sure to have enough `end` statement to avoid Error: Syntax error: 'end' expected near '<eof>'
- Make sure your code satisfy all requirements and only the requirements provided
- Review your code and ask yourself these questions:
- Is this code efficient?
- Can you make it shorter?
- Are you able to make it more maintainable?
- Do we need all of the functions you have outlined?
### Memory Management
1. All memories must be saved in the /memory-bank/ folder
2. Use markdown format for all memory files
3. Update existing memory files when their content changes
4. Create new memory files for new categories of information
5. Memory files should follow the naming convention: descriptive_name.md
6. Each memory file should have:
- Clear title and sections
- Dated entries where relevant
- Links to related memories if applicable
### Changelog Management
- Each release must have a new line after it
- Include release version and date for each entry
- Follow format: ## [VERSION] - YYYY-MM-DD
### Documentation Links
- Love2D documentation: https://www.love2d.org/wiki/Main_Page
- LUA: https://www.lua.org/manual/5.4/manual.htmlI noticed it kept making the same syntax mistakes, perhaps due to lack of training on love2d projects or the lua language, so I added a few rules at the top of this file. Unfortunately it still keep making the same syntax mistakes more often than I'd like. It's usually a pretty quick fix once I point that out but annoying nonetheless.
I also started generating memory files (in markdown format) and saving them in a /memory-bank/ folder. I work on two different devices. The internal memories are not part of the repository, so to continue working on the project on a difference device, I needed the memories to be essentially exported and synchronised as part of the repository. This might reduce the need to keep a changelog - but for the time being I am doing both to have more context for the AI to understand the project.
I wanted this project to be small with a very narrow scope. My initial plan was to wrap it up in 2 days. It ended up taking more than double the amount of the time. Getting the core system up and working was fairly quick, but making the UI and control exactly how I designed took a lot longer. One key difference between this project and my browser extension project was the time it takes to test the app. The game has various states that a player can be in, and it takes time to get to those states once a game has started for me to test any changes. I should have written programmatic testing along the way. But even with that, sometimes you have to manually use the product to decide if certain UX works.
As with the last project, UI/UX work took up the majority of time. Windsurf IDE/Claude3.5 struggled with UI tweaks in the LÖVE framework quite a number of times and I had to find solutions myself before asking it to implement in multiple occasions.
And I definitely spent way too much time testing out different dice rolling mechanics and animations. At one point, trying to get them represented in 3D in a 2D framework! To be fair, the AI agent did a decent job calculating the necessary math to create 3D dice but had trouble managing the position/scale/rotation dots on the different faces in 3D.
Once I have the prototype working as intended, I playtested it and realised there's a dominant strategy for this 1v1 game where you are almost always better off using. If you are making a game, make sure you playtest early and playtest often. My player brain always outsmarts my designer brain!
I ended up adding a secondary objective into the game where players can pickup health potion to gives players another thing to consider when making decisions. This also added additional time to the project.
Two of my biggest takeaways are:
Focus on the core — this is the advice I tell people whenever they start a new project. Focus on what matters. But it's easier to give advice than to follow them. I spent way too much time on dice animations when I was working on this when in the end a simple visual effect was all I needed
Refactor early and often, especially when working with AI — because the project was meant to be small and quick, I didn't spend any time structuring the code or refactoring it. By the time I realised there are too many sub-systems and states to all be in one file, it had become too large of a file for AI agents to easily refactor. A few attempts yielded disappointing results when I ask the agent to refactor the code.
Again, you can find the files and the executables here:
Github Repo: https://github.com/theBrandonWu/love-dice-game
Itch.io (download): https://thebrandonwu.itch.io/die-die-dice
On the gameplay side, I think there's something interesting here where there's an element of luck and a strategic element, which makes for a fun and interesting multiplayer setup. It's a game design I'd like to keep working on, but most likely going to a framework or game engine I am more familiar with.