The first part of this design was about your people's culture and their relationship with their giant turtle. I'm really interested in strategy games about building up a culture rather than just making optimizing decisions. I previously made a Ludum Dare game, Annulus, in a similar vein.
This time, it also matters how your people relate to the turtle. They can exploit it, or treat it as a steed - cared for, but with a focus on usefulness, or as a pet - loved but subordinate. Or they can worship it. All of this is handled very simply in this small game - it basically asks you which of those four you want. Beyond that, you can have a more religious or warlike culture, or hire an engineer to make novel machinery.
The second part is that because the turtle inexorably moves towards the sea, the environment constantly changes. Your main interaction is clicking on nearby tiles to harvest resources and send out expeditions. Inevitably, new tiles come into range and old ones drop out, so you only have a certain time window to harvest a given resource, which means you have to prioritise and guess or scout what's ahead.
And you can somewhat control the movement of your turtle. It will always head east towards the sea, but it can also go north or south at the same time. Depending on the available tiles in front of it, you may have a chance to nudge it one way the other. Failing that, you can perhaps bribe it, or build a giant whip to force it. Or your engineer can build a steering harness.
The idea there is that in 4X games like Civilization, the first part of the game, where you're placing your early cities, is the most interesting. Should you build a coastal city to enable trade and naval warfare, or move a tile or two inland to capture some extra resources? Is that perfect but far-away spot worth it, or will it prove to be indefensible?
Once that early phase is over, gameplay pretty much shifts to a combination of warfare and watching meters go up, which is less interesting.
But if your city moves, has to move, with partial control of where you're going, that first part repeats throughout the game. Whenever it moves, at least three new tiles come into range. Which one should you pick first? Are you short on water? Is there a town where you might acquire quick resources or some special items or people?
Note that At the Gates does something similar, forcing the player to be nomadic because resources degrade over time. Unfortunately, I can't really recommend AtG. Its economic system is really complicated and punishingly hard, as opposed to other aspects of the game like diplomacy, which are barely there at all. My frustration with AtG was also a reason for making the interaction system really simple: you just click on a tile to interact with it, and there's only one interaction possible at a time.
So we made this game in rather less that 48 hours, especially because I was also running the Zurich GGJ site at the same time. And we're in our 30s, and believe in self-care, so we went home to sleep in our beds every night.
We ended up submitting a version that worked, looked really nice, but was unbalanced and pretty much impossibly hard. Turns out that playtesting is a thing you should do?
You can check out the source code here. It's all put together using HTML5/Canvas, not using any engine. I like doing jam games that way. I've had bad experiences where trouble with the game engine ate up large amounts of time in jams. Using these simple tools means you have to type a bit more, but you can make very steady progress. We had exactly one bug that I couldn't instantly fix, which was a logic error in the code for choosing which tiles were available to move to, and this error wouldn't have been avoided by using an engine.
I also made the whole thing heavily data-driven. Tile types, encounters, buildings, the world map, even the options for convincing the animal to move to a certain tile, are all defined using simple text-based formats. Again, this meant some extra time to write the parsers, but even with the short timeframe of a jam, being able to tweak and add new content easily was absolutely worth it.
Plus, once you've done it a few times, writing a parser that basically splits input on newlines and then on spaces, and takes the first word of each line as a command, is really straightforward. (This might be my self-taught nature showing through. I glued together games using REALbasic for Mac for years before getting any formal programming education.)
After the jam, I kept poking away at the game for about a week. I wanted to make it a more balanced and enjoyable experience, improving the UX, fine-tuning the map and encounters, adding some more story elements.
I also added sound effects and some simple music. Again, the music is also data-driven. There's nine instrument loops which are all technically playing at the same time. The same variable system used for resources and encounters also modulates the volume of the loops. This means the music can change as you move closer to the ocean, and based on things like the animal's health, the biome you find yourself in, whether you're strong and martial, or despairing.
Again, I'm pretty pleased with it, especially because it all took less than a day of work. I've also arranged the soundtrack into a piece:
All of this resulted in the final post-jam build, which I suggest you go play. You can play it in the browser or download it.
Can you reach the ocean? There are multiple paths that require different strategies.
What do I conclude from this? Making jam games is really fun. OK, I knew this. But this experience also tempts me to spend some time making smaller games once I'm done with the next Airships update. Creating one game a month and putting them on Steam for $3 apiece could be really creatively satisfying and maybe even sustainable?