level finalization, demo recording, tools for TASing, and other speedrunning concerns...

[Danfun64]

Since TSC is apparently going through a code rewrite, I guess now is a good time to voice my concerns.

I would appreciate it if you plan ahead for stuff like record keeping and future proof demo recording. I can't stand when FLOSS games have demo formats which are incompatible with newer versions (I'm looking at Hedgewars and the Cube engine games...) in addition, Mario games, which is what TSC is inspired from, have a large speedrunning base.

Demo recording isn't just great for speedruns and other types of record keeping through. They can also be used to provide gamer angles not normally seen in normal gameplay...

One thing to note though. If you implement these features, you should also provide an ingame way to render videos like ioquake3, prboom-plus, and hedgewars do.

That sounds only useful for multiplayer games, though.

Also, games like Hedgewars and Cube probably don't have that much going
on compared to TSC, where the engine would have to keep track of and
record hundreds of enemy paths, effects, level/world changes and other
state changes.

Sounds like a nightmare to implement to be honest.

On 01.06.2016 18:06, Danfun64 wrote:

Since TSC is apparently going through a code rewrite, I guess now is a
good time to voice my concerns.

I would appreciate it if you plan ahead for stuff like record keeping
and future proof demo recording. I can't stand when FLOSS games have
demo formats which are incompatible with newer versions (I'm looking
at Hedgewars and the Cube engine games...) in addition, Mario games,
which is what TSC is inspired from, have a large speedrunning base.

Demo recording isn't just great for speedruns and other types of
record keeping through. They can also be used to provide gamer angles
not normally seen in normal gameplay...

One thing to note though. If you implement these features, you should
also provide an ingame way to render videos like ioquake3,
prboom-plus, and hedgewars do.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#541, or mute the
thread
https://github.com/notifications/unsubscribe/ACxSOnqIK3xcyHm79xKsgXsFtOP6zUMfks5qHa3qgaJpZM4IrtuC.

[Quintus]

I would appreciate it if you plan ahead for stuff like record keeping and future proof demo recording.

Why provide an in-game video recording facility when there are enough external tools that allow you to record your screen? Even screenshot facility is something that should better be left to a tool on its own. Providing such functionality duplicates tools thare are readily available.

I can't stand when FLOSS games have demo formats

You’ll have to help me out on that. What is a demo format, other than a recorded video?

Vale,
Quintus

[Danfun64]

Demo files log the input of a game and play it back using the game engine. These files are very small in size and can be played in whatever the resolutions of the computer running them is.

The downside to them is that they can only be run in the game they belong to. That's where video rendering (whether internal or external) comes in.

The advantage of internal video rendering is that every frame can be recorded, while external video recording software like OBS can very well cause frame loss.

[Danfun64]

As for demos only.being useful for multiplayer games...I think TASVideos, the Speed Demo Archive, Compet-N and the Quake Done Quick series prove otherwise.

[Danfun64]

That being said, coop would still be a nice feature :P

That would require TSC to be deterministic, e.g. no random decisions in
some enemy type's direction states. Not sure it is worth it.

Am 01.06.2016 um 21:47 schrieb Danfun64:

Demo files log the input of a game and play it back using the game
engine. These files are very small in size and can be played in
whatever the resolutions of the computer running them is.

[Quintus]

Demo files log the input of a game and play it back using the game engine.

Ah, I see. sauer2 is correct when he imagines this to be very difficult to implement. It would require some hook in every moving function, and probably in even more stuff. Logging all the actions is going to be quite a problem with performance also I guess.

The advantage of internal video rendering is that every frame can be recorded, while external video recording software like OBS can very well cause frame loss.

Losing a few frames should not be too much of a problem; just play at a smaller resolution to ease things for your graphics card if it really becomes a bad problem. However, as with screenshots already, I think implementing such a feature is fine if it isn’t too much work. In this case, it’s probably just an extra call at the end of the Draw() function in each frame and some code to glue the frames together when the game exits.

That would require TSC to be deterministic, e.g. no random decisions in some enemy type's direction states. Not sure it is worth it.

This can be worked around. TSC does not make use of “real” random number generators, but relies on C(++)’s PRNG. The function srand() can be used to seed that generator. Once seeded with a number, it will always spit out the same random number sequence later, making it deterministic. So if a player wants to record a demo, the game can just save the used seed as well.

Valete,
Quintus

That sounds pretty cool.

Are you sure it's completey independent of the machine it runs on?

I'm asking, because I believe CDogs SDL uses the same thing for random
level generation and while I get the same mazes on the same computer,
mazes differ between different computers although the seed should be the
same...

Am 01.06.2016 um 22:01 schrieb Marvin Gülker:

This can be worked around. TSC does not make use of “real” random
number generators, but relies on C(++)’s PRNG. The function |srand()|
can be used to seed that generator. Once seeded with a number, it will
always spit out the same random number sequence later, making it
deterministic. So if a player wants to record a demo, the game can
just save the used seed as well.

[Quintus]

Are you sure it's completey independent of the machine it runs on?

The sequence depends on the implementation of rand() in libc. I don’t know what PRNG glibc uses, but as long as the two machines run the same (unpatched) version of the same libc (like two equal versions of glibc), the sequence should be the same.

Here is a simple C program which you can use to try things out. Run that on whatever machines you have available and observe how it behaves when you use a different environment.

Vale,
Quintus

Thanks!

I get the same numbers on the same PC, but different numbers for my
Ubuntu 16 LTS computer with libc 2.23 vs my Windows 7 computer where I
was unable to find the glibc dll in the mingw directory. That is, if
mingw isn't wired to use the c++ stdlib redistributable from Microsoft.
And then again, who knows what C-Dogs uses on Windows.

Also, if I remember correctly, the randomly generated levels look even
different on the Ubuntu 14 LTS machine of a friend, so there might even
be differences between not too afar versions of glibc...

Am 01.06.2016 um 23:06 schrieb Marvin Gülker:

Are you sure it's completey independent of the machine it runs on?

The sequence depends on the implementation of |rand()| in libc. I
don’t know what PRNG glibc uses, but as long as the two machines run
the same (unpatched) version of the same libc (like two equal versions
of glibc), the sequence should be the same.

Here is a simple C program which you can use to try things out
https://gist.github.com/Quintus/2a0ec1eb67055ddd37f915e43eb83e7a.
Run that on whatever machines you have available and observe how it
behaves when you use a different environment.

Vale,
Quintus

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#541 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACxSOvJNhb_z1yX_6jIA5A4EadvXz-4Cks5qHfRdgaJpZM4IrtuC.

[Quintus]

Thanks for posting the results, I’ve never looked closely on the phenomenon. Good to know that.

my Windows 7 computer where I was unable to find the glibc dll in the mingw directory

MinGW uses Microsoft’s libc (msvcrt.dll), which certainly implements rand() differently than glibc. If you want glibc on Windows, you’ll need to use cygwin.

so there might even be differences between not too afar versions of glibc...

Probably. You’d have to read glibc’s changelogs to be sure.

Vale,
Quintus

Is shipping an own PRNG an option?
Are there such libraries that could be statically linked, so one could
be secure it will always cause the same results?

EDIT: Would https://en.wikipedia.org/wiki/Xorshift do the trick?

Another thing that comes to mind when having the record based on player
input:

How will other aspects like different display resolutions and ratios be
handled?

[Quintus]

Is shipping an own PRNG an option?
Are there such libraries that could be statically linked, so one could
be secure it will always cause the same results?

Only if things do not evolve into a complicated code base. If we code one ourselves, its output of course will not vary as long as the same version of TSC is in use. For static libraries, there might be some, but you’ll probably get into conflict with package maintainers for Linux distros.

That being said, I am not really in favour of such a recording feature, not because of the PRNG, but because of the other implementation hazzles this is going to cause. I expect much more issues to crop up than the few we have mentioned in this thread.

If we agree that this feature is a good idea, it will certainly not be on the list of important goals, but rather something that will be added longtime.

EDIT: Would https://en.wikipedia.org/wiki/Xorshift do the trick?

It looks as if it could, but I leave this math-heavy question to @datahead8888 to answer, he is more knowledgable than me when it comes to such things.

How will other aspects like different display resolutions and ratios be handled?

Since that only results in an equal zoom, it should not impact the recording. An enemy for example just wants to move 10 units forward; how far 10 units is, is determined by the resolution settings. The recording would only capture the 10 units information. At least that’s how I’d expect things to be done.

Vale,
Quintus