0
\$\begingroup\$

I want to create an offline 2D platformer that is not very physics heavy. After a lot of consideration, I've decided to run most of the physics at a fixed rate of 480hz, and I'm not experiencing any issues with it at the moment.

However, I'm using Gamemaker Studio and although I'm trying to write code as efficiently as possible, I'm worried that I will run into problems further into development when considering lower-end devices such as consoles. I have absolutely no idea if this is too demanding of a task for this kind of game development software and I don't want to run into any issues, especially when considering console ports in the future.

Since I have pretty much no experience on this topic, is it worth writing an engine from scratch in a lower-level language, or will I be okay provided that I keep the scope of the game small enough? The game runs fine on older laptops, but I don't have any convenient way to test consoles yet, and I'm still quite early into development so I'm not sure that would help.

This is probably a dumb question, but I'm more of a designer than a programmer and I really don't have any prior experience to know if this is a good idea or not. Typically games written in this software run at 60 updates a second albeit not very well optimized.

I'm curious to know if anyone has any experience they could share that will help me with the decision.

\$\endgroup\$
4
  • \$\begingroup\$ Nobody knows the load of your physics scenes better than you do, so I don't think we can give you a better answer than your own profiling. I will say though that 480 Hz is alarmingly frequent. This is well above the refresh rates of most displays, so you're calculating many many intermediate states that will never be seen by the player. I understand you might want some extra sub-steps for stability/precision, but this is extreme. It's not uncommon for games to step physics at 20-60 Hz. You'll get diminishing returns doubling, quadrupling, or octupling this. \$\endgroup\$
    – DMGregory ♦
    Commented Dec 23, 2022 at 11:23
  • \$\begingroup\$ Are you using the dedicated physics library at 480 updates per second, or the legacy physics variables/functions with a room_speed equal to 480? \$\endgroup\$
    – liggiorgio
    Commented Dec 23, 2022 at 15:59
  • \$\begingroup\$ I'm using a custom written physics loop that will be as optimized as possible, my room_speed is maxed out with delta_time keeping track of steps (like the Gaffer on Games article suggests). I've tried using a lower rate and interpolating between frames but I must be doing something wrong because it looks far worse than just using a rate of 60 with interpolation off. I've been trying to find a "correct" implementation but it's been very difficult to find anything. Everyone insists on using variable time steps but I can't afford to with this style of gameplay. \$\endgroup\$
    – Kaeru
    Commented Dec 23, 2022 at 17:33
  • \$\begingroup\$ You may want to post a question showing your current interpolation implementation, documenting the observed symptoms, and asking for help fixing it, rather than resort to throwing massive iteration counts at the problem. \$\endgroup\$
    – DMGregory ♦
    Commented Dec 24, 2022 at 2:09

1 Answer 1

Reset to default
0
\$\begingroup\$

You should run your physics as often as you need for the project, but 480 seems awfully high. What is your need for it? However heavy your physics calculations will be, you'll still use 8 times more resources than 60 ticks.

Don't get me wrong, higher tick rates are used... but typically for things like car sims, etc. I can see some value of going higher than 60 maybe for something like angry birds, but generally speaking, I'd try to avoid it. From the other perspective, many FPS games have tickrate on servers even lower than 60.

\$\endgroup\$
3
  • \$\begingroup\$ Mostly I want smooth framerates across many modern devices without having to compromise on determinism, but I'm realizing there probably are better ways of doing this. I never thought about calculating intermediate frames on hardware that could handle it. The problem with that though is then the calculations would not be very precise, which may lead to visual stutter (unless there is actually a way to implement this flawlessly, but that's beyond my understanding). Do many games do this, or do they simply stick to a locked rate? I wanted the best of both worlds but it may not be possible. \$\endgroup\$
    – Kaeru
    Commented Dec 23, 2022 at 16:03
  • \$\begingroup\$ You may be interested in this past Q&A exploring decoupling logical updates from rendering framerate. \$\endgroup\$
    – DMGregory ♦
    Commented Dec 23, 2022 at 17:33
  • \$\begingroup\$ @Kaeru I feel like you are trying to solve a problem that isn't really there. You are saying that you are mainly a designer, so maybe don't try to reinvent the wheel on your first try. If you don't have a solid case FOR it, don't do it. And if you do, then don't ask if it's a good idea, since you need it anyways. There are several ways the engines deal with it, but the fixed rate is easiest to use. That aside, I'd use what is the default in a given engine. \$\endgroup\$
    – Gonzi
    Commented Dec 31, 2022 at 13:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .