I’m very curious how this one will pan out. I tried Outer Worlds, and I dropped it after about 10 hours or so. It felt oddly empty to me. I figure I should give it another shot at some point.
Same, I really enjoyed Veilgaurd and actually finished the damn thing, which is rare for me these days. It wasn’t perfect, but it was a good, breezy arpg.
Shame to not have Mortismal’s “review” since they are probably one of the biggest PoE fanboys on the internet and CRPGs are their wheelhouse www.youtube.com/watch?v=aMCS_1ortZk
They’re fun enough in their own right and it’s cool seeing a large 3d version of the world and cities, but the story changes are some Kingdom hearts overcomplicated bullshit. Each game gets dramatically worse near the end in order for each chapter to have a climax ending. I’m only looking forward to part 3 to see how weapons play out but concerned they are going to screw that up with over-animefying it. Not here for the story at all anymore.
I haven’t been following the story as I’m already familiar with the original story. I didn’t think they would have made and significant changes to it. I just wanted to see the worlds.
This is my biggest problem. I don’t like the real-time combat. When I originally played the demo of part one of the remake and discovered it was real-time combat, I went into the settings to change it to turn-based, only to discover there was no such setting. Stopped playing pretty soon after that.
It’s a modern game, nobody but people who played the original would play it if the combat stayed the same. There are many criticisms of the game, but the change in combat isn’t one of them.
Feels slightly hyperbolic. Atlus’s games are mostly turn based and seem to have sold in only somewhat worse numbers compared to FF7 remake (Persona 5 in particular). One series (Yakuza / Like a Dragon) even switched from action combat to turn based.
Anyway, I found the combat to be kind of forgettable and didn’t really add to the game, although I understand there have been improvements in the second game.
The combat is fanatastic. But they don’t lean into it enough, and so you don’t get to fully engage with it beyond a superficial level. Except for some fleeting moments most people wont even notice.
I love it, but I hate how they’re too afraid to commit, even to the point of not allowing you to play Rebirth on hard until ng+.
Why do you say that? Lots of other old games get remakes that don't try to completely change genre. Just because a game is old doesn't mean no one would play a faithful remake, that reasoning doesn't make any sense.
Hell, SE themselves have done faithful remakes of games that are much older. Dragon Quest III HD just came out and I hear it's been selling pretty damn well.
That said I really like the combat system in modern FF games. It’s a mix of hack n slash + strategy you don’t really get anywhere else.
They’ve made something unique, and I approve. My only complaint is that they don’t lean into it, and all but the highest difficulty lets the player get away with button mashing.
Being forced to walk in certain places is a replacement for a loading screen. Some of your other criticisms are very valid. I hate that they fluffed out the games just so they could split it into three full ass games.
I watched a friend of mine play it shortly after its release, and while it was pretty entertaining at times to watch, I just didn’t like the combat system.
I suppose it could be because I’ve invested hundreds of hours into the original, dating back to its launch. I don’t know. But the charm just isn’t in the remake, IMHO.
If you’re just watching, you won’t get the main appeal of the modern FF combat systems. That being the underlying turns and the strategy around what to do with them.
And unfortunately, at lower difficulties, you can get by with button mashing. It’s really disappointing that the difficulty that actually requires thinking is locked behind ng+, but at that level, the system really shines.
It’s all strategy, dressed up as a hack and slash, but if you just button mash, don’t min-max your builds, utilize the entire party, their abilities, spells and synergies, you are dead.
And it’s all made more intense by the combat happening in real-time (though you can slow time to a crawl at any time). I really love the panic of the way you are forced to control any last surviving party member, waiting for your turn to be available so you can use a phoenix down.
Yeah, I get what you’re saying about me not having actually experienced the full gameplay. I guess the lack of turn-based play is what made me not super interested to begin with, though.
I’m old (ha), and my favorite games are the old FF series, Baldur’s Gate, etc. that all have turn-based combat. Maybe I enjoy it because I’m slow 😂
I don’t know how much you know about the intricacies of the newer FF combat systems, but “turns” are still in there, but among a bunch of new stuff that may or may not jell with you.
If you want, in the remakes you can set the combat to “classic” which makes it so that the AI controls all three charachters, rather than just the two you aren’t playing as.
This leaves you to deal with only the “turns”, and which abilities, spells, or items, to use them for. And you don’t need to be quick, the passage of time nearly pauses while you engage with the action menu to decide what to do with a turn.
Characters and enemies can only engage in basic attacks outside of their “turn”. To use abilities, spells or items, it must be your “turn”.
All the decisions that make turn based combat interesting are overlayed on top of the real-time action. At times they even overlap. When not using classic mode, it matters how you control a characters real time actions. The exact timing of when you use a turn can have consequences, you need to make sure you are standing in a good spot for a given ability, you need to make sure you’re not about to take an attack that might interrupt an action, etc.
You have to decide stuff like whether you need to use your turns to spam cure just to keep the party alive. Should Aerith spend one turn and the MP to use Cura on one party member, or wait two turns to use Pray on everyone. Should Cloud go for damage on this turn, or build stagger in case it leads to a stun and bonus damage next turn? Can Tifa keep herself alive with Chakra or do I need to have another charachter heal her? Do I remember the pressure conditions for this enemy or do I need to spend a turn on Assess to find out?
If all you want is turn based classic gameplay, then yeah, it isn’t here. But they have made something very interesting. It’s got hack slash style flashy action, but with an amount of strategy involved I don’t think any other games have achieved. It’s unique.
But I really like turn based combat. I don’t like to have to run around, spam buttons, or time anything right. I like to read and have time to make a decision. It’s a personal preference, but one that made me not get very far in the remake.
Flydigi Vader 3/4 Pro. Been using one for a couple months. Hands down best controller I have used. Hall effects, trigger locks, rear buttons, mechanical face buttons, glorious d pad. The not so fun is the crap software and joystick defaults. Once you update on pc it is great. Under $100 for either model.
Do you use it on Linux? I recently got a Vader 4, it works wireless on xbox mode (using the xpad linux module), but I was hopping to make use of the gyro (hopefully without losing the analog triggers), and it seems that the dinput mode (which does allow some gyro action + analog triggers and working extra buttons) does not really work with the wireless dongle for me (it works if I plug it via cable, but that’s also not optimal since it disconnects mid play sometimes for some reason).
That’s harder to implement. Suddenly you need to store that extra state somewhere and don’t mess it up. The last save should already have a timestamp and is immutable. A lot less likely to get bugs that way.
The state “the game is paused” is different from " the game is paused and saved". Sure that could be another key in some atate machine but like above: it’s the “not mess it up” part that is harder.
Plus all the lines to update the state, when the menu is closed, when the game is closed (i.e should it be true or false at startup), when the game is saved obviously.
That’s at least three more lines plus the one you mentioned for no extra value. And again it’s easier to screw it up e.g. while refactoring.
I think we write our code in different enough ways that we’re not seeing eye to eye.
Tracking the state of the game being paused, when the menu is open and when the game is saved can all be a single match statement on a current “game state” variable which just holds “running/paused/paused and saved/exit” and when it becomes exit, it checks the save time. Only 2 lines of code and adding an enumerated state to the variable to add this functionality. Since the variable is enumerated, it’s really difficult to mess it up when refactoring because if you can’t pass the wrong code or else your game doesn’t save or close
Ok, I mentioned a state machine in another sub thread. It’s not as bad if you already have a state machine.
It’s still adding more complexity though - again when the value is updated. You still need to change the state when saving. You need to decide which state to use when starting the game.
There is still risk of screwing that up when refactoring. And still the value is nearly none.
Regarding state mchines, it’s a complexity in itaelf to add random flags ro the state machine. Next time you want to add another flag you need to double all the states again, e.g. PAUSED, PAUSED_AND_SAVED, PAUSED_AND_MUTED, PAUSED_AND_SAVED_AND_MUTED. I would never add mute to the logic of the menu but that’s the pnly example I could come up with. Maybe you see my point there, at least?
Complexity being added at updating also feels wrong to me. Let me pseudo code some rust (just the language I know best off the top of my head right now) at you, cause it feels like maybe I’m just not understanding something that’s making this seem easier than it is.
<span style="color:#323232;">Enum Game_State
</span><span style="color:#323232;"> Paused
</span><span style="color:#323232;"> Paused_Saved
</span><span style="color:#323232;"> Running
</span><span style="color:#323232;"> Loading
</span><span style="color:#323232;"> Exit
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">///Technically you could make Menu() part of the enum but I'd probably leave it elsewhere
</span><span style="color:#323232;">
</span><span style="color:#323232;">Match Game_State
</span><span style="color:#323232;"> Paused </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Menu()
</span><span style="color:#323232;"> Paused_Saved </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Menu()
</span><span style="color:#323232;"> Running </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Main_Loop()
</span><span style="color:#323232;"> Exit </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Exit()
</span>
And then your other functions always return a game_state. You’re right that adding that return would be a huge undertaking if it’s not handled in the initial building of the game, but it’s a QoL for the user that’s easily maintainable and is therefore worth doing IMO. But these two things, defining the possible game states and then always routing decisions through that game state, makes this kind of feature relatively doable
I’m sorry I don’t getting your point . You start off by agreeing that you don’t like the extra complexity that the update statements give. Then do some pseudo code of something entirely different where we all already agree is not an issue.
Then at the end your conclusion is that it is totally feasible. Why? You still didn’t adress the problem of updating the state
My point was “are state machines really that complicated? Isn’t it just something like this pseudo code and a return value from your functions?”
Basically I feel like this is a 2 step process but you seem like you either know more than I do or have a different philosophy about how this would be implemented, so I want to understand what I’m missing
I really enjoyed it, it’s different… and in higher difficulties is actually pretty challenging, you need to really plan out everything from your materia to your skill set. I had fun for a good … 200 hours I think. I haven’t played the second part though
Disclaimer first: I work as a coder, everything I say about publisher interaction is second-hand knowledge.
We have made one Linux game. It was the first one of our two “indie” titles (quotation marks, because both of them ended up being partially funded by a publisher, so they weren’t really indie in the end), where we had promised a Linux build on Kickstarter, long before a publisher got involved.
The main reason why we did not do native Linux in our publisher-funded games is quite simple: Our publishers didn’t pay us for it.
There are actually some publishers who are very keen on getting native Linux versions for their games, but we sadly have not released a game with any of them yet…
The publishers we released games with did not agree to the buget that we think is needed to do a Linux port of sufficient quality. If we would lower the price for doing a Linux port to the point where our publishers would agree to it, we would take on a lot of financial risk ourselves, so this is sadly not an option.
If everything worked as it is advertised by engine developers, making a Linux version would be quite cheap: Just click a few buttons and ship it. This is, sadly, not the case in real-life, as there are always platform specific bugs in game-engines. Our one Linux game was made with Unity, and we had quite a few Linux-only bugs that we forwarded to the Unity devs (we didn’t have engine source code access), and had to wait for them to fix… For the engine we mainly use nowadays, Unreal, we have a rule-of-thumb: “Engine features that are used by Fortnite are usually well maintained.” There is no native Linux version of Fortnite… (We did try Unreal’s Vulkan RHI in Unreal 4.26 for Steam Deck support in one of our games. Let me put it this way: The game in question still uses Direct3D on Steam Deck.)
So, from experience we expect that the chance that we would have to find and fix Linux-specific engine bugs is quite high. Therefore we have to budget for this, what makes offering a native Linux version relatively costly compared to the platform’s market share. Costly enough to make our publishers say “no”.
This, by the way, also answers the question why publishers are willing to pay for the way more expensive console ports. There are also way more console players, and therefore potential customers out there…
(I can only guess, but I would expect publishers to be even more reluctant to pay for native Linux, now that WINE works so well that getting a game running on Linux needs typically zero extra work.)
Multiplayer games will only target Windows, officially, and might even ban Linux altogether because of the perception that anti-cheat is more costly, impossible, or just hard under Linux. True Kernel-level anti-cheat is not possible on Linux like it is on Windows but the real reason is risk: anti-cheat is an arms race between cheaters (and, critically, cheat vendors who would sell cheat tools to them) and developers and those developers want to limit the surface area they must cover and the vectors for new attacks.
The biggest engines, like Unreal, treat Linux as an after-thought and so developers who use those engines are not supported and have to undertake an overwhelming level of extra work to compensate or just target only Windows. When I was working on a UE5 project, recently, I was the only developer who even tried to work on Linux and we all concluded that Linux support was laughable if it worked at all. (To be fair to Tux the penguin: we also concluded that about 99.9% of UE5 was -if-it-worked-at-all and the other 50% was fancy illumination that nobody owned the hardware to run at 4k/60fps and frequently looked “janky” or a bit “off” in real-world scenarios. The other 50% was only of use to developers who could afford literal armies of riggers and modellers and effects people that we simply couldn’t hire and the final 66% was that pile of blueprints everyone refused to even look at because the guy who cobbled them together had left the team and nobody could make heads or tails of the tangle of blueprinty-flowcharty-state-diagramish lines. Even if the editor didn’t crash just opening them. Or just crash from pure spite.)
A very few studios, like Wube, actually have developers who live in Linux and it shows but they are very few and far between. (Factorio is one of the very nicest out-the-box, native Linux experiences one can have.) Even Wube acknowledge that their choice to embrace Linux cost them much effort. Recently, they wrote a technical post in their Friday Factorio Facts series about how certain desktop compositors were messing up their game’s performance. To me: this sort of thing is to be expected because games run in windows and render to a graphics surface that must be composited to some kind of visible rectangle that ends up on screen: after a game submits a buffer to be presented, nearly all of what happens next is outside of the games control and down to the platform to implement properly. Similarly, platform-specific code is unavoidable whenever one needs to do file I/O, input I/O, networking or any number of other, very common things that games need to do within the frame’s time budget – i.e. exceedingly quickly.
Projects which are natively developed on Linux benefit from great cross-compilation options to target Windows. This is even more true with the WSL and LLVM: you can build and link from nearly the same toolchain under nearly the same operating system and produce a PE .exe file right there on the host’s NTFS file-system. The turn-around time is minimal so testing is smooth. For a small or indie project or a new project, this is GREAT but this doesn’t apply to many older or bigger projects with legacy build tooling and certainly does not apply as soon as a big engine is involved. (Top tip: the WSL will happily run an extracted Docker image as if it was a WSL distribution so you can actually use your C/I container for this if you know how.)
Conversely, cross-compiling from Windows to Linux is a joke. I have never worked on a project that ever does this. Any project that chooses to support Linux ports their build to Linux (sometimes maintain two build mechanisms) if they weren’t building on Linux for C/I or testing, already, anyway. (Note: my knowledge of available Windows tooling is rather out of date – I haven’t worked with a team based on Windows for several years.)
Godot supports Linux very nicely in my experience but Godot is still relatively new. I expect that we might see more native Linux support given Godot’s increase in population.
What’s that? Unity? I am so very sorry for your loss …
If you’re not using a big engine, you have so many problems to handle and all of them come down to this: which library do you choose to link? Sound: Alsa, PulseAudio or Pipewire: even though Pipewire is newer and better, you’ll probably link PulseAudio because it will happily play to a Pipewire audio server. Input: do you just trust windows messages or do you want to get closer to some kind of raw-input mechanism? Oh: and your game window, itself? Who’s setting that up for you, pumping your events and messages and polling for draw? If your window appears on a Wayland desktop, you cannot know its size or position. If it’s on X11 or Win32, you can. I hope you’ve coded around these discrepancies!
More libraries: GLFW works. The SDL works. SDL 3 is lovely. In the Rust world, winit is grand. wgpu.rs is fantastic. How much expertise, knowledge and time do you have to delve into all these options and choose one? How many “story points” can you invest to ensure that you don’t let a dependency become too critical and retain options to change your choice and opt for a different library if you hit a wall? (Embracing a library is easy. Keeping your architecture from making that into a blood pact is not.)
NONE of this is hard. NONE of this is sub-optimal once you’ve wrapped it up tight. It is all just a massive explosion of surface-area. It costs time and money and testing effort and design prowess and who’s going to pay for that?
Who’s going to pay for it when you could just pick up a Big Engine and get the added bonus of that engine’s name on your slide-deck?
And, then, you’re right back in the problem zone with the engine: how close to “first-class” is its Linux support because, once you’re on Big Engine, you do not want to be trying to wrangle all of these aspects, yourself, within somebody else’s engine.
bin.pol.social
Aktywne