Trouble In Paradise by Nick Rafalski

Click to play in browser!
Game Background
- There's trouble in paradise! Everybody wants margaritas, but they're too drunk to go fetch the ingredients!
- Luckily the archipelago is rich in natural resources, and specifically the ones needed to mix up some margs!
- Explore the islands, locate the ingredients, bring them to the locals, and let the party start!
How to play
- Control your ship with the Up/Down/Left/Right buttons or WSAD
- Your ship cruises and steers at discrete increments. Tap a button to change the speed/heading; there's no need to hold the buttons
- Gather the ingredients (Ice, Tequila, Limes) from islands and deliver them to the houses. Once an island has 1 of each ingredient, it's time to party!
- Bring the party to 10 houses in as short of time as possible!
Tools:
- Unity
- Paint.NET
- Audacity
Meta:
This was my 12th Ludum Dare compo and by far the one I struggled with the most. I actually had a nugget of an idea almost immediately, which is rare for me. The rough idea was "explore a procedurally generated archipelago" and the theme would come in via some kind of cargo management mechanic, but I didn't have a super concrete idea for the actual gameplay. I took most of Friday night to just reacquaint myself with Unity (specifically the Cinemachine camera system), and then nearly all of Saturday fighting with the procedural generation. By Sunday morning, you could pick up stuff, but you couldn't do anything with it. Needless to say, I rushed through Sunday making the most minimum viable product I could, even copping out and just making the "score" time based, which I wanted to avoid since it adds a sense of urgency to a game that is supposed to be chill. I was initially picturing some kind of "overall happiness" rating that you would try to maximize, but it wouldn't necessarily be tied to time.
Like I alluded to, the procedural generation gave me some fits. The initial iteration was very straightforward. With perlin noise, I generate the islands, and easily map that to the Unity TileMap system. I had the basic look of the archipelago within a couple hours. But the devil is always in the details. One problem I ran into is actually identifying the ocean! What if a totally land-locked body of water gets generated that is isolated from the rest? If I start your ship here, you won't be able to get very far in the game. So I used a flood-fill algorithm to detect each "body of water" and assume the largest (by cell count) is the ocean. All others are deemed "lakes" and filled in with a swamp-green color. You can play many rounds and never see one, but you just might. This worked in the end, but at one point the algorithm was using recursion and resulted in consistent stack overflows (hint: don't try to push 32k calls onto the call stack), then my next implementation with a queue worked, but it would take 3 minutes just to flood fill the whole ocean. I finally settled on an implementation that uses a 2D array to track added tiles, and that got the time down to under 3 seconds.
With all the trials and tribulations of the procedural generation eating my time up, I didn't get to many of the features I wanted to: * Different island graphics to, for example, make "lime islands" distinct from "tequila islands" * Different types of ships with different cargo capacity and handling characteristics. You would commandeer the ships either in port or at sea with a minimal combat system. * Detect rare islands (small, far away) and give them something cool to explore like a light-house or pirate camp * Pirates! * "Missions" where a particular harbor would hail you to bring a specific resource asap (there were going to initially be many more than 3 resource types) * Spending more than 20 minutes coming up with, and recording, the background music. Take more inspiration from Jimmy Buffet songs and maybe even incorporate a drum track
Alas, it wasn't meant to be. I'm definitely not going to "expand" on this game directly; the code is too gross for that, but I do think I learned a few lessons about procedural generation that I will (hopefully) remember in the future. As always, it was a fun, but frustrating, experience.
| Link | https://nostyleguy.itch.io/ld54 |
| Original URL | https://ldjam.com/events/ludum-dare/54/trouble-in-paradise |
Ratings
| Overall | 278th | 3.229⭐ | 26🧑⚖️ |
| Fun | 322th | 2.813⭐ | 26🧑⚖️ |
| Innovation | 270th | 3.083⭐ | 26🧑⚖️ |
| Theme | 335th | 2.708⭐ | 26🧑⚖️ |
| Graphics | 279th | 3.083⭐ | 26🧑⚖️ |
| Audio | 145th | 3.354⭐ | 26🧑⚖️ |
| Humor | 101th | 3.196⭐ | 25🧑⚖️ |
| Mood | 228th | 3.146⭐ | 26🧑⚖️ |
| Given | 23🗳️ | 27🗨️ |
By far the coolest thing was getting to read about your process! It's super fascinating to see how something got to the place it's in.
The tech here is amazing for 48 hours. You have a mini-map, and procedurally generated islands, and fog of war, which aren't trivial! Well done :clap:
Only gripe is that I accidentally dumped my inventory on accident -- maybe add some friction there.

Music + scenery makes for a great atmosphere as well.

I also have a flood-fill story to share. Had to use it on my game (although much simpler than yours), to which I was surprised I could code from memory! But then, it not surprising, didn't work at all. Checked the code, checked the code, looked for pseudo codes online, added prints, read about GODOT debuging, nothing makes sense... then... out of nowhere I look at the input array and see: *levelArray[pos.x][pos.x]* fixed it, saw the scoring system / greenefication working first time, went immediatelly to bed semi frustrated (3 AM)
Commit message:

Translation:
Reverted the id thing to improve shot (caused worse bug).
Flood fill counting points.
tomorrow little cars
(shot is how I called creating canals, the walls shoot a "building canal" that when colides with a canal, trace the path back creating canals to all nearby building canals. I had added an ID to prevent another building canal to build another canal shot at the same time. Sounds fancy but that code is HORRENDOUS. In the end I "fixed" it by making the canals shoot much much faster, which also improved the gameplay on accident, so win win)
No regrets. Good luck! May our code works first run on the next compo!
For me the game would have been fine if the keyboard controls mirrored the onscreen controls. I'm assuming it is a bug, but pressing 'A' for left or 'D' for right only moves the ship one tic. Holding the button does not continue to turn the ship left and right so you have to constantly tap the keys which is frustrating. I noticed that when you click and hold on the onscreen buttons that you do turn smoothly (still tic by tic, but holding it keeps you turning).
If you fix that, do @ me so I can play it again!