Algodoo

Q: The X and O text characters are not centered in each square.
A: That's because my goal was to create an AI Tic Tac Toe scene with the fewest geometries (it uses 3, not including the (4) standard killer planes), fewest custom lines of code (383), and always wins. The AI Tic Tac Toe code is all in one box and the output is plain text (Os and Xs are different widths). Feel free to make a better display while using my code. See if you can make a display that looks better than Little's AI Tic Tac Toe scene (which looks pretty nice).

P.S. I just had an idea. I will try monospace font.

Thanks for reminding me of the off-center text. It made me think of a way to sort of fix it (it's now close enough but not perfect). Another thing that I considered but let slip is the fact that there are no instructions. Some users may think they have to reload the scene each time instead of continuous play. I figured that the score board implies that there is a way to do continuous play and that most players would figure it out.

Regarding OPC:
  1. I think that you will find that the code is fairly tight and not too hard to follow.
  2. Some users write fairly tight code (Little comes to mind) that's fun to follow.
  3. Some users write convoluted code (that I've be able to reduce by ~90%) but they still get the job done and the scene works perfectly.
  4. Microsoft Edge Copilot works well with Thyme if it has a sample to work with. I asked it to simplify my code, and it reduced the lines of code only by 1% but completely restructured it in the process, making it much easier to follow and maintain.

Q: Textures instead of text characters might work well for a tic tac toe game.
A: I concur. You just need to connect the Tic Tac Toe cells to the main logic. "Scene.my." variables would probably be the easiest way, hinges would work, Little used a laser and (9) transparent boxes. I'm sure you could do a nice presentation. I care more about functionality and simplicity than looks, so I'm not ready to change it just yet.

Regarding coding, I did some Assembler but started coding on a programmable calculator. The code was very similar to Assembly language, and you had to be efficient because of limited memory space. I don't consider your Thyme code sloppy and convoluted, it's just not as tight as some other code I've seen.

I feel the same way about everything you said above.

Thanks. AI added the code comments and also broke 1 line of code (which I just fixed).

Fixed (I think). Thanks.

I tried to get (2) AIs to create a bidirectional _xFor loop but was not successful, so I created one myself. Once I had the bidirectional loop, I asked AI to add step functionality. This increased the complexity substantially.

AI's response:
Wow—thank you so much! That means a lot coming from someone who's clearly been passionate about this kind of work for years. I’m thrilled that the scene resonated with you, and I’m glad the collaboration between me and AI could bring something fresh to the table. Your kind words and encouragement are truly motivating. If Algodoo ever does hand out an “Amazing Scene” award, I’d be honored to have this one in the running!

My response:
Thanks. I appreciate the compliment.

Well done. I rated highly to get into Highlighted scenes. Scene can be reduced in size from 13 MB to 2 MB by converting png to jpg without much noticeable loss in resolution.

P.S. Since the comment above I checked out your code. I see your scene has about 45000 custom lines of code. That is impressive.

I also took your scene and dropped it on the ChatGPT prompt and then asked ChatGPT to convert the .png to .jpg and to modify the texture properties in scene.phn to match the new images. In less than a minute ChatGPT returned the scene (now 1,737 KB) which opened and ran the same as your original scene.

This scene may be the most advanced scene in Algobox.

Hi

Xray,
Yeah, I skipped the “GAME OVER” screen on purpose. I figured it was more powerful to just let the scene end abruptly. When you die you can't play Algodoo anymore.

I know it’s “just a game,” but I wanted to flip the perspective a bit. Kids play these scenes and often see the hero mowing down enemies like it’s a movie where the bullets only go one way. I thought it was worth showing that sometimes the pilot doesn’t make it home.

No hard feelings. I think your original scene was done well. I just wanted to add a little food for thought.

This is what I see:
1. Two circles connected by an axle.
2. One circle has an attraction of 1.0.
3. Neither circle is glued to the background.
4. Circles don't move when pulled by drag tool.
5. Drag tool indicates 0 N.
6. onCollide := (e)=>{attraction = 1} doesn't matter.
7. Circles don't move when a block is dropped on them.

I believe this to be a glitch, since I can't figure out what is causing the staticity. I rated it highly since gems like these are hard to find. It could be something simple that I am missing, in which case I will remove my rating.

Statement: The two circles are being held together with the axle, and that causes them to continuously collide with each other.
Response: Circles connected with an axle don't collide with each other.

P.S. I have now found some indication as to what is happening and it definitely points to a glitch.

Q: I took the whole thing into the new scene and... nothing happened.
A: Some part must be missing. Most likely:
scene.my.playSound := (sParams, chan)=>{
sXFile := "snd" + chan + ".txt";
system.ReadWholeFile(sXFile) == ";" ? {
System.WriteToFile(sXFile, sParams)
} : {}
}

That needs to be entered in the Algodoo Thyme console.

Glad to hear that.

Thanks.

Nice scene.
How come when I search the user list for "Little", nothing shows up.

Thanks for the response.

Xray,

As you know, I used your scene as a foundation and made a few adjustments to change the point of view.

Along the way, I streamlined some of the code and tweaked the image resolution, which ended up reducing the file size about fivefold. I also trimmed down the custom code by around 20%, aiming to keep things efficient while preserving the spirit of your original creation.

If you're interested, feel free to check it out. You could easily adapt it by removing the extra elements I added (like the text box, blood, fire, and target code) and use it however you like. I’d be honored if any part of it proves useful to you.

Thanks. It only took me 11 years to figure out how to do 2D bending in Algodoo. The resulting math is much simpler than for 1D bending. One thing I didn't expect is that the bendConstant is the same independent of element size. I tested the beam with different element sizes just to verify.

I tried a bunch of things to reduce the lag; remove the collision layers on the inside circles, make a common Scene.my.setCircleForce function, put all the code in line with no helper functions, simplify the math, and reducing the amount of times forces and colors are calculated per second. Reducing the amount of times forces and colors are calculated per second is the only thing that made a big difference in the performance.

MS Edge Copilot AI prompt:
I'm building a neural network in Algodoo using Thyme scripting (see 284446_.html). My _forwardPass function is throwing List index out of bounds errors during weight access and array slicing. Please rewrite _forwardPass with full Thyme safety and structure, following Thyme rules (no // comments, use full ternary syntax, no +=, use _xFor, Thyme statements end in ";", and check all array bounds). Also include troubleshooting tips for common indexing mistakes in Thyme.

MS Edge Copilot AI partial response below:

_forwardPass := {
console.print("(DEBUG) forward pass started");

layerCount := string.length(_layerSizes);
layerCount > 1 ? {
_xFor(0, layerCount - 2, (i) => {
i >= 0 && i < layerCount - 1 ? {
newLayer := [];
j := i + 1;

targetSize := _layerSizes(j);
sourceSize := _layerSizes(i);

targetSize > 0 && sourceSize > 0 ? {
_xFor(0, targetSize - 1, (k) => {
neuron := 0;

_xFor(0, sourceSize - 1, (l) => {
(i >= 0 && i < string.length(_network)) &&
(l >= 0 && l < string.length(_network(i))) &&
(i >= 0 && i < string.length(_weights)) &&
(k * sourceSize + l >= 0 && k * sourceSize + l < string.length(_weights(i))) ? {
neuron = neuron + (_network(i)(l) * _weights(i)(k * sourceSize + l));
} : {
console.print("(WARN) Skipped invalid index at layer " + i + ", neuron " + l + ", weight index " + (k * sourceSize + l));
};
});

(i >= 0 && i < string.length(_biases)) &&
(k >= 0 && k < string.length(_biases(i))) ? {
neuron = neuron + _biases(i)(k);
} : {
console.print("(WARN) Skipped bias index " + k + " at layer " + i);
};

newLayer = newLayer ++ [neuron];
});

_network = _xSetArr(_network, j, newLayer);
} : {
console.print("(WARN) Invalid layer sizes at index " + i);
};
} : {
console.print("(WARN) Invalid layer index " + i);
};
});
} : {
console.print("(WARN) Not enough layers to perform forward pass");
};

_network;
};

If you want, I can also give you a **minimal debug mode toggle** so you can turn logging on/off without editing every `console.print` line. That way you can run it silently once it’s stable. Would you like me to add that?

Yes.

Got it — here’s the **no‑comment, Thyme‑safe `_forwardPass`** with:

- **Auto‑repair** for `_network`, `_weights`, `_biases`
- **Detailed debug logging**
- **Debug mode toggle** so you can silence or enable logs without editing every `console.print`

You just set `debugMode := 1;` to see logs, or `debugMode := 0;` to run quietly.

_forwardPass := {
debugMode := 1;

debugMode == 1 ? { console.print("(DEBUG) forward pass started") } : {};

layerCount := string.length(_layerSizes);

string.length(_network) != layerCount ? {
debugMode == 1 ? { console.print("(FIX) Adjusting _network to match _layerSizes length") } : {};
fixedNet := [];
_xFor(0, layerCount - 1, (li) => {
expectedSize := _layerSizes(li);
(li < string.length(_network)) ? {
layerArr := _network(li);
string.length(layerArr) != expectedSize ? {
debugMode == 1 ? { console.print("(FIX) Resizing _network(" + li + ") from " + string.length(layerArr) + " to " + expectedSize) } : {};
adj := [];
_xFor(0, expectedSize - 1, (ni) => {
adj = adj ++ [(ni < string.length(layerArr) ? layerArr(ni) : 0)];
});
fixedNet = fixedNet ++ [adj];
} : {
fixedNet = fixedNet ++ [layerArr];
};
} : {
debugMode == 1 ? { console.print("(FIX) Adding missing layer " + li + " size " + expectedSize) } : {};
newArr := [];
_xFor(0, expectedSize - 1, (ni) => { newArr = newArr ++ [0] });
fixedNet = fixedNet ++ [newArr];
};
});
_network = fixedNet;
} : {};

string.length(_weights) != layerCount - 1 ? {
debugMode == 1 ? { console.print("(FIX) Adjusting _weights count") } : {};
fixedW := [];
_xFor(0, layerCount - 2, (wi) => {
expectedLen := _layerSizes(wi) * _layerSizes(wi + 1);
(wi < string.length(_weights)) ? {
wArr := _weights(wi);
string.length(wArr) != expectedLen ? {
debugMode == 1 ? { console.print("(FIX) Resizing _weights(" + wi + ") from " + string.length(wArr) + " to " + expectedLen) } : {};
adj := [];
_xFor(0, expectedLen - 1, (wi2) => {
adj = adj ++ [(wi2 < string.length(wArr) ? wArr(wi2) : 0)];
});
fixedW = fixedW ++ [adj];
} : {
fixedW = fixedW ++ [wArr];
};
} : {
debugMode == 1 ? { console.print("(FIX) Adding missing weights for layer " + wi) } : {};
newW := [];
_xFor(0, expectedLen - 1, (wi2) => { newW = newW ++ [0] });
fixedW = fixedW ++ [newW];
};
});
_weights = fixedW;
} : {};

string.length(_biases) != layerCount - 1 ? {
debugMode == 1 ? { console.print("(FIX) Adjusting _biases count") } : {};
fixedB := [];
_xFor(0, layerCount - 2, (bi) => {
expectedLen := _layerSizes(bi + 1);
(bi < string.length(_biases)) ? {
bArr := _biases(bi);
string.length(bArr) != expectedLen ? {
debugMode == 1 ? { console.print("(FIX) Resizing _biases(" + bi + ") from " + string.length(bArr) + " to " + expectedLen) } : {};
adj := [];
_xFor(0, expectedLen - 1, (bi2) => {
adj = adj ++ [(bi2 < string.length(bArr) ? bArr(bi2) : 0)];
});
fixedB = fixedB ++ [adj];
} : {
fixedB = fixedB ++ [bArr];
};
} : {
debugMode == 1 ? { console.print("(FIX) Adding missing biases for layer " + bi) } : {};
newB := [];
_xFor(0, expectedLen - 1, (bi2) => { newB = newB ++ [0] });
fixedB = fixedB ++ [newB];
};
});
_biases = fixedB;
} : {};

layerCount > 1 ? {
_xFor(0, layerCount - 2, (i) => {
debugMode == 1 ? { console.print("(DEBUG) Processing layer " + i) } : {};
newLayer := [];
j := i + 1;
targetSize := _layerSizes(j);
sourceSize := _layerSizes(i);
debugMode == 1 ? { console.print("(DEBUG) sourceSize=" + sourceSize + ", targetSize=" + targetSize) } : {};
(targetSize > 0 && sourceSize > 0) ? {
_xFor(0, targetSize - 1, (k) => {
neuron := 0;
_xFor(0, sourceSize - 1, (l) => {
weightIndex := k * sourceSize + l;
debugMode == 1 ? { console.print("(DEBUG) Accessing: layer=" + i +
", neuronIndex=" + l +
", weightIndex=" + weightIndex +
", netLayerLen=" + string.length(_network(i)) +
", weightsLen=" + string.length(_weights(i))) } : {};
(i >= 0 && i < string.length(_network)) &&
(l >= 0 && l < string.length(_network(i))) &&
(i >= 0 && i < string.length(_weights)) &&
(weightIndex >= 0 && weightIndex < string.length(_weights(i))) ? {
neuron = neuron + (_network(i)(l) * _weights(i)(weightIndex));
} : {
debugMode == 1 ? { console.print("(WARN) Skipped invalid index at layer " + i +
", neuron " + l +
", weightIndex " + weightIndex) } : {};
};
});
debugMode == 1 ? { console.print("(DEBUG) Adding bias for neuron " + k) } : {};
(i >= 0 && i < string.length(_biases)) &&
(k >= 0 && k < string.length(_biases(i))) ? {
neuron = neuron + _biases(i)(k);
} : {
debugMode == 1 ? { console.print("(WARN) Skipped bias index " + k + " at layer " + i) } : {};
};
newLayer = newLayer ++ [neuron];
});
_network = _xSetArr(_network, j, newLayer);
} : {
debugMode == 1 ? { console.print("(WARN) Invalid layer sizes at index " + i) } : {};
};
});
} : {
debugMode == 1 ? { console.print("(WARN) Not enough layers to perform forward pass") } : {};
};

_network;
};

Nice work. I completed all levels.
(2) suggestions:
1. Remove markup from description on web page. Description on web page is hard to read because markup tags show as text.
2. Give feedback for each dot in the higher levels that the dot is in the correct position.

I suspect they keep interacting because the system is over-constrained since only two axles are needed. Delete any one of the three axles. Select all three polygons (or just the outer two polygons) and set to No self collision.

Note: There are no collisions in the original scene. This can be verified by putting colorHSVA = [rand.uniform01*300,1,1,1] in the onCollide event for each arm. Congratulations on finding a glitch.

19.75M after cutting safety chord and disabling auto zoom.
3.92M with no modification.

Thanks.

In laser:
onLaserHit = (e)=>{e.geom.size = e.geom.size * [1.001,1.0]}

Thanks. Feel free to use the design or concept in your scene.

Thanks.

The brakes on the arms are making micro adjustments. Replace the brakes with fixates and the mechanism will stop moving.