Gruedorf Post 2021-02-21

THIS again.

I’ve actually been pretty diligent about development for a while now (despite all of the… everything). This year, I’ve resolved to start being more vocal about what I’m up to, so I can try to build some momentum for an eventual release, and I’ve started by doing biweekly #screenshotsaturday posts on my Twitter account, https://twitter.com/shamuspeveril. After seeing a bunch of people posting here, I figured I’d join in. I’m trying to be protective of my time so that I don’t just end up spending all my time talking about the game instead of making it, but here I am for now. I’m going to be a bit indulgent of my rambling side in this first post; later posts should be more focused.

So, what am I working on?

Ancient History

Let’s start way back in the halcyon days of early 2004. I was feeling the game-making itch again. I decided to look up this old game engine I’d spent a lot of time chatting about and messing around with (and accomplishing very little) years before - Verge! I happened to load it up just a short bit after vecna had made an update saying that Verge 3 was right around the corner. Exciting! What a great time to dive back in!

Journey to Black Mountain

When V3 did actually release a month or so later, we all had a compo (known these days as “a game jam”) to celebrate the release and do some bug-finding. In a week, I built (with my then-girlfriend-now-wife, tulokyn) a small game, Journey to Black Mountain. It was about Kiel, a young healer, setting out to find a rare healing component to help her friend’s sister. It was pretty rough. It was basically a 2d walking simulator with some light puzzles, well before that genre was anything close to established or respected. It didn’t look great, but it had some interesting ideas (at least so I thought) and I liked the characters.

Geas

A few months later, mid-2004, there was another compo, but this time we had two weeks. I wanted to do something about the further adventures of Kiel and her friends, so I came up with another story about them, set five years later. With twice as much time, I obviously planned roughly 10 times as much game, and it went about as well as you expect. We got something submitted but it was very, very far short of what I wanted to do. There were rudimentary bits of the game in there – a combat system, a shop system – but it wasn’t anything remotely complete.

Post-compo Development

After the compo, I did not want to let it go. I liked the characters, and I liked the idea. Worse (?), I had some MORE ideas. I decided I’d keep working on it, and if I’m going to keep working on it, why not expand it into a full game? Why be beholden to the idea I had for a two week game jam? So I kept working on it, developing the systems further and further. I also expanded the story; the original game idea became the first chapter of seven, four playable characters became twelve, and the world ballooned in size (though I will say that I kept myself to a relatively “manageable” world size; the game was contained mostly within a few relatively small kingdoms which I wanted to make fairly dense and interesting, rather than spanning a whole planet with exactly six towns on it).

I released a tech demo of this version in late 2004, and generated some mild excitement!

Rewrite

Unfortunately I started to hate it. As I worked, I got better at coding and art and wanted to bring it up to speed. I brought some people onboard to help me, and as is the way with things, they drifted away. Verge3 got the ability to use Lua instead of VergeC for scripting, and it’s just a much nicer language to work in. Rather than convert everything, I started over from scratch; according to file dates I think it looks like I started new sprites in mid-2006. I drew new sprites and new tiles, made new maps. I ported over some of the systems and rebuilt others. At this point I started numbering my attempts at Geas, optimistically starting with “01”, so just in case I hit my 10th rewrite the directories would still sort correctly. This version looked nice, I still think it does. I worked on this for a couple of years, until some time in 2008. I sat down and worked out that at my current rate of work, it would take me dozens of years to finish.

Cutbacks

That was more than a little disheartening. I decided to change tack, and mercilessly cut huge swaths of what I’d added. I didn’t want to go back to the single “first chapter” idea, because I’d thought too much about the rest of the world, but I cut back the seven chapters to three, and the twelve playable characters to only five, and you’d only ever have access to four at once. The broad strokes of much of the story was there, but I cut out a lot of the later parts of it (which, conveniently, were also the least fleshed out anyway). I cut back the resolution to my old friend 320x240, and started over again.

This was version was what I posted about primarily when I was doing Gruedorf the first time. I made some decent headway, and worked on it until some time in 2010. As with the other versions, though, work on it (along with Gruedorf participation across the board) kind of petered out. Other projects, and other life things, started taking up more of my time.

It’s Just Sleeping

It stayed dormant for a long time. It never really left my thoughts, really, but I wasn’t actively working on it. It was always something I would do in the future, when the time was right. One of the things that I decided wasn’t right for it, anymore, was Verge. Like Geas, it had dried up and development on it basically ceased. There were enough eccentricities and problems with it that I didn’t want to go back to it. I started investigating other things, with the idea that I would eventually get to it.

I tried a few engines, I built a few, even. The most recent was Cozy, a web-technology-based engine. It owes a lot to Verge, really, both in the way I structured things, and many of the things I made them the way they are because I wanted to fix a problem I’d always had with Verge. I built SimpleQuest in that engine, but in the back of my mind what I was building was the Engine That Would Be Used For Geas. I built it, and I released SimpleQuest.

I’d poured a lot of time into building Cozy into the engine I wanted to use for Geas, and I love a lot about the engine. Once SQ was out and done, though, I took some time to really look at it, and see if it fit what I wanted for Geas, and I decided that it didn’t. I was also sick of spending time building engines; looking at Cozy, I saw years of tinkering and tweaking and support, not jumping into more games. That’s why it’s on hiatus, and hasn’t been touched in some time.

I learned a lot building Cozy, though, including what parts of making the game I enjoy and am good at and can do quickly, and which parts I fail at one of those. It also helped me realize that I just do not want to build my own engine. It’s not that I can’t (obviously), it’s just not where I find joy in making games. So I went back to looking at engines. I made myself pro-and-con lists for various engines. There were strong contenders, and I started building prototypes, but I ultimately settled on Godot. It’s not perfect, but it’s the best fit I’ve found so far.

So, back to Geas!

Well… not quite.

What

When I decided to work with Godot, I built an RPG prototype. A little dungeon-y thing that had no real “game” or “story” to it, just a map that had the various things you might do in a Zelda-style game in it. I was satisfied that I could build an RPG in it, and would be reasonably happy doing that. And then I built something else.

I was still looking for excuses not to start on Geas. At this point, there’d been 15+ years of thought and work building it up into a Very Big Thing, and so I looked for reasons not to start on it. Last September, though, in a conversation with friends I realized what I was doing, and I decided it was time to just stop. To stop looking for a reason to avoid it, to look for other unrelated games to make first, and to make a real step towards it.

First thing was to finally document some things. I’ve been holding a lot about Geas in my head, and not keeping it written down. Don’t be like me, kids. I know have the majority of the plot and other ideas I’ve had kicking around written down (unless I forgot them, in which case they are lost to time).

One of the thoughts I’d had in the years about Geas is that Journey to Black Mountain, the initial game, is actually pretty important to the overall character arcs of many of the main characters. The further Geas got from “the next compo game I made” the more it seemed important to make that story accessible in some way other than digging an ancient Verge game out of the archives. I toyed with the idea of making it a small game-within-a-game as a flashback, or something like that.

I decided that, to really make progress toward Geas, I would start with remaking Journey to Black Mountain. I’m keeping the setting, the characters, and the overall point of the plot from the original and throwing out the rest. I’m using this as a way to build a “chapter” of the larger story, and I’ll release it as its own thing. The idea is to cement my understanding of the engine, build myself a library of code and art to lay the foundations for Geas, and to get something out there so I can tweak the foundation so Geas has the best shot it can get.

Black Mountain

So to that end, I’m now building Black Mountain, a complete rewrite and rebuild of the original Journey to Black Mountain story.

I’m working with placeholder art now, that I’m making entirely myself. Current goal is to get a complete end-to-end “draft” version of the game done as quickly as possible, and then figure out how to polish it into a real game. Future plans include potentially another “prequel” game, and then Geas, broken up into chapters and released as such. I’m not entirely decided on whether I’ll keep a stripped down version of it, or go back to the full thing, but I’m leaning toward the latter at the moment. For now, I’m focusing on making Black Mountain stand on its own and to learn as much as possible from it.

At this point, I actually have a lot of the foundational programming work done. Godot does a lot for you but it’s still a generic game engine, so I’ve been focusing on building all the parts I’ll want – maps, exploration, combat, items, equipment, shops, skills, etc etc. It’s pretty close to a real game. I have a bug list as long as my arm (and that’s WITHOUT extensive playtesting with others) and a few core things left to figure out (and procrastinating on those is why I’m here writing my Geas auto-biography). Once I get those sorted out, it’ll be full steam ahead on the draft assets and writing.

See you in a week, maybe.

Gruedorf Post 2021-02-28

• Can now add water polygons to the map
• Set up z-indexing so I can have multi-part entities that sort correctly
• Built a “follower” system for having party members on map, but commented it out
• Can now add shadow polygons to the map
• Drop shadows on character entities are not part of the sprite now, they’re an actual shadow
• Started work on hopping off cliffs

Water Polygons

While Black Mountain is a relatively low resolution game and the end result will probably be mostly pixel art, I am not trying to mimic any particular old hardware, nor am I holding myself to any sort of purity test. I am doing my best to avoid actual mixed resolution (because I personally hate it), but I am not going to avoid using modern conveniences like shaders or polygons to do things. The water can be added to a map similar to an entity, but by drawing out a polygon (which Godot’s built-in tools make pretty easy). It is animated, rippling slowly and wobbling the underlying tiles of the background, and I am able to give it a direction for the movement so I should be able to use it for (slow-moving) rivers as well.

Multi-part entities

One thing that I always find annoying with making maps is dealing with thin upright pieces – things that you want the character’s head to render in front of when they’re standing in front of them, and you want the character’s feet to render behind them when they’re standing behind them. To make this easier on myself I actually have a lot of “placeables”, which are basically furniture, and are just entities like the character sprites. I put them in with the sprites on the map layer and they get sorted appropriately.

Unfortunately, this means that you have to be careful with exactly how it’s drawn. Every entity has an origin – for the character it’s the space right between their feet. The origin is the y-position used to determine render order. If the character’s origin is higher on the screen than the placeable’s origin, it gets rendered behind. If it’s lower, it gets rendered in front.

But what about things like rubble strewn on the ground? A treasure chest with coins spilling out of it? This is fine as long as the “floor” layer of the sprite is entirely contained to below its origin, but that’s not always the case, and when that happens you end up with rocks, seemingly lying on the ground, floating on top of the player when they walk there.

To allow for this, entities can now have other parts. Godot has a built in z-index system that gives you an extra means of control over the render sorting that’s happening. It’s a little bit brittle; it’d be easy to make something draw entirely wrong. If I were worried about other people using this I would probably try to do something about it, but if I shoot myself in my own foot, well, I know who to blame.

Shadow Polygons

I feel like any game where you can see the ground beneath the feet of the character benefits from having a drop shadow. I had a drop shadow under the character before, but it was just a hand-sketched partially transparent circle.

The problem with partially transparent things, of course, is that when they overlap, you get a darker spot. This is fine for Venn diagrams but not so much for shadows. So to fix that, I added a shadow layer to my maps.

The shadow layer can have shadows added to it by an entity that lives on the map (or is placed there), and it can also just have shadows added directly to it by the map maker. It works by drawing all of the shadow polygons to a separate surface, and then drawing that surface all at once with transparency. As you can see in the screenshot, the shadows lie underneath the sprites and on top of the background layer of tiles… but it is underneath the foreground layer of tiles. The real assets for the game are going to have to be constructed to deal with this; I’m not exactly sure how I’ll do it but I’m confident I’ll figure it out and that’s good enough for this stage of development. Also for the future is to figure out the best way to make them softer-edged.

Because it was easy, I also added a way to look up if an entity is currently standing in a shadow (other than their own). If they are, I draw them darker too.

Showing Followers on the Map

I always go back and forth on how I feel about having the rest of the party shown on the map as you explore. I could do the classic thing where everybody marches in a line that perfectly follows the leader, but I don’t feel like that would fit with Black Mountain. I put a bit of time into testing something where there are other sprites on the map and they try to catch up to you, but I didn’t really care to make the pathfinding work correctly so they just kind of got hung up on things (I’m fine with monsters getting hung up on things, since it means the player can be clever and escape from them… it’s less great when your party members are too dumb to walk around a tree to catch up to you). I also realized that having them on the map complicates some of the things I’d like to add later… so I turned them back off. I’ve still got the code so you never know, they might come back, but for now you’re just driving the leader around the map.

Hopping Off of Things

One of the things I’d like is for Black Mountain to be a game that feels better to move around in, and involves the characters doing things outside of combat on the map. This is driving a few of my core decisions about the game, and in a sense it’s pushing it a bit away from your traditional jRPGs towards an action RPG – getting a little Zelda in my Final Fantasy, if you will.

To that end, I’m going to be adding some of the staples of more action-oriented RPGs. The first was to add the ability to jump down off of cliffs. The intent of doing this is actually what drove the shadow separation work I rambled about above (along with wanting to deal with the overlapping polygons), so that I could lift the player sprite up off of their shadow to make it seem like they are falling or hovering.

This isn’t quite done. I have the hop and the fall, the shadow separation, etc working, but I’m stuck on the nitty-gritty of figuring out exactly where the character needs to land when they jump off. I know roughly what I want to do, I just need to make sure that the plan doesn’t wind up with the character stuck in a wall or being annoying to set up. Since I’m largely ignoring the grid for a lot of Black Mountain, I can’t just cheat by saying “jump down by 3 tiles”.

That’s it for now! It was actually a pretty productive week, all things considered, even though it felt like a bit of a slog at times. See you next week!

Whatever it is you do/did for the holidays, I hope it’s been enjoyable and relaxing.

Here’s hoping for 2019.

Gruedorf Post 2021-03-07

• Finished cliff hopping
• Added gap jumping
• Added block pushing
• Added blocks being pushed off cliff kind of
• Broke everything, rewrote collision handling/movement code
• Shouted my frustration at the cold, uncaring universe

Different Events

There are two classic, straight-forward styles of events in RPGs: I call them “step events” and “triggers”.

Step events are your classic events (like Verge’s zones) where when the character enters the event area, some sort of effect happens. This is good for map boundaries, stair cases, triggering cut scenes when the player character steps in a particular place, etc. (Technically my step events have some configuration which mean I can differentiate between events that I want to happen when the character just touches the edge of the event area, or if their center-point has to be inside of it; which one I use will depend on how I want to tie it to the visuals of the world.)

A trigger is something where the character must face the event area, and press a button to trigger it. These are often solid (though they don’t necessarily have to be), and are used to model doors, switches, people to talk to, soemthing interesting lying on the ground, etc. They’re something that the player is choosing to interact with directly, by pressing a button, rather than something that just sort of happens to them because they stepped in the right (or wrong) place.

I decided to add a third event that seems to be most prevalent in Zelda games, that I’m calling a “push event”. The push event has to be solid, and when you bump into it at first it acts just like a wall. After you continue pressing against it, though, then I run the event code. It’s not rocket science, but it gives me some fun things I can do with it, like requiring you to commit to jumping off of a cliff before actually doing it, or adding weight to blocks you can push – things that are in between just moving around and intentional interaction. They can keep moving through the world with only a brief interruption but also where they won’t just be flinging themselves off of cliffs or kicking boxes out of the way just because they stepped a touch too close.

So, with that I have a couple of things working now…

Hopping Off of Cliffs

I mentioned this last week, but it’s finished now. When you push against the top of the cliff polygon, it figures out where the bottom is and plays an animation of you hopping down. Right now the height can be arbitrarily tall, but it wouldn’t be difficult to add a check for height if I wanted to. If you push against any part of the cliff that doesn’t have a “bottom” below it (e.g. the bottom of the cliff) it ignores the push and just treats it as a wall.

Jumping Over Gaps

Similar to cliff jumping, you can also define a “gap” that can be jumped. Rather than jumping vertically to the bottom, it projects across the area instead and jumps you to the other side if it’s close enough. Similar to the cliff height caveat, the jumpable gap size is currently fixed (to one tile) but could be modified by an item or skill or whatever in the game.

Pushing Blocks

Entities can also be set up to receive pushes, and they work like a push event but can also be moved by the event handling. I haven’t tried it yet, but these could be set up to trigger (some) events when moving, so it should be pretty straightforward to make the classic “push a block onto a floor switch” kind of puzzle! I just need to make sure I don’t inadvertently create the “push a block out of the map and it’s gone forever” kind of puzzle. I could probably leverage this for general NPCs; there’s nothing more annoying than a villager standing in the way and you just kind of have to wait for them to decide to wander out of the way.

Pushing Blocks… Off of Cliffs

I said that I haven’t tried to set up a block “stepping” on a button yet, but I wanted to immediately tackle having blocks that are being pushed trigger other push events – specifically to have them trigger a cliff jump. It actually just kind of worked once I got everything hooked up! Except when it didn’t.

Sometimes, the push just wouldn’t register with the cliff. The player kept being able to trigger it, but the block was inconsistent. I narrowed it down a little – it seemed like the more “flat” the cliff edge was to the block, the less likely it was to trigger the event. It seemed like the issue was rooted in using Godot’s move_and_slide(), a built-in function for kinematic physics bodies which produces (close-ish to) the kind of movement I wanted out of the box… except that it for some reason it was now causing issues.

Rewriting Collision, Again

I hate writing collision and movement code. When I was building SimpleQuest I actually just kind of stopped working on it for weeks (maybe months) when I hit this wall. I didn’t want to ruin my streak of work so I just plowed in. Thankfully, things are a bit easier for me this time. But not much.

It turns out move_and_slide() is a wrapper around a lower-level movement function, move_and_collide(). I didn’t especially want to write all of my own collision detection code (since it would be an enormous waste and of time and it would almost certainly be slower than using the built-in facilities, and most importantly it came with the risk of just killing my forward momentum entirely) so realizing there was a lower-level thing to fall back to was a relief. I just need to deal with the collision resolution, not the detection.

So I re-wrote the resolution. Unfortunately, push events and push events triggered by pushed objects present a lot of issues. In particular, the sliding block will begin colliding with the player first, when squeezed between the player and a push event. This means the push event never really gets the collisions. I suspect this is what was happening internally within move_and_slide() as well. Maybe! Who knows?!

Anyway it was very frustrating but after a few hours of trial and error and reams of debug logging, I think I have it mostly working now. I’m sure I will (unfortunately) have to revisit it some day (I already know it’s not working exactly how I’d like), but at least it’s kind of there now, and I can move on to the next thing. Hopefully next week will be smoother sailing.

Gruedorf Post 2021-03-28

• Brainstormed about how I want to handle skills
• Start implementing that

Brainstorming

I wrote some last week about the trouble I’d been having with deciding how I wanted skills etc to work. I waffled a lot, and eventually started building pros and cons lists for various approaches. I ultimately ended up going with a fairly traditional route, and deferred a lot of the more unusual ideas I had for future games. I certainly could change my mind, but for now I at least have a way forward.

And Finally, Progress

I spent basically all week reaching the decision and finally came to it today. So I started implementing SOMETHING so at least I’d have a little to show off.

I’ve had a “Status” section in the menu just kind of hanging around with debug information in it. I wasn’t really sure what to do with it, but I realized that I could finally put it to use. The status section will have three (for now?) sections in it: the default info section, the “spend XP” section, and the attributes section. I may actually move these around and change what the default is, but that’s going to need some playtesting to figure out how these actually flow in practice.

The info section is pretty straightforward – it shows you info about the character. I’m undecided exactly what I’ll put here, but I’ve written a couple sentences of backstory for each character. I may add more random “demographic” information here, or I may add other interesting stuff. Not really sure yet.

Spend XP is where you’ll be “levelling up” your characters. There isn’t a traditional level system in Black Mountain; instead you use XP to buy skills and passive upgrades and such. It isn’t displayed super well at the moment, but there’s a hierarchy of upgrades you can buy, as well as levels of each. The available trees of upgrades depend on the character’s available classes and equipment. I had actually built this interface a while back, but it lived under “Skills”. I’ve moved it here, though, and will repurpose the Skills section into where you actually use your skills outside of combat.

Speaking of skills based on equipment, as I rambled about on twitter a while back, Black Mountain and later games will not have the standard jRPG equipment “treadmill”. I wanted to avoid the classic jRPG silliness of “Here is this amazing legendary sword! … That you will sell to a merchant in two hours because the sword you bought at a merchant in the next town is better”, and strive for something a little more in line with epic fantasy books. A characters’ core equipment will be a part of them, and will grow along with them – changing equipment will happen only very infrequently, and usually as an “upgrade” to an existing piece of equipment or as an expansion of options, rather than replacing them. In Black Mountain, for instance, Kiel uses the sword that her father left behind when he died; it would be ridiculous for her to just toss it aside partway through the journey. Since the equipment is more-or-less fixed (or, in later games, a very small pool), it functions partly as the character’s “class”, and so the character will have skills associated with that particular weapon. (Coincidentally this also happens to mean that I don’t have to worry about inconsistent art for different weapons.)

The last section, Attributes, isn’t done yet. It’s where I’ll show the character’s stats, but I haven’t started work on it yet, so no screenshot. I’m considering switching this to be the default screen, rather than the info section, since the info section will be (relatively?) unchanging, while Attributes may have things the player wants to check on every now and then.

At Least I’m Moving Forward Again

The last two weeks haven’t been great, but I’m glad to have made a choice. Hopefully I’ll be back to my usual productivity next weekend.

I went and made my own engine and released a game with it. Nothing big, just a little freebie on itch – https://speveril.itch.io/simplequest. I’ve got plans for more engine work (maybe even a release that other people can use!) and more games there.

The engine is pretty different than Verge in a lot of ways, but its design is definitely informed by Verge… stuff I liked and stuff I didn’t like as much. :)

I’m also still occasionally helping Grue with Sully but I’m kind of a flake there. Sorry, Grue.

Gruedorf Post 2021-03-14

• Added wall climbing
• Added block pulling
• Made a floor switch that clicks down when the player steps on it or puts a block on it
• Added push/pullable block constraints
• Broke wall climbing somehow
• Fixed wall climbing

Unfortunately screenshots don’t demonstrate most of these super well, but I’ll do what I can.

Wall Climbing

I can now define an area as climbable. If you push against the top or bottom of it, you’ll switch to climbing mode (which currently does not have different art) and you will be able to climb around on the surface. It’s a bit jittery and weird and I haven’t fully put it through its paces so I’ll have to revisit it at some point, but it’s working for now.

Block Pulling

I’m not making a sokoban game. I don’t necessarily want or need to derive a lot of difficulty from constraining exactly how the player can move blocks around, so some (most?) of the time I’m going to want to allow them to pull blocks when they’re able to push them. This will cut down on the possibility for the player to get stuck on puzzles; it’ll also severely curtail the actual allowable difficulty for the puzzles, so it’s something I can toggle individually for a block.

While I was at it I also made it so you can toggle pushability as well, so I can have pull-only blocks. The screenshot may be a little hard to parse, but that block has a sort of debug-graphics black bar that stretches into the wall; when you let go of it, the whole thing will slowly retract back into the wall.

Floor Switch

Having step events (as described last post) isn’t new, so this isn’t that novel, but it’s got a satisfying click to it when you step on it, and it visually changes to show it’s depressed. More importantly, the block can also push it down (but it’s even harder to get a meaningful screenshot of that than it was with the player stand-in sprite).

Block Constraints

I am able to add solid obstructions to a pushable block that constrains it from moving. These constraints are in addition to any normal solid walls, but they don’t block the player (or any other entity) from moving around. The dark polygons on the ground below both blocks in the above screenshots are just visible polygons to help me ensure they’re working correctly, the space constraint obstructions are normally invisible.

That’s All!

That’s it for this week. After the debacle of last week’s collision stuff (and the knowledge (which turned out to be correct) that I would have to delve back into it a bit for this stuff), I kind of dragged my feet on getting into it this week. I’ve got a few more map-interaction “primitives” like this stuff that I need to build, and a few that are on my “maybe” list, and then I’m mostly left with a few small features, a bug list, and “actually building out the story”. I’m looking forward to getting to that part.[0_1615760291123_climbing.mp4](Uploading 100%)

Gruedorf Post 2021-03-21

• Made a liftable block
• Changed my mind about how some things should be implemented
• Fixed liftable to fit the new way
• Angrily stared at some docs and my todo list, a lot

Lifting Blocks

To go along with pushing and pulling things, you can also now lift them, and then put them down.

The “liftable” entities play a quick lifting movement animation, which will eventually be accompanied by an animation from the character, and have the player character lift up their arms, but that’s for later. When the character puts the pot down, it triggers floor switches just like a pushable block.

Changing My Mind

Pretty much immediately after getting liftable entities working, I realized that I wanted to implement them in a different way that is more flexible. There was something more pressing to work on, and they worked! So I decided to move on.

But then, once I actually confronted the next thing to work on (see below), I decided to switch back to it and see how well the different implementation worked, and whether it was a lot of work. If it worked out, then I’d probably want to make the same change for pullable/pushables. And it did work out! I haven’t made the change to pullable/pushable blocks yet, but I will. I decided I needed to stop putting off the bigger decisions I needed to make.

Decisions

So far I’ve been implementing a lot of stuff that I’d already decided on, or seemed obvious to me – things like how equipment would work, or just basic navigating around a map. I’m starting to run out of the obvious things, and a big core part of the design that I’ve been been putting off is now an impediment to getting more done.

Black Mountain is intended to be the first in a series of games. As such, I’m building as much as I can with an eye toward re-use in the future. I am not making myself build everything I might ever want in Geas, but I am trying to at least work in that direction. Part of what I want is to have a world that’s a little more reactive than your average jRPG; rather than just invisible monsters, things that wait around to have a button clicked at them, and the ability to script some cutscenes, I want the world to have a bit of logic and physics to how the player interacts with it.

This is what’s been driving my attempts to let you maneuver gaps and cliffs naturally, pick things up, push things around, etc. Some of the things I’ve got planned for the bigger picture I have intentionally put off for this game, which is fine, I can fill them in later.

What I need to actually figure out, though, is whether there are items and skills that the player has that they use out “on the field”. Think of tools like the hookshot or the hammer in Zelda; they can be used as weapons, certainly, but they add specific and meaningful ways to traverse and manipulate the world. I don’t have a clear vision for how I want this part to work; either what tools and skills I want available to the player outside of combat, how different characters and equipment play into it, or even whether I even want to deal with them at all. Once I decide that, I can probably figure out a reasonable stripped down version for Black Mountain, but without a strong guiding idea I’ve been floundering a bit trying to figure out how to begin figuring it out.

After a few days, I am making slow progress on the decision, so I’m not completely stuck at least. I’m currently mapping out the choices I have to make, what options I could choose, and working out the implications of said choices. What I decide will end up tightly intertwined with building maps, combats, and the general minute-to-minute tension of the game, so I want to at least come up with something that feels right on paper, even if it has to change later.

Gruedorf Post 2021-04-11

• Figure out that I’ve been drawing maps to the wrong intended scale
• Figure out what the right scale is and how to draw them
• Start building out the first “dungeon” map

Maps

Maps! They’re hard. I’m building them in a bit of a strange way.

Since I’m not building the final maps for the game at the moment, I am trying to develop a workflow that strikes a balance between a couple of points:

1. It has to be relatively fast
2. It has to be relatively easy to change
3. It has to be something that I can give to artists and they can understand it all well enough that they can see how to improve it (and hopefully enjoy it as-is)

I would normally just make some tiles and use tilemaps. That’s something I pretty familiar with, but it turns out… I’m not actually very good at tile art. It takes me a long time and I fuss with it a lot. I could just use some coloured squares, but then I’m losing out on my third goal – it’s not clear what things are. I could FIND some tiles to use but I have a terrible problem that if I sit down to find “relatively good” tiles to work with, I end up looking for the PERFECT tiles. I also don’t want to be constrained by what someone else decided to put into their tileset (and if I let myself start drawing my own tiles then we end up back at the beginning of this paragraph.)

While I’m not a great pixel artist, I am semi-competent with a pencil. All of the art you see in the game so far (in earlier posts) has been drawn by me (I primarly use a Huion tablet and Clip Studio). So I’ve also been pencilling the maps.

This COULD lead to a lot of terrible waste. The first part of the game is set in a forest, so rather than signing myself up to spend the next ten years of my life drawing trees (though I’m sure I’d be quite good at drawing trees by the end), and to avoid having to fight with pasting things in the right order, I’m still using a “tile” engine internally. Godot’s Tilemaps, to be exact.

The other problem with pencilling something is that it is very easy to focus on one thing and ignore the larger picture. With tiles this is kind of okay (most of the time) because you’re focusing on some details in a tile and then piecing together the larger picture late. If you’re actually producing a map’s layout and its “pencils” in one go, though, this isn’t good. It’s a work in progress, but I’ve been gradually refining the process…

The Process

First, I start in Clip Studio. I’ve got a file where I am drawing the entire game (well, it WILL be the entire game eventually) in one big image, with blocky pixels. It’s drawing at roughly a one-fifth scale, and it looks kind of like this:

As you can see it is very light on details. I’m doing some mental planning as I work on this, and have some references within other documents (mostly in Google Drive so I can peck something into them from my phone if I come up with an idea while I’m not at my computer), but they’re quite messy. The grid is a grid overlaid by Clip Studio and it is very very roughly set at about one tile per square.

Since I have all of the maps in the one image, I can also make sure that they line up and roughly fit with each other. This is important to basically no one in the world other than me, but I like that I can do it.

When I decide to move further with a map, I make a new image that is 1:1 full size for that map, and I clip out the section I’m working on from the big “complete game” image, and blow it up to the right size. Then I start pencilling in the shape of the map over it.

I actually work with the rough map more transparent than in the image, but I upped the opacity so it was more obvious. I’m drawing in red because there is a psychological effect that black lines seem more “finished” (or so I’ve heard), and I want this to feel like a draft. It’s just a pencil drawing, so it’s not set in stone.

You’ll notice that there are some features drawn on the map, but I mentioned this is supposed to be a forest. There are no trees! Earlier in development, I pulled out three sizes of trees (cleverly named “small”, “medium”, and “large”), and I’ve divided them into the “below the player” and “above the player” parts. It turns out that Godot’s Tilemaps have a very loose definition of what a “tile” is. It can be any image – whether or not it’s the supposed size of the tile. This means I can just treat my two pieces of tree as tiles on two layers.

So I import my pencilled map into Godot, and then start dropping in the reusable parts like the trees. If they are thing that should exist on the same layer as the player (e.g. a barrel that you can both walk in front of or behind) then I have a separate “entity” layer for them.

The last step to make it useful is to put in the obstructions. I use CollisionPolygon2D instances for this, which Godot has native editing support for. It makes things very colorful.

Then I run the game and wander around to see if I messed anything up! (Spoiler: I usually did.)

Going Forward

I’ve got a lot of map drawing ahead of me. I’m not really entirely sure about this process yet; I’m worried it’s not quite fast enough. This won’t necessarily make for very exciting Gruedorf posts!

But that aside, my next several weeks will probably be a bit constrained anyway. My wife and I are gearing up to move in the while, so we’re doing the whole finding-an-apartment-and-packing-everything-we-own thing. I’m going to do my best to still post on Sundays, but I probably won’t take the time to ramble nearly as much.

Gruedorf Post 2021-06-20

• More maps
• A droppable ladder

Sunday

Hey, did you know it’s Sunday? I forgot.

Ladders

One thing that I appreciate in map design is when you traverse a map multiple times, but when as you go through you open up little short cuts for yourself. I’ve actually implemented the first instance of this in Black Mountain; a rope ladder.

You first encounter the rope ladder rolled up at the top of a cliff. There will be a small cutscene drawing attention to it (mischievous forest spirits up to no good, naturally). You’ll go far, far out of your way to work around a different path and eventually come to the top of the cliff.

If you use the ladder, it’ll flop down, and what was an impassable cliff is now a climbable area.

Aren’t you clever?

This will be useful, because just north of this area is a small boss fight (mischievous forest spirits, again) and then a town. In the town you will be tasked with doing something that involves returning to the forest and unlocking a new area – I certainly don’t want to have to walk all the way back through a damp cave system to get back and forth while testing, so why should I make the player do it?

Gruedorf Post 2022-03-16

• Made most of an entirely unrelated game.
• Released a game I wrote years ago, finally.
• Tried a couple of things in Black Mountain that weren’t definitely wins, and put them on the back burner instead.
• Made myself some handy debugging UI in-game.
• Updated and added functionality to my cutscene framework.
• Wrote and implemented (real, but draft) cutscenes for the beginning of the game.
• Investigated how to handle localization in the future, and left some proof-of-concept stuff in place.
• Reworked parts of the combat system and redrew the art as necessary.
• Added a timer that keeps track of how long you’ve played this save.
• Added the first pass on new “wander within an area” behavior for entities.
• Fixed a bunch of bugs.

There’s a lot to talk about, so this is a long one; it’s been a while. I left my full time job (which I’d been at for more than a decade) in mid February, and while I’m not exactly sure what my time looks like in the long term, for now I’m taking a break and focusing on my own stuff for a little while. This means the last couple of weeks has been particularly full of development, I just hadn’t gotten around to writing anything.

Other Games

I released a game I wrote years ago on Itch. It’s called “The House”.

You can play it in your browser.

It’s a “Halloween game” – it’s not particularly scary or anything but it is, I guess, “mildly unsettling”? I started this back in 2015, and had most of it done some time around Christmas. Since I had missed any useful window for releasing it, I think I got my mom to play it and didn’t bother to release it more widely than that. (That’s not a joke.) It’s also built in probably the dumbest possible way to build an IF game in a browser.

I also spent a week or so building (in a somewhat less stupid way?) a nostalgic love letter to a 1979 game called xn--The Wizards Castle-qq9j (and a handful of other names over the years) – I call my version “Zot”.

I played a lot of an MBASIC port of the game when I was a kid, on a computer slightly older than me. I’ve actually remade it before, as some hard drive spelunking recently reminded me, but I figured it’d be quick to remake and the old version was for DOS.

Anyway, it’s not done, and I decided to stop using it as a reason to procrastinate on getting back into Black Mountain. I might still pick at it every now and then, but it’s not my focus. When/if I finish it, I’ll probably release it for free on Itch like The House.

Debugging UI

The game is pretty big now, and I’m not just working linearly through a bunch of maps, so I decided I needed some more debugging/“cheat” controls within the game. It’s pretty easy to bash together a UI in Godot as long as you don’t actually care much about how it looks, so I just did that. It even has a tabbed interface and everything.

The first tab is the flag manager. Internally, the game just has a big table of key-value pairs that can get set and checked (in code or in cutscenes), which automatically gets persisted through save game files. Not exactly ground-breaking stuff, but it works. All this panel does is give me a way to edit/create flags so I can bump around where exactly I am in the story or whatever, so I can re-trigger an event that I just ran or test different branches easily, that sort of thing.

The second tab is for jumping to a different map. One thing I’ve always despised in building a 2d RPG is having to carefully figure out an exact coordinate to drop the player on when they switch maps, and then put that coordinate in the map switch call. If you change the structure of a map, you have to go and find all the references to it in all the other maps’ code (or wherever those live), and change them. Instead I opted to put simple invisible nodes, “entrances”, and when you send a player to a map, you send them to an entrance instead – the player’s entity inherits the position, facing direction, and layer parentage of the entrance. It also makes it convenient to query and list all of the possible entrances to a map, which is what this list gives me. I can open the “accordion” for any map in the game and click an entrance, and it triggers a map switch to that entrance. Handy for hopping around to test different things.

(I should say that TECHNICALLY you can still send the player to a specific coordinate on a map rather than an entrance, but it’s a lot less convenient and I mostly only use it for internal stuff like loading games.)

I’m thinking about adding another tab with all available cutscenes and letting me trigger them, but that’s a little trickier. Not technically, but being able to trigger a cutscene anywhere you want would be a bit wonky since they will, by their nature, be written to work on a particular map and at a particular location. Might be worth it anyway; it’s just debugging stuff, after all.

Cutscenes

Black Mountain is a fundamentally story-driven game. One thing that I have always found both interesting and frustrating to work out is a good way to define a cutscene. In this case, I’m using “cutscene” in a pretty general way – anything where the player is not engaged in moment-to-moment decisions or direct control. In particular, I’m always striving for some particular things:

• I want a good way to be able to have as little boilerplate as possible in my cutscene definitions. I find it hard to write interesting scenes and program at the same time. Yeah, I won’t be able to completely get away without any “code” whatsoever, but I want it to fit as naturally into the writing as possible.
• I want to easily be able to set up things that do not complete immediately and wait for them. Something as simple as making a sprite walk a couple of tiles before popping up the next textbox can be surprisingly annoying to do, and often requires a lot of boilerplate (which I don’t want).
• I want to be able to do multiple things at once. Even worse than waiting for one thing is waiting for multiple things, especially when those aren’t trivial “things”.

I don’t know if I’ve necessarily built the best thing to handle all of this, but I do like what I’ve made. (I do wish I had encountered Dialogic earlier – if you yourself want to solve these problems, I suggest checking it out instead. It might work for you, and be a lot less work than what I did!) What I’ve ended up with is essentially a Domain Specific Language (DSL), which lets me load any number of .txt files, parse them at load time into an array of objects (that are essentially opcodes with arguments), and then trigger them whenever I want, by name.

The .txt files look something like this:

# Lines that start with a # sign are comments. I haven't bothered to implement comments that
# start some time later in the line, largely so I don't have to worry about escaping #s if I
# decide to use them in dialog or something.
    # Note that whitespace at the beginning of a line is ignored in all cases, so indenting
    # comments, or any other piece of the script to help with readability, is fine. Similarly,
    # blank lines are simply ignored, so you can space things out if you need to.

# A line that starts with a $ starts a scene; I'll use this name in an event to run this
# cutscene.

$ Scene Name
    - A dash shows a text box with no "speaker" defined, for narration or whatever.
    <Kiel> This is a dialog box, using Kiel's name and her portrait (if available.)
    > This would be a continuation of the previous dialog box, after the player hit a button.
    
    <Violet:sad> I can have variants of portraits; in this case the ":sad" will get stripped off and Violet's name displayed.
    > If there is a "sad" variant of Violet's portrait, it will get used.
    > If there is no "sad" variant, it will fall back on Violet's default portrait.

    <Some_Guy> For technical reasons, names can't have spaces, so I convert _ in a name to a space for display.
    > Also if there is no portrait for someone, it'll still show a name for the speaker but no portrait.

# A single file can contain as many scenes as you want; being able to load multiple files is just
# for convenience and organization.

$ Some Other Scene
    # ...

In addition to showing text boxes, I can…

• move entities (including the player and the camera) around the map (including walking around, changing movement speed, facing different directions, teleporting them to another location, switching maps, etc.)
• add temporary “puppet” entities to the map, with a specific name, that get removed at the end of the cutscene
• add and remove characters from the party
• play sound effects or change the music
• give items to the player and change character equipment
• start a combat
• set story flags
• branch based on flags (as described above in the debug UI stuff)
• run multiple chunks of script in parallel, waiting on all of them to finish before moving on
• etc.

There are some bits of functionality I know I’ll need that I haven’t thrown in there yet, but it’s pretty robust at this point. A couple of future things I want to do is be able to load different cutscene files based on the current language/locale being used, and also be able to compile the .txt files into .gd files that simply define the cutscenes directly in the object/opcode form – it’s very convenient right NOW to be loading text files but I don’t really want to parse those unnecessarily every single time the game launches. You can see a lot of this in action in this video of the first 5 minutes (moreorless) of the game:

(Note that the music is currently placeholder – it’s public domain stuff found on OpenGameArt by the fantastic Juhani Junkala/Subspace Audio.)

Let’s Fight

With the beginning cutscenes blocked out, it was time to start tackling the next thing – fixing up the combat system. You can see a bit of it in the video above, but it’s rougher than the rest of the game, and so I started working on that. I decided I wanted more space on the screen, so I needed to make some things smaller, and there’s a lot of cruft internally from the various iterations I’d gone through. Also, as funny as that monster graphic is (to me), I was getting awfully sick of looking at it.

I was originally going to have a “heart” based health system rather than a more traditional HP system, but I decided to ditch that. The energy system was also going to be somewhat different but I realized some systemic issues with it that led some of the overall game and dungeon design in directions I didn’t want, so it’s a little more standard now as well. The bar (still to be implemented) is an adrenaline gauge system similar to a fighting game, where more adrenaline can empower special attacks and/or change how the character fights at different levels. I also replaced the constantly-ticking active time battle system with a visible queue of actions – it’s actually pretty much the same system but instead of filling up meters as time passes, it just pre-calculates the next X turns, so you can see when each character will be acting.

There’s still lots to do, but it’s coming together.

Wandering Monsters

I have a class of objects that I call “behaviors”. They’re nodes, or areas, or whatever, that you just drop into an entity on the map. Then, when the entity is being processed each frame, those behaviors get a chance to control the entity (in the order that they’re in the scene tree as children to the entity). Previously, I had three available behaviours: “look around”, “chase”, and “fight touch”.

• Look around simply stands in place and randomly changes direction. This is actually changing the facing of the sprite, so the entity is visibly “looking around”. It also doesn’t just pick a new direction and snap there, it will interpolate to the new direction over time.
• Chase adds a vision “cone” to the entity, and if the player enters that cone then the entity starts chasing the player. Almost, anyway – the behavior actually checks to see if there are any walls or other obstructions between the two, and will ignore the player if the sight is blocked. If the player gets out of sight (either by escaping the vision cone or ducking behind a wall), the entity will continue to the location it last saw the player, and then look around. If it has lost sight of the player completely, it gives up and stops chasing them.
• Fight touch just means that if the entity touches the player, it launches a combat. The behavior has the set up of which monsters at what position on teh battle screen.

Using these, and the fact that the behaviors will attempt to execute in a particular order, means that I can naturally express “fight the player if I’m touching them, chase them if I see them, and just look around if I don’t” just by dropping nodes into the entity. Also, changing the children (or just the order) in response to some other event means they could change what they’re doing based on whatever.

Anyway, so I also added a new behaviour, wander. The wander behavior needs to have a reference to a special “territory” polygon, and then the creature will simply pick a random location in the territory and, assuming it’s actually able to stand there, it will beeline straight for it. Once it arrives, it will immediately pick a new target location. This leads to my monsters sprinting around their territory in a frenzy, and also there’s no path finding or accounting for complex shapes, so it definitely needs work, but! This means that by dropping in a wander behavior instead of the “look around” behavior, I have monsters that will wander around, chase you if they see you, and attack. It’s another system that I’m pretty happy with how it’s turning out to be flexible and sensible as I work with it.

And then…

Anyway, so I’m spending a lot more time on Black Mountain these days than I was. Hopefully that keeps up! I’ll try to get back into this but we all know that the surest way to kill a blog of any sort is end every post with “I’ll post again soon!” If it comes down to it, I’ll always choose putting time into the game over posting a devlog… but maybe I can find a bit more of a balance, at least?

Have a good week.

Gruedorf Post 2022-01-09

• Drew a bunch more interiors
• Did a bit of a style test on a sprite

The last week has been pretty productive in terms of “work done” but honestly not a lot interesting to talk about.

Interiors

I finished the remainder of the story-important interior maps (assuming I don’t realize I missed some).

As you can probably see, these little homes are mostly built out of reusable pieces. This is because I got tired of drawing maps in the least efficient way possible! I’ve been experimenting with my scatter system to see how far I can push it and, in a pleasing turn of events, the answer seems to be “pretty far”. As an example, the smaller chairs visible in the various houses are all actually a single type of “scatter” as far as my tools are concerned, but you’re able to set the frame you want and flip the sprite, so they’re pretty convenient for bashing together a map quickly.

A Sprite

Quite some time ago I was trying out a sprite style for Geas and I drew a sprite of Kiel; just a single frame, sadly. I happened to run across it the other day and remembered how much I liked it.

Unfortunately this is made for a different resolution than I’m targeting with Black Mountain; it’s built for a 32-pixel tile (which would be about right for a 480p resolution). For Black Mountain I’m using a 24 pixel tile (because that fits a 360p resolution, which I’m using because it upscales to actual widescreen HD resolutions properly). The design is also wrong for Black Mountain; it’s an older Kiel who has gotten somewhat more confident and past her awkward teenage years.

So anyway I sat down to try to recreate a similar style, but for the smaller tile size and the right design.

I’ll probably still go back in and mess with it some, and then of course there’s the whole problem of it still only being a single still frame, but I’m glad I did it. It’s nice to remind myself occasionally that the game isn’t just going to be a sketchy red mess forever.

So What Now?

With the maps above complete, I am done the bulk of the (story-necessary) map making for the game. I’ve got two big projects left on this version of the game: Fill in the “game” bits, like puzzles and combats, and fill in the story. (After that, of course, I have the general “clean up and make sure everything’s in that I need in”.) I’m sure that I’ll need to tweak the maps as I go somewhat, but I’m hoping that won’t be too difficult. The danger with the way I’ve been building these maps, of course, is that if I need to substantially change a map’s structure I have to go back to Clip Studio and start moving things around – as I’m sure I’ve rambled about in the past, this is why I’m doing the whole “sketch” version of the game. Especially as I’ve been trying to switch to building more maps out of reusable pieces, this should hopefully not be too big a deal. So this time next week I will probably be griping about how my cutscene system has bitrot or something.

Have a good week!

Gruedorf Post 2022-01-02

• Neglected to post a devlog for a month
• Completed an interior area
• Reworked some level flows

Happy 2022, everyone!

The last month has been kind of hectic, and I was sick for some of it (no, not with that). I’ve managed to make some progress but haven’t gotten around to writing about it.

The Second Floor

The second floor of Black Mountain (which I mentioned a few months ago) is an abandoned town carved out of the rock. When pilgrims journeyed to visit the phoenix that lives atop the mountain, they would stay here. Unfortunately, like the rest of the interior, it has fallen into ruin and is now empty.

Or is it!? (It wouldn’t be a very interesting area if it was empty so you can probably guess that it is not.)

Some Miscellaneous Code Fixing

Since I am, fundamentally, much more of a programmer than an artist, I sometimes try to sort of side-step into getting some work done by tackling a small code issue or whatever. I’ve done that a few times, so my Entity Palette works a lot better now. I was having a lot of trouble getting Godot to actually generate preview thumbnails for the placeable scenes, so I read a lot about Viewports and the like and I’m now simply instantiating a little copy of the scene into the toolbar. It then also does some scanning of the scene to figure out how to automatically scale things so they fit into the “button” properly.

Getting the math right on the scaling was surprisingly challenging! Not because it was especially difficult, but my brain had temporarily stopped working, as it does.

Scatter Was Worth It!

Adding the “scatter” objects that I talked about in my last post was completely worth it. Much of the “dressing” of the rooms in the screenshot are, in fact, scatter, and while the bits themselves need some work, the workflow with them has been great, and it’s freeing me from having to hand-draw a ton of rocks, which I’ve gotten pretty sick of drawing.

Unfortunately, there’s not a ton more to talk about despite the long period between posts. Working on these maps is time-consuming, but I don’t want to show everything off. I’ll have to work even harder to figure this out when I get to actually filling things in with story. That sounds like a problem for later-Kildorf, though!

Anyway, hopefully I’ll be back in a week. Have a good one!

Gruedorf Post 2021-12-05

• Finished building a multilevel cave
• Added a “scatter” type

I couldn’t devote quite as much time to Black Mountain this week, but I still made some decent progress.

A New Cave

I have drawn most of the maps in roughly “chronological order” in terms of the order that the player encounters them. There is one particular cave (which you use to bypass a roadblock) which I just kind of… skipped when I was drawing maps earlier. Not entirely sure why, but it’s wired up now.

Scatter

And in making ths cave I just… could not bring myself to draw millions of rocks again. One thing that is a drawback of the way I’m doing maps is that it’s not like I can just play around with tiles until a cave looks as messy as I want; I have to draw each thing individually or go through some extra effort to set them up as entities. Entities are, internally, KinematicBody2Ds with their own collision information, they can move around, they have the potential to react to being “activated” by the player, etc, and I don’t really want to have hundreds of them in a map (even if, really, at least on PCs it probably won’t make that much difference).

Worse, since most rocks are tall enough to occlude the player character, I often have to draw each of those rocks in two pieces – behind and in front of the player. They also must be at least a whole tile wide or else you just can’t do that split correctly. This is also why I can’t really just toss them into the tileset. Trees also have this problem, but they’re big enough that they naturally split into a “stump” and the trunk/foliage. It’s kind of annoying to place two tiles per tree, but hey, it’s way better than the days when a tree was like 25 individual tiles on different layers!

Anyway, I decided to go ahead and add a new kind of thing; I only really need the art, they don’t need to move or have their own built-in collision or anything, but they do need some offset information and I want them to be easy to reuse. I called them “scatter”, which is a term I cribbed from tabletop miniatures. They’re the random crates and barrels and other junk that you can just kinda toss around the map to make a room look lived in. I had previously updated my entity palette (which I wrote about earlier) to allow for multiple sections based on subdirectories of my entities directory, so I just threw in special casing for a “scatter” subdirectory.

When you drag a scatter piece into the map, it finds (or creates, if necessary) a YSort node within the existing sprites YSort. I didn’t have to put them in their own subnode, but it keeps my scene tree a lot more manageable, since I can collapse that section.

I’m actually really happy with it. I’ve dressed up the cave pretty well with some boulders and some stalagmites, and it was significantly less work than drawing that all bespoke.

Miscellaneous Notes

• Remember that if a YSort node is a child to another YSort node, they will sort their children together.
• Godot allows you to enter a formula in its UI edit boxes – if you have a rect and you just want to move it to the right by 3 tiles, each 24 pixels wide, you can just edit its X member and write, e.g. 240+3*24 and it will convert to 312 for you.

That’s it for now. Next I’m going to be rearranging some of the Black Mountain maps a bit. I realized that I need to reorder the flow of the 2nd and 3rd level of the mountain to introduce doors and keys in a better order. Along with that I’ll need to actually draw some interiors (which I feel like I’ve mentioned every post for the last three months). See you next week!

Gruedorf Post 2021-11-28

• Got back to work on Black Mountain
• Imported all of the maps I’d drawn but not gotten into the game yet
• Fixed up some stuff I just hadn’t finished
• Some code refactoring
• Started drawing another cave

I had a week off so I got quite a lot done this week, and it wasn’t JUST playing Heretic.

Importing Maps

I had a big backlog of maps that were drawn but weren’t functional in the game yet. I sat down and got those all in. It’s semi-rewarding to do but still just kind of monotonous. You can now (I think) walk from the beginning of the game to the end! There’s no story in there yet though, just the maps, and some of the bits which are going to be light puzzles just let you walk through instead.

A Second Look

It also let me see that I just kind of… had stopped halfway through some of the maps. It also let me take another look at the flow of the maps – I’ve corrected one pretty layout issue and have some thoughts about fixing some others. I’m not super proficient at map design, so it’s something I’m trying to keep an eye out for. It also gave me the opportunity to try out the flow of re-organizing a map in this “drafting” format. It’s… okay. It’s certainly not as easy as changing around a traditional tile map. I don’t think I’ll change my mind about how I’m building the maps for this game, but it’s interesting to see what works well and what doesn’t.

I also came up with some ideas for how to make building the levels a little less onerous. I’ll talk about that more when/if I get around to doing it.

Code Refactoring

I’m trying to apply bits and pieces of what I learned from making six games in the last month to clean up some of the code. All things considered, I’m still relatively new at using Godot, and still firmly in that awkward phase where it takes way longer to make anything (big) than it takes to get better enough that you develop a pretty hardcore disdain for the code.

Happily (?) I intend to leverage this code for other games so it’s worth spending some time cleaning it up. The biggest thing I did was just small housekeeping things.

• I was inheriting from Node for a lot of helper objects that should have just inherited from Object. If it doesn’t need to go in the scene tree, it doesn’t need to inherit from Node.
• I was registering a lot of things as custom types unnecessarily, with the primary goal of being able to refer to them by class name. You can just use class_name for that – class_name Foo will make Foo available globally as a reference to that class.

I’d like to take a crack at making my movement system better, maybe. First I need to figure out whether I had a good reason for some of the decisions that I don’t like now. I also want to try to iron out some wrinkles in some of my basic map primitives, especially cliffs and climbable areas.

A New Cave

I have one cave that I need (you have to move through it to get through an area) to draw, that I just hadn’t yet, so I finally got started on that.

Some Pictures

It’s been a while since I’ve posted any screenshots from Black Mountain so here we go. The maps are not “finished”, they’re missing bits and pieces like trees, etc.

Gruedorf Post 2021-11-21

• Built a 2d block-pushing game with mediocre puzzles

Grab the Gems

You can play Grab the Gems online. – at least in theory. As I’m writing this my webhost seems to be having issues so if it doesn’t seem to be loading very fast, try again later I guess!

Grab the Gems is the name of a number of games I’ve made in the past. I come back to it and make “a new version” every now and then, usually as a way to try out a new programming environment or tool. I might come back and revisit this one some day because there is actually a certain amount of (very dumb) “lore” that I did not include in this game at all.

This particular version of the game is based heavily around simply Sokoban-style block pushing puzzles. Every level has a door that needs to be opened by pressing down a switch, usually with a block. Blocks that fall in the lava turn into platforms you can walk on. There are, in fact, gems to grab, but there isn’t… actually any particular point to getting them.

But Why?

So if I didn’t get around to adding in that stuff, why did I make it? Especially when it took two weeks!?

Well, first of all, you’re not the boss of me. I’ve been kind of exhausted and needed to pull back a bit on this stuff to keep from burning myself out too much.

Second of all, I specifically chose it to learn more about two areas of Godot that I want to get better at: controlling asynchronous behaviour and building editor tools, so I focused on those instead.

Asynchronous Behaviour

The original Grab the Gems was “turn-based” in the sense that it was a QuickBasic game where nothing happened at all until you pressed a key. So far, most of the Godot work I’ve done has been with real-time stuff, and I wanted a simple-ish game to dig into to try and nail a turn-based loop. It SEEMS like it should be easy, but it turns out that the standard way of doing things in Godot leans very heavily into these real-time systems. Even in a more fluid movement/real time game, I want to have a better understanding of event loops and such because I’ll need them for things like cutscenes and textboxes.

I already have some of this stuff kind of worked out for Black Mountain but it’s always felt a bit hacky and hand-wavey. I was hoping to figure out a more solid way of doing it! I had perhaps moderate success. I feel like I’m coming to a better understanding of it, mostly, but I still don’t feel like I know how to update the systems in Black Mountain appropriately to make things more controlled and predictable. I’m sure I’ll figure it out, though.

Editor Tools

Since I kept talking about it, I decided to use this as an excuse to try building some tools and then actually use them.

One of the problems that I’ve had a number of times in making these games is getting things in the right place in the scene hierarchy. In this case, all of the “entities” in the level (the player, blocks, switches, gems, etc) all live in a YSort node (called “Entities”) sandwiched between under and over tilemaps.

Standard Godot UI gives you a file explorer. As you can see I’ve got all of my Entity .tscn files tucked into a scene/entity directory. I can grab any of those .tscn files and drag them into the currently edited scene to place one of those entities. That’s all well and good, but it will create the entity as a child of whatever node you happen to have currently selected. I want them all to land under Entities, but if I happened to just be dragging around “Gem” to reposition it and forget to click on Entities in the scene tree again, if I drag another Gem.tscn onto the map, it’ll become a child of “Gem”. That will look correct, and might even work most of the time, but I don’t want to just have my nodes strewn all over the place willy-nilly.

It’s also a bit of a pain, because I want to grab the .tscn files, not the .gd files. Yeah, I could put the script files in a different location than the scene files, but I prefer this layout.

So I set out to make myself a palette of entities that will just always drop them into the right place.

And I did. Getting it working probably took half of the total development time, in the end, but it DID actually make creating levels faster. It was 100% not actually worth it for this project, since I only bothered to make three levels, but it’s definitely something I’m going to be cribbing in the future for other projects. The code isn’t quite just drop-in and it works, but it shouldn’t be hard to rework as needed. So that’s cool!

The basic parts of it are:

• Create a new plugin
  • Plugins are very cool but plugin development is a pain in the ass. I had to frequently reload the editor, since an error in some code might lead to having UI panels left over that I can’t ever clean up.
  • Another annoying thing is that when you change the code of a loaded plugin, it appears to reinitialize all your member variables but it doesn’t re-run _ready() and so on. If you have a saved reference to something, it just throws it away, and now you get a bunch of errors.
  • It is incredibly obnoxious that Godot’s editor doesn’t save your window size and position. I am using a single large 4k monitor, and Godot really wants you to use it maximized. There are apparently workarounds you can set up with a plugin, so I’m going to look more into that, but it’s offensive that I have to.
• Instance some UI and add it to the docks
• Add a refresh button
  • This saved me from SOME reloading at least.
• Get a list of all the .tscn files in the scene/entity directory
• Generate a preview of each one
  • Previews are built into Godot! Accessing them is awful. You must have access to the (global but NOT singleton) EditorInterface object to get access to the (global but NOT singleton) ResourcePreviewer object, but you can ONLY get the EditorInterface in the actual EditorPlugin class, NOT in the UI scenes that it instances.
  • I used a disgusting hack to get around this – since the EditorInterface is global for all EditorPlugin objects, I just instantiate a new EditorPlugin and get it from there. This trick is documented in Godot Q&A but it is another thing that is offensive to me.
  • Also worth noting that once you DO get the ResourcePreviewer, you can call queue_resource_preview() on it – this takes a path, an object and function to callback to once it has the preview ready, and a “userdata” for you to pass info through. It turns out that queue_resource_preview() will not actually call that callback, if you pass null as the userdata. Pass 0 instead.
• Add drag and drop to preview buttons
  • This was surprisingly not too bad, but I didn’t bother to use the built-in drag interface. I just used button down and button up signals on TextureButton controls.
• Make UndoRedo work
  • This was kind of annoying to get right. You’ve got to supply both “do” and “undo” functions, and in this case since I was instancing a new version of the packed scene, I needed to make sure the lifetime on the instance was right. Instead of calling queue_free() on it for undo, you just want to remove it. Instead, instance the scene before you set up the do/undo methods, and use add_do_reference(instanced_scene); that way it’ll be around for redo to add it back to the scene, but it’ll get cleaned up it falls out of the UndoRedo history.

I’m probably forgetting some pieces. Like I said, it was probably the hardest part of this whole project. It’s very nice to have it working, though, so it may just be some pain I have to put up with, in order to have a nicer time of building the rest of the game.

Have a good week!

Gruedorf Post 2021-11-07

• Messed around with tool scripts and plugins to get a better feel for them
• Built a blocky first person shooter

Castle Escape 3D!

I have harnessed what was previously only hypothetical: a THIRD dimension for video games. You can play the result, Castle Escape 3D, online.

Tooling

I actually wasn’t going to make a game at all this week. I figured since I’d made 4 in the last two weeks, I could take a breather for the week and instead delve into looking at building tools for Godot. I messed around a bit, figured out how to add novel UI to the editor, and then felt the itch to just make a game instead. I still learned quite a bit, and realized that I had been using plugins/addons incorrectly for Black Mountain. So, toss that on the pile of things I need to clean up when I get back to it.

Escape the Castle

I was a kid at just the right time for Wolfenstein 3d and Doom to be a huge deal. We also had the shareware version of a lesser-known cousin to those games, Catacomb Abyss, which captured my imagination – look, I’ve been a Tolkien nerd since before I could read – in a way that nazis and sci-fi demons didn’t quite manage. It certainly isn’t a better game, but I do love fantasy shooters, and I feel like they’ve always been an underserved market.

Anyway, so I had the 3d Catacomb games in mind a lot while I was building this game. I decided that, for the sake of speed, I would build the levels (which, in the end, was only one level) out of blocks, just like that era of game. I actually re-used some of the tiles I drew for the platformer a few updates ago, but drew lots of new art as well, probably more than I should have. The hand (based on a photo ref on my own hand outstretched toward my computer monitor) is probably some of the best work I’ve done for these games so far.

I ran into a few hiccups. In no particular order…

The HTML export didn’t work out as well with this game. It’s been great with the 2d games, but this one seems to have a bit of hitching that isn’t present when running on the desktop, and there were some texture glitches. Nothing game-breaking, but unfortunate. I also didn’t actually spend any time trying to troubleshoot those, so maybe it would be easy to fix.

Importing textures in 3d defaults to importing them in “Video RAM” format, and filtered. This probably makes a lot more sense when you’re not using pixel art for textures. The real lesson here is, if you’re going to be importing a lot of art that matches in style, use the “Set As Default for X” feature (under the Preset menu in the Import tab). Don’t just keep redoing it manually like a dumbass when you’re trying to build a game in two days.

GridMap is the “3d tile map” primitive that Godot offers. It’s actually really cool in a lot of ways but in a few specific ways it is not so cool. Its UI is kinda bad; in particular, its tile selector does not show you tile IDs anywhere, even though their integer ID is the only way that the rest of your game is going to be able to refer to them.

Similarly, it’s really cool that you can set up a scene with a bunch of meshes and some collision data, etc, and then import that as your MeshLibrary (“tileset”) for use with GridMap. What is less cool is that it centers every one of those meshes, even if they are not supposed to centered in their grid space. If you double-click the MeshLibrary .tres file after the conversion, you can manually modify the offset for the each mesh – but next time you create the MeshLibrary by converting your scene, it will throw that away. Also, if you rename one of the meshes in the source scene, it will not get rid of the one from before and will instead just add a duplicate with a different name. (It’s possible you could leverage this second bad behaviour to work around the first? It’s annoying that you have to, though.)

I use billboarded sprites a fair bit in this game. It took a while to get the rendering just right, and it turns out that you probably want bill boarding turned on (I used y-locked bill boarding throughout this game, I just prefer it) and you also want to set the Depth Draw Method to “Opaque Pre-Pass”.

And So On

Not sure what I’ll work on next. Maybe I’ll actually take a week off from making games? Maybe I’ll actually make something smaller and easier like I keep intending to, rather that making something more complex each week? Who knows. Have a good one!

Gruedorf Post 2021-10-31

• Made a spaceship game

Space

I made a game that I call Gravity Ships, and as per usual, you can play it online.

It’s something like if you took Asteroids and made it with a Spacewar! engine instead. There are planets, asteroids (which spawn over time), enemy ships (which are suicidally stupid), and a black hole. Everything is affected by gravity (except the black hole) – for convenience’s sake I don’t bother to calculate the pull from anything other than planets, asteroids, and the black hole, but the only truly stationary thing in the field is the black hole at the middle of it. It also has a mini-map, which isn’t particularly exciting other than it served as a way for me to learn the way custom drawing for nodes works in Godot.

There are plenty of things that could be added to the game: a score, shields, smarter enemies, etc. I kind of had a vague idea about needing to do something at the planets, either blow up things on the surface or what-have-you, but honestly I got pretty sick of working on this game. The numbers involved in gravitational equations aren’t intuitive in any way, so it was a lot of guess-and-try-and-guess-again development. The playing field is (by design) large and mostly empty, and it’s actually not especially fun to fly a space ship with “realistic” controls, and really this isn’t even especially realistic – there’s no fuel and the mass changes that result from it, rotation isn’t force based, etc etc. All in all, surprise surprise: more realism isn’t necessarily more fun!

As harsh as I am on it, I do think it could be fun with some more work. I’m not really interested in putting more time into it now, but the future is unknown! Perhaps I’ll come back to it, or scavenge it for parts later on.

Happy Halloween, and see you next week!

Gruedorf Post 2021-10-24

• Built a Breakout clone
• Built a platformer in the style of old DOS games

Breaking Out

I built a clone of Breakout. You can play it online.

This one actually has a win condition! If you beat three levels you are done! I feel like this game is a little more even in terms of difficulty than Tank Attack but honestly I’ve never been especially good at Breakout so what do I know?

In terms of features, it’s pretty standard barebones Breakout. Each brick is worth 100 points and takes one hit to break; you get a new life at certain score thresholds, etc.

I actually finished this one earlier in the week, and decided to just get started on the next. So uh…

Zombies, Bullets, and Platforms

I also built a platformer! You can play it online, too.

It features a hero wearing a bright magenta shirt, so I think we can all agree it is an instant classic. This one also has a win condition – it’s got four levels, and if you beat all four, you win! If you feel like it has no particular theming to hang the narrative together, you are correct. Thanks for noticing.

Feature-wise, it’s got your standard jumping and shooting, limited health and ammo, and collectible score/money. There are five different enemy types, all with different behaviour. There’s an overworld map for level selection, including gating different areas of the map behind completing a particular level. Dying in a level just shunts you back to the overworld map (and resets your ammo and money to what it was before you entered).

I had a bunch of ideas for other things to add, and I’ll probably come back to it some day, but I felt like I’d reached the right point to stop with this one.

Thoughts, Feelings, and Lessons Learned

As hoped, making these small games is both helping me understand how I like to build stuff in Godot, and also giving me small drips of dopamine, so that’s nice. I’m coming to realize that, while after trying a bunch of different engines, Godot ended up being the one I hate the least, I’ve still been fighting it and trying to stick with building things how I want to instead of what is easy and natural with the engine. I’m also finding out that I may actually be faster with Godot now than I ever was with Verge, if I actually co-operate with the engine.

I wanted to collect some notes and thoughts about the things I learned this week. Mostly, I’m writing them down to solidify them in my own head, but you never know, maybe this will help other people out too. Almost all of these come from building the platformer because I didn’t bother to write any notes down while building the Breakout game because I was kind of operating in a fugue state.

AnimationTrees Will Break Your Heart

I use AnimationTrees for some of the animation handling in the game, and that may be a complete mistake – multiple times, Godot went behind my back and messed up some of my entity scenes in a way that I needed to dig into the .tscn files directly to figure out what was what. It was like, the first time you added an instance of a given enemy to a level, it would be fine, but the second one would freak out in weird and unpredictable ways, and cause the first to glitch as well?

In any case, I eventually figured out that it was because (for some reason), the enemy scene was being saved with a relative path for some of its animation stuff which went to its parent and back in – ../Zombie/Sprite:frame for instance, when just Sprite:frame would be correct. This meant it seemed to work as long as it retained its name of Zombie, but since Godot cannot have siblings with the same name, the second Zombie would get named Zombie2 and it would break, both because the second one wouldn’t animate correctly and it would be trying to animate the first as well.

To fix this bug I ended up manually modifying the .tscn files. Thankfully, Godot’s PackedScene file format is dead simple.

Physics

A generic physics engine is great for getting going quickly, but it can be kind of a pain, even when it’s specifically got special handling for games like Godot’s. I’m not sure it’s more of a pain than writing it all myself, but it does mean you have to sneak around behind its back sometimes. I lost a couple of hours of development time to trying to get my moving platforms to stop being pushed around by the player and bullets.

Think About Testing

Even if it’s a pain, it’s worth putting a little extra time into making it so you can run a level scene directly (instead of using F5 to run, you use F6). If you have autoloads that set things up, this will be a little annoying, but ultimately it will be worth it – especially in a game like this where levels are quite discrete and some levels act as “gates” to the others.

Tool Scripts

Tool scripts in Godot are when you mark a script (with the tool keyword) as running in the editor as well as in the game. Since Godot’s IDE is actually written in Godot itself, this means you can do whatever you want within the editor, with the full runtime engine available – including the current scene tree and the editor UI.

They’re something I’ve dabbled in a little with Godot, but not as much as I’d like. They seem incredibly powerful for custom ad hoc stuff. In this case I added a couple of small things like making sure (some of) the enemies would face in the right direction to make it easier to see how they would interact with the player, and drawing a bounding box in the level based on where its camera bounds were set up. I need to try to do more with them!

Miscellaneous

• Cheat codes: you’re going to want them for testing. Maybe I left them in my games when I shipped them?
• Consider using separate tilesets for your foreground and background tilemaps. Maybe then I’d stop drawing them into the wrong frigging layers.
• Draw all your sprites facing the same direction instead of picking a random one each time, maybe?

Next Week

That’s it for this week! I’m not sure exactly what I’ll tackle next, but I’ve been adding ideas to a list whenever I think of another game I’d like to remake or a problem I’d like to tackle or a style I’d like to try, and it’s getting pretty long already!

I probably WON’T try to do two games next week. I was having a lot of fun (… most of the time) working on the games this week, but I don’t want to burn myself out even further – if I only get one done next week (or if I take two weeks to build the next one!) I’m not going to be too hard on myself.

Gruedorf Post 2021-10-17

• Spent several weeks in a useless funk
• Roughed in the final map (of the game, not the final one to rough in)
• Rebuilt an old one-hour compo game

Da Funk

I’ve been pretty burned out on just about everything lately. It hasn’t been fun, and it’s been even less productive, so I haven’t really had anything to say on here for a while. I can’t really say it’s “over” either, but I’m hoping that I’m starting to see the end of it – or at least maybe I can find a way to be productive anyway. I know that sounds like I’m just a workaholic, but truth is that this stuff is what I do to feel good about things. If I’m not working on some creative project for too long, things get dark, so I’m trying to avoid going and further down that road.

Sorry! I know that’s vague and depressing, so I’m hoping I can talk about more positive things now!

The Climax

I actually did manage, last weekend, to do some more rough map drafting. I drew out the final area of the game, the peak of Black Mountain itself. Those of you who played the original Journey to Black Mountain might remember this as the place where Kiel finally meets the Phoenix! I don’t really want to completely spoil things at this point, but that is still true in this version of the game, but the specifics of it are very different.

I’ll need to review notes and such to be sure, but I think I have one more required dungeon area to draw out, a number of interiors for the abandoned town area of Black Mountain, and then a handful of miscellaneous things to finish or fix up for various maps, and then I can actually build out the beginning-to-end maps for the draft version game. After that will be starting to fill in the story and actual stuff in the maps.

A(nother) Detour

A couple months ago I talked about how things were wearing me down, and how I was working on SimpleQuest 2 as a way to deal with some of the burn out on my large game. Perhaps it escaped your notice, but I decided to take a break from building the content out for a large game by building content out for a different large game. This is extremely on-brand for me, but also not very useful.

I was thinking back to the Crappy Games Xplosion of yesteryear, and realized that 16 years ago I could knock out a (bad) game in an hour. I have learned a lot about making software since then but I don’t think I’ve ever felt as comfortable with a game engine since Verge 3 – comfort defined as “being able to knock out prototypes very quickly” – not even the engine I built with my own two hands.

So this time, in an attempt to shake myself out of the rut, I instead opted to go in the other direction. I’m going to challenge myself to make crappy games, but quickly, and hopefully in great quantity, and I’m using Godot to do it. It’s not exactly “making progress” on Black Mountain but as you may have noticed I haven’t been making any progress anyway so I may as well try to hone my skill and familiarity with the tool that I’m using.

To that end, I rebuilt one of the games I made for the Crappy Games Xplosion: Tank Attack. I started it… a little over 12 hours ago at the time of this writing, but I also got groceries and cooked dinner and various other things today, so I think in total I spent 4-5 hours on it. I tried not to stress about making it good, but it is pretty similar in scope to Super Tank Attack, the version I released after spending a few extra hours on it. It’s a lot harder, but “balance” wasn’t really what I was aiming for.

You can play Tank Attack (2021) online. Keyboard and mouse required.

So far the highest score I’m aware of is 730. Join us on Discord to let me know how you did! Or don’t, either way is fine.

Not sure what I’ll have to talk about next week, if anything. I’m aiming to have another tiny game to play, but we’ll see. Have a good one!