janosdebugs

We tried, the source code DLC has a full touch interface, but we ran into a Godot issue when doing the testing in the Google Play Console where we'd have to switch back to the GL renderer which, unfortunately, makes the game unplayable. It works on our devices, but we don't want to ship something that is likely to break on a number of devices.

It's working now, but it may have been a hug of death indeed. The website is running on a tiny server as it usually doesn't get a whole lot of traffic. :)

LOL small world indeed. :D

Hey, just noticed your comment about OSX above. If you bought the source code DLC and you are having trouble downloading the source on Mac, please drop us a mail: make@something.pink We are just now trying to figure out a short-term solution for downloading the source package on Mac.

@SingAlong thanks for the email, we responded, please check your mail.

We'll upload it here today or tomorrow: https://www.youtube.com/channel/UCXF--ktsN0t97W9R0GN6_3Q

That is accidental and we actually didn't even realize. :D

Yes, I have 5+ hours in it on the Deck. The only thing worth mentioning is that the in-game key bindings menu works slightly better than the Steam overlay because we didn't integrate Steam Input.

Thanks for the feedback, we were debating this a lot.

Once the game makes enough money, we might reinvest into a Mac to ship it for that platform, too.

If it was buildable from source, I would buy a source code DLC for a great many games. However, I imagine that would not be possible for a lot of games because their engine is proprietary and their legal department would have something to say about that, too.

Oh wow, that's not good. We'll get in touch with Steam support and see if we can do anything about that. Would you mind dropping us an e-mail to make@something.pink so we can contact you when we sort this out?

Godot was fine, for the most part, it's a good engine for small games. The main issue was around working together and resolving conflicts with git (Godot isn't really working and constantly kept changing IDs in resource files), and it kept losing data in scenes when the code changed so we had to rebuild things several times. On previous test games we also ran into huge performance issues in the editor when we wanted to do too much work in scenes, so we had to switch to doing most of the work in code.

The worst part was when I had to rip out a bunch of testing code that used @tool for release as it seemed to cause issues when doing a release build. The engine is generally not great when you want to follow clean software engineering (e.g. dependency injection is not possible, I opened a proposal to that end here[1]).

[1]: https://github.com/godotengine/godot-proposals/issues/8850

Had a good laugh. Now that you mention it, we can't quite decide ourselves.

We used GDScript, more than 5000 lines of it.

We did send it to a few, haven't received any replies yet. Do you have any in mind?

Not really, we're old but not quite there yet. :)

We don't have a Mac and couldn't justify the cost of getting one for now. It's not just Godot, we also have to compile the C++ gdextension and we also want to only release on platforms we have actually tested the game on. (That's why there is DualSense support, but not DualShock. In theory it should work, but we couldn't verify it.)

With the source code DLC it should be possible to compile everything for a Mac regardless, even if it's a bit of work. If we make enough money from the game, we might reinvest it into a Mac. :)

Wow, that is really valuable feedback, I suppose we should rework the trailer to work without voice-over too. Thank you!

Good luck! We learned a lot simply from the process of releasing the game. Wish we had done it earlier since now we feel ready for slightly larger projects and know we can push it over the finish line.

Thank you! Apart from the Godot engine and the Rubik font (which are correctly attributed with detailed licenses in the game in the "Credits" section), we made everything in the game ourselves (code, graphics, sounds, music). The source code includes 3 MIT-licensed libraries we made, too. These are available in the source code DLC.

As far as people re-releasing our game is concerned, the source code DLC is licensed under the Steam Subscriber Agreement with a few added grants for mods and making videos, so legally nobody is allowed to re-release our game as a whole or even reuse the non-MIT parts without asking first. If anyone wants to re-use parts of the game in their own game, they are encouraged to contact us. (We definitely won't make a fuss about minor parts of the code when asked, but re-releasing the entire game is out of the question.)

We were debating this exact thing back and forth and decided for the current price based on expected playtime. By now, I have 10+ hours in the game, but you can beat the game to level 80 in roughly 4 hours, which equates to 1$/hour or the regional equivalent in price. We made the style and source code DLCs for people who were willing to pay more or support us, but wanted kids with low allowances to be able to buy the game as well.

Can't speak to Godot 3, but v4 has some infuriating bugs, unfinished features and idiosincracies. The interaction between scenes and code caused us to lose data more times than we can count and the dev team seems to be completely overwhelmed with the number of issues.

That being said, it is an engine that works and is used by enough people that you'll find bugs reported on the things that bother you, so you'll at least know if something is broken.

We found that doing as much as possible in GDScript and as little as possible in the editor is the way to go. The only time we had performance problems was when adding nodes (for some reason adding nodes is insanely slow). The multithreading is also still in need of work, but thread groups will, hopefully, solve the problem in the future.

We are currently looking into Bevy and Fyrox for BlockBawks since it needs a custom simulation engine, but we are still unsure. (It currently has a semi-working version in Godot, but spawning several 100k nodes is creating problems and will need optimizations.)

BabylonJS indeed. We had a tutorial up on our previous YouTube channel, if there's interest, we'll reupload it.

You just made our day, we were laughing do hard. :D

I did, and I'm wondering if you can reclaim VAT cross-border at all if you didn't get a 0% invoice in the first place.

Having a business in Europe is significantly more complicated than in the US with lots of rules to follow. France seems to be especially strict if your business expenses need to be on a separate accout, that isn't the case in other EU countries. However, it's worth noting that with a VAT ID the ticket also becomes cheaper because the 20% VAT for France doesn't get added.

Why would you need to reclaim VAT? If you are a business and have a VAT ID, the seller should invoice you with 0% if it's a cross border sale and you need to report it to your government (reverse charge).

It also doesn't make much sense from a productivity standpoint. Whenever I did on-call, it would obviously disrupt my sleep schedule and my work performance the next day would be... suboptimal. Follow the sun makes much more sense.

I can confirm this, I have a mail server with extremely low, non-bulk mail traffic and without SPF/DKIM/DMARC nothing works. Even with, Gmail started rejecting mail (probably noisy neighbor), so the only way around that was to use the little-advertized relay service in the paid Google Workspace when sending towards gmail or workspace domains.