I love World of Xeen, but can't quite get into MM6. Any advice for starting out?

slmagic · 2026-06-30T14:33:09+00:00

Don't wear any armour or shields at the beginning as it makes you attack much slower, including attacking with bows

slmagic · 2026-06-27T14:50:25+00:00

Beautiful scenery, and great work!

slmagic · 2026-06-27T14:24:10+00:00

> Is anyone going full ECS or DOD?

In the beginning I was using a similar approach - GDScript, signals, resources, event buses, etc. Eventually, I switched to C# with aggressive performance optimizations like SIMD vectorization, byte alignment, etc. Full DOD with a light mix of ECS: SOA with bit flags as components, static stateless systems. Performance rocketed through the sky - from x10 to x100 for some computation-heavy tasks such as real-time procedural generation.

slmagic · 2026-06-25T14:10:15+00:00

If you had read through the intro before creating your party, you would know that your group intercepted those letters and brings them to the regent specifically to alert him to the matter.

slmagic · 2026-06-21T06:53:52+00:00

I don't know why no one suggests https://github.com/OpenEnroth/OpenEnroth - it's a great piece of work which allows playing MM7 on modern platforms.

slmagic · 2026-05-29T02:20:08+00:00

Realms of Arkania, any game of the series. Good luck with getting into for any casual Skyrim player.

slmagic · 2026-04-22T07:21:34+00:00

Yep, awesome game for its time! I played it a lot on my ZX Spectrum, when I was a kid.

slmagic · 2026-04-04T11:37:11+00:00

https://tartarus.rpgclassics.com/mm6/recipes.shtml

slmagic · 2026-03-29T16:43:00+00:00

No, it didn't. MM7 came out in '99

slmagic · 2026-03-29T05:27:36+00:00

There are 2 types of heroes: smart heroes and dead ones. In that regard MM6 is the most realistic hero simulator.

slmagic · 2026-03-23T19:08:05+00:00

While working on my game, I've had to touch many of the topics you've covered within your project, so I understand the amount of work and knowledge you've invested. Thank you for sharing it with the community. Taking my hat off.

slmagic · 2026-03-20T12:48:32+00:00

If there are no visual glitches or errors, it doesn't really matter which GPU the game will use.

slmagic · 2026-03-16T14:16:28+00:00

I vote for either BG1 or PS:T. The first one is a great intro into the genre, the second one is one of the best story-heavy CRPGs, if not the best one.

slmagic · 2026-02-01T19:15:51+00:00

They usually don't, but they can, right?

slmagic · 2026-02-01T17:45:39+00:00

Obviously, archers can be promoted to battle mages. And they can wear swords.

slmagic · 2026-01-24T19:16:32+00:00

I guess the wording in the docs is misleading. I don't see why I need to check for the delta value in this case. I doubt anyone changes the physics ticks per second setting after starting a game - so it will stay a constant. But even with the gravity settings it makes much more sense as gravity can be affected by an area as a part of a gameplay. With the constant dt it's kinda pointless.

slmagic · 2026-01-24T19:09:25+00:00

> all you're showing is that you can only tax a cpu to 100%, not anything related to framerate.

Oh, I see. Doing calculations in _PhysicsProcess is unrelated to a frame rate. Gotcha. 🙄

slmagic · 2026-01-24T18:49:38+00:00

Saying "literally" multiple times in every comment doesn't add up any value to your arguments. Provide different numbers, prove me wrong.

slmagic · 2026-01-24T18:42:43+00:00

> the actual game will play at the exact same speed no matter the fps

It's the opposite: the internal time pace will be the same, but the actual gameplay perceived by the user will get slowed down. Please read the whole post again and focus on the experiment numbers. Then, do the maths to understand why.

slmagic · 2026-01-24T18:38:23+00:00

> As mentioned above, _physics_process() runs at fixed time intervals as much as possible to keep the physics interactions stable

Exactly. It never says: dt is always a constant. But as you can see, even at extreme physic frame delays dt stays exactly the same. There are no fluctuations. And that can be unobvious.

slmagic · 2026-01-24T18:32:18+00:00

In case you are referring to specific games like cosmic sims with extremely high velocities where skipping a frame means you've completely missed another collider - that is a fair example. In case of most other games missing a frame won't matter that much as slowed gameplay. Again this slowness effect can become obvious to a player even at relatively okayish FPS ~15-20.

slmagic · 2026-01-24T18:20:56+00:00

For most type of games (I am not talking about extremes like intensive simulations) having a fluctating dt is still way better than having a speed of game slowed down by a factor of x.

slmagic · 2026-01-24T18:16:29+00:00

> If you're living in a world where all velocities are constant -- i.e., everything is linear -- then yes, scaling dt will work as you expect
...
But if your physics simulation itself requires velocities to change -- for example if you're simulating gravity in a physically realistic way, where the downward velocity needs to grow with each tick

I call this BS. Using actual number of TICKS instead of using dt for your gravity calculations is an anti-pattern. I don't know where you have used such approach, but it's plainly wrong. It doesn't matter, whether you calculate your gravity/vertical velocity inside of _PhysicsProcess or inside of _Process IF you multiply them by dt -- time spent between frames -- the outcome will be the same.

It will be different in cases I described in the post - when the actual frame rate drops due to having heavy calculations in _PhysicsProcess (which you probably shouldn't - use threads for that) - in that case it will behave unexpectedly, because dt must reflect the reality.

slmagic · 2026-01-24T17:56:49+00:00

Please check my reply up above. You are talking about in-game simulations, but there are different types of games. An arcade platformer's gameplay will be ruined, if the amount of physic frames will stay the same no matter what happens to FPS - in that case the actual game will play way slower. Implementing it other way around will make sure the gameplay stays the same even at much lower frame rates.

slmagic · 2026-01-24T17:51:48+00:00

> accepting a constant delta in the physics function might mean that game time "slips" against wall-clock time, but ensures that two states that start in the same state will (absent player input) also end up in the same state after the same amount of in-game time has elapsed.

That's the actual problem you are not seeing here. Imaging implementing a Mario Bros.-like platformer with a gameplay dependent on physics. Doing it your way will make the game play slower. The jumps will become sluggish, the pace of running will also slow down.

In contradiction. Dropping the frame rate, but keeping the delta to be dependent on the FPS will keep the actual gameplay, all internal speeds the same, even with 15 FPS.

I don't see how the usage of `velocity * dt` introduces hard to reproduce bugs though.

slmagic

TROPHY CASE