Hello gamedev.net,

I'm thinking about making a medium-sized game in flash inspired by the idea of a quine:

"A quine is a program that prints its own source code."

I'm curious what direction you think this game should go. Technically, making a program a quine is a small challenge by itself. I'd also like to add the condition of using no assets at all. No bitmaps, animations, sounds, nothing. The entire game would be present in its source code. It would probably be a top-down shooter, for simplicity. Now, onto the design direction:

The player does not care about it being a quine. I mean, imagine you play a game, and then you find out all of its graphics and sounds are generated. Cool. And then it shows you its code at the end. Cool. But unless the game was good, you don't care. This would only make it interesting for programmers, and that is no way to design a game.

The quine-ness has to be built into the game mechanics. You could receive parts of the code, level after level, until it is completed at the end. This could possibly turn the game mechanics on and off. Like, you only have sounds from level 4 and in level 1 you can walk through walls because you don't have collision yet.

But... it's weird. Unless the game actually emulates the code you put in, it just feels staged and it might as well be staged. But if there is an emulator, what do I do to prevent the player from setting opponents' health to 1 or 0? Or could this what the game is about? To find how to change the code so you can win an impossible level? A game about debugging the rules?

That would require the player to try to understand the code. I could put a link to wonderfl.net and tell the player to paste the code in it(it is a website that compiles to flash online) to see it works. It could go as far that the player has to write the game loop itself - for() loops to display the level, graphics.drawCircle() to display enemies etc. It could be educational, but I'm not sure about this direction.

One idea I like is a recursive ending - as you gather the pieces of code, you display them in a terminal, and when you have the entire game, it starts again in the terminal(like 80% of the window). And the real ending could be the 2nd. Or the 3rd or 4th or whatever I choose, story would be made up to fit.

I still want it to be an actual quine. Maybe it could be about a conspiracy, that something higher is controlling the player's life, and it would display the class with the scripts as the last one? Or should it focus on the emulation? Should I completely omit the requirement for the player to understand the code - no "debugging"? Is a game running in itself on a terminal a cool enough concept to bet on? Tell me what you think.

I think the program actually being a quine wouldn't matter to 99.999% of potential players. I'm not saying don't do it, but realise that it will be a lot of extra work mainly for your own pleasure.

If you allow the player to modify the code in some way you run a variety of risks:

• Crashing
• Anti-virus software flagging it
• Unplayability (if they get it wrong)
• Not understanding what they're meant to do

Now that I've got the negative stuff out of the way, I think you could potentially do something interesting with a very simplified sandbox, maybe just flags for turning things on and off (gravity, collision detection, graphics for certain objects, etc), or perhaps a flowchart-style system. I can imagine the player having to complete a literally impossible task which can only be achieved by selectively turning rules on and off at certain times. There might be certain pros and cons, for example you can walk through a barrier with collision detection off, but you can't pick up the item you were meant to. Perhaps the player collects chunks of code and applies them to certain objects or subsystems.

A possible angle would be a Matrix-like scenario where in your fight you crashed the system and it needs to be fixed. But beware, you may unleash the very enemy you were fighting by re-enabling some systems.

You might want to check out things like the 96k FPS .kkrieger which generates basically everything procedurally. I could imagine intentional texture generation bugs which need to be fixed, but you'd need to let the player know when they got it right.

I can't remember the name, but there was an ASCII sokoban sort of game where the game logic was part of the stuff you could push around (and doing so would radically change the way the game worked, leading to hilariously wrong results if you pushed the wrong identifiers). I wish I had saved the name; I think the name may have used letters so it's hard to google for.

The first question I would ask about gamequines is: what counts as "printing" in a game? I'm guessing it means that the level layout, etc. are the realization of the source code. And a realization in a more obvious way than just being generated from the source code, like the player is navigating through a visualization of the game's source, not just navigating a procedurally-generated level where the source code was the source of information. (After all, anything that uses a seed to generate levels can use itself as that seed.)

My two thoughts on letting the player manipulate their environment, since this would presumably change the code itself:

• Nearly everything a player could do would lead to code that doesn't run at all. Especially if it's a top-down shooter -- there are relatively few places in a codebase that you can destroy something and still have a working program! I'd start in the other direction and ask "What manipulations would be likely to lead to code that still runs?" and base the game around those actions. (Say, if you had a "gun" that swapped two identifiers.)
• If the player is going to make code manipulations, I'd consider using or inventing a language with a relatively straightforward syntax and semantics, and coding the game-logic in that (and having that be the quine), and then having your Flash game be the interpreter. (I don't consider that cheating any more than writing a quine in any high-level language would be cheating.) Some language like Forth where the syntax IS the execution model, and there aren't many constraints on having a valid program (matching parentheses, etc.). I could picture a platform like game where each "block" is a single instruction in a Forth-like program, and you have various abilities that move, change, swap blocks, but meanwhile those blocks are the game logic that's currently running.

Thanks for the responses so far.

I agree that an actual quine output is not interesting for most of the players. I'll keep it in as a curiosity, so the name doesn't lie, but it won't be what the game is about. The theme is still code, simulation, and possibly recursion. The setting will definitely be a simulation.

If it would give the player an emulator / a programming environment, yeah, I would reduce it to the simplest of functions. An interpreter that can't crash and runs little commands issued by the player.

On being quine - at the very end the game presents a text field, Ctrl+A and Ctrl+C yields the contents of Main.as, the only file the game is made of. On collecting the code, I thought that it could show the code of a class at the end of every level. Like SoundManager, Collision, something like that. I would write the code in such a way that it is simple, nice to look at, and can be broken down to systems represented by classes (-> levels in the game as you turn them on). That's why I considered making it educational.

It feels fake if it displays the code of the SoundManager class and you simply click "Add to game loop" or something like that. I wanted it so that you COPY the code, PASTE it into the collection you have, so you know it works, since the game executes it as it is. But . . . this excites me, not the player There's no point in this if they don't know how to change it.

I'm afraid I can't go far in making the player do any programming. I could present the player with a:

for(i = 0; i < units.length; i++) {
 var unit:Unit = units[i];
 //type here
}

and then from observing other code the player would know to type "unit.Damage(100)" or "unit.Destroy()" - there could be a catch in damaging yourself. Such code could be binded to a weapon, or if it's too devastating like here, entered in a terminal. There would be a few in each level, like safe zones.

But that's about it. Anything more complex is just pointlessly endangering the environment. And this way the player would just write their best commands into it and spam it. Not much of a game, at this point this is just a normal shooter with a programming theme.. or each function could have an "execution time", and there could be functions like unit.Root(), unit.Slow(), unit.Heal(). Then you could design multiple weapons for yourself, and possibly level up your CPU speed? . . . But this is too far from what I wanted to do. It's "programming: the game", not "quine: the game".

My random thought on this, as a 2d side scroller, have the code be the terrain that the player moves through. Variables can be shot, and hitting them could do funky things like increment or decrement them, or perhaps the ability to 'pick up' a variable, and replace it with another variable. You could make anything that is immutable logic solid/unchangeable, since changing it is just likely to crash the program.