4 hours ago, Dawoodoz said:

I did that in the 1990s, so I know the pain. Higher languages change and dependencies go missing. The format needs to be minimalistic and stable against dialects by being expressive like a binary. Entering code would be automated by the camera once someone deciphered the document explaining how it works.

You would also need to explain how a computer works, how video works, and what those images you project onto the screen are.

The key question may be, How do you communicate the experience? 

In a game like Space Invaders, think of the timing of the sprite movement, the sound effects...that increasing pace. Left    right   left    right left right left right leftrightleftright. How fast your ship moves, timing the bullets.  This, rather than fidelity to original code and hardware limitations, is what makes or breaks adaptations  (at least for a player). 

There was a Mario game for the CD-I and what struck me was how much the designers talked about the challenge of getting the feel of Mario's jump right. 

Beyond that, I'd stick to data structures and pseudo-code with diagrams for sprites, controls.  

42 minutes ago, Mosker said:

The key question may be, How do you communicate the experience? 

In a game like Space Invaders, think of the timing of the sprite movement, the sound effects...that increasing pace. Left    right   left    right left right left right leftrightleftright. How fast your ship moves, timing the bullets.  This, rather than fidelity to original code and hardware limitations, is what makes or breaks adaptations  (at least for a player). 

There was a Mario game for the CD-I and what struck me was how much the designers talked about the challenge of getting the feel of Mario's jump right. 

Beyond that, I'd stick to data structures and pseudo-code with diagrams for sprites, controls.  

 

Maybe both are needed then. Methods in scientific papers are often ambiguous without example output and reference implementations.

3 hours ago, VanillaSnake21 said:

I think the best way to represent source code universally is by using the most minimalist assembly instructions. That would be something like mov, add, mul etc. Just find the most basic instructions that any program can be rewritten with and use only those instructions for writing the source of the game. Then you would include some kind of a primer that would identify the mov instruction as such. All data would be written in regular binary formats, just basically color dumps for images. You'd still need primers for data, but it wouldn't be that difficult to write those. 

Removing stack memory using named or indexed globals can probably be done for non-recursive calls. Visual Basic 6.0 had no stack memory.

2 hours ago, Endurion said:

Another challenge thoroughly overlooked here is that you also have to have defined specs of the runtime environment (for e.g. graphic, sound, input), unless you go text only. Assembly is one thing, but it obviously is designed for one specific architecture.

No OS below, unless you also put that on paper.

 

initializeScreen(width, height), setPixel(x, y, r, g, b) and display() would probably be the simplest resolution and color agnostic graphics api capable of defining completed frames.

1 hour ago, deltaKshatriya said:

Paper degrades pretty badly over time...paper would be a horrible means of long term storage. I'd say that there are a ton of modern storage systems that would be far better than paper if survivability is the goal.

That's why you need printing plates in a metal that won't get rusty or looted for materials during wars and poverty. Crystal discs might be overwritten as soon as a server company runs out of storage space and buys it on the black market. Peer-to-peer sharing dies out in the next middle age.