[GRUEDORF] Kildorf's Devlog

[kildorf]

Gruedorf Post 2021-06-27 28

• More map work

Late

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

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

[kildorf]

Gruedorf Post 2021-07-07

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

Continued Slog

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

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

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

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

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

And Art

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

[kildorf]

Gruedorf Post 2021-07-25

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

Missing Time

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

Maps

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

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

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

The Size of the Thing

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

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

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

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

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

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

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

[bengrue]

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

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

[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.

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

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!

[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.

[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!