Ludum Dare 32 Jam – Weathermage Postmortem
Our ludum dare 32 entry, Weathermage, was the rockiest submission I’ve ever done. It was incredibly ambitious, aiming to combine the gameplay of Divinity: Original Sin, one of my favorite turn-based RPGs, with a vast world inspired by The Elder Scrolls V: Skyrim. In short, we succeeded in this goal, but the journey was rocky and the final implementation clunky.
The theme was “An Unconventional Weapon,” and our idea was to use weather effects as a combat system. This means the player character has no “auto-attacks” – to damage enemies the player must use weather-based skills to trap enemies in hazardous situations. This means in addition to an outdoor environment, we needed a believable weather system.
You don’t create a massive, content-populated world in one weekend, at least not with existing tools. However, we’re getting closer to being able to do so: The level designer we brought on to start on during the warm-up weekend who would work for the entirety of the week up to the jam had been working on a procedural world creation system that could create AAA-quality worlds (with content!) in hours. For us, this jam was a chance to test out what he already had in place, and for him, this was an opportunity to put his system to the test and see how it might be improved moving forward.
We’re quite proud of the level he created, although he had to place a lot of the content manually anyway. I gave the designer a lot of artistic freedom in how the level should look. These were my basic requirements:
- 2 villages.
We ran into some issues with the atmosphere, but eventually settled on a wonderful sky and weather combination asset called Tenkoku. It was actually not released on the asset store in time for the jam, but we were so eager to test it based on previews that we purchased it directly from the creator. It fulfilled all of our needs, but had a few issues in practice that were mostly resolved over the weekend by notifying the developer.
Our team was composed of four people assigned to different roles:
- Myself, UI and content assembly
- Adam Goodrich, level design.
- Jose Contreras, gameplay programming.
- Adam Aagocs, minimap research and development.
This split of tasks was combined with split repositories in source control, meaning the level designer could work on the level without ever needing to do merges with what the programmers were doing. This was great because it allowed us to do a small number of combines instead of constantly merging in a single repo.
The majority of the gameplay was coded and tested in a small prototype scene nowhere on the same scale as our actual level. The minimap was tested with a mocked up terrain we created. Our theory was to integrate everything together within the last 24 hours and then make adjustments where necessary. This didn’t work out as we had hoped, and we learned a hard lesson in scale – what works for a small case may not work for something massive. Our major problems:
- Pathfinding bugs made finishing the game impossible. Our prototype scene was mostly flat except for a small hill. When we moved the game into the actual level, which featured hills, lots of obstacles such as large rocks, and sloped terrain, our pathfinding solution (A* Pathfinding Project) ran into both performance and navmesh grid generation problems. The lack of good local avoidance in A* Pathfinding Project meant that the player character would often have a valid path but not be able to get there due to colliding with an object along the way such as the side of a tree or a rock.
- The minimap only worked for a certain amount of detail. This is because the method we used to generate the minimap involved taking a high resolution image of the entire map and breaking it into chunks. However, I was unsatisfied with the quality of the chunks and requested a more detailed overall image, which led to my computer hitting its RAM limit and us concluding that the only way our method would work is if we had a supercomputer. We ended up scrapping the minimap entirely.
- Tedious enemy placement. I was originally going to manually place each enemy on the map, but when we realized how unbelievably small our enemy (and player character) was compared to the world, we realized it was going to take hours to place them all. Thankfully, our level designer (who also happens to be a very good coder – hire him!) mentioned he would need a dynamic spawn system for his procedural world creation system anyway, so he made one for us. It was a very impressive script that featured both in-editor generation and dynamic spawn, alongside a pooling system that would load enemies based on player proximity.
- Rain puddles looked terrible on actual terrain. Our prototype scene had ‘passable’ puddle formation on the Unity terrain primitive, but when we used it on an actual textured terrain, the effect looks really bad. We had to explore a different method in order to create more ‘natural’ puddles (imperfect circles) and have them use a different material so they would show up better.
The last three issues were not difficult to resolve, but the first one delayed our ‘actual’ submission by two weeks. I ended up submitting a placeholder during the deadline so we wouldn’t miss it entirely. I don’t consider it cheating because our game was playable by the deadline, but it was complete-able due to pathfinding bugs.
Unity Terrain and Pathfinding
There are a number of pathfinding solutions on the Unity Asset Store, but there seemed to be next to little discussion on the Unity forums about pathfinding over large terrains. This is because most Unity games that use pathfinding take place on either square grids (where movement is intentionally restricted by level design) or within special ‘battle’ areas, most of which have a grid layout or do not take place outside. It was only when I realized we might be breaking some new ground with Unity pathfinding on terrain did I realize we might have set the scope of our project too high due to the assumption that ‘pathfinding will just work’.
By the end of the first week after the deadline, we had exhausted the A* Pathfinding Project and started looking for other options. I was very worried at this stage because reimplementing pathfinding would involve setting up new grids and rewriting a lot of code, so it was important that we find a solution that would work so we did not completely miss the judging period. After reading many reviews, I settled on the combination of Apex Path (for pathfinding) and Apex Steer (for local avoidance). We spent a few days setting up the two in a test scene and were very impressed with the speed it calculated paths and local objects. We spent the rest of the second week getting it to work with our massive level, which involved a multiple-grid setup and moving characters from one pathfinding grid to another.
One Week of Ratings
This is the first time I submitted a complete-able entry within the last week. I quickly spend an entire day playing and rating other games so we would show up in the judging area. I rated somewhere around 107 games that day, and I was very exhausted by the end of it. However, I was able to accomplish my goal of getting Weathermage on the radar for those still rating games in the last week, and we got a mix of positive and critical feedback:
Nice, solid composition of the assets to maintain a cohesive style! It took quite a while to understand that the green thing in the top left was pointing me to an enemy, but it was fun exploring in the mean time. The actual battle seemed kind of buggy, it worked but some kind of tutorial or description of how it worked would have been nice since I didn’t get the turn-based-ness of it. But overall it’s a fantastic idea, and I love the idea of using weather as a weapon.
Some people mentioned they had issues running it, which made me realize this may be the first entry out of all ludum dare entries where system requirements should have been specified.
It was unplayable for me due to slow framerate, even on Fastest graphics.
This is a general indicator that our scope was probably too big for a weekend jam, but given my previous track record of ambitious submissions, we’ve always pushed the bounds of what we thought we could do in a single weekend and I didn’t intend to stop with this one.
We got a few comments that every game jam team wants to hear:
I would totally buy this if it were fleshed out and polished! Great work 🙂
Overall, I consider our entry a success even if it does not place high in the ratings due to the low amount of exposure.
We had two team members I had never worked before prior to this event, and both impressed me in their dedication to quality. Moving forward, I would love to work with them in the future, and I’m currently talking to members of the Zems project on how we might bring on the gameplay programmer. However, I would prefer not to ditch Weathermage entirely and to continue working on it (slowly) over time. Things I want to do include:
- Refactor codebase so it doesn’t look like a messy game jam project.
- Switch to a third person camera. Someone mentioned that the top-down camera made the terrain tiling obvious and that the vast beauty of the terrain could not fully be experienced in this perspective.
- Add a party system – multiple player characters in the style of the Dragon Age series.
- More enemy types.
- More weather-based skills, such as raining fire, blizzards, and more.
- Improving current weather effects with better particles. Our puddle formation system is currently ‘passable’ for ludum dare, but I’m still not very satisfied with it because players will notice a pattern over time. I want a more dynamic and random puddle formation/deformation method.
Multiple people have commented that this concept of worthy turning into its own game. I’m not ready to commit to that yet, but I think we have built a solid basis to be explored and iterated upon further.