Request Watch others

[Jeff Strong]

The thread title is creeping me out.....

 

[Tuomas Hämäläinen]

After some thought on the subject, I may end up waiting until the PC version comes out to continue my videos. While I love my 27in 2560x1440 LED display on my mid 2010 iMac 10.8.3, the controls leave a lot to be desired. I've managed to get the 360 controller working pretty good with a program called "enjoy". The problem is if I'm holding a flipper button, I can't nudge. As you can imagine this has led me to do some strange things to make decent scores. =) The software I'm using to record the videos on OS X is called "Screenflow". It offers a ton of options and fair video quality.

Thanks for the reply! You should try a PS3 controller with your iMac, it's awesome.

 

[Mike Reitmeyer]

The problem with this is that pinball isn't entirely deterministic. There are (semi-)random rolls in some situations on some tables and that would throw the entire thing off kilter. These things are also almost completely impossible to implement without rebuilding the entire game engine with that in mind.

This is the biggest problem. I tried to implement a replay system for debugging, but the only way to get real valid data was to record every single frame. Too much randomnesss off of some things. Once it gets slightly out of sync, it goes down hill from there. We would have to re-write a good deal of logic.

Also the state of the emulation would have to be stored exactly the same at the start.

 

[9u1d0]

This is the biggest problem. I tried to implement a replay system for debugging, but the only way to get real valid data was to record every single frame. Too much randomnesss off of some things. Once it gets slightly out of sync, it goes down hill from there. We would have to re-write a good deal of logic.

Also the state of the emulation would have to be stored exactly the same at the start.

If you only focus on the playback you could think of storing all relevant data of every object per frame.
For a ball you need the x/y/z coordindates only per frame.
Every drop target only needs to store it's state per frame.
Also every light (on/off) only needs to store it's state per frame.
Every frame you can also store the score-delta.
For the flippers, just store the state it is in, probably an integer per frame.

In an OOP environment this could be easy implemented.
The playback just needs to read back and set the state of all objects per frame.

Optimize it (reduces amount of data) by only storing delta objects. A light that stays on for 200 frames and turns of at frame 201, just record the change at 201.
Think of it like some kind of playback-script telling all objects how to appear.

Not sure if this can be implemented easy on things like the DMD, or the music that's playing.
Also TPA probably has a lot of objects.

 

[superballs]

Ah, bummer for the PS3 crowd once again..

Its not so bad. The unit ships with a component to hdmi adapter or something. Really for the purpose they will do fine

 

[Mike Reitmeyer]

If you only focus on the playback you could think of storing all relevant data of every object per frame.
For a ball you need the x/y/z coordindates only per frame.
Every drop target only needs to store it's state per frame.
Also every light (on/off) only needs to store it's state per frame.
Every frame you can also store the score-delta.
For the flippers, just store the state it is in, probably an integer per frame.

In an OOP environment this could be easy implemented.
The playback just needs to read back and set the state of all objects per frame.

Optimize it (reduces amount of data) by only storing delta objects. A light that stays on for 200 frames and turns of at frame 201, just record the change at 201.
Think of it like some kind of playback-script telling all objects how to appear.

Not sure if this can be implemented easy on things like the DMD, or the music that's playing.
Also TPA probably has a lot of objects.

Just take the ball for example. x,y,z is 12 bytes (x, y and z are all floating point 4 bytes each). Then figure 6 balls per table (so far thats the most on a table we've done. 60 frames per second, 60 seconds in a minute, 60 mins in an hour comes out to 12*6*60*60*60 = 15,552,000. So an hour of gameplay would be 15MB just with the ball data.

Doing the DMD would require much more data storage, and then you also have the sound effects the rom plays. Unless you are emulating the rom and having it go as it's actually playing you would need to store 1000's if not 100s of 1000's of sound calls and timing, for an hour of gameplay.

 

[TomL]

Are the pseudo random number generators seeded with known values? If so, then reseeding with those known values plus a timestamped log of user intputs (plunges, flips, nudges) should allow the game engine to recreate gameplay.

 

[jhamdotme]

Doing the DMD would require much more data storage, and then you also have the sound effects the rom plays.

Isn’t this the point of in-engine playback? We’re not suggesting that these videos should be recreated for YouTube here. Traditional videos would be terribly inefficient for something like this. I just want to be able to play back “replays” from within the actual game. I want to see stuff that’s being recreated on the fly.

Are the pseudo random number generators seeded with known values? If so, then reseeding with those known values plus a timestamped log of user intputs (plunges, flips, nudges) should allow the game engine to recreate gameplay.

This is what I was thinking. Isn’t in-engine playback just following a script, and isn’t that basically just text? That seems small. And like TomL mentioned, the only thing keeping this from a straight-up “tool-assisted speedrun” style replay is the randomness inherent in pinball. So can’t those random numbers just be logged alongside the rest of the inputs in the log?

 

[TomL]

You wouldn't need to log any of the random numbers, just the initalizing seed(s).

Random numbers from software is pseudorandomly generated. Know the seed used to initialize the prnd function, and you can generate all the same "random" numbers again.

 

[Sean DonCarlos]

Random numbers from software is pseudorandomly generated. Know the seed used to initialize the prnd function, and you can generate all the same "random" numbers again.

Some of the table ROMs generate their own random number sequences internally (Twilight Zone does for its Camera awards, for example), and the seed values used for these sequences are not necessarily available to FarSight's code.

 

[TomL]

It's still being seeded, even if it's a prnd function within the table ROM. Probably based on the table's system time in milliseconds.

If the table is being emulated Pinball Arcade, then as long as the total initial state of the emulation is known, then it can be reproduced again.

 

[Sean DonCarlos]

RNGs aside, suppose you have a recorded replay from some time ago, and then FarSight updates the table in some way (bug fixes, physics improvements, what have you) that causes the played back data to yield different behavior. Now what?

 

[jhamdotme]

It'll have to play back using the same engine, and using the same assets. There will be overlap here, if all these things are going to be preserved to support older replays. There will surely be redundancy.

But even with all of this stuff, it'll still be much more efficient than encoding traditional videos. A single video would take up more storage space than all of these redundant assets, most likely.

 

[TomL]

You'd need a replay engine that's compatible with the pinball arcade app and table rom used to produce the recorded replay. Obviously.

The point is, with known software code (app, roms) and known initial state (seeds, system datetime) and known user inputs, you can recreate the gameplay exactly.

In essense, you're emulating the Pinball Arcade app's emulation of the pinball table's ROM execution.

Inception. We must go deeper.

 

[Sean DonCarlos]

My programming experience tells me that this would be more trouble than it's worth, but that's for FarSight to decide, not me.

 

[9u1d0]

Just take the ball for example. x,y,z is 12 bytes (x, y and z are all floating point 4 bytes each). Then figure 6 balls per table (so far thats the most on a table we've done. 60 frames per second, 60 seconds in a minute, 60 mins in an hour comes out to 12*6*60*60*60 = 15,552,000. So an hour of gameplay would be 15MB just with the ball data.

OK, this is worst case scenario. Most of the time only one ball will be active. Using delta values here will probably cause rounding-effects, but can be compensated for in special 'compensation' frames.
Optimizing this will be a challenge though

But 15MB per hour is still way less than an hour of YouTube video.
Light/bumper/droptarget states could often be placed in single bits. (On/Off, true/false)

Doing the DMD would require much more data storage, and then you also have the sound effects the rom plays. Unless you are emulating the rom and having it go as it's actually playing you would need to store 1000's if not 100s of 1000's of sound calls and timing, for an hour of gameplay.

I guess SFX will often be activated by drop target, bumpers, etc. So a lot could be activated via the data-'script'.

Ofcourse it will be a lot of data per game. But I think this can be done.
We're living in the era of 'Big-Data'. I do know a 4-men Hi-Tec company that can help you with this

Also considering only storing the top 50 per table in the leaderboards might be a good idea.
And endusers can store any game on their device only. That would not need server space, nor it would need network traffic

 

[Gord Lacey]

Though it may beossible to do it, where does the funding come to implement it? How many man-hours would it cost to code and debug, and how do you justify this cost? That's the question (or questions).

 

[TomL]

Though it may beossible to do it, where does the funding come to implement it? How many man-hours would it cost to code and debug, and how do you justify this cost? That's the question (or questions).

Mike mentioned that a replay system would be useful for debugging. I would say anything that might improve the quality level of the product is worth considering.

Esp if it can serve multiple purpose of debugging tool, replay engine, etc.

 

[Mike Reitmeyer]

Mike mentioned that a replay system would be useful for debugging. I would say anything that might improve the quality level of the product is worth considering.

Esp if it can serve multiple purpose of debugging tool, replay engine, etc.

In our debugging version I created something that records the last 10 seconds of gameplay. This requires 2MB of ram per ball to store all the details of each frame (and sub frame), what the ball is colliding with, etc. We use that for debugging physics.

I had to go this route cause I wasn't able to get a full replay system working in a reasonable amount of time.

 

[ER777]

My programming experience tells me that this would be more trouble than it's worth, but that's for FarSight to decide, not me.

Though it may beossible to do it, where does the funding come to implement it? How many man-hours would it cost to code and debug, and how do you justify this cost? That's the question (or questions).

Of course the Mod and the Admin have summed it up nicely. People are quick to forget the opportunity cost of this type of endeavor also. If FS is working on this then that's less people working on fixing bugs and implementing more useful features.

Just because something is theoretically possible and might be "neat" if done, that doesn't make it a good idea to pursue.