Hi Thomas,
thanks really a lot for your insight - I never thought of comparing with the WGAN 
So yes !!! I’m keen to do the experiment you suggest i.e. comparing the three-player game setup in this paper with the WGAN. I’m very curious how the two compare! Will need to think a bit more carefully though about a reasonable architecture for the WGAN - I’ve got no experience of training sequence GANs so I’m sure how to do it yet?
I’ve got a reasonable amount of the architecture and training code for the 3 player game paper done now. What I’ve got so far is - that the Encoder E is basically just a standard image captioning CNN-LSTM architecture 1  with the 2D residual CNN replaced with a 1D  residual CNN. The Predictor P can just be a simple MLP.
So this architecture can be trained using the algorithm posted at the top of this thread, minus the discriminator loop, i.e. just ignoring the lines repeat, Update  discriminator D: until
In the paper, in section 4.5 - Role of Our Adversarial Discrimnator, the performance of this simple setup, (of just the Encoder and Predictor), is refereed to the “baseline model”, and it’s compared with the full setup, i.e. including the Discriminator. It seems the performance of the baseline is not soon bad on it’s own, but the addition of the discriminator has some important effects, in particular it allows the learning transitions between the labels, which is a hidden/latent category never presented to the predictor network - so that’s empirically quite interesting 
So hopefully we should be able to test this baseline model soon - i.e the next few days, I’ll try it and get back to you - I’m guessing that it should train reasonably quickly compared to larger image/more complicated GAN models?
As you pointed out, looking into the data pre-processing in more detail it appears there are few different reasonable ways to convert the accelerometer data into spectrograms? I believe the ichi2014 dataset has a 100hz sampling frequency so slicing this up into 30 second windows should give 3000 data points - I’m hoping that this will be good enough to get a reasonable spectrogram - using scipy.signal.spectrogram 1 - which should output a single 1D vector of the amount of energy in each frequency “bin” - for each 30 second window. Alternatively I’ll just have to experiment with different sized windows as I’ve seen the spectorgram method applied to accelerometer sleep data before. Though I believe it’s quite common for accelerometer activity recognition data 1 - so perhaps I/we could have a look into that if this doesn’t work? Alternatively, the authors of the MIT paper have said they will release their RF and Polysomnography data, but I’m guess if that does happen it won’t be till mid August, after they present the paper at ICML17 
Here’s a nice picture of the the time evolution of a spectrogram “window”,
spectrogram.jpg743×527 256 KB

If I’m not going crazy - each single spectrogram is a slice through this 3D plot at a set time. This slice is then simply a vector of real numbers, where each number in the vector is the power in a particular frequency bin, i.e. the height plotted on the amplitude, z-axis
Since there are 3 channels in the accelerometer data, I’m guessing I’m either going to train three separate Encoders, and perhaps share the weights? Or, alternatively and more simply I could just add the spectrograms, to get the energies summed across all three channel, for each given bin. I’m not too sure about these two design decision’s so I guess I just have to try them both?
I’ll post the all code (loading-preprocessing-spectrogram, models and the training scripts) in a Github repo as soon as it’s working/worthwhile to share.
Really nice to be working with you again 
Best regards,
Ajay
PS - thank you very much for the link to code on the  this uni-siegen page - somehow I missed that?
PS2 - there’s a nice video about the RF device implementation here - https://www.youtube.com/watch?v=BhSL7AILTzE 3 - it does’nt talk about the three player game or really any deep learning methods, but it’s interesting background for this particular use case