Hey! I’m discoPiranha, and this is my third time in MFGJ—so not my first, but hopefully my most successful! Past entries (with a team) included very first steps of a farming game set on the Moon, and a demo of a Galaga-style shooter with random enemies and a 9-stripe pride flag laser.

For Winter 2020 and the theme of Cold, I’m finally prototyping a game that I’ve been thinking about for a few years! The First Flame (working title) will follow a person/creature with the ability to create and manipulate fire who has to venture out from their village into the nearby forest for supplies, rescues, and eventually to understand where threatening creatures from the forest are coming from, and why the summer, overdue for generations, has not come back. (Short sentences aren’t my strong suit)

The central mechanic that has been stuck in my head is a special HUD to show the player two stats—hyperthermia (or overheating) and hypothermia. Hyperthermia appears as a fiery light that emanates from the player. When they use fire, it grows, and if it covers the entire screen they will fall unconscious from overheating. Hypothermia appears as a frost that encroaches from the edges of the screen, and grows with exposure to the cold. If it reaches the player, they’ll fall unconscious as their core temperature drops too low. The two will balance each other, so that the player can make fire to stave off the cold, and the player’s hyperthermia decreases as hypothermia increases when the player is away from heat sources.

So for these two weeks, my goals are:

• Create that HUD! Make a player stand-in with hyper- and hypothermia stats, and tie these to a red circle that increases in size and a cut-out in a blue overlay that decreases in size.
• Make a player! Pick some open game art, and make an animated player who can move, produce a flame from their fingertips, and fall unconscious if hyperthermia or hypothermia reach 100%
• Keep up with a devlog, and participate in the community! I’ve never really done the participation part, except with my direct team and commenting on submitted games, and I feel like that’s only doing half the jam.

If at the end of two weeks, I’ve done those three things, I’ll be happy. I’m trying to keep my expectations meager, since I’ve also got full-time research to do. From those, though, I’ll have first steps on an idea that’s been in the icebox for years, and, I hope, some feedback on the ideas I’m bringing to it now!

So here's some initial progress on the HUD!

I got the red circle working last night, after learning about the built-in _draw() function for Nodes in Godot, and the draw_circle() function. What turned out to be more complicated than I expected was the hypothermia overlay. 

What Godot is doing here is

1. Draw the player sprite and the heat circle
2. Encountering a BackBufferCopy node, and caching what's been drawn to the screen so far
3. Drawing a rectangular pale blue transparent overlay across the whole screen
4. Drawing a white circle over that, with a shader that sets the texture of the circle to... that cached picture of the screen!

It seems bizarre to me, but after a lot of searching it seems to be the best method I can find. If anyone has a suggestion, though, I'd love to hear it! Obviously the structure of the node tree and the way the code is written is going to change, but I'm sticking the screenshot above in just in case someone else is using Godot and looks for a way to make a hole in a texture. I'd like to write this up into a more detailed example in the future, since it would've saved me a couple hours to have a detailed example of how to use the BackBufferCopy and shaders like this!

Final submission up! https://itch.io/jam/my-first-game-jam-winter-2020/rate/561687

I want to write a post-mortem when I have time this week, covering a few hang-ups, resources that were essential, and things that I learned.

Final post / Post-mortem:

Short version: This was my third MFGJ, and it continues to be a good time! My main goals for this jam were to prototype an idea that I've had bouncing around for a while, and to actually interact with the community through writing devlogs and checking the Discord actively. In those three goals, I feel it was a pretty successful two weeks! Something always comes up, of course, but I think I did a pretty good job paring down my scope and expectations. I would've liked to write more devlogs. 

Long version, a.k.a. things I wanted to devlog: 

Outline:

1. Backbuffercopy + shaders
2. Fixing the screen UI
3. Animations!
4. Tilemap funkiness
5. YSorts

1. Backbuffercopy + shaders

This was my first big breakthrough. The first thing I figured out when making my hot-cold overlay is that it's super easy to draw a circle and a rectangle in Godot from code, and not nearly as easy to draw a rectangle with a circle cut out of it! The structure of my UI, finally, is 

UI -> A canvaslayer node, so that it isn't affected by the viewport moving
    TemperatureOverlay -> a Control node, with a script to feed info to the overlay elements
        Heat -> A Node2D
        BackBufferCopy -> a backbuffercopy node
        Cold -> A Node2D
        Not Cold -> A Node2D
            "Not Cold" has a ShaderMaterial, with the Shader code
                shader_type canvas_item;
                void fragment(){COLOR = texture(SCREEN_TEXTURE, SCREEN_UV)}

The funny thing about all this is that I'm not positive that each element is necessary for it to work. The BackBufferCopy node, by virtue of existing in the tree, saves a buffered image of the screen when it would be drawn, so it captures all the player action going on under the UI and the red circle that shows Heat. Cold draws a blue rectangle that's a bit bigger than the screen and covers everything. Then, "Not Cold" draws a circle that gets smaller than the screen as the player's body temperature drops below neutral. It's a plain, white circle, which has the buffer from the backbuffercopy reflected onto every pixel by the shader. I think! Shaders are super weird, and I'm still learning a lot. 

2. Fixing the screen UI

I spend a lot of time screwing around with that UI above to get it to follow the player correctly. In the final iteration, these three things seem to be essential: 

1. The root node of the UI is offset to the center of the screen
2. The TemperatureOverlay node has its anchor and margin values set following the "Center" instructions from https://docs.godotengine.org/en/3.2/tutorials/gui/size_and_anchors.html
3. The BackBufferCopy, and this took me forever to notice!, is set so that Copy Mode is "Viewport", and the Rect is 0,0 to 480,320, the size of the game

3. Animations!

This is just a fun little note. If you play and use the fire swirl, you may notice that it appears to pass behind the player, in super fancy faux-3D fashion! What I did to accomplish this, and I'm proud of just how ridiculous it is, is that the player has two sprites, one on either side of the flame in the node tree. The first Sprite is fully animated by the AnimationPlayer and is active all the time. The second one becomes visible only during the fire swirl, and is just the top of the player animation that plays during the swirl attack but in a position to be drawn above the fire. So silly, but it works! 

4. Tilemap funkiness

There are four TileMap nodes in the game. There's one that has all the ground, one  that has all the snow, and is checked against when the player uses FireSwirl (And tiles are set to -1 to disappear), One to draw all the border trees, and one to draw just the tops of the trees, so that the player passes in front of the trunks and behind the tops. All my tilemaps come from sprite atlases, and I cannot for the life of me understand how the whole process works. Future goals are to know a single, solitary thing about how TileMaps really work. 

5. YSorts

This was a real treat to figure out at the end! Between the TreeTrunks TileMap and the Treetops TileMap, there is what's called a YSort node. Nested in the YSort are another YSort that creates and holds all the bats, the Player, a YSort holding all the trees you can walk around, and a YSort containing all the signs and shrines. While that's all a lot to take in in a single sentence, what it means in the node tree is that Z-Sorting (Figuring out what to draw in front of what) happens automatically for every child of a YSort or child of a nested YSort. This is super cool, to me, and I'm happy it's baked in to Godot 3+ 

If you've read this far, leave me a message if anything didn't make sense, and I hope you found something here useful! I may come back later and add images, which would probably be a lot more useful than descriptions.