Happy #ScreenshotSaturday! It's been a while since I've had something to show y'all, but I've been working tirelessly on this little interactive adventure. I've learned a bunch about working with lighting and NPCs already, but I'm super excited for some of the stuff I have planned for this project.
So I was poking around in the #GodotEngine Discord like a nosy bastard and someone mentioned off-handedly that an oft-neglected aspect of #gamedev is project management: being able to set realistic goals and estimate time so you can see where you need to delegate or ask for help, that kind of thing.
I'm definitely weak there. Maybe I should take a course in that.
It's not very long, and you don't have to pay if you don't want to, so if you want to participate in the study you can download it at the link below and it will take you to a quick questionnaire.
Only available on Windows, sorry.
If you download an indie game for free and you end up enjoying it, consider sending a tip to the developer, if they take them. Just send what you think it's worth. Making a video game, even a very simple one, is very difficult and time-consuming. Be a part of making someone's dream come true.
When #godot creates shadows it will use vectors, which totally screws up the pixelated look of the game. For pixelated shadows what you want to do is set your ViewportContainer's Stretch property to true and then increase the Stretch Shrink property. This will reduce the resolution of everything inside the container, thus pixelating everything.
Doesn't seem to behave when resizing the window, though. See images.
Something I really dislike about the way the #GodotEngine works is that it has a bad habit of putting huge single-line blocks of data in its files. It's generally fine for user-facing purposes, but it makes source repo software like #git absolutely shit itself.
Because this is all being stored as one line, every time I modify this tile map and commit my changes, HUGE amounts of data have to be rewritten. I MIGHT be able to fix this by hand, but I shouldn't need to.
Working with tile maps in #GodotEngine is pretty funky. In this example, the "ground" tile randomly chooses between four different sprites as you draw them, but they update when an adjacent tile is updated, resulting in this weird behavior where the tiles change as I draw walls around them.
So you guys remember all that bitching I did about how many third-party software licenses there are in the #GodotEngine? I found out recently that the engine has functions which give you a comprehensive list of all the licenses that apply to any given configuration you might be using.
I wrote a (messy) script that parses & displays this information in human-readable format for a game I'm working on. Maybe I'll genericize it later.
Well I didn't get as much done as I wanted to today, but I did finish the Pitfall clone for Minigame Madness, or as it's now known "Get Across!"
Features four fun hazards and the return of our old friend, Indiana Jumpman!
Get it now for the web, Linux, Windows, or macOS!
Against my better judgement, I decided to start another #Roguelike project. This one required a different mapgen algorithm than normal, with rooms that are directly adjacent. I implemented this by recursively splitting rooms that are too large.
I haven't implemented doors yet because I'm still working on determining which rooms are adjacent. I'm still mulling over this one, which is why I haven't released the source yet.
Unfortunately I might have to veto it. Even though the platforming code is the same as in a previous minigame it doesn't work. I think it's because the assets are tiny. The window is 80x60 pixels
I pushed it to a branch on GitHub in case anyone wants a look:
Happy #ScreenshotSaturday* everybody!
* or #ScreenshotSunday depending on your time zone
It's been a while since I've had a #gamedev screenie for you, but here's one from my new minigame for Minigame Madness, "Put on Pants!" In this game, you have to put on some f***ing pants!
You can play this and other minigames via the latest version of Minigame Madness, available here:
This isn't the stupidest thing I've ever done for #IndieDev but it is the most silly.
So the default @godotengine export template, the one with all the 3D and other modules I'm not using for this project, produces a Linux binary that's about 40 megabytes in size.
I spent all day learning how to compile a custom export template that's optimized for size by excluding all of the stuff I don't use, and that produced a binary that's over 270 megabytes in size.
Instead of killing my brain trying to figure that out I'm gonna chalk this one up to an act of God.
It doesn't work; I presume that I'm missing some dependencies or maybe it was an experimental feature that didn't survive to 3.3-stable. It would be pretty cool if I could build games for Haiku, but unfortunately I don't know anyone who uses the platform, so I couldn't bully anyone into testing it for me.
I'm not saying that #gamedev should be done on bare metal or anything, but if you have a reasonably simple project that doesn't require a lot of bells and whistles then it might be worth your time to learn how to code it all by hand. It will take a lot longer and require you stretch your #programming skills, but you'll get a much more optimized product than you would from just using a general-purpose game engine that contains a bunch of features you don't need.
You know, between the third-party licenses I have to keep track of and the weird issue of imprecise collision detection, I wonder if it's not beneficial to avoid general-purpose game engines.
Obviously it's nice to not have to re-write code in-between projects, but no engine will run your game as optimally as one written specifically for that game, and you don't get pixel-perfect refinement unless you have full control over the core.
I guess this is to be expected with any kind of game engine especially a 3d-compatible one, but it never ceases to amaze me just how many code files #Godot relies on.
There are so many damn third-party dependencies in this system and so many individual code files that need to be checked, compiled, and linked, it's just crazy. My poor laptop, man.
Screenshot of a dude wearing only a fig leaf.
This is arguably not the *most* ridiculous thing I've ever drawn for a #gamedev project, but it's definitely the thing that's made me feel the most silly... so far.
This minigame will be appearing in a future release of Minigame Madness soon. Maybe even before tomorrow, depending on how fast I commit and push my changes.
I'm an aspiring #gamedev who occasionally pretends to be a writer. I believe very strongly in free software and the free market and oppose censorship in all its forms.
A instance dedicated - but not limited - to people with an interest in the GNU+Linux ecosystem and/or general tech. Sysadmins to enthusiasts, creators to movielovers - Welcome!