[GRUEDORF] Kildorf's Devlog

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…

kildorf

Gruedorf Post 2021-08-02

Continued work on the maps

Busy

I had a busy week, so I didn’t really get a ton of time to work on Black Mountain. I made sure to get a bit of drawing done on the big map I’m working on, at least.

kildorf

Gruedorf Post 2021-08-08

Decided to take a break from Black Mountain
Made most of a town!

And Now For Something Completely Different…

The grind on the Black Mountain maps has been wearing me down. I’ve been finding it hard to feel motivated the last couple of weeks, and I’m not the best a “relaxing” at the best of times – I’ve been finding myself in that awful loop of not feeling up to working on my thing so I just kind of try to do something relaxing but have the buzz of anxiety in the back of my head about how I should be “productive”.

Brains are dumb.

Anyway, there’s actually something that is somewhere in between actually relaxing and being productive! I am a huge sucker for games that feel like you’re doing something productive; I have to be careful sometimes with games like Cities: Skylines or Factorio or I end up going to bed when I intended to get up in the morning. Turns out, one step from that is to do something productive that feels like a game.

Enter RPG Maker MV and yet another unnecessary sequel! RPG Maker can be used to build some solid, real games – but also if you lower your standards it can be used to make dumb, terrible games, but (comparatively) very easily!

SimpleQuest 2

Or, more fully known as SimpleQuest 2: The Heroic Legend of the Epic Quest for the Mystic Crystals of Power. I might add more to the name, who knows, a game can always use an extra ALPHA MEGA TOURNAMENT EDITION or something added on there.

A town in a much simpler style than Black Mountain.

SimpleQuest (as you might remember) was a smallish game that I built as a test game for an engine that I abandoned. It followed the adventures of a guy named Hero (because his parents had high expectations) dealing with a dragon that was (supposedly) terrorizing a small town. I also built it (almost) entirely of freely available assets.

SQ2:THLOFEQFTMPCOP is a follow-up sequel that literally no one asked for. It follows Hero as he reunites with his sister, “Treasure Hunter”, his childhood friend (and “secret” crush!) Wizard, and their travelling companion Corwin, who has a normal name and does not understand why they keep calling him “Healer” no matter how many times he tells them his real name. This time they’ll be hunting down four crystals of power and squaring off against an evil wizard who has an unsettling fondness for orbs. I’m taking a similar tack and only making assets when they are “necessary”; I’m editing sprites to make the main characters and I’ll (probably?) draw some portraits for the characters, but I’m going to spend as little time doing asset creation as possible.

Will I keep working on this? I don’t know! I’m going to work on it for a bit as a break, and I’ll try to keep it in mind as something I can come back to in the future if I need another break. I don’t really want to spend an extended period working on it instead of Black Mountain but so far it’s working as a bit of a mental trick to help me just chill the hell out, at least a little.

Have a good week!

kildorf

Ah, and I wanted to mention: Nearly all of the art you see above is from a CC0 pack of assets by Mighty Palm: https://themightypalm.itch.io/the-mighty-pack

Have fun! Now that I’ve tipped my hand, if someone else makes SimpleQuest 2 faster than me then I will… uh… probably just keep making this one. No one else but me can possibly remember the order of the words in the subtitle, so I’m not too worried.

kildorf

Gruedorf Post 2021-08-15

(SQ2) Bigger overworld map
(SQ2) A few areas
(SQ2) Confronting RPGMaker’s limitations

The SimpleQuest 2 overworld

Expanding the World

Stuck with working on SimpleQuest 2 this week. I’m looking forward to getting back to Black Mountain, kind of, but I still needed the “break”. I expanded the overworld map from a meager 20x15 tiles to a whopping 62x62 – exactly one quarter of the original Dragon Quest’s overworld map size. I filled out a lot of it while thinking about the structure and story of the game. I’ve added the first other areas outside of the initial town, Seaside, including a small logging camp, a second town (Lakeside), and the entry area for the first dungeon.

The exterior of a run-down castle

It’s still fun. It’s nice to have an existing set of graphics to work with. I’m starting to edge into the place that I always, eventually, end up with RPGMaker, though…

RPGMaker’s Limitations

RPGMaker is a lot of fun. It’s very good at making exactly the game it was built to make – a pretty standard jRPG with about half the bells and whistles you want. The other half of those bells and whistles though… Yikes. Here are two of the things I’ve been wrestling with:

Cutscenes with the whole party in them. jRPGs tend to go one of two ways: You’ve got a silly conga-line of people trailing off behind you (with a total party length significantly longer than the width of any town in the world), or you’ve got the lead character standing in for the whole party. I personally lean toward the second for reasons both technical and taste-related, but I can appreciate the first. The default in RPGMaker is the conga-line, but you can toggle that off. Easy!

Until you want a cutscene. It turns out that when you’re writing a cutscene, if you want to control the sprites of the rest of the party, you… can’t. Full stop. They are simply not available for targeting in the event scripting. This is true whichever style of party display you’ve chosen. Even dipping down into the JS layer does not give you a good way of accessing them. No problem, right? Just spawn new sprites! Wrong! You can’t do that either, and if you could, you’d still have no way of targeting them.

The result? Every single map has three hidden entities (or “events” in RPGMaker terminology) that I teleport to the player for a cutscene, can script, and then hide them at the end of the cutscene. These have to be created in the editor, and they must be in the same “slots” on each map, because you also can’t reference an event by name. I’m working with this by creating a template map that just has those three events, and creating a copy when I’m making a new map instead of starting from scratch.

Multiple copies of vehicles. RPGMaker has the classic three RPG vehicles built right in: a boat that can go in shallow water, a ship that can go in any water, and an airship that can fly anywhere but can only land some places. It’s easy to change the look of them, and put them wherever you want. You can hide them until they’re created/discovered, move them around as parts of events, etc etc.

What you cannot do is have more than one of each. You must have at most one boat in the entire world, one ship, and one airship. (You also cannot easily change which tiles are allowable for boats vs ships, but that’s a problem for another time I guess.)

I’ve figured out a scripting solution for this where I can put dummies down in the world that, when activated, will swap places with the actual boat, letting you use it seamlessly as if it were a boat (and leaving the dummy in the boat’s previous location so it can be swapped back later if necessary). This is offensive to my sensibilities, but whatever. It works, though I am still trying to figure out exactly how to persist this across map loads (i.e. I want ALL of the various boats to stay where they were, not just the last one you used, when you come out of town.)

Anyway…

I’m sure I’ll keep finding things that annoy me, and maybe being annoyed with RPGMaker will chase me back to Black Mountain faster, who knows? I’ve barely even scratched the surface on combat in SimpleQuest 2, so I’m sure there will be more to complain about.

I also dumped most of a glass of water directly in my keyboard this week. I’m seeing if it’ll work once it’s dried out, but things aren’t looking good. Thankfully I have a million keyboards kicking around so it’s not ideal but at least I’m not stuck in “I literally can’t type things into my main computer” territory.

See you next week!

kildorf

Gruedorf Post 2021-08-22

(SQ2) Fixed boats
(SQ2) Started dungeon interior

Slow Week

I actually didn’t get much done this week. I did finally get a bit done today, though, and figure out how to have multiple persistent copies of vehicles, and started on the interior of the first dungeon. Trying to figure out how to get switches to animate correctly now.

Here’s a picture of Lakeside, the town where you will get your first boat! That is way past the dungeon I’m now working on, I’m not really sure why I did things in that order.

Lakeside, the village by the lake.

kildorf

Gruedorf Post 2021-08-29

(SQ2) Made a switch work
Back to Black Mountain!
Moved on to the next map, got it mostly roughed in

Nearly Forgot!

Whoops, nearly forgot to post. No pictures this time, just hastily written words.

SimpleQuest 2 Switches

On the SimpleQuest 2 front, I got a wall-switch to open a door to work. At least, it switches back and forth, it doesn’t open the door yet. This shouldn’t have been as difficult as it was but it took some time for me to realize that the asset pack I was using has the switches laid out in a way that doesn’t work for RPGMaker. There is not (as near as I can tell) a way to just play an arbitrary sequence of frames; in fact, sprites are generally packed into a sheet with seven other sprites, and the actual animation they play is pretty baked in. I’m sure it can be changed with plugins etc etc but anyway…

Point is, the switches in the (absolutely great) Mighty Pack are presented as just a series of three frames for different colours. To make it work I had to copy them around and turn it into a full sprite with the three frames (plus an extra that I made just because) are mapped to the switch sprite’s 4 directions. Then, to play the switch flipping you just animate the sprite “rotating” in place. This is how chests and doors in the built-in assets are animated as well!

Back to Black Mountain

And then I decided I really wanted to work on Black Mountain again. I’d kind of churned out of drawing on one of the cave levels, because it’s a big map and it’s got a lot of details. I gave myself permission to leave the rest of the details… un-detailed, and move on to the next map (the next floor up, which is an abandoned/ruined town that was carved into the middle of Black Mountain). It’s not quite as big (the interior floors of the Black Mountain cave system get smaller the higher up you get, since the mountain is roughly conical) and has gone pretty quickly. It’s got a bunch of interior maps (since there are “buildings”) but those should mostly be a screen or two, so no biggie – and I’m going to be skipping the unimportant ones for now. (Unimportant is defined as “you don’t need to go there to complete the story”.)

It feels good to be back on the game. Hopefully I can keep making decent progress! Have a good week!

kildorf

Gruedorf Post 2021-09-06

Roughed in all of the big maps

A Holiday

Whoops. Normally I post on Sunday but Labour Day made me kind of miss that I needed to post yesterday. But anyway… working on more maps! I’ve got rough drafts of most of the “big” maps — the exteriors and the big dungeon levels. There’s are still interiors to draw but the end of the marathon is in sight. Then I need to do more marathons!

Anyway, yeah, have a good week!

kildorf

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!

kildorf

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.

kildorf

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!

kildorf

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!

kildorf

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!

kildorf

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.

bengrue

@kildorf this is sexy and I love it (and by extension: you)

kildorf

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!

kildorf

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!

kildorf

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!

kildorf

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 The Wizard’s Castle (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.

slimehunter84

@kildorf The map accordion system sounds like a good time-saver. I also really like the choice of over-the-shoulder battle camera angle and turn order toward the top of the screen.