A short tongue-in-cheek adventure game about fighting Chaos with Jelly!
Solve problems for weird characters, laugh at/with the snarky main character, and be horrified by the pixel art.
Plan B is a tile-based adventure game. It was made in Java, using the LibGDX framework.
The art was made using Aseprite.
Java is required to run the Java builds. (I've also provided an experimental Windows build, and an experimental low-res web-build)
Why "Plan B"? Well, as the Jam went by, I realized that my original game idea did not work out as I hoped. So rather than not making a game at all, with less than half of the time remaining, I decided to start from scratch. Hence: Plan B
The game therefore lacks a bit of polish (as well as music), but it is fully playable (and hopefully entertaining).
UPDATE: Added a port (experimental web-build to play directly in the browser)
UPDATE2: Added port/localization: Support arrow keys and french AZERTY layout
@psevrain Thank you very much for pointing this out! I was not aware that this was an issue :-)
I have ported the game versions, so that they now also support arrow keys and french keyboard layout. Does this solve the issue?
@katuiche Thank you for your comments! I'm glad you liked the dialogue!
Strange that the resolution should be causing issues, it should be running in standard HD (1920x1080) for the desktop version, and 1280x720 for the web-version.
Strictly speaking, the main theme of the game is (to defeat) Chaos. As I understood the rules, using all three themes was optional?
I did include maps and ships anyway, and made sure that they were integral obstacles of the story-line as well, hence using them to inform the game-/puzzle-design of the adventure - whether that counts as using all three themes or not, is probably a question about semantics :-)
Again, thanks for your comments :-)
@Somnium Ha thanks I was able to play it entirely.
Not too long, not too complex, a good rythm of humour. It was 5 good minutes of play :)
And quite impressive for a plan B!
(For the themes, it depends if you consider they must be the inspiration, the core of the game, or just elements to insert into your game. (3/3 in this case))
@TheGrumpyGameDev Thank you! And heh, well, what can I say, I'm a big fan of the ZAZ works - so least it didn't feature girl scouts fighting.
@maartene Thanks! I'm not sure if the humour was aided or hindered by my sleep deprivation, but I am pretty happy with the end result :)
@psevrain That's great! Thanks for your comments, and again thank you for pointing out the technical issue! And yes, it was a bit of a close call, I finished it with only 6 minutes to spare. Lesson for next time I guess, if an idea doesn't seem to be working, switch to a new one sooner than on the beginning of the last day… :)
I'm always impressed by people switching their ideas mid-jam!
It's … ok? The part with the keyboard/legend mixup was the best bit I thought. I also liked the inventory system (at first I thought I'd have to use it to inspect the map, but it's just an item).
Other than that it was just a bit too linear for my tastes, without much to distract from that (I will add that self-referential humor tends to grate for me the longer it goes on, so that might not have helped).
@remco Thanks! And yeah, I was a bit limited by the time constraint there - a larger number of puzzles, would mean being able to solve more puzzle chains in "parallel". I could only stretch the handful of objects and NPCs into three seperate chains.
As for the jokes, I guess parody is among the least universal categories of humor :)
For a plan B this is surprisingly coherent. Visuals aside, everything else works out just fine. Sure, it is small, but that could also be by design. Short and sweet, and all that.
In a world of less stringent deadlines, a short experience should have more depth to incentivice replayability. In this case a third reaction from CHAOS when confronting it with nothing would be easy to implement. Also the order in which actions are taken should affect dialog at least a little bit. For instance, trying to feed the liquorice pipe (which totally looks the part, by the way!) to the brutish troll for humorous results.
I did get this sort of an error on Linux:
WARNING: Illegal reflective access by org.lwjgl.LWJGLUtil$3 to method java.lang.ClassLoader.findLibrary(java.lang.String)
Windows worked out of the box, so I didn't go down dependency lane this time.
Just out of curiosity, what was plan A about?
@HuvaaKoodia Thank you for your feedback!
And I agree, the final CHAOS interaction was planned to be what combined the outcomes of the different "quest chains" of different islands. In the end I had to cut some ideas, so that only two levels of jelly remained, and kept the generic lose-condition I wrote at the earliest stage of the game.
As for the item usage, the idea was to have more non-linear interactions - the inventory screen was a precursor to this, with the intent being to pop up the inventory screen when using the interaction button, in order to select the item to be used in the interaction.
In its current form, since the action item is autoselected, it will "block" the interaction unless it is consumed by it. So for the troll, he only reacts to two items, the correct consumable item (jellyfish), and a single incorrect item (the red herring) which would block other incorrect items. Instead, I added extra interactions to the conversations of the map-seller and admiral (they both have an extra dialogue after their respective quests have been completed). But ideally, I'd wanted unique dialog for most subject-to-item interactions.
Thanks for the error report - I don't have access to a Linux machine, so I could only verify the jar on Windows - it seems to be a framework/packing issue, I should look into that. Which Linux variant did you use?
For plan A, my idea was to interpret the chaos theme by having the player disrupt a stable/predictable system.
Specifically, space trading ships would fly to one of several planets to trade, and then return to the player. Following the rule that they would choose the most profitable planet to visit next after returning, but prioritizing safe routes over unsafe ones.
The main game mechanic would be, that the path to a given planet would become increasingly unsafe over time, with this "risk" being reset by traders returning to the player with an up-to-date star map. I.e. the age of the map determined the safety of the path to a given route, and the player influenced the traders decisions about their next target, by choosing which maps to share with the trader in return.
In the end, I found the goal of the game (destabilize the empire by influencing trade) to be a bit too abstract to define as a specific victory condition, and I also had a hard time coming up with a clear way of communicating the reason for the traders decision (and the effect that different maps would have on this) to the player.
I'm running Linux Mint (19.3) with the bog standard Java installation from package manager (openjdk version "11.0.8" 2020-07-14). Openjdk might be the issue here, but that is just a guess. I don't use java for anything these days (apart from the odd jam title!)
Plan A sounds like it could just about work with a lot of effort. As you say, indirect decision making can be hard to design and balance right. Stabilizing the trade routes would be a more direct challenge and easier to understand. When fighting against a system instead, the system has to be at the same time predictable yet adversarial. A tall order.