Hey there! Feel free to use the discussion boards to ask questions.
Marquis Kurt
Creator of
Recent community posts
Thanks for the heads up! While it is good to know that the community has ported the package over to that particular storefront, I don’t think adding it to the official downloads page would be a good idea, as it would imply that I provide official support for that specific package. Since I just discovered this, it’s clear that I don’t officially provide support through that storefront.
Figured I might provide some insight, as I have built the game on Mac from source. Haven’t noticed any particular bugs, even on the upcoming Ventura release. The only thing that I noticed was weird was the display scaling when turning on HiDPI; however, this is more of a Godot problem than this specific game’s problem. I found that doubling the window’s size for macOS fixes this particular issue, using the feature override system.
I’ve recently created an addon/DLC for Mannequin to give characters bushy tails, and I’d like to suggest including a form of manifest validation in the Developer Mode.
Initially, I had a configuration in which componentName
was misspelled as compomentName
; however, I didn’t discover this type for some time, wondering why Mannequin would keep spinning in a frozen state. Once I discovered the type, the import worked as expected.
I think it would be beneficial to include a form of manifest validation that would present an error if a specific key is invalid or cannot be found, to prevent these sorts of problems.
I haven’t done a lot of work inside, but I have noticed it is faster to open up and there haven’t been issues. I’m not able to recreate my export setup due to the content still being updated, but I’ll try to make a more complex piece from what’s available at the moment and try a larger batch export to see if there’s any noticeable change. I’ll update as soon as I have done this and some metrics, if possible.
I’ve used both GitHub/GitLab and YouTrack in the past for issue tracking. Generally, this is what I’ve come to notice:
- GitHub works well when you need something quick that integrates with your project. It also works well for those that want to make a request, as long as they have an account for that service and are willing to use said service (I’ve had my fair share of no-GitHubbers since MS acquired it). I imagine there won’t be as much friction with GitLab, but I’m not too familiar in that area.
- YouTrack is a very powerful piece of software and is really flexible. Guests can easily file reports without needing to sign in (given it’s configured properly for that project). JetBrains, the developers of the software, use it internally and are improving it. It does have a bit of a learning curve, but it can work well. You can see an example from my own here: https://youtrack.marquiskurt.net/youtrack/projects/19e01d60-e6ff-4fe1-8081-495aeff3ea68
Suffice to say, I recommend looking at all the options, trying them out to get a feel for it, and then make a confirmed decision. Both work really well, and it’s sometimes difficult for me to stay on one. I’ve been using YouTrack more recently, but I have plenty of projects using GitHub issues.
I love using this product and being able to export in batches. However, I noticed that I’m not able to export as quickly. I’m not sure what the cause is, but I wonder if there would be massive improvements to battery life and performance if Mannequin were to be updated to support M1/Apple Silicon processors.
If I recall correctly, I believe Mannequin is built on Electron. According to this article, v11 and later of Electron supports Apple Silicon natively: https://www.electronjs.org/blog/apple-silicon/. I imagine there’s a lot more work to be done besides upgrading Electron.
Hello AR14 and Mannequin developers,
I saw your announcements on Twitter about some hotfix updates to Mannequin. However, I noticed that the Mac and Linux builds (40 and 41, respectively) seem to be well out of date compared to the Windows version (52).
Are all of these on the same version, and if not, do you have any plans on bringing these updates over to these platforms (even if not notarized on Mac)? I use macOS on a regular basis and love using this product on it.
Thanks in advance.
Edit: clarification.
Please see the support document “What to do if the game doesn’t launch”: https://marquiskurt.itch.io/planting-uneasy-feelings/devlog/286720/what-to-do-if-the-game-doesnt-launch
I’m unfortunately able to do anything for Windows as I cannot test for that platform. If you’re still having issues on Windows, you may want to try building from source at https://github.com/alicerunsonfedora/planting-uneasy-feelings
There are rare instances in which a Mac is required to build a version for macOS. Most game engines allow you to make Mac builds pretty easily.
There are only a couple instances I know of where you need a Mac:
- For code signatures and notarization (see: Notarizing macOS Software Before Distribution - Apple Developer)
- Your game engine does not support building a Mac version of the game
Like @ASecondGuy has said, if your engine has the ability to export to HTML5, you may want to do that if you’re worried that the Mac build will not work. Just a heads-up, though, that it may not work correctly in Safari on a Mac; I’ve tried playing many games online for jams, and it seems Unity WebGL doesn’t play nicely with Safari.
Hey all,
I’ve released a postmortem that explains the process behind this game as well as what I’ve learned. I hope this clarifies some of the choices and issues in the current release.
https://marquiskurt.itch.io/package-resolved/devlog/282299/unmasking-the-bird
While I usually appreciate feedback I receive, I find the wording of this a little offensive, as if I have never done software or game development before. Nonetheless, I will try to address the points you have mentioned.
When I started planning the game, I didn’t consider whether vertical or horizontal running would be more efficient in completing the game’s objectives, because I would’ve left that up for experimentation; additionally, I needed to make a design that would work on mobile devices as well. I designed the game loop in such a way that when the player reaches a certain point on the may, they teleport back to the top, and everything is re-generated on a random basis. The only way I could get it to look remotely seamless in the time that I had was to compromise by not having the player start at the top. Sometimes it’s not that seamless because the obstacles can generate in the region where teleporting occurs.
I also had initially written the prototype in C# with Godot before realizing that, besides going over the 3hr limit, I was nowhere near done because I felt that I was too slow in C#. I practically reset the timer and redid all of the work I did in GDScript, and added other features such as the power-ups. I had a build ready and up for testing, but I didn’t receive enough feedback to warrant any major game-changing changes. I kept the game as it was, added the missing assets, and submitted. I’d also like to point out that my time was limited, because I visit family members on the weekends to play cards in the summer.
I acknowledge that there are areas for improvement, as I did notice a few bugs in the endless mode; however, given the circumstances, I did not have the time to be able to make these changes before the deadline.
Close, but not quite? I know that you can launch yourself with F.I.N.D., but the best way to reproduce what I am describing is:
- Position F.I.N.D. like you want to launch up.
- Press
W
, without firing F.I.N.D. - Notice that the player is propelled erratically.
That glitch did help me in some levels where jumping didn’t work, though.