itch.io

Just tried this again today (after over 4 months of setting the game aside for a while). I discovered two things:

1. I can save-scum this level (i.e. create my own level checkpoint). Setting a checkpoint at the sniper garden made the area much more bearable. It still took many more deaths, but I sorted it out in the end.
2. I worked out the trick for the slicing duck room. For some reason I forgot that <redacted>, despite having needed that when dealing with the <redacted>. After realising that, getting past the slicing ducks was much easier.

The remaining rooms were almost pedestrian in comparison.

A game coded in Unity has a translation layer between the Unity code and the operating system code.

Same applies with Godot, the game engine used for Angeline Era, or any other game engine.

Wine translates Windows API calls to "native Linux" calls. It turns an application using Windows API calls into a "native Linux" application.

What you're asking for is something that has the same function as Wine or Proton, but isn't Wine, and [as a result of that] is less well-tested. That testing matters. You can't just take identical code and expect it to work everywhere.

Why waste resources on creating something that's worse than a FOSS product that already exists?

Wine is a native Linux application

The trail is implemented. It activates once you've experienced everyone. You're probably missing a few extra sets of underwear.

It works with Wine as well

Nice game; I like how the leveling system fits in with the theme of the player character. I feel very filled up by that ending; great work on the animation!

Took a huge amount of effort to get there though, mostly because I needed a good non-stopping setup to get around the buttons not being visible or usable because they were pushed off the bottom of the screen.

I've spent quite a while on this one particular area (In Han Tani's Challenge difficulty), enough that I want to talk about the area as I have experienced it so far:

• Respawn point - this was an interesting / enjoyable puzzle.
• Alarm room - a constant source of frustration, until I discovered an easy way out. Unfortunately the area has a scripted ghost jar that appears in three different rooms (including the first room after the respawn point), and the third of those appearances is annoying enough that it's easier for me to just be consumed by the jar in this alarm room when I first encounter it.
• Eye stalk room - annoying, because there's no repeatable sequence that works every time. The straight shooter and lobbers trace my position (which is easy to work around), but the start time for the straight shooter is variable enough that my kickback after jump-slashing the eyes for the first time ends up with damage from a straight-shooter hit on occasions. The eye stalk movement is random and buggy, clipping through the walls and ending up on top of the walls from time to time. Jump slash is not predictable due to the random movement of the jars and the eye stalks, and sometimes I get damaged from the eye stalks even when jumping into them.
• Spider room - annoying. The large spider appears to have reasonably deterministic jump patterns, but the small spiders don't. The shots from the large spider occasionally clip through the boxes, which basically means that nowhere is completely safe from the shots, and the best way to block them is to avoid them completely (which is made more difficult from the random movement of the spiders and jars). As with the eye stalk room, jump-slashing is not predictably safe; it's often the case that I'll get hit in the air while facing the large spider in it's non-firing period, and have no idea why.
• Sniper garden - mostly fine. The bushes serve as a bit of randomness, but the only damage is from the snipers and ghost jar, all of which are deterministic trackers that follow my position with varying speeds, so it's easy enough to avoid that, as long as I'm not making stupid movements.
• Lobber room - Annoying, because the lobbers are not deterministic, the sight lines for the straight shooters leave only a couple of safe-ish spots, and I'm often down to only being able to take another 1-2 hits when I reach this room. This is the third appearance of the scripted ghost jar, and it's *really* frustrating, because it essentially removes the safe spots. When shifting from the safe spots to the lobbers, the sight lines of the straight shooters and the period between shots means that I can only hit the lobbers once (otherwise I get clobbered by the shooters), and need to avoid the shooters after returning to the safe spots.
• Sword shooter room - only really annoying because I'm usually at 1 hit remaining when I get to this room (if I get that far). Because all the movements are deterministic, it's just a skill check room.
• Slicing duck room - similar skill check issue. Not enough bullets to get rid of all the ducks, and I need some more practise at getting the angle right for hitting the ducks (i.e. without taking damage).

I haven't got further than that so far, and my motiviation for tackling this area is substantially lower because of how often the ghost jars pop out.

Summary: the combination of ghost jars, randomness and clipping bugs makes this area a lot more frustrating for me than I feel it should be.

Running the Linux version of this game, I get an "illegal instruction" error.

Running the Windows version of this game using Wine64, it starts up, gets past initialization, then reports "Error: itch.io service not available".

Is there any way to fix these?

The high-level view of your responses are that they are an attack on the developer of this game, someone who has already put in seven years of effort to get to this point already (as demonstrated in the game development blog). The developer does not need that, and digging in deeper to become more aggressive will not help you get what you want.

There are reasons for not developing on Linux, as there are for other platforms (e.g. MacOS, PS5, Switch). As great as it would be to just drop the same code on different platforms and have it work perfectly every time, that's not the reality. There are *always* platform-specific issues that crop up:

"If you don't design your software with platform-nonspecificity in mind, then it just makes it harder. Nothing is truly impossible to port, disregarding hardware capabilities and computing speed. There's no such comprehensive "tool" for porting games to other platforms, though, since they all work differently under the hood."

https://gamedev.stackexchange.com/questions/49375/what-are-the-main-requirements...

Regardless of your own personal opinions on what should or shouldn't be done, the developer has already answered your question about Linux ports, in particular mentioning that it is appropriate for users to use Wine (in the form of Proton) to play Taiji on Linux. And, if the game not working on Linux is a showstopper for you, the developer recommends you consider purchasing on Steam due to a better refund policy.

Regardless of what your arguments are, the personal reasons of the developer are what matters for what platforms this game is provided on. You can choose to pay for the game, or not. Paying for the game supports the developer, and allows them to develop more. It is not reasonable to argue that someone should have put in additional unpaid effort to do something for unknown future benefit, or that they should charge less for a game because it's only available on one platform; that's their choice, and their decision.

For context, development of Taiji was started in mid 2015; it took seven years to finish. That's with the Commercial Game Engine, and even with that, there were platform-based bugs that needed to be worked around (issues that won't be present on other platforms, or will have different presentations); here's just one of those, involving an issue around mouse sluggishness:

https://taiji-game.com/2020/07/13/68-in-the-mountains-of-madness-win32-wrangling...

If the developer is not already familiar with Linux, then there's a small mountain of language barriers around using Linux that needs to be overcome first, before being able to get to the game development phase. It's rare for game development to work on different platforms when it can't be tested on those different platforms. While it might be easy to cross-compile on a Windows system (e.g. via IL2CPP), that's only if everything works perfectly (which is unlikely to be the case). 

Your statements demonstrate a misunderstanding of WINE and APIs. What you're getting with WINE is a community implementation of the programming interface that is accessed by the instructions in the Windows executable files. It's using the native operating system, and not involving a contract with Microsoft. Similar reimplementations of programming interfaces happen all the time in Linux with different binary formats (with ELF being the most common).

The $25 pays for the game, not the platform. If other platforms become available in the future, I expect - as has been the case for all other games I've looked at here - that additional downloads for those platforms will be available at no extra charge.

Developing for multiple platforms is expensive, difficult, and time consuming, especially when a game only has a single developer, and especially for Linux, with all it's different flavours. If this game gets popular enough, the developer may decide to add additional platforms, or hire someone else to do that porting.

In the meantime, we have WINE, which gives us a way to play this game natively on a Mac or Linux system without needing any additional effort on the part of the developer.

Wine isn't an emulator, it's a collection of code that interprets Windows executables for various different systems:

"Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop."

https://www.winehq.org/

FWIW, the Steam Deck relies heavily on a derivative of Wine for getting existing programs to run on the platform.

Some programs will actually run faster under Linux + Wine than under Windows, which wouldn't be possible for an emulator running on the same hardware system.

For OSX, Taiji.exe is a 64-bit executable, so it should work on the OSX version of the current staging version of Wine, but it complains about DirectX 11. I found a workaround using wine-crossover:

%  brew install --cask --no-quarantine gcenx/wine/wine-crossover
[after successful installation]
% /usr/local/bin/wine Taiji.exe

when I initially tried to get it working under Wine on Linux; I got the following error:

Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: Bad EXE format for Z:\home\username\install\taiji\Taiji.exe.

This was related to the executable being 64-bit, and I was trying to run 32-bit Wine. I got it working by setting the architecture to 64-bit via "WINEARCH=win64":

WINEPREFIX="/home/username/.wine64" WINEARCH=win64 wine Taiji.exe