About Exeneva


Ludum Dare 35
Ludum Dare 32
Ludum Dare 30
Ludum Dare 29

Exeneva's Trophies

Exeneva's Archive

Ludum Dare 32 – Weathermage Postmortem

Posted by
Thursday, May 7th, 2015 2:17 am

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.

Warm-Up Weekend

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.

The world of weathermage.

The world of Weathermage.

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.
  • Waterfall.
  • Lake.
  • Forests.
  • Mountains.

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.

The game centers around combining weather effects like shooting ice to freeze a puddle of water and everything in it.

The game centers around combining weather effects like shooting ice to freeze everything in a wet area.

The Weekend

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.

The character's path was valid according to our pathfinder, but she could not actually move over there due to collision.

The path was valid according to our pathfinder, but the character could not actually move there due to collision.

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.

Moving Forward

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.

Cohack – Our Ludum Dare 30 Postmortem

Posted by
Tuesday, August 26th, 2014 2:45 pm

Ludum Dare 30 was a success.

The prototype we made, as specified in one of my personal blog posts, is a modern retake on Shockwave game Spybot: The Nightfall Incident.

Gameplay Screenshot

It features two abilities inspired by the “bug” program in Spybot (I forget the name): Add tile and remove tile. The basic idea is that enemies are scattered on different ‘islands’ and you have to build paths to get to them or remove paths to block them off.


The prototype was developed by four people, although sound effects were created by audio composer Rich Douglas from the previous 2D version of the project mentioned here: http://www.exeneva.com/2013/08/cohack-a-reimagination-of-spybot-the-nightfall-incident/

Ultimately, the jam went very well. I’m going to keep this postmortem short and highlight the main points of what worked out for us.

Team Logistics

I believe the key to teams is having a manager. When the team is more than three people, having one person who is in charge of overseeing the project is important. This keeps people from sending a file to all team members or not knowing who to turn to when something is in question. This manager would also be in charge of logistics and balancing the work schedules of other team members. I was the team manager for this project, and here are the things I did to keep everyone together:

  • Brainstorming. Since I was working with two people I found on Reddit, it was important for me to find out what timezones the team worked in. For this LD, the team was scattered all over the world and I’m pretty sure I sacrificed the most sleep to keep things together. For me, it was important to know a.) timezones and b.) general ‘work hours’ since everyone was doing this on their free time.
  • Kickoff Solidarity. We knew that ‘Connected Worlds’ was the most-voted theme leading up to the event, so we started brainstorming ideas a few days before. When the theme turned out to be what we expected, we made a quick Skype call to share ideas and come up with what we considered ‘core’ and what is considered ‘extra’, this way everyone knew what we were working on first and what the bare minimum of our submission was intended to be.
  • Prioritizing. This is my third time participating in LD, and one of the things I’m personally good at is maintaining scope. The first LD I participated in was a heck of a mess in the first hour, with people putting down ideas without really solidifying what the ‘core game’ was going to be. For the last LD and this one, I made sure the team remained focused on agreeing upon a ‘core’ and then voting on what ‘extras’ were most important. For example, the minimap at the bottom right was the most agreed upon ‘extra’ in a big list of ideas, and because we had a list of priorities we were able to incorporate it and keep the project as a whole from ever getting sidetracked.
  • Wrap-Up. The final 12 hours of a jam can be very stressful. Team members who aren’t programmers are generally worried whether the project is going to be finished because they aren’t a part of the final building process (creating the executable or web-playable version). Again, this is where the manager comes in: I was able to tell team members ‘Ok here’s where we are, here’s what I expect by the time you wake up, which will be after the submission period’. I think everyone on my team who had to sign off before submission did so without any worry.

There’s not a lot that went wrong with this jam and I’m very confident that the December jam will be just as smooth. We plan to continue working on this game after the jam, renaming it Cohack: Nightfall in reference to Spybot: The Nightfall Incident. If you’re interested, feel free to follow us on social media:

Facebook: http://facebook.com/cohacknightfall

Twitter: http://twitter.com/cohacknightfall

We also have a working design document that anyone can comment on if they would like to give suggestions for the game: http://goo.gl/OWtsgb

Please check out our ludum dare entry and tell us what you think!

An Online CCG – Beneath the Sea Edition!

Posted by
Monday, April 28th, 2014 6:03 pm

For our entry into the jam, we’ve created an online CCG with matchmaking and single player (with optional tutorial). While we weren’t able to implement all the cards we wanted, most of them are working and we’re quite proud of what we have been able to accomplish. Play the game here: http://goo.gl/T6jy9M





Messy UI, but art has been integrated.

Posted by
Saturday, April 26th, 2014 8:12 pm

LD29 Main Menu Mockup

Posted by
Saturday, April 26th, 2014 5:00 pm

Putting Card Illustrations Into the Card Templates

Posted by
Friday, April 25th, 2014 11:53 pm

[cache: storing page]