itch.io

Yeah, I think I should have had the delay effects visible between runs. The cards definitely could use more play, balance, and verity. I started this project on Wednesday, so I only had 3 days. I feel like if I pushed on it some more, polish could really bring it up a notch.

I originally conceived the game as a 1v1 network game (I’ve done multiplayer for jams before) but couldn’t get WebRTC working. Then I thought I’d do couch game, but thought asking players to have 2 controllers was a bit much. So dumb monster it is. Better monster AI could have definitely elevated that though.

Thank you for playing!

Neat little potion system!

It’s SO pretty. Well designed art direction and a neat little throw mechanic.

But the mouse sensitivity is just too high. It’s REALLY hard for me to play. I have my mouse at default DPI. But I’m on a large monitor with HiDPI settings. Chrome and Firefox were both rough.

A loading bar to indicated download speed would go a long way. I thought it had crashed.

Damn, it is stressful. Engine picking is rough. I don’t think I ever finished a lap not in 6th place.

I think I get it, but it’s HARD.

Silly little toy. I’d like to try more level!

Thank you! Getting the timeline was SUPER important to understanding HOW the actions you where taking effected the outcome. Without that, it’s pretty opaque what’s happening. I’m glad it came through well.

Thank you! I’m glad you see the design theory here. I thought it would make a good 1v1 card battler, but I couldn’t get network multiplayer working fast enough and I thought it might be too much to ask people to have two controllers and two players IRL to test a jam game.

BRO THANOS SNAPPED!?

I really like the mechanic. “Ludonarratively” does an amazing job creating the multitasking experience!

I had load it up chrome because firefox does NOT like Godot’s mouse implementation.

I tried. I REALLY tried. But the fishing game killed me.

This is a fun little mini-game gallery!

SILLY FROG! I love him.

I did think space would be jump and thought I had crashed the game a couple of times before I realized it was pause.

I really like how the wheel works with projectiles. But I think the wheel screen itself can explain that. “WOOD:+Tracking,-Range” and “EARTH:+Range,-Tracking”.

That would have been an awesome framing. And frustrating too.

Slower feels like it has a multiplier on it? Bigslice->faster, smallslice->slower, and I’m going backward?

“I’m going to fucking kill you Wheelfox” is exactly how I felt after all those pun.

Damn. lvl4 got hands. Definitely could use a couple of levels between 3 and 4…

I love the vibes.

But it seems like I can just attack everything forever. I did die eventually. I know that I can’t just attack forever. but it SEEMS like I can until I can’t. And when I can’t, it resets back to the beginning. So the lesson of what I’m suppose to do is behind several minutes of doing what I already know until I actually can start experimenting. A reset to previous fight, rather than a reset game, would go a long way to help the user focus on figuring out the challenge and not waste time on getting to the challenge.

If this was a retail game, that might not be as much of an issue: people are more willing to spend time figuring out a game they bought than their general expectation for a jam.

Hello Everybody! I need to convert the comment section here into a Forum. There are just too many lost threads here.

Unfortunately, when switching a comments section to a forum, Itch breaks links to comments. So this is a warning. This area is going to go away soon. Sorry everyone!

This is more of a Godot question. You can look at Project->Project Settings then look at the input map tab. These events correspond to events from the script.

Cute!

Looks like the shader you’re using is a “screen reading shader”. Somewhere in the shader code itself, you’ve got something like hint_screen_texture. Remove that, then a new variable will be exposed in the material variables. Make GodotBoy set it’s texture to that variable.

https://docs.godotengine.org/en/stable/tutorials/shaders/screen-reading_shaders.html

If it works how I think, this texture is taking your entire screen as input. You need to be able to set what exactly it’s catching. Should be easy to fix!

Alternitively, if you wanna learn some shader code, might be good chance to make it read only the part of the screen you want it to. But that might be more effort than it’s worth.

What shader are you using? Looks fun, could be good to include in a future release.

My non-programmer friend was able to build for Mac well enough. He did have some issues and I added some notes on the readme regarding some of his pain points. He was not, however, able to reproduce your exact issue. I’m not sure why Bash is looking in your home directory and not it’s own file directory.

The build system is written in Bash. It’s a very useful scripting language to know/learn. If you’re still having issues, you can read it and see if you can find the cause. You can also try to export to Mac using the manual steps listen on GodotRust.

I’ve spent some hours on debugging your issue now and that’s time not spent on my own projects. No one else can seem to reproduce it. Let me know if you figure out what’s happening so we can add it to the readme to prevent other people from having this issue.

If it’s not working still, then I think I should drop Mac support all together. Trying to figure out what’s happening on your system is becoming time consuming. I don’t own any Mac hardware so I cannot debug locally. I’m going to ask a friend to try to see if they can build it with the instructions provided.

It looks like you are running that script from your /Users/max/Library folder, not the repo copy. You need to pulled the repo into a clean folder and run ./buildSystem.sh --allMac from inside that folder. I’m not sure how you’re doing this, but if you are doing this all correct and still having this error, then Mac support is broken and I don’t have hardware or time to fix it. I will have to delete the Mac instructions from the repo.

You could try to read the build script itself and figure out how it works to see why it’s failing. It’s build on these instructions, so you could could try running them for yourself: Export to macOS and iOS.

You shouldn’t need to do that if you’re using the template. But if you’re compiling it yourself you’ll need to read buildSystem.sh

I don’t know why it’s not detecting your OS. I use this line to detect Mac. But I don’t own a Mac so this isn’t an important feature for me.

    elif [[ $OSTYPE == "darwin"* ]]; then
        export TARGET="macos"

Try building with ./buildSystem.sh --allMac. Please start a new, clean folder and pull the project into that. Don’t run it out of another folder like /Users/max/Library. That’s a recipe for mess and disaster.

Clone or download the repo and run the builder in the cloned copy.

Did you do a git clone of the whole repo or just download the single files? You need the whole repo.

I’m getting pretty good frame-rate on at least one of your games. Did you use the version from this website? Did you compile it yourself, and if you did, did you use the --release flags? Do you mind sharing a ROM that has more immediate problems? I’d really like to figure out what is causing these kinds of issue for you in case it’s happening to other people or end-users.

Ooo, I’ve been thinking about doing some touchscreen controls for mobile exports. That could be useful.

I haven’t looked into it lately. I have a lot of plates spinning right now. Day job nearing major release.

I’d love to get back to improving GodotBoy, but it’s hard to justify spending time on it right now.

I can usually run dozens of instances before multithreading and often hundreds once I do multithread with Godot.

I’m curious about your project if you’re having issues. Does it have similar issues in other emulators? Have you tried on real hardware?

I would love a wood wall and a fireplace.

Also: Your Twitter link seems down and I can’t find you on BlueSky or elsewhere. If you are open for commissions, I’d like a character as well.

The asset lib version is old. It will always be old. Godot AssetLib is not a good platform for automating updates. It says as much in the AssetLib listing.

If you can find a legal homebrew ROM that can replicate this error, I will look into it. But I cannot spend time on a fix for an ripped cartridge ROM, even if it’s for personal use copied from a legit cartage that you own. This emulator is intended for publishing homebrew games on modern hardware.

I suspect that game doesn’t quite follow the spec and that’s what’s causing this error. I would be curious to see if it causes other emulators to crash. Regardless, investing that is outside of the scope of this project. Sorry.

I’d love to see what else is in your 3d emulation system. But I’d also like to see what causes that error. Do you have a ROM that will reliably reproduce it? Does the error result in a ROM crash or does it continue normally after the error?

Blib_buf is used for sound. I find it strange that it would error like that. It does lots of checks before hitting that line to insure it won’t read out of bounds.

If you’d like to file a bug on gitlab that would probably be easier to talk about code with.

I don’t think it’ll make a difference but: did you download an old version or do you have the latest version here.

What part of it was “inscrutable”? It’s outlined very simply: install rust and run the build script. Not sure what part your caught on.

How has it been going?

Try the instructions as written on the repo and tell me if you have any trouble. I’ve written buildSystem.sh, refined, and reused it for quite a few projects at this point. And others hasn’t had any problems. One person didn’t install the prerequisites, but they figured it out. It’s pretty battle-tested at this point. But please try it for yourself and let me know how it goes! If you have any trouble, it’ll be worth learning what happened to further refine the buildSystem.

Really, anyone trying to use this tool is likely trying to publish on Steam or similar. They’re gunna NEED to codesign for themselves.

I apprentice the offer to build it for me, but I have no way of knowing if what you built was really what I sent. This itch build is compiled on GitLab. Anyone could audit the log (I should install install checksums if anyone was concerned). Ultimately though the project does get updates pretty regularly and I don’t think people will want to have to call someone else to get them builds.

I could pay for GitLab to use one of their Mac build machines, but this project already makes less then nothing, so I can’t invest in a Mac build pipeline when I get Windows, Linux, and Android for free.

Really the best way is to refine buildSystem as much as possible. If you find any pain points, I’d love to hear about them.

I don’t own any Apple hardware and I don’t have a subscription to Apple’s developer program, so I can’t deliver Mac binaries for codesign reasons. BUT if you check out the repo, there are instructions on how to compile it for yourself and those instructions work for Mac. You’ll have to figure out codesigning for yourself too.

That’s also mentioned in the text above.

If you’re having trouble playing it, here is a video: https://youtu.be/Li4AvQnlrxo?si=9GV3Ro5JjPO87nqZ

I think it’s actually more CPU bound generating meshes. Does the framerate recover if you stand still for a bit?

I did most of the development on mobile integrated framework and I get pretty okay framerate on my phone. So I’m wondering if something else is wrong?