Jump to content
  • Advertisement
Dawoodoz

Storing full games on paper?

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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.  

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!