top of page

Wiz Biz: A Summons' Sacrifice

This project was created for the Ludum Dare 55 game jam in 72 hours. On this project I focused on designing the mechanics and levels.

63f84.png

This project had a couple constraints. Ludum Dare 55's theme was summoning and the entire project had to be complete within 72 hours. Additionally, my team had 2 other members which handled the art and main programming that the game required.

Day 1: Finding an idea

Day 1 the majority of our time was focused on getting a strong idea for the game. We begun with some brainstorming sessions on a whiteboard at our college. We tried to look at different ways summoning could be interpreted. A king's summons, or maybe you were trying to avoid being picked as a wizard's familiar. We really liked the idea of how wizard's often mistreat their familiar in many fantasy settings and DnD campaigns so we used that as a starting point. There were many ideas pitched and explored, but ultimately we decided to go with a simple game where summoning familiars would help you solve puzzles and traverse dangerous levels.

At this point it was my job to figure out how the summons worked, what they did and how they helped the player progress. I began listing out characteristics each summon could have and how that could change gameplay. For example, maybe one of the summons was carrying a tough stone on it's back which could allow them to jam spinning fans. I came up with a long list of these and the team picked a bunch we liked. At this point we decided a couple pillars of the game, "Summons do the work" and "Summons are expendable".

20240413_011551.jpg

Day 2: Fixing the idea & making it

Day 2 was a bit more complicated. The team already felt overwhelmed with all the ideas we had planned for the game. The list of things summons could do came out to a total of 12 different game changing mechanics over 3 different summon types. It's safe to say we were already worried about scope. So, I began redesigning to reduce scope. I reduced the planned summons down to 2 and began focusing more closely on our game pillars. One of the problems with the old system was that most of the ideas we had for the summons enabled the main character to do great things. The would add to the platforming aspect and increase the player character's toolkit. My new system tried to focus on the interactions the summons could have in the game. 

The redesign is as follows. The wizard (player) can only summon within a radius around them and they must maintain line of sight with their summon. The wizard then mind controls the summon until that sight link is broken, upon which the summon goes dormant. Additionally, I changed the summons's capabilities a bit so they would be exploited more often for the wizard to complete their tasks. I pitched a fluffy summon which could be thrown onto spikes to create a platform as an example. This new direction focused on the summons and their uses and the team loved it. This was our new direction for the game moving forward. I finished up the day ironing out all the level and summon mechanics and then began to do some level designs in Miro using our planned grid size as a template. For level design I used a Kishōtenketsu structure by progressively teach, test and twisting the mechanics to the player. I feel this approach made our game easy to learn and made the flow of difficulty feel appropriate (at least for a 72 hour game jam).

SS wiz biz 1.jpg

Day 3: Build it all!

Day 3 was a race to the finish. Over the night of the 2nd day I planned where I was going to teach each mechanic the game has which resulted in 13 total puzzle screens. However our programmer needed some help this day fixing bugs so the first few hours of work I did were committed to fixing the player controller while they got the summoning logic working. After that it was smooth sailing! Okay maybe not exactly, but we got the bulk of the game built after that. Many levels needed to be tweaked as I built them due to the metrics of the game being implemented slightly different than I imagined. This was a failure to communicate on my part. The entire game was planned to rely on a certain speed the player could move and a certain height they could jump, but the main programmer was unaware of this. Aside from that though I felt my Miro planning pay off big time! Many of the puzzles worked and were actually feeling pretty good. I dragged a few friends over to try our most recent build because at this point I was the only one who had played my levels. I learned a lot but overall we didn't find any major exploits and there were a lots of laughs at the exploitation of these poor summons. It felt great and really energized me to complete the project!

We finished our little puzzle game and submitted to the jam. Overall this was a great experience for my first time working with this group. Also this was my first 2D puzzle game I designed for and I LOVED it. I spent so many hours testing puzzles and thinking of new ways summons could interact. If I was to do the whole thing over again I would definitely try and communicate my metric intentions with the other members a bit more clearly, that would've saved a lot of time... 

ss1.jpg
bottom of page