Show HN: Mazelit - My wife and I released our first game

The privacy policy is also well written. I didn't know you could not have a cookie pop up.

+1 really well made. I wonder if there's a framework for making these kind of websites?

Connected to this I laughed at the piles of toilet paper packs in the "contact" entrance.

Hey that Broomrocket stuff looks interesting. And nary an LLM in sight.

janosdebugs, could you comment on the tech behind it?

Headquartered on Webgasse no less. I wonder if that's intentional or accidental!

I gave up after watching the cake loading animation for 2/3 minutes. Might be a HN hug of death or something

"Privacy policy" in the toilet! Nice.

Ha the hamburger is genius. How has nobody done that before? (afaik)

Pricing is a funny thing. You'd think lower prices would lead to more demand.

Games under $5 are easy impulse buys and never regretted or refunded unless they don't actually run on my system. $10 would make me question "do I really want to buy this game?", which more often than not is a "no" or "not now", and so it just becomes another slot on the wishlist to be scrolled past and added when it's on sale.

Strongly disagree. A price of $9.99 may seem “quality “ to you, but may be out of reach for many people (including, but not limited to, those who are not in developed countries). I’d rather have a lower priced item that allows people to pay a lot more at the time of purchase or perhaps a reminder (not annoying, and only once) to donate/pay more on reaching a certain level.

A price of $3 may be an impulse buy for some people, while a price of $9.99 may be a pause to evaluate that against other purchases.

Customers with higher disposable incomes can be targeted with additional content (DLC) or digital merchandise.

I don't know... at $10, I almost certainly would have just passed. At $3 I decided to buy it, and then when I saw the source for a couple of bucks more I bought that too.

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.

Disagree. If you agree, buy it and leave a review.

Or even $7.99, that or $8.99 is sort of a nice line between signaling "very cheap game" and "potentially short but enjoyable experience for the evening worth the gamble to find out if so".

I can't speak to it in general, that's just my 2c on the matter/issue without really knowing too terribly much about the game (or game development in generally, really, I'm just a consumer here! XD). <3 :'))))

Wasn't Vampire Survivors originally 2.99? I just checked, it's 4.99 now but I think it was cheaper in the beginnings.

The point is, 2.99 is a "no think" price tag, while 9.99 is a "wishlist and consider when discounted" price tag.

Bu that's only my tl;dr of this blog post: https://howtomarketagame.com/2022/01/31/vampire-survivors-su...

Do commenters like this ever stop to consider people who cannot afford to pay higher prices, before encouraging creators to arbitrarily raise prices higher than the creators have already calculated? Do these commenters ever stop to analyze their world view that leads them to believe the litmus test for quality products is whether the product is priced like an Apple product?

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

That’s something GPT4 is usually good at helping with

You can force Steam for mac to download purchases that are windows only from the command line somehow...

https://openmw.readthedocs.io/en/latest/manuals/installation...

This is for OpenMW so you'll have to change the app id of course.

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?

I had exactly the same thought (Hi Tomas and Janos) :D

The game is really cool, well done! It feels like a modern twist on pacman, but with space alien snakes and upgradable super powers. Should make for a good lunch break game.

LOL small world indeed. :D

Thank you very much! If you have a Mac, you may have trouble downloading the source code DLC so drop us a mail if that is the case: make@something.pink

I'm a Mac user as well, and I bought the Game and DLC. It's such a great idea. Congrats on the game launch (I'll wait patiently for a Mac version rather than trying to get the DLC working), but it was more about supporting the concept than anything.

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

switched to bevy

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.

In the screenshot of the DLC it shows GDScript.

We used GDScript, more than 5000 lines of it.

Per this thread linked from their store page, yes.

https://steamcommunity.com/games/2816120/announcements/detai...

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.

Whether the game mechanics are totally obvious from a video or not is pretty game-dependent. The voiceover made it clear enough what was going on to me.

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.

Yes, the Steam version already includes a native Linux binary and we tested it on both the Steam Deck and Ubuntu 22.04. If you run into any trouble, please let us know.

Same. Nice work!!!

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

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

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

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

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

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

My wife was annoyed at not having released a game for almost a year and she set a hard deadline with the smallest game idea she could think of. It became fun when the game became playable and if we had to do it again, we'd focus on getting to that stage much earlier. The game was finished before the deadline, so we even had time to polish, balance the game mechanics against each other and add a touch interface for the Android release that never happened, but made it into the source code DLC anyway. Previously, we had spent way too much time switching back and forth between Unreal Engine and Godot, not being able to decide or finish anything. Kicking each other's behind to finally get it done also helped a lot.

Now the pressure is on, summer sale it is then.

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.

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.

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