Happy ! 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.

Thought I'd give this a boost: This is collecting data for a thesis paper they're doing by gauging the player experience after playing a game they've designed.

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.

scary-cube.itch.io/the-buildin

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.

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!

github.com/swashdev/minigame-m

Happy !

Against my better judgement, I decided to start another 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.

Got a screenshot for you guys. This was to be a Pitfall-inspired minigame for Minigame Madness. I made the sprites using and just for fun I used the color palette.

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:
github.com/swashdev/minigame-m

Happy * everybody!

* or depending on your time zone

It's been a while since I've had a 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:
github.com/swashdev/minigame-m

This isn't the stupidest thing I've ever done for 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.

hmmm, if I reset my @godotengine repository back to about 3.2.2-stable or something a platform appears in my list of available build targets.

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

Show thread

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

Holy crap, a engine implementation for the . Very cool.

freds72.itch.io/poom

There's even a devlog explaining their process for implementing it.

freds72.itch.io/poom/devlog/24

Clever bastards.

Linux.Pizza

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!