Gruedorf Post 2021-11-28

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

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

Importing Maps

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

A Second Look

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

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

Code Refactoring

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

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

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

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

A New Cave

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

Some Pictures

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

Gruedorf Post 2021-11-21

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

Grab the Gems

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

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

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

But Why?

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

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

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

Asynchronous Behaviour

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

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

Editor Tools

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

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

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

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

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

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

The basic parts of it are:

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

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

Have a good week!

Gruedorf Post 2021-11-07

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

Castle Escape 3D!

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

Tooling

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

Escape the Castle

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

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

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

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

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

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

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

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

And So On

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

Gruedorf Post 2021-10-31

• Made a spaceship game

Space

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

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

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

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

Happy Halloween, and see you next week!

Gruedorf Post 2021-10-24

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

Breaking Out

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

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

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

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

Zombies, Bullets, and Platforms

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

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

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

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

Thoughts, Feelings, and Lessons Learned

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

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

AnimationTrees Will Break Your Heart

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

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

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

Physics

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

Think About Testing

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

Tool Scripts

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

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

Miscellaneous

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

Next Week

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

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

Gruedorf Post 2021-10-17

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

Da Funk

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

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

The Climax

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

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

A(nother) Detour

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

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

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

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

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

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

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

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!

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!

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.

Gruedorf Post 2021-08-15

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

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.

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!