devlog

I have hit the first wall with TLB, in which I have almost completely stopped working on the game. This is due, in part, to the fact that I was waiting on an artist I hired to do some prototyping. While I waited there was grind work I could have done but I simply needed a break. This is a normal work cadence for me.

For me, bringing on an additional person raises the stakes in two ways, at least. First, I am putting money into the project. If I don't publish, I will lose money. For me, this is a means to push myself to publish. While I don't expect to make money from this game (I do not know if I will charge for it in the first place), the act of publishing has monetary associations and thus is the offset of the scales to the 'putting-in-of-money', so to speak. So long as I publish, I can tell myself that the work I paid for is seeing the light of day, and it wasn't for nothing.

Linked to this, is that another person is now part of the working agreement, in some capacity. Regardless of whether this person likes or enjoys the work you have requested of them (and paid them for) one is now somewhat beholden to this person as a spectator. When a lack of interest drifts into town, for whatever reasons, I can at least temporarily project myself into the other person, and imagine for a second (whether or not this is delusional or self-centered, I can't say, nor does it matter) that a thought such as 'I wonder what will come of that thing I worked on' might cross their mind.

Regardless, I am not unhappy I have hit a wall as the wall is merely a distraction of a new project that has surfaced, which will be covered in a future post!


I'm a little late on an update but I'm glad to be back at the keyboard and writing.

About two weeks ago I transitioned the last billionaire into a “high definition” game; that is, no longer prototyping under a pixel-art screen size.

This meant changing the canvas size to 1920x1080 and exploring what assets might look like at that size. I was previously playing with the idea of using collage as the aesthetic for the game. It looks like I'll be going forward with that. It seems like it'll work fine resolution wise, and also I'm more intrigued by it as an aesthetic than pixel art.

Thankfully, I think this approach might also be the “right kind of limiting” toward getting things done.

So, I've spent a few hours basically finding creative-commons licensed images that can be isolated in photo editing software and put in-game. It works fairly well, although finding images that fits the perspective of the game (ie, one point, head on perspective) are a bit challenging. I've gone out to shoot a few photos of some of the trash and junk in the neighbourhood and managed to find a handful of candidates. There will be lots of toil-work to get a healthy catalogue of items.

I'm also re-arranging some ideas on the game to make it hopefully a bit less tedious and focused. I've had some help on brainstorming some solutions that helped me see outside my idea a bit. Originally the billionaire was going to go and visit a “scrapheap” to find items. This could have worked but story-wise it didn't really make sense and it was also tedious for people to go back and forth between two different scenes simply to look at a heap of garbage and try and find something to “bring home” from there. While the boring-tediousness of that makes me smile, it's ill-fitting.

Instead, I might go in the direction of the Billionaire being accompanied by a drone (yes, that's right) that does a lot of the building and movement in game. That means the drone would be responsible for moving items around (instead of just the mouse clicking on items and moving them), perhaps via some kind of lazer/tractor-type beam, as well as going and finding items for the Billionaire. Some friends pointed out that it might make more sense that the drone could effectively go fishing for items either in the same scene that it builds the shelter in, or in some other mechanic. Since a mechanic of the game is that sea levels are rapidly rising everywhere, it makes more sense to play to the idea of scavenging a floating garbage patch.

We'll see going forward how things end up. I've brought on a talented friend to help with the character design for the billionaire(s) and the drone as well as to help with some conceptualizing. That's it for now – thanks for reading!


This week's update is about saving and loading data in game. My second attempt at this is just wrapping up and hopefully I won't have to work on it again for a little while and can move onto some other things.

I originally used this tutorial to manually save json data representing node properties into a .save file. It worked totally fine, but when it came to start storing data that was in resources and outside of nodes, I was starting to wonder if it was the best option. I think it probably would still have worked fine, but I felt unsure.

Then I found another tutorial – “How to save Game Progress in a Single Resource File” that seemed like a better alternative. So I refactored to use resources for saving. And hold up? what's this? Another tutorial?

So, there's a few different ways to do this; but the last two seem to be the way I'll go for now; using resources to save files. I think my case is a bit more unique in that I'm working with nodes that are accumulated and disposed of during gameplay (the build_items) which are found in the scrapyard and then used in the temporarily-named build mode. Since nodes are entering and leaving the scene tree, I can't just assume I can load functionality straight out of the resource file without first re-adding a node to the tree.

I see some future issues here. First, a minor point, I prefer to just work with text data. .tres files are unique to Godot and aren't as easy to parse, navigate, make changes to etc. If I wanted to maintain a spreadsheet of items that a player can build their fragile-mountain-home with it would be a bit cumbersome to take that data, convert to csv, and then into tres. But, I think I'm going all in on using Godot specific -isms – all my items are .tres files that are linked to an Item.gd script. So I don't look forward to the day of having to go and add/update a new characteristic of an item across 30 + items in the future, and then update the save/load functionality of it(the latter not being that complicated, I suppose).

On the other hand, I can see being able to make changes in the inspector being really convenient. If I was working on a team and with folks less familiar with programming, they could still make changes to scalar values, like the height of the water level, or the physics of an item.

To be honest, I was starting to get a little bit discouraged and frustrated with the project as I attempted to build out the inventory and then the save system, but now that things aren't resetting every time I change scenes / open the game, I feel like I've learned things and am making progress.


That's it for persistence for now. Next up I have some small changes to make to the UI and to make development a bit easier, and then I'm going to tackle re-thinking the canvas size. It's still to early to be thinking about art style and visuals, but I also need to prototype some ideas to see if my ideas are feasible. I originally planned on making this game a pixel art game, but also thought briefly about using collage as a possible visual representation. After sharing the basic premise of the game with a friend they also suggested collage as a possible avenue (it's always confirming when someone has the same idea as you before you tell them your ideas). I'll have to look into what it takes to be building a “high resolution” game instead of a scale-able pixel art game (I don't really know much about either).

As The Last Billionaire you were clever. Clever enough to bring your briefcase to the mountain where your new home will be established in your attempt to evade rising sea levels. With your trusty briefcase, you can carry an impressive four items with you at any time.

At this point in planning, the briefcase will enable the picking up and carrying of a limited number of items that you find in the scrapheap. These items (tires, girders, ladders, bricks, etc) will be used for building your house in the build scene.

So, an inventory is needed with the following abilities:

  • Pick up items found in the scrap heap
  • The choosing of items in the inventory to enable placement in build mode.
  • The ability to discard items in favour of picking up other items.

These are the minimum requirements for the inventory at this point in the game. This is the first time I've built an inventory system and so my first attempt was naive (but perhaps not an uncommon approach) It looked something like the following:

  • Create a json file for storing all the possible items that can be found in the scrapheap.
  • On load, pull the JSON into memory as an Items dict:

    var items = {
        "tire": {
            "buoyancy": 70,
            "durability": 50,
            "scene": "build_items/tire.tscn"
            "name": "tire"
        }
    }
    
  • When entering the scrap heap, pick a random item from Items.

  • Create an a variable briefcase and fill it with 4 null slots.

  • Whenever clicking on an item in the scrapheap, the item (as represented in data) is pushed into the briefcase list.

  • Build a control node set to represent the gui.

I got about that far before I found this excellent tutorial on building an inventory in Godot using resources. At that point, I was starting to wonder what kind of “node” best represented the inventory. In my mind I saw the inventory as a Singleton that would need to be preloaded before each scene – since all scenes would need to interact with it up to some point. However, I didn't really know how this should be represented in Godot, so something seemed amiss.

According to the docs, “[a] Resource is the base class for all Godot-specific resource types, serving primarily as data containers.” So, following the tutorial above, I think I've found a much more Godot-ish way of doing things. Coming from doing web development, I sort of think of resources as representing State, while nodes are responsible for rendering visual representations (with interactive capacities) of that state.

So now, I have an inventory.tres which has exported variables for a) the briefcase and b) all possible items in the game.

All possible items are also represented as a resource:

    extends Resource

    class_name Item

    export(String) var name = ""
    export(Texture) var texture
    export(Resource) var build_item

    export(int) var buoyancy = 0
    export(int) var durability = 0

    var stats = {
        "buoyancy": buoyancy,
        "durability": durability,
        "name": name
    }

    func get_stats():
        var stats = {
            "buoyancy": buoyancy,
            "durability": durability,
            "name": name
        }
        return stats

This means that for each item in the game I will have to create a .tres scene for it, and attach it's sprite, as well as the build_item scene that represents it (ie. link to the scene to instance when building the house in a physics mode). This seems more conducive to working with Godot, but I do feel the tension of slotting the problem at hand into the “game engine” approach rather than just writing code. I'm sure I could go the all-code route and maybe even programmatically create the resources but for now, as I'm rather optimistic about and interested in Godot, I'd like to do it the manner most befitting it's workflows. With that said, it's still my first time and I have a lot to learn.

The inventory tutorial was also helpful for figuring out how to connect everything to the control nodes, so I certainly am grateful for that. After, setting up a basic popover with item stats was pretty simple.

What remains at this point is to be able to pick up items and place them, and to fix a strange bug . When “picking up” an item it seems to be picked up twice based on how I've setup handling input. Items as they appear in the build and scrapheap mode are called “build_items” internally and have a script attached for handling their possible interactions – in build mode this includes the picking up and placement of items physically; in the scrapheap these items are no longer rigid bodies, and instead will just appear statically in the scene. So, the code is already getting a bit problematic, and hence I'm running into the double pickup bug somewhere. My input code looks like this:

    func _input_event(_viewport, event, _shape_idx):
        if event.is_action_pressed("mb_left") and scene_mode == Game.Scene.BUILD:
            emit_signal("clicked", self)

        ### FIXME: This is firing twice.
        if event.is_action_pressed("mb_left") and scene_mode == Game.Scene.SCRAP:
            if not inventory.is_briefcase_full():
                inventory.pickup_item(inventory_mirror)
                queue_free()

I've tried using different _input* callbacks, but it seems that in order to detect clicking within the item itself, input_event is necessary. I'm hoping I'm just missing something from the API and will be on my way shortly. I'm still a little confused about which methods to use (Input map, vs events passed to input callbacks) when using Godot.

Not sure what comes next after that. Perhaps ability to discard an item you don't want – or some of the other edge cases I'm sure I have yet to run into that I haven't though of yet.

I've started prototyping for a new game. This is the premise:

Sea levels are rising more rapidly than ever before. Exponentially so. You are a billionaire and you've escaped in a helicopter to the closest mountain top (with little more than your briefcase) where you will have perhaps an extra boon of time to build a home from what scraps you can gather; a home that hopefully will stand on it's own as the water rises up to the mountains themselves.

That's the gist of it. The idea is blatantly stolen and adapted from this amazing clip from comedy bang bang. There are some other story elements that I would consider incorporating, but there is a prototype to be built before any of that can happen.

I've decided to try and build this with the godot engine for a few reasons, which I might get into later. I'm still learning the ropes of it quite slowly, but it's exciting to be building something creative with all open software. I've been particularly inspired by carrotcake studio – in a few ways – so do go check out the author's upcoming game “The Garden Path” – it looks and sounds delightful.

In the meantime, I'll write a bit about how I've been planning MVP's and type aloud as to whether they are really effective (right now: doubtful).

MVP

Scene: build mode [2/3]
- Make a basic background with a mountain
- make a foreground that things can be placed on
- enable “placement of items” (tut)

STRT End game mechanic [0/2]
- build time / water rising
- if water rises above X game over

This is copied and pasted out of my projects.org file, where I track my time and tasks on each projects I'm actively working on. As of writing, I've completed both of these tasks, which seems to say that the MVP is done. However, the project feels so far from being a game that I'm not really sure it's an MVP. I try and keep explorations of a new idea to the absolute bare minimum so that I can save myself the time of realizing something is not feasible. That means there is no custom art, just free assets I've found online, and there is no inventory, and no story. Just the bare minimum mechanics.

If I like where things go ... well, this is where “MVP” gets conflated. I will end up just adding batches of tasks that continue to grow as I discover edge cases and mechanics I had not thought of. Since I'm new to game development soon I expect all kinds of bumps along the ride. Perhaps this time I'll create a series of MVPs, or milestones that increment overall play-ability.

That's it for now.