DDraceNetwork - mapping

had an idea for a randomized ddmax map, quickly rushed a concept, should i develop it further ?

RNG_DDMax.map

100.52 KB

That sounds interesting

i have played the map

14:08

and i think it is a good concept

14:08

although there are many problems with this prototype map

14:12

i think it would be better to have some sort of progression

14:13

instead of playing the same parts over and over

14:13

or

14:13

use the same parts but with a twist

14:13

like a weapon

14:15

there is also a bug when two tees finish a part in the exact same time

14:15

which is very easy to do when playing with a dummy

pilonpl

use the same parts but with a twist

i planned on that

14:42

but this is just a small concept

another issue is that there isnt really any reason to randomize the order of parts

15:25

you could put all those parts in one order and the map would be basically the same

15:26

there needs to be something that makes the rng justified and fun to play

how i make my images smaller in the editor

15:57

im scaling the png file down and it still appears as big as before

15:57

even when im embedding new file

15:57

and its edgy as fuck

15:59

okey nvm i set the layer to be tile instead of image im actually dumb

16:03

but still dont know how to make it smaller in editor

DeKaeL

but still dont know how to make it smaller in editor

i guess by selecting a quad and moving those red points

but it doesnt work the way u think

16:34

its deforming my image instead of making it smaller/bigger and if i hold shift and resize it down, the new version of the image slowly start to appearing (edited)

idk

16:36

i dont have that much experience

16:37

using the editor

16:37

but you can deform the quad to be smaller

16:37

there is also this menu

16:38

in which you can resize to keep the aspect ratio the same

none of this options do this

16:38

or maybe im doing smth wrong

16:39

ye nothing works

16:39

the only thing that works for me is to make a big canvas in image editor and make objects smaller/bigger on the same canvas to make em appear smaller/bigger in the game

16:40

but its tidious process and at the same time not practical i think

16:40

i have never been doing the quads thing and i dont know a shit, editor is not so intuitive

16:40

or maybe there is no option for that at all

hold on

16:48

omg i didnt know it automatically aligns the corners, though its only kind of deformation thing

16:48

well ty i guess

you can use grid to resize quad too

making tilesets is hard

16:56

but i think this look quite good

pilonpl

another issue is that there isnt really any reason to randomize the order of parts

my original plan was to make it so that your run lasts 3 seconds or your entire lifetime, only a few people are gonna finish the same map twice (excluding multeasymap players)

That probably wouldn't get released as an official map tho

obviously but what about the fun category

Idk

19:59

I had an Idea where the whole map is rng only

19:59

And you have 1 in 1000000 chance of winning

19:59

Literally

heh, yea I also had that idea

20:27

you could make it insanely improbable, and it would be a challenge for hax-authors to beat it by manipulating the rng

it would be a challenge for hax-authors

sounds like a bad idea

fair

Imagine if it would be actually impossible to beat the map

20:38

Because of the rng not being perfectly random

20:38

BTW

20:38

Does anyone know

20:39

Why that one trick on grandma

20:39

That used to work

20:39

Doesn't work anymore?

you gotta be more specifc than that :p

pilonpl

Why that one trick on grandma

The tee stack?

20:40

Here

20:40

Where you could align your dumny to the left wall

20:40

And then jump in

20:41

And bounce out of the freeze

jump in with a single jump?

Idk

well that could change the outcome

It just worked

20:41

Every time

20:41

And now it doesn't lol

20:42

Maybe i am just dumb

there shouldn't have been any change in regards to that, I'd like proof that it worked 100% before

20:43

^^

pilonpl

Maybe i am just dumb

And there has always been a way to screw up in that part

20:43

That's what i assumed at first

strong/weak could also affect the outcome

Why

20:44

No, i don't think it has anything to do with hook

strong/weak is not directly a hook thing, it also affects most other physics interactions

I didn't know that actually

20:46

~~why is strong/weak still in the game~~

20:46

We should fix it imo

bump mechanic is alot different with weak vs strong

20:47

for example

So maybe i was just lucky

20:47

To always do it the same way

pilonpl

We should fix it imo

that has been discussed multiple times already, here is the permanent github discussion: https://github.com/ddnet/ddnet/issues/4575

the physics of a part can also change if you move the part to another location, because of differences in floating point calculations

Yup

20:50

But the map hasn't changed

20:51

The only thing that could have changed is the server

20:51

Could be compiled differently

20:52

But that doesn't make much sense i guess

20:52

In terms of physics

the physics wasn't changed, so it also behaves the same and compiling has no element of randomness in such cases

Compilers can reorder operations

maybe new mouse / keyboard or some latency that changed on your end, or just change in muscle memory of doing the part

Idk

20:54

It's weird

20:54

I'll investigate this further tomorrow (edited)

pilonpl

Compilers can reorder operations

yeah but only if the result is the same the optimizations they apply, like un-rolling a for-loop, or constructing some optimized mathematic formula won't change the outcome. unless of course there is undefined behaviour, see Undefined behavior can result in time travel

I don't know exactly how compilers work

20:57

But i am pretty sure there is a flag

20:58

That allows the compiler to reorder operations on floating point numbers

20:58

Which can actually change the result slightly

20:58

But if it was the case

20:58

Predictions wouldn't work i guess

20:58

So

20:58

Yeah

yeah it would break the consistency of those systems, so that is unlikely. but can't rule out anything for certain, there were definitely such bugs in the past, see Pentium FDIV bug. but nowadays, exponentionally more unlikely to happen

21:05

and probably not the case here, anyway it's an interesting topic regardless

I thought about it because i watch a video about a similar issue in team fortress 2

21:07

Where the server would do different things based on the os it was running on

21:07

Because of different compilers

yeah that is definitely a thing especially when you add stuff like asynchronous code or anything system dependant

21:10

but usually the development should focus on cross-platform compatibility and do a lot of testing

21:10

to avoid such issues

Btw why are we using floats for stuff like player position

21:11

When it should have the same precision no matter how far we are from the origin

at this point probably tradition

21:11

but I agree, fixed-point seems better-suited

It literally doesn't make sense

OpenGL has float with 32bits as their default go to type

21:12

so this could be a reason, to be compatible

Maybe it's also faster

no, fixed point would likely be faster

21:13

fixed point stuff is essentially integers

Well i guess

21:13

Actually what would be a good use for floats

21:14

It's convenient for idle games

21:14

With really small and really big numbers

floats are really good for scientific stuff

21:14

and neural networks, apparently?

floats are fast because all CPUs have a FPU that is designed to carry out float / double operations and they are small, 32 bits but can go from -10^38 to +10^38 with about 6-7 accurate digits after the decimal point

21:17

so kind of a powerful compact thing and if you need more precision, you just go to a double with 64 bits and doubles are used alot everywhere

Floats in python are doubles i think

21:18

By default

yes

Python float values are represented as 64-bit double-precision values.

not only by default, it's the only thing that exists. python doesn't really have a 32-bit floating point type (edited)

Yeah

21:22

Integers in python are interesting

21:22

Because they don't have a limited range

https://www.agner.org/optimize/instruction_tables.pdf is telling me that on 11th gen intel CPUs, a floating point add takes ~1 cycle and an integer add takes ~¼ cycles

I also wanted to add that OpenGL likes float32 because it has usually enough precision to correctly position any object, you wouldn't spot a difference at all if you go through a 3d world and have 6-7 digits of precision vs 15. and more importantly, you save your 3D objects in a vertex array, which is an array of 3 rgb floats, 3 position floats and also potentially 2 vertex coord floats. so 3 + 3 + 2 = 8 floats, so 64 bytes per vertex. if you go double, you double the required memory, which could be a huge factor.

21:27

but that has consequences to the calculations, so yeah like heinrich said the best system would probably be one that uses fixed point floats. and then you convert those to the floats for the graphics api, (opengl / vulkan), if the performance loss is worth the accuracy

In case of ddnet there wouldn't be much difference i suppose

it would break the old maps though

Yeah

21:35

Of course

21:36

Nadeo doesn't care about breaking old maps

21:36

In trackmania

21:36

Lol

Based