Mistakes in transitioning EE to EEU

peace · 2019-11-03 14:43:23

i agree wiht ^ they release a product and ask feedback we give and htye chnage to what most poepel want

Processor · 2019-11-03 20:46:19

And you have completely missed my point. There is no issue with iterating on things. I never complained about that.

Long planning phases are not part of scrum. My issue was with the long planning phase which as far as I can see has yielded no apparent benefit to the game.

LukeM wrote:

Processor wrote:
Like what?
The core physics engine, the ways we handle state, how we handle varying framerates, those sorts of things.

This is a 2d platformer game with axis-aligned rectangular hitboxes. Writing a physics engine for it is not rocket science.
Variable framerates and handling state are not novel issues and good algorithms and libraries exist for both of them. Every game in existence deals with that. I fail to see how that can be so challenging.

rat

LukeM · 2019-11-03 21:08:38

Processor wrote:

This is a 2d platformer game with axis-aligned rectangular hitboxes. Writing a physics engine for it is not rocket science.
Variable framerates and handling state are not novel issues and good algorithms and libraries exist for both of them. Every game in existence deals with that. I fail to see how that can be so challenging.

Don't have time to go into the detail right now (I've probably given some more detail elsewhere if you want it), but the physics engine we're using is more than the basic calculate a; v += a; d += v; check collisions; thing, and supports non-rectangular non-axis-aligned hitboxes, and we're doing variable framerates in a better way than most of the default implementations you're probably thinking of.

Processor · 2019-11-03 21:34:56

On a 120 FPS screen, my smiley "vibrates" when falling down.
On a 60 FPS screen, it works fine.

So whatever "better" method you're using, it isn't working as intended.

This is a solved problem guys, there is not much science behind it.
Original EE ran physics independently of the graphics.
Which is the industry standard for multiplayer games (to ensure identical results on different machines).

Zumza, Grilyon2, rat

peace · 2019-11-03 21:37:48

proc EE runs at 60 fps only

Processor · 2019-11-03 21:39:07

No, peace, it runs at maximum 60 fps, due to other constraints. EE definitely supported variable frame rates under 60 FPS.

peace · 2019-11-03 21:42:14

yeah thats what i mean so even if oyu have an 120FPS screen it only suports 60 FPS so 50% of what your screen cn ahandle

Processor · 2019-11-03 21:51:36

I can confirm that the smiley vibrating issue happens on a 30 FPS screen as well or when you lag because your Processor / graphics card is rather old

Norwee · 2019-11-03 22:17:50

XxAtillaxX wrote:

until the game is in a state where it doesn't look like a Chinese rip-off of a smiley face game made in 2010.

Lol that's such an insulting way to describe it. I love it.

peace · 2019-11-03 22:21:04

Processor wrote:

I can confirm that the smiley vibrating issue happens on a 30 FPS screen as well or when you lag because your Processor / graphics card is rather old

its because you only get 50% of the intended FPS

LukeM · 2019-11-03 22:21:06

Processor wrote:

On a 120 FPS screen, my smiley "vibrates" when falling down.
On a 60 FPS screen, it works fine.
So whatever "better" method you're using, it isn't working as intended.
This is a solved problem guys, there is not much science behind it.
Original EE ran physics independently of the graphics.
Which is the industry standard for multiplayer games (to ensure identical results on different machines).

(About the issue):
That's an issue with the camera being handled seperately to the physics system, it's on my list of improvements to make.

(About variable framerates in general):
That system looked terrible in EE though, it's the reason people claimed that EE didn't look smooth even when they were running at 60fps, it means that you alternate between advancing one tick and advancing two ticks per frame, which makes it look pretty bad.
In EEU we have a pretty nice system that allows the game to truly run at different tick rates without leading to the inconsistencies you mentioned that most games that do true variable refresh rates have.

Processor · 2019-11-03 22:28:49

LukeM wrote:

That system looked terrible in EE though, it's the reason people claimed that EE didn't look smooth even when they were running at 60fps, it means that you alternate between advancing one tick and advancing two ticks per frame, which makes it look pretty bad.

The solution to that is to just interpolate between the last two frames. This article explains it pretty well:
http://web.archive.org/web/201904030121 … _timestep/ (section "The final touch")

EE wasn't perfect and it didn't use standard methods to deal with things, there is no doubt in that.
To claim that these were things you had to do long "planning" for is silly because existing algorithms to these problems exist.

LukeM · 2019-11-03 22:30:28

Processor wrote:

The solution to that is to just interpolate between the last two frames. This article explains it pretty well:
http://web.archive.org/web/201904030121 … _timestep/

That would be a possible way to do it, yeah, but it would lead to small inconsistencies and complications and our physics system supports doing it properly anyway, so that's not how we're doing it.

den3107 · 2019-11-04 00:05:39

Processor wrote:

And you have completely missed my point. There is no issue with iterating on things. I never complained about that.

If this was directed towards my post, then I think we "miscommunicated", since my post wasn't directed towards yours (I do agree with what you had posted about the UI).

Processor wrote:

Original EE ran physics independently of the graphics.
Which is the industry standard for multiplayer games (to ensure identical results on different machines).

In all honesty, it's an industry standard to always run physics on a fixed time step (that runs "independent" of the normal tick speed). Happens in both Unity and UE4 (although I'm not sure if that's turned on by default in UE4).
Using this does create other issues, such as managing essentially 2 ticks, making sure physics never locks up graphics (through interpolation if needed), and you might need to create additional tick "phases" (such as pre/post/during physics).

Processor · 2019-11-04 00:59:52

The discussion dynamic shifted away from the point I was making.

Yeah, it sounds complicated to do physics independently of graphics, but that's exactly why so many libraries exist to help

You're reinventing the wheel.
It's silly to assume that you have implemented a superior solution to what has basically been the industry standard for a decade.
Do not underestimate the amount of experience AAA game engine developers have in this area.
They are smarter than you are.

As a player, I honestly couldn't care less about how the physics are ticked.
Instead of focusing on things that actually matter, you have spent your time on some over engineered solution to an already solved problem.

My player vibrates and I hate it.

den3107, coinage

LukeM · 2019-11-04 01:23:05

Processor wrote:

The discussion dynamic shifted away from the point I was making.
Yeah, it sounds complicated to do physics independently of graphics, but that's exactly why so many libraries exist to help
You're reinventing the wheel.
It's silly to assume that you have implemented a superior solution to what has basically been the industry standard for a decade.
Do not underestimate the amount of experience AAA game engine developers have in this area.
They are smarter than you are.
As a player, I honestly couldn't care less about how the physics are ticked.
Instead of focusing on things that actually matter, you have spent your time on some over engineered solution to an already solved problem.
My player vibrates and I hate it.

To be perfectly honest, the reason I decided to design the physics engine like that was because I wanted to try out some related maths I'd been studying at uni and thought that a physics engine would be a good use for it. The reason that the industry standard is what it is is that it's a lot faster to implement, and in most games the physics engine isn't important enough to spend a lot of extra time developing something better when the problems are small enough that you don't usually notice them. EEU is pretty much just a hobby for me so if I have the chance to do something that is more interesting and results in a better end product than the industry standard, I'll choose to spend the extra time any day.

Minimania, KirbyKareem, mutantdevle, Xenonetix

Official Everybody Edits Forums

#26 2019-11-03 14:43:23

Re: Mistakes in transitioning EE to EEU

#27 2019-11-03 20:46:19, last edited by Processor (2019-11-03 20:48:18)

Re: Mistakes in transitioning EE to EEU

#28 2019-11-03 21:08:38, last edited by LukeM (2019-11-03 21:12:56)

Re: Mistakes in transitioning EE to EEU

#29 2019-11-03 21:34:56

Re: Mistakes in transitioning EE to EEU

#30 2019-11-03 21:37:48

Re: Mistakes in transitioning EE to EEU

#31 2019-11-03 21:39:07

Re: Mistakes in transitioning EE to EEU

#32 2019-11-03 21:42:14

Re: Mistakes in transitioning EE to EEU

#33 2019-11-03 21:51:36, last edited by Processor (2019-11-03 21:58:57)

Re: Mistakes in transitioning EE to EEU

#34 2019-11-03 22:17:50

Re: Mistakes in transitioning EE to EEU

#35 2019-11-03 22:21:04

Re: Mistakes in transitioning EE to EEU

#36 2019-11-03 22:21:06

Re: Mistakes in transitioning EE to EEU

#37 2019-11-03 22:28:49, last edited by Processor (2019-11-03 22:30:05)

Re: Mistakes in transitioning EE to EEU

#38 2019-11-03 22:30:28, last edited by LukeM (2019-11-03 22:31:25)

Re: Mistakes in transitioning EE to EEU

#39 2019-11-04 00:05:39

Re: Mistakes in transitioning EE to EEU

#40 2019-11-04 00:59:52, last edited by Processor (2019-11-04 01:01:08)

Re: Mistakes in transitioning EE to EEU

#41 2019-11-04 01:23:05, last edited by LukeM (2019-11-04 01:25:53)

Re: Mistakes in transitioning EE to EEU

Board footer