Summoner's Dilemma
This game is from ldjam.com, which is currently unavailable.
You can try viewing the original page on Web Archive (may not load correctly).
You can try viewing the original page on Web Archive (may not load correctly).
*-- Why'd all my stuff disappear? --*
Play on Itch at https://needscoffee.itch.io/summoners-dilemma. Plant, grow, and eat "blooms" to regain mana and reach the highest floor you can before mana runs out. Your specialty -- you can "summon" any item from 24:00 hours in the future, but you'll have to live without the item once you get there.
* Aseprite
* Prelude font by DamienG https://damieng.com/zx-origins
*Orb* -- Slows the rate of mana drain by 50%.
*Clock* -- Slows the rate of time by 50%.
*Pot* -- Grows [ Blooms ] at a rate of one stage every 4:00 hours. Unaffected by the rate of time.
*Spout* -- Increases the growth rate of adjacent [ Blooms ] by 50%.
*Vault* -- Spawns a new [ Bloom ] seed every 4:00 hours.
*Bloom* -- Has five stages of growth, and restores 10 mana when fully grown.
*Altar/Stand* -- Place any item on the [ Altar ], then use the [ Stand ] to grab the same item from the next floor up, 24:00 hours in the future.
First thing to acknowledge -- the game has a very steep difficulty curve, and not in a good way. You're guaranteed to make it to floor 2, getting to floor 3 is a challenge, and I can barely reach floor 4. Aside from bug squashing, I gave myself almost no time to test and adjust the balance of the game, and it shows.
That said, the concept for the project was "what if you could summon items from your future self?" There are a few essential parts to the idea. One -- you need to know *what* items exist in the future (in other words, you need a set number of items). Two -- you need a concept of time or levels, to determine *when* to summon the item from. And three -- there should be a reason for the player to summon those items.
The first step of development was making a grid-based movement system. This was not something I'd done before, and it took a few hours to get right. In particular, I discovered an awkward situation that sometimes came up while turning:
* Say you press the [UP] key to move the character.
* While the character is moving, you press [LEFT] to make a turn.
* You let go of [LEFT] before the character has finished moving [UP].
By default, the character would just ignore the [LEFT] input, which felt bad to me. So I added a buffer to store the next movement whenever A) you pressed a key while already moving, and B) the new direction was different than the old direction (so you don't move forward twice). In hindsight, it was maybe not the best use of time, but it was nice to have some polish in the controls.
Saturday was spent writing the gameplay loop, mechanics, and some UI work. I originally planned to have a single "Summoning Circle" with a UI to select what you wanted to summon. Instead, I went with a "Copy Machine" type approach that felt cleaner, let me limit the controls to a single action button, and didn't require any extra UI work.
A lot of Sunday was spent drawing sprites. I've dabbled in pixel art once or twice, but making a full set of sprites was a new thing for me, and it took longer than expected. I also gave every object instance a different palette so it'd be obvious which instances had been summoned. This was done manually in Aseprite, though I'm sure there's a more systematic way to do that.
The remaining time was a scramble to add animations, floor scrolling, in-game help, a day-night cycle for the background, a start screen, a game-over screen, and other polish. I ran out of time for sound again (third compo in a row), but maybe next time? ¯\\\_(ツ)\_/¯
Ideally, the game would have played like a puzzle game with a time-limit. The player would have to figure out the best combinations of tools to avoid the loss condition as long as possible. But there are a couple issues that I think prevented it from working that way.
First is that the time drain and mana drain are way too steep, so you aren't given time to solve the puzzles in the first place. That would have been an easy fix (just a couple values in the editor) if I had done a little more playtesting.
The other issue, which is harder to fix, is that I didn't give the player much incentive to use the main gimmick. That would have required a few things:
* Interactions that are better (or more interesting) the more of an object you have.
* Losing the object in the future should not make the game unplayable.
* Having the object now has to be more worthwhile than having the object in the future.
The game has some seeds of interest in the first point. I tried to mitigate the second point by having multiple of every item, although the mana drain is so steep that losing anything is pretty detrimental. Point three, though, is the game's weakest point. The only situations I can think of where it makes sense to have an object early are if you A) don't think you'll need the object later (which is sometimes the case when copying "blooms"), or B) if you don't think you'll make it past the next floor anyway.
If I could add new features, I'd probably explore giving the player much more control over the flow of time. Let them pause, slow down, or speed up as needed to solve the puzzles. The game could also use more transparency into how each item works. Overall though, I'm happy to have a completed project.
Play on Itch at https://needscoffee.itch.io/summoners-dilemma. Plant, grow, and eat "blooms" to regain mana and reach the highest floor you can before mana runs out. Your specialty -- you can "summon" any item from 24:00 hours in the future, but you'll have to live without the item once you get there.
Tools & Credits
* Godot 4.2* Aseprite
* Prelude font by DamienG https://damieng.com/zx-origins
Item Descriptions
*Orb* -- Slows the rate of mana drain by 50%.
*Clock* -- Slows the rate of time by 50%.
*Pot* -- Grows [ Blooms ] at a rate of one stage every 4:00 hours. Unaffected by the rate of time.
*Spout* -- Increases the growth rate of adjacent [ Blooms ] by 50%.
*Vault* -- Spawns a new [ Bloom ] seed every 4:00 hours.
*Bloom* -- Has five stages of growth, and restores 10 mana when fully grown.
*Altar/Stand* -- Place any item on the [ Altar ], then use the [ Stand ] to grab the same item from the next floor up, 24:00 hours in the future.
Screenshot
Process & Thoughts
First thing to acknowledge -- the game has a very steep difficulty curve, and not in a good way. You're guaranteed to make it to floor 2, getting to floor 3 is a challenge, and I can barely reach floor 4. Aside from bug squashing, I gave myself almost no time to test and adjust the balance of the game, and it shows.
That said, the concept for the project was "what if you could summon items from your future self?" There are a few essential parts to the idea. One -- you need to know *what* items exist in the future (in other words, you need a set number of items). Two -- you need a concept of time or levels, to determine *when* to summon the item from. And three -- there should be a reason for the player to summon those items.
The first step of development was making a grid-based movement system. This was not something I'd done before, and it took a few hours to get right. In particular, I discovered an awkward situation that sometimes came up while turning:
* Say you press the [UP] key to move the character.
* While the character is moving, you press [LEFT] to make a turn.
* You let go of [LEFT] before the character has finished moving [UP].
By default, the character would just ignore the [LEFT] input, which felt bad to me. So I added a buffer to store the next movement whenever A) you pressed a key while already moving, and B) the new direction was different than the old direction (so you don't move forward twice). In hindsight, it was maybe not the best use of time, but it was nice to have some polish in the controls.
Saturday was spent writing the gameplay loop, mechanics, and some UI work. I originally planned to have a single "Summoning Circle" with a UI to select what you wanted to summon. Instead, I went with a "Copy Machine" type approach that felt cleaner, let me limit the controls to a single action button, and didn't require any extra UI work.
A lot of Sunday was spent drawing sprites. I've dabbled in pixel art once or twice, but making a full set of sprites was a new thing for me, and it took longer than expected. I also gave every object instance a different palette so it'd be obvious which instances had been summoned. This was done manually in Aseprite, though I'm sure there's a more systematic way to do that.
The remaining time was a scramble to add animations, floor scrolling, in-game help, a day-night cycle for the background, a start screen, a game-over screen, and other polish. I ran out of time for sound again (third compo in a row), but maybe next time? ¯\\\_(ツ)\_/¯
Ideally, the game would have played like a puzzle game with a time-limit. The player would have to figure out the best combinations of tools to avoid the loss condition as long as possible. But there are a couple issues that I think prevented it from working that way.
First is that the time drain and mana drain are way too steep, so you aren't given time to solve the puzzles in the first place. That would have been an easy fix (just a couple values in the editor) if I had done a little more playtesting.
The other issue, which is harder to fix, is that I didn't give the player much incentive to use the main gimmick. That would have required a few things:
* Interactions that are better (or more interesting) the more of an object you have.
* Losing the object in the future should not make the game unplayable.
* Having the object now has to be more worthwhile than having the object in the future.
The game has some seeds of interest in the first point. I tried to mitigate the second point by having multiple of every item, although the mana drain is so steep that losing anything is pretty detrimental. Point three, though, is the game's weakest point. The only situations I can think of where it makes sense to have an object early are if you A) don't think you'll need the object later (which is sometimes the case when copying "blooms"), or B) if you don't think you'll make it past the next floor anyway.
If I could add new features, I'd probably explore giving the player much more control over the flow of time. Let them pause, slow down, or speed up as needed to solve the puzzles. The game could also use more transparency into how each item works. Overall though, I'm happy to have a completed project.