[GRUEDORF] Kildorf's Devlog

[kildorf]

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.

[kildorf]

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%)

[kildorf]

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.

[kildorf]

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.

[kildorf]

Gruedorf Post 2021-04-04

• Rewrote how energy is used to power skills
• Made it possible to use skills outside of combat

Energy

I’m using the term “energy” in place of what you might more traditionally see as “MP” or similar in a jRPG. It’s a small thing, but magic is not as plentiful in the world that Black Mountain is set as you generally see in the most RPGs; most people in the world (including characters in your party) do not have a great deal of experience with magic, and are much more likely to encounter it in the form of lightly-enchanted items than to be wizards themselves. I mentioned last week that the main character is a healer – I mean this in the traditional sense, not a magical one. She doesn’t have any magical healing ability, and such a thing is quite rare. (I actually hope to explore that, and the tension between traditional healing and magical healing (and the practitioners of the two) in more detail some day in Geas!) Anyway, point is: “energy” is a more general idea than a “mana” pool or something similar, it just represents the character expending internal reserves before they’re exhausted, meaning it will be used for skills and powers that are not actually magical in addition to “casting spells”.

Along with that, like any good epic fantasy hero, the characters have the option to overdraw themselves. You can continue to use skills even if your energy is depleted; you will start using your own health, instead. This could be dangerous but it might be a worthwhile tradeoff in the moment.

Right now, of course, there’s the issue that using a simple First Aid skill causes less damage than it heals. I’ll have to fix that, and I’m not exactly sure how yet; either I’ll fiddle with the numbers and ratios so that isn’t possible, or some skills will not be usable by burning life points. We’ll see.

Interfaces

I’ve also finished up the interface work I started last time.

“Attributes” shows the characters stats and a list of any passive skills they have unlocked. Because of the complex and time-consuming nature of magic, a student of magic like Violet will not generally gain access to new and more powerful spells simply by levelling up – the spells will be part of equipment, usually as gems/runestones/whatever that socket into a weapon, which anyone can use. Instead, someone with actual knowledge of magic will be better at using those spells, casting them better and more safely than others.

“Skills” is now a list of all skills the character has available. They’re greyed out if they’re combat-only skills, and they’re red (not pictured) if using them would damage the character.

There were also changes within combat (including the ability to use ANY skill even if doing so will outright KO the character, just in case an old man ever needs to cast Meteo…), and I realized that I haven’t really talked much about combat yet. It’s actually in there, already; I built most of it before I started posting about the game. It’s got some issues, though, and some things to work out, so I’ll probably just try to dedicate a post to it in the future.

Moving On

With this sorted out, and a few last ideas that I’ve moved to the “maybe for a future game” category, I’ve actually sketched out the alpha/playtest version of all the mechanical building blocks of the game. I’ve got lots of bugs and other things to address, and I’ll definitely need to build some more pieces as I figure out what I need, but I’m going to basically be shifting gears going forward to focus on building out the “draft” version of the game.

In my head (and in my notes) I have a handful of milestones that I’ve mapped out. Hitting this point is sort of a mini-milestone, I suppose, but the real first milestone is what I’m referring to as a “draft” (or version 0.1). It’s going to have placeholder art, questionable UI, mediocre writing, and lots of bugs, but it will be the main story beats of the whole game, beginning to end. The point of the draft is to get it to a place that someone else can actually play the game all the way through and actually understand it as a game (and hopefully even enjoy it at least a little) with a minimal amount of me waving my hands and explaining things that there yet. Hopefully I’ll be able to use this version to bring some other people on board to help me, especially with art. We’ll see.

For what it’s worth, this process might be a horrible idea, and I don’t necessarily recommend anyone else follow it! I also know it’s pretty unusual for how a game is normally built. A much more usual flow would be to build a very short slice of the game, polished to somewhere close to the “real” version of it, and use that to get a publisher on board or something like that. In this case, I have a reasonably clear(ish) idea of what I want from the game, and it’s a passion project. I’m not really concerned with finding a publisher ASAP, but I do want to work with other people on it. It felt like the right course forward, then, was to focus first on getting the basic framework nailed down and the whole game sketched out so my vision is (hopefully) clear. It’ll be interesting to find out if it works out as well as I want it to.

[kildorf]

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.

[kildorf]

Gruedorf Post 2021-04-18

• Rebuilt my “complete” map template at a new scale (I know, I know)
• Redid the blocky draft for the first dungeon
• Drew another full-scale map (hooking it up still to be done)

Maps

Like I said last week, this will be a short update. I’ve got another map almost bashed together, and need to get it into the game. Hoping to get a couple more done for next week, but we’ll see.

See you next week!

[kildorf]

Gruedorf Post 2021-04-25

• Added obstructions to map I drew last week
• Got bridges working

Bridges

I wanted to talk about a topic that is one of my personal bugbears for any top-down 2d games: bridges. Specifically, bridges where the player can walk on top of, or underneath them.

Traditionally you’ve got essentially two layers of “stuff” – what is behind the player sprite, and what is in front of it. Other things that are on the same layer as the sprite, but are tall (so sometimes the player should be drawn in front of them and sometimes behind them) complicate things a bit, but you can fix that by sorting the sprites by their position and layering them that ways.

When you have a whole section of the map, though, that should be drawn in front of the player sometimes, but not others (e.g. if they approach a bridge from underneath it vs. from on top of it), it’s a whole other issue. The drawing is relatively easy to deal with, KIND OF, but once you have other entities occupying the space, and when you might have events that should trigger when you’re on top of the area but not below it, things get rather complicated!

It may seem like a weird thing to fixate on, but it can allow for more interesting map exploration flows, and it’s always kind of fun to revisit an area you’ve been in but from a different angle. In that sense, it’s like the other “walk around the map stuff” I was writing about a few weeks ago, but it’s a little more subtle since it’s not something the player does specifically, it’s mostly about presentation. In the best case, it’s not really something the player ever thinks about. Of course you can walk under a bridge if there’s ground under it.

VERGE in particular did not handle this well. You were able to modify the renderstring in real time (which allowed you to handle the drawing reordering, sort of) but there was only ever one entity-layer entry; if you reordered the entity drawing it reordered it for ALL entities. If you had any NPCs in the vicinity of the bridge they followed the player’s draw ordering. If you wanted to trigger some zones only if you were over the bridge, you had to manually do checking on things in the zone. It was a pain.

When I built SimpleQuest I knew I wanted this to be a solved problem, in particular because I was using it as a way to build out a framework for RPGs I wanted to use for bigger things, and others might use. I only ended up including one bridge, as a proof of concept, but the functionality was there. None of the code was something I could carry over, but I carried over the principles, and one of them was the way of handling this particular problem.

With the Black Mountain engine, my layers are much more complex than just a single tile map or a list of sprites – in fact, each Map is made up of one or more MapLayer objects. The MapLayer objects contain at least two tilemaps (more, if you want to add them), any arbitrary extra sprites which can sort above or below the tilemaps and entities, a shadow layer, obstructions, and a container for entities, including step event shapes. When checking for triggering events (attached to entities or otherwise) I only check the ones in the player’s current MapLayer entity container; similarly an entity will only collide with obstructions that are in their current MapLayer. Moving between the layers means identifying a good transition area where, when the player passes them, they should go from one layer to the other. The actual move is accomplished by “just” moving the player entity into the other layer’s entity container (it’s a little more complex than just a reparenting, but not much).

Anyway, this all works now. I had been using the MapLayer setup for some time now, so really the work this week was just writing the layer switching code (which, as I said, isn’t that complex). Still, I’m glad it’s done, and I can now continue building maps with the assumption that it’s available.

See you next week!

[kildorf]

Gruedorf Post 2021-05-02

• Finished up a map, completely did another, and started on a third

Busy

Got in some decent work this week but nothing really to ramble about. Still working on finding some place to move. See you next week!

[kildorf]

Gruedorf Post 2021-05-09

• Worked on a map

Still Busy

Too busy to get a lot done this week, but at least some progress is still being made! Far better than just letting it lie fallow for months. I’m optimistic that the next couple of weeks will see my free time opening up a bit, but I also feeling like I’m inviting a curse on my own head for saying that. Well, we’ll see!

[kildorf]

Gruedorf Post 2021-05-16

• Finished a map, started a new one

I know that saying this is asking for trouble, but my time should free up a bit in a couple weeks. Hopefully that’ll mean more to actually show off, AND a return to my ramblings. This is a threat.

[kildorf]

Gruedorf Post 2021-05-23

• I don’t actually remember

This week sure was something. Between a hectic week at work and setting up a new computer, I’m not sure I actually got much of anything done on Black Mountain this last week. My drawing tablet isn’t even set up on the new computer yet. THAT SAID, I am taking some time off for the next bit, so I will have plenty of time (in theory) to get things set back up and get back into the flow of things.

In theory.

[kildorf]

Gruedorf Post 2021-05-30

• Made a lot of headway on a new map

Caves

You know, I was thinking about it. A very, very classic staple of jRPG maps is the Cave. Really, in a lot of ways they’re almost the quintessential dungeon in fantasy stuff in general! I suppose this could probably be traced back to Tolkien’s books – The Hobbit especially involves a great deal of the protagonist grubbing around in caves that aren’t ancient ruins or whatever. Just caves. Since it’s Tolkien, this probably dates back even further; I suspect Beowulf was gallivanting about in caves when he was off killing Grendel and his family.

It seems a little absurd, though, right? When was the last time you were in a cave? If you’re not a professional or hobbiest spelunker, it’s not really something you generally do! Caves are unpleasant places; they’re formed by flowing water which absolutely does not care about making anything resembling a nice safe floor for you to walk in, or making tunnels anything other than a claustrophobic nightmare. Maybe caves are over-done, you know?

So anyway, the next area I’m working on in Black Mountain is a cave.

The Shorthand

So I fell into a trap of my own devising. I had gotten pretty quick at drawing the maps I’d been working on, and foolishly believed this means that I could just steamroll through and become an unstoppable map-drawing machine. Unfortunately I failed to account for the fact that my speed was based on the fact that I had developed a quick shorthand for drawing the forest maps I was working on.

Then I started drawing a cave and realized that I have no clue how to draw a cave. They’re terrible! I’m not convinced any RPG has ever featured a realistic cave (see my rant above). So I had to actually force myself to do real work and figure out the shorthand I would be using.

(As a reminder, the stuff I’m drawing now is not a final version of anything – the entire goal of this current “draft” version of the game is to just stand up a beginning-to-end version as quick as possible*, so I can start evaluating it as a full game and I can start showing it to others. Then, either through my own work or those aforementioned “others”, we’ll start making it look good.)

Anyway, I started and re-started several times on my first map. Just like with the rest of my maps (see the process discussion back in https://verge-rpg.com/topic/35/gruedorf-kildorf-s-devlog/8) I started with a quick, dirty sketch of the area, and then resized it to full size for the level drawing. I ended up trying several approaches before I eventually found one that struck the right balance of fast and readable.

I’m still not completely happy with it, but as I keep having to remind myself, it took drawing three or four full forest maps before I was happy with that shorthand.

Have a good week!

---

* I’m actually doing an awful job of doing it as quickly as possible. I’m taking far longer than necessary on the art, but I’m hoping that the time spent will translate into less time trying to explain incoherent chicken scratches to an artist, later.

[kildorf]

Gruedorf Post 2021-06-06

• Finished up the cave I was working on

Decisions…

Not much to report. I’ve (almost) finished the cave I was talking about last week. This means that the game’s maps up to the first boss fight are ready to move on. I’ve got to draw the boss’ “lair”, and then another town.

I’m not sure exactly what I’ll do after that. I’m waffling on whether I want to just forge ahead and keep drawing maps, or if I want to go back and fill in what I’ve got. I’ve got a few more maps in the forest area I’ve been working on that the player doubles back to after visiting the town, which then takes you to the second boss fight. I’ll probably just go ahead and finish those maps, and then start filling them in, which will mean making some more monster art and starting to tackle some things I want to fix up in the battle system.

Alternatively I may just try to ride the momentum of map-making and try to get all of them done for the whole game (or at least all the maps that you actually need to visit – there will be a number of places that only exist for side-track stuff). Then you’ll be able to walk start-to-finish, and I’ll get a better sense of how big it all feels, and then I can start to cut down or expand as necessary. I’m not convinced I’ll get a good understanding of that without stuff like monsters in place, so we’ll see.

See you next week!

[kildorf]

Gruedorf Post 2021-06-13

• Progress on the layout/world map
• Drew six maps

Progress

Decided to ride the momentum of map making for now. Filled out the maps to complete the initial forest area, drew a little town, and have started the transition maps to the next area (which is actually more forest, but centered around an abandoned and blocked road).

The numbers on this week sound like a lot of progress but honestly I was hoping for more. I’d also like to tackle something that needs some more thinky work in the next week, so I have more to write about! There’s only so interesting “yep drew some maps” is, week after week.

I guess the good news is that eventually I’ll run out of maps to draw. Theoretically?

[kildorf]

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?

[kildorf]

Gruedorf Post 2021-06-27 28

• More map work

Late

Eugh, I wasn’t at my computer a lot yesterday because I was trying to give my hand a rest (I tweaked it weirdly so it was aching over the weekend). It’s feeling improved, but not all better! Anyway, I never got around to posting here yesterday so I’m a day late.

Even disregarding that, I wasn’t super happy with my productivity this week. I’ve been trying to chip away at it each day, but that hasn’t always been happening! Such is life, I suppose.

[kildorf]

Gruedorf Post 2021-07-07

• (Mostly) finished forest maps
• Started planning out the maps for the second half of the game

Continued Slog

Things have continued on their recent slow trajectory. I meant to get back on my normal posting schedule by posting on Sunday, but I didn’t do that, so now it’s Wednesday. Ah well.

I’ve gotten all of the forest maps drawn (though not brought into the engine yet). I’ve got some more caves to draw to link up some parts of it, but I decided to instead finish up the planning/“blocky” versions for the maps for the rest of the games. They’re coming along! There are three (kind of four) distinct areas in the second part of the game (Black Mountain itself) and the biggest one is done(ish?), and I’ve got some preliminary sketches of the rest.

I’m actually starting to worry about the size of the game – Black Mountain was supposed to be a small game that helped me get a process worked out and some engine development out of the way. My map-focused development so far has made it easy to imagine larger (and more) maps than I probably need. For the time being, though, I’m going to keep on with the current plan and build out the draft maps. That was the point of the drafts, after all. I need to focus more on getting through them instead of getting bogged down in details while drawing them… but I’m also cutting myself some slack since this is a very personal project, I figure if I’m having fun doing the details then I could certainly be spending my time in worse ways.

I just need to balance that “having fun” against “taking forever”, because it’s ALSO fun to finish things.

Here’s a “work in progress” of the entrance to Black Mountain (that I thought was finished until I looked at it just now and realized I didn’t finish the ruined walls that are sketched out on the ground there). This is a small rest area between the last section of the forest (an abandoned, ruined road) and the first section of Black Mountain (the partly-flooded, lowest level of the interior).

And Art

I’ve also been spending some time doing some drawing. I realized that maybe I should warm up a bit each day before working on the maps, so I have been. Warming up is actually mostly pen/hand-control exercises, and then I do a bit of free drawing or some figure drawing or whatever. Lately I’ve been looking a bit at artists I admire and trying to break down what they’re doing and seeing if I can synthesize the bits I like into my own stuff. It’s nice to be drawing again, I think?

[kildorf]

Gruedorf Post 2021-07-25

• Finished (mostly) planning the rest of the maps
• Started working on the first interior level of the Mountain

Missing Time

I actually didn’t intend to miss a week there; I thought I had posted and then discovered I hadn’t. I decided to just leave it until Sunday so I could get re-aligned. I have been getting a bit of work done, at least.

Maps

I have the majority of the important maps planned out now. There are a few sort of small incidental maps that I’ll need to add (a room connecting two doors, for instance), but more importantly the flow is basically there.

So I started on the first cave level. After entering Black Mountain, the party gradually works upwards through its interior, an abandoned temple and a small ruined town attached to it. The first level is the biggest of the three interior levels, and actually the largest single map in the whole game. It’s slow going because I am, of course, spending more time on it than I need to. There are a lot of rocks.

This is, of course, highlighting the drawbacks of my approach. Since I’m just hand-drawing every level “in place”, I’m spending a ton of time doing essentially repetitive work, like drawing various piles of rocks. Likely, in the final art, these piles will just be replaced with instances of reused artwork. I’m actually not sure whether I’m saving time or not doing it this way, but I know I would be spending a ton of extra time if I were painting it to a decent finished quality. As it is, it’s helping my practice drawing inanimate, natural forms like trees and rocks, which is a weakness I’ve always had in drawing. You can draw your own conclusions on whether it’s working, I guess.

The Size of the Thing

The more I work on this the more I’m a bit troubled by the potential size of it all.

It’s a classic problem (previously written about by a miscreant you’ve likely heard of) for amateur map makers to end up with maps that are way too huge, and not visually interesting. In my earlier post about how I build my map (from April 11, 2021) I didn’t talk about how I was trying to keep myself from doing this, because I hadn’t worked it out yet. Now, though, I actually work on the map in units of “one screen”. I know how big the screen is, and I have a to-scale grid on my planning map of screen size.

This way, when I build an area, I’m thinking in terms of how much is on a screen at a time, so I can try to avoid having any “dead” screens where there’s nothing interesting, and hopefully the screens can be visually distinct to help the player find landmarks as they explore the map. Each individual map can be more than one screen, but I’ve been mostly keeping each individual map as only a few screens big.

I do still have the option, though, of making a map as one big map, and then splitting it up and letting you move through it screen-by-screen. At the moment I’m doing this for interiors, like the caves.

This is set up by something I built for SimpleQuest, years ago, and have carried forward – I call them “camera boxes”. Basically, I can define a set of rectangles on the map. At any given moment, if you aren’t in a camera box, I query the map to find one that you’re currently in. The camera is then locked to that box; it won’t scroll past the edges of that rectangle. As you move, as long as you’re still in that box, you stay in there. As soon as you step out, I figure out what camera box you’re in now, and quickly scroll the camera over to its new position, locked inside the new camera box.

This isn’t exactly a new idea – it’s built to simply mimic how 2d Legend of Zelda games have worked for decades. It’s a reasonably elegant way (at least for me) to define it for your maps, though. Sometimes I just want to take about straightforward stuff.

I’m not completely sold on having the separation of “outside is all separate maps, inside is always just a camera-box limited map” but that’s what I’m running with for now.

[bengrue]

There’s so much here that I like, my dear nemesis.

I’m glad we think about screens similarly. Maybe we should chat about story graphing. I have a technique that I like…