godandrea / drown-in-future Goto Github PK

In the last development log I've mentioned I'd make a post listing my next steps in about the same order as I intend to take them. This is that post.

The roadmap I talked about

Do note that, while I'm doing this for curiosity's sake (and to add to the devlogs as a form of recording what's on my mind development-wise), it's also the roadmap I'll be following myself. This does not mean it's the carefully curated but ever changing to-do list one would normally keep private, as opposed to the public rough outline one would share just so people wouldn't pester them. It's actually a public rough outline that also happens to be the best outline I personally own for what I still need to do, with the approximate order I'll be getting to it. In another words, buckle up lads, the captain has but a slight idea where this tub is going, and it is as follows:

• Get rid of half the mesh library since I won't be using gridmaps for terrain
• Draft the level layout using Godot's cube mesh and collision shapes
• Spawn houses on click, and in the correct location
• Implement other structures
• Do a fast check on numbers and if population/jobs respect the number of homes/workplaces
• Implement logic that forbids building if you don't own enough resources
• Add a popup menu for choosing what structure to build
• Change structures to be toggled on/off
• Design a decent system for the consequences of running out of food/water/energy
• Design decent consequences for getting stuff turned off (specially houses)
• Separate the level in areas ("regions") so that all structures in an area can be toggled on/off at once
• Make a plane (the 2D shape, not the vehicle, bird, or superman) that blocks building
• Make that plane toggle the regions under specific circumstances
• Make that plane move
• Change the plane movement to match a cool function
• Get the water shader to work with the orthogonal camera, which I don't want to let go
• Change the waterfall in the middle of the map to change size and other parameters based on external variables
• Apply water shader to moving plane and make sure it looks dramatic enough
• Add bridges, which can only be built in specific locations
• Change regions so that they start off but turn on when connected by a bridge
• Add floating foundations, which float. Duh.
• Make lumber camps actually consume trees and turn off when out of trees
• Model decent-looking islands in Blender
• Model decent looking structures in Blender
• Model decent looking props in Blender
• Will it blend? That is the question (tododo do doooo 🎶)
• Choose a decent color palette (preferably not the NES one) and add materials of these colors
• Apply the materials to the meshes I made
• Mess with the lighting
• Make sun slowly set over a play-session (move and change color)
• Make sure it's dramatic, pretty, and a bit sad
• Program the NPCs who will act like other leaders in a similar situation
• Add a scoreboard, where you can see their situation (money, population, jobs)
• Add selling and buying resources with money
• Make menus less ugly
• Maybe even finally a main menu screen?
• Add scripted, timed dialogue for the other leaders
• Add contextual interactions with other leaders
• Draw some dumb portraits for other leaders
• Add the default victory
• Add some (one? two?) alt victories
• Add sound effects
• Evaluate desire for actually composing own music for the game
• Alternatively, just use some free tracks
• Add game options and customization
• Oh shit, I forgot the skybox
• Add in-game credits
• Finally release this shit

Looking at it laid bare like this, it certainly looks like a lot. I did convince myself I could do most of it in a mere week so maybe it's not that bad. Either way, many of the bullet points are actually the same task divided into an arbitrary number of steps, so it will probably take a lot less time than it looks like. You might wonder "isn't the opposite also true, i.e. you condensed many tasks into a single one, while also possibly forgetting some, or grossly underestimating some challenges?" Well, worry not; rest assured, that is definitely the case and I'm certainly ignoring many problems. Join me in blissful ignorance as we march forward, and until next time.

A matter of perspective

A very smart person once said "a good game starts from a good camera". I have no idea who it was, and I'm not even sure they're right, but boy aren't I embracing that philosophy.
When I first made my Godot project for Drown in Future, I copied Miziziziz RTS tutorial to get a basis from which I'd eventually change everything. It was a starting point, and a very good one, but once his tutorial had been replicated, I poured over what exactly I wanted, and how to make it.

The first thing I decided was to use an orthogonal camera instead of a traditional perspective camera. The result was more charming, IMO, and any morsel of style I can get for this game, which I wouldn't have time to invest in art, is welcome. The other decisions followed thusly:

1. The camera must have some decent freedom, since the game must feel 3D even if the camera makes it look flat, and RTS relies a fair amount on a good, flexible camera
2. The great challenge of the game, the impending doom, must be visible, and the camera allow the player to focus and stare at it
3. Said challenge, which accumulates over time, should have its impact visible. If it manifests as a moving wall of death (as an example), the area beyond the wall must be visible, so the destruction can be seen
4. I already knew what it was and I'm merely keeping it secret from now (though the title of the game does make it terribly obvious). I decided therefore the camera would be able to rotate around itself, but its movement would be tethered to this one central point. Trying to move sideways makes you move around that point, and trying to move away from it drags you down, like a drone anchored to the ground trying to fly away. The effect is a lot less drastic in the orthogonal camera than in traditional perspective, which I consider a victory, since it's less pronounced but also doesn't get in the way for most of the game.

The first day of actual development, then, was dedicated to getting this to work. It was a success.

Time overdraft

Now we may look back at the game jam and see why exactly my project didn't come to fruition in time. Reasons abound, not the lesser of which is that I bit more than I could chew, but I'm considerably less interested in understanding that than actually finishing the game. I'm convinced it's a game worth more than the novelty of having been made in a single week, so I'll continue working on it, but at a more reasonable pace. That does mean some ideas will be discarded (as they were only included for the sake of the achievements) while other discarded concepts are now back on our menu, since I'm giving myself the luxury of taking the time to get them done.

Collision Course

The rest of this devlog shall be rather straightforward, and comment on what I actually got done since the last one. In my next post I shall lay out the road ahead.

Once the camera was done, I put myself hard at work actually designing and making the game itself. By that I mean of course the actual game systems and how I'm conveying the message and experience I outlined in #1 . I knew I wanted you to manage a city/country/kingdom as you deal with the end. That's essentially the premise of the absolutely wonderful Frostpunk but with a different apocalypse (though I only realized that after all the game's mechanics had already been defined). The RTS tutorial I used to make the base of my game had some drag'n'drop unit selection and a rough pathfinding to order your little minions to move around, but that had nothing to do with what I wanted, so I scrapped that. No builders, no individuals; the game would be purely about spawning structures with a click of the mouse, and they would work themselves by the fiat of your invisible citizens, all accounted for as a number on a scoreboard. Talk about human resources 🥁

Also, I had an important limitation that would define every aspect of my game: I'd be completely reliant on free assets I could find on the internet. Kenney is not know in r/gamedev as "asset Jesus" for no reason, and he had almost all I could need. The little else would be some buildings by Quaternius, all of which were of high quality, and ready to use. No time to mess around modelling stuff in a jam, right? Well...

Turns out that was a dangerous bargain. Not by fault of these artists, whose work is commendable and deserving of a lot of money I don't have, but because they were sightly artistically incompatible with one another (a minor issue I was willing to ignore), because Kenney's assets are essentially 3D tiles to be stacked like building blocks, and because Godot's tools and pipeline to import said 3D tiles are rather terrible. Kenney recommends using the DAE formatted files, and indeed it's the once preferred by Godot, so much the engine devs made a plugin to export that format from Blender. Turns out both ends of the pipeline suck so much, for varying reasons, it was called "pipeline hell" by more than one person talking about it in threads I found when searching Google for guidance. Yikes.

After forsaking DAE in favor of the more practical OBJ format, I still had to manually add collision for each tile to make the engine's gridmap functionality, well, function. And yet it didn't work, and raycasts couldn't detect collision with the tiles. Now, free from the constraints of the game jam, I'll be making my own assets to use in the game. And that does include the actual landscape that would otherwise be built of tiles. The end result may even look better, but that's not the goal. All I want is for it to work.

Tables go brrrrrrrrrrrr

A very smart person once said that while there are plenty of tools to aid and save time with game programming, like ready-made engines to use, the same is not true for design, including the arduous task of setting up an economy for your game, which is fucking bullshit. I'm paraphrasing, but I wholeheartedly agree (the person would be my master, tutor, and friend Wil). It was my absolute first time doing something like that, and with very little time to test, how could I guarantee I'd get the numbers right?

Well, I couldn't, so I just tried to be organized and deliberate about it. First, I made a little diagram:

Then I made a table and slowly filled out the values as if I were doing one of those large logic puzzles. Who's the Englishman's neighbor? What color is house 3? What does the person who lives in the pink house drink? Well, I know I drink just about anything, as I knew what I wanted things to cost in relation to one another, while simulating in my head how long/hard it would be to set up some building combinations. No spoilers, of course.

Turns out programming it was easy, so hey.

Drown in Future development log: entry 1

Introduction

By 20h00 of Monday (18th of May, 2020) a post on the Definitely not Meeting Jam Discord server announces the themes (and achievements) of this jam. It reads as follows:

[...]
Themes:
-Don't look
-It's not about winning, but to keep standing up
-Quick! They're coming!
-Obvious mystery
-One for all and all for one, until only one remains

Acheivements:
-Secret ending: have a secret ending
-Alright, keep your secrets: put a picture of Frodo Baggins somewhere
-BEES!: add bees to the game
-POTATOES!: add potatoes to the game
-Local multiplayer: make a game that can be locally played by more than one person
-Monochromatic: make every part of your game using the same color
-Where's Waldo?: hide a picture of each developer somewhere in the game
-You thought it was an achievement, but it was me, Dio!: make a Jojo reference
-DevLog: register the entire development process and post it somewhere
-Certainly not chess: make a game that does not envolve chess
-Plotwist!: have a twist in your game's plot

Very well, that's easy enough. Five themes to choose from, all of which are quite good (IMO), and I still have the freedom to decide which (if any) of them I'll follow. On top of that, there's also a selection of achievements of varying challenge to pursue. I was interested in keeping a development log ever since I decided to participate in this jam, but the devlog achievement made the decision final. It wasn't the only achievement that I decided to pursue either: I consider the inclusion of a secret ending a stretch goal of sorts, and I'm very much for the inclusion of hidden pictures in one's game. Bees can be but a visual effect, potatoes can be the crops in farms (more on that later), the allure of hoping on the bandwagon and making yet another chess-like game can be resisted, and I'm rather sure the plot does have a twist. A pretty game will probably need a well-defined palette, and I think the NES will be good enough. It's a complex-ish game visually speaking, so making it monochromatic without being confusing would be too big of a challenge.
And no way I'm trying to make my first ever multiplayer game during a jam. No. Way.

And so, we move to the actual game.

What am I even doing?

Turns out I already knew what I wanted, and it fit very nicely some if not most of the themes, depending on how much leeway for interpretation you'll allow me (I do wonder if I'd have just ignored the themes altogether if my idea fit none of them, though).

Not too long ago I read Innuendo Studio's thoughts on Outer Wilds, a game which I frequently call "Game of the Year, every year". It has very little to do with the game, but much to do with it's themes and the ideas and reflection it causes on players. The author, in a simple sentence, crystallized in me a thought that has been lurking in my head for months, if not years now, and I longed to express somehow. I needed to coalesce it in art or thought experiments but never quite managed to get a hold on it. Said sentence is:

"Thinking about how to prevent the end can mean never learning to live with it."

Yes, it's a reflection on so many things the contemporary person lives with, but all in all, it's simply a thought on the end of the world, whatever that entails. The author, in turn, considered it because he too had been thinking about something for a while now. In his case, it was a book, a collection of essays by Elizabeth Sandifer called Neoreaction a Basilisk, which I absolutely had to read. It's about the alt-right, but so much more. As per its very introduction, it considers "what if we're fucked?" and runs with it.

In it's first essay, the author focuses on three "manifesto-writing visionaries", one of which is this man called Eliezer Yudkowsky, and compares an online community built by him (LessWrong) with a cult postulated by Neil Gaiman in Sandman. Said cult was devoted to Despair, and two years after its creation it was completely undone, from the inside, as a consequence of its own beliefs, for all members succumbed to despair themselves and committed suicide. In LessWrong's (less poetic) case, the sum of their beliefs led to something baptized "Roko's Basilisk", referenced in the book title.

Roko's Basilisk is a fascinating thing. Reading about it on the Rational Wiki took me down quite the rabbit hole, in a way I thought no mere thought experiment could ever do. Almost a cyberpunk lovecraftian tale disguised as Philosophy, Roko's Basilisk is an unholy mix of The Game (which I just lost, of course) and a Basilisk. Instead of killing those who gaze upon it as the mythological creature, it dooms those who consider it. Damnation through one's thought, as in a medieval interpretation of religion, but in a cyberpunk clothing. It posits this super advanced AI in the future which would retroactively punish all of those who knew of it (as it could unerringly know, being able to perfectly simulate mere human minds) but didn't actively help it's creation as best as they could. As no one is actually willing to do everything in their power to accelerate an abstract AI's advent, all who learn of it are irreversibly and inevitably doomed in the future. And as I read it's fascinating, lengthy entry on the Rational Wiki, a realization came over me:

"wasn't I supposed to be making a game?"

Drown in Future

The game would be about the end. At first, it would seem like a regular management game, where the player leads a nation of sorts, and with some artificial competitors who simulate other leaders, all competing in a score board. Eventually, one of the regular challenges of the game starts growing and spiraling out of control. A good player may resist it, outlasting the NPC's, but instead of a happy ending, they find and inevitable end slowly approaching. It's not about victory, for it's impossible to win. Being the last to die is as much of a victory one can aspire to, and if I have enough time to spare, there would be a difficult, niche way to progress that allows you to actually survive the end. A secret, true ending, except there's nothing "true" about it.

It's a game about the end. Not happy endings, not endings in general, not avoiding or preventing it.
And yes, the title is a pun on "drowning future".