I've been dabbling with the idea of a game based on programming and Self-Modifying Code for a long time (inspired by Code Wars and ...this sub-game...). My idea involves having "robots" which move on a grid, with "instructions" (like arrows or rotations) which are either tiles on the grid or movable blocks. The robot(s) would read instructions as they encountered them, and either store them somewhere or cause some other robot to execute that instruction. Or perhaps there could be different color instructions and different color robots, such that a robot would "push" his own instruction blocks, but step on others so as to affect the other robots. Perhaps instead, the robot(s) could have a "processing unit" which actually moves around in the grid, but can also be interacted with directly. ... Lots of variables and options; and I don't even know what the goal would be!!!

However, I have once again found a possible idea for this kind of game (though it's not a complete idea): There could be instructions for moving (whether fixed directions, or rotations and "foward/backward" etc.), and there would be numbered instructions. The robot(s) have their own set of instructions that they are executing (separately from what is on the grid). For every (non-blank) tile that the robot steps on, the corresponding instruction is copied into some kind of "memory" (For now, let's assume that all memory banks are numbered [one per possible number instruction], and that their contents are visible). It is important to distinguish that the robot will be continuously EXECUTING instructions from some memory bank (rather than from the tiles that it steps on directly). As the robot(s) steps on a tile, that instruction is read into some memory bank. The numbered instructions represent "calls" (or gotos) to other memory banks. One problem I have so far is that there are 2 ways to interact with numbers (step on or execute from memory), but 3 actions associated with them (goto/call another subroutine, write the number to memory, or switch which subroutine to write to). This brings me to realize that I can either have the robot write to where it is reading from (e.g. execute an instruction, but leave behind another), or have a separate indication as to where the "writing" is going. If there are essentially two "instruction pointers", then perhaps I can color the numbers to differentiate whether they move the "writer" or the "reader" between subroutines (so far I assume that they both advance "forward" in memory, which may or may not be looped). One thing that is interesting to note is whether or not all robots would share the same memory (which I like, actually), or whether instructions can be different colors so as to have significance toward certain robots (if there are more than 1 anyway).

A slight (but significant) variation on this would be to have one (smallish) memory location, which the player would modify before starting the "simulation" (the positions of anything physically on the grid is not alterable at this point, and is what would constitute a "level"). After that, the robot is to run the "program" from start to end, and then stop (and then we see if some goal was achieved). HOWEVER, there could be an instruction to "open" a "new" program, which the robot will read instructions into until it is "closed". Each new program would correspond to some number, and after it is "made" (by the robot executing a "make N" [where N is some program number], reading instructions into it from the grid, and then executing a "close"), then the corresponding number-instruction means to execute that program. This is recursive, meaning that while the robot is "writing" a program, it can write OTHER programs to use in that first program; and once it is done writing a program, the number-instructions revert back to the programs they referred to BEFORE that program. I suppose I could make a visual to show the "program being made" next to the current program, and while that program is being made, it can do the same, etc. ... There would be one display showing programs executing (stacked up next to eachother), and another separate display showing programs being made.

Of course there are other things to consider as well: Does movement continue until hitting a wall/block or until another instruction is read, or just result in moving ONE step? Are there movable blocks?

I can add more to my previous "variation": perhaps after "making" a program, that program in its entirety (including its own "local"/inner programs) is placed on the grid where the robot was, so that any other robot can walk over it and thus "read" it into memory as an instruction. This would allow these programs to just sit there and be reused. This would also allow "inner" programs to be made by making the inner program, and then reading it as an instruction into another program-in-the-making. The idea with this variation is that memory is only ever modified for programs being made, and not for already-made programs.

... So that's quite a lot of randomness, but I'd REALLY like to see this done! I can do it in Java; but is anyone else interested in exploring this kind of idea/game or trying their own variations?

(another variation could involve having robots separated by walls, and they somehow have to program eachother, probably by sharing a common memory. The player would/could put instructions for an initial robot, and then...).

Previous ideas have included having the "processing unit" for robots actually be ON the grid, and possibly have their own movement or be "pushable" (and possibly slide like they are on ice), or having robots act as eachothers CPU's (e.g. robot-A executes instructions that robot-B steps on), or having instructions be robot-specific (e.g. the red arrow makes the red robot move; with some rule about robots ignoring their own color or not being able to step on it, or something like that), or having CPU units only be able to move onto their own color, but other colored tiles get pushed by them like blocks ... ... So that's just some ideas from the past, but let's focus on my "Making a program" idea (whether it uses dynamic program creation, or a finite set of shared memory).

...Ideas? Comments? Opinions? ...

Might I suggest jgap for this? jgap.sourceforge.net

Now that I have more time to write this post out. I like the initial idea, but then I think you made it a little too complicated. The general idea of having robots learn would be an interesting idea.

Shall I suggest starting out by having good/bad blocks, and giving each robot a score. Then, you can have them reduce their score if they "eat" a bad block, or increase if they "eat" a good block. This way, you can get out all the bugs with their learning movement from randomness if you choose to go that route.

wow, this would be an awesome project

I admit I TL;DR'd on most of that, but it seems like it boils down to a robot fightin' game based on a genetic algorithm. The first thing I thought of when starting to read was generating corewar programs with a genetic algorithm.

Re: JGAP. Yes! This is the library I've looked for (and knew it existed) before but Google didn't find!

Note: A lot of the stuff I said contains random ideas I've had for such a game; it cannot ALL go together (so I don't think I'm making it too complicated ... I'm trying to simplify by weeding out / separating all these ideas, which have been stirring around in my head for a couple years at least).

It is not a genetic or learning algorithm. Each level has a way to win it (whatever that means: push all the blocks somewhere, or get the robot somewhere, or collect all of something ... I'll decide that later), and the player is supposed to figure out the "how". Of course, since this might be very complex, it would probably be smart to go with a scoring method rather than a "try it again until you get it right on the nail" approach.

To make it more simple, think of something like corewar, except instead of the instructions controlling the machine/CPU's, they are controlling robots outside of itself.

I suppose if I made it multi-player, it could be a competition to "get the most stuff" or keep moving the longest or something ... or to kill the other robots

...Ok, here is another idea similar to this:

You know how in Minecraft, you start out with raw resources and combine/manipulate them into other things? Well, I'm thinking of doing something similar, but with code. That is, you start with the most fundamental instructions and can combine them together to get more complex things -- This came to mind when I was thinking about the idea of making "subprograms" into single instructions.

However, instead of it just being raw code, you have an interactive environment based on "game components": Basically, physical blockish-things that have a position and can move/be moved, etc., only they are "made" with intelligence about what's around them. Think of instructions being create (some object), move, change speed, destroy, etc., and you can refer to properties of self or of given objects. Each object can be given particular functionality, so stuff would trigger "on collission" or something, and perhaps an update-ish loop. The idea with a game like this would be something progressive, so you'd have to be able to construct something fundamental things to get past the first level, and then need more advanced things after that, etc. The objectives might be different per level.

As for "crafting" objects, there would probably have to be so extent where the objects can be programmed to craft other things. This might be done by having "instructions" actually represented as things that can get pushed around and perhaps somehow "sandwiched" into a working thing. Just to make a bizarre example, suppose the environment were like minecraft, and by themselves, each block had certain properties; but surrounding a line of blocks on either end with stone makes it into something else, and the blocks inbetween determine that. The blocks in the line-up would be the actual instructions ... But I'm not supposing that "minecraft" blocks should be used, but something. Perhaps the things are like robots, and they can pick up "blocks" and manipulate them on some metaphorical "crafting table" and then spit them back out.

... Again, very loose idea, and anything rigid (physical) I said is up for change -- it's the concept I'm after

Skynet?

...Ok, I'm starting this over: http://www.cemetech.net/forum/viewtopic.php?p=179869#179869

Great to hear; I'll look forward to following your new project with interest. Of course, I won't be locking this topic since Cemetech policy is to leave topics open for future reference and discussion.