Algodoo

I used all of my tic-tac-toe game strategies to try to beat it, and the best I was able to achieve each time was a draw. Good job s_noonan!

Thanks. It's the best and worst game since it can't be beat.

That won't stop people from trying!

Just a picky little thing that I noticed for those of us who are "perfectionists".... The X and O text characters are not centered in each square.

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.

Q: Feel free to make a better display while using my code.

A: Thanks for the offer but I'll pass because I usually avoid using "OPC" (other people's code) as much as possible for obvious reasons. I struggled with the decision whether or not to mention anything about the off-center text because you did such a great job on the scene overall and I knew that the design and coding tasks were not trivial. Most people playing the game would probably not notice that the text was slightly off-center because it does not affect the game functioning at all.

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.

Thanks for the hint about using Copilot to restructure code. I'll have to try using it some time.

Concerning coding ability, I learned Assembly language coding before I learned any high level languages because I had to learn it for my job back in the early 1980's. I became very familiar with the Intel 8085A processor and I don't mind bragging that I was pretty good at it (other engineers have told me that!). I later learned C and C++ (and a few others) only as a hobby, and so my programming skills with those languages have been a little sloppy (and convoluted!).


BTW... The X and O look a lot better now.

BTW2... I was thinking that maybe using textures instead of text characters might work well for a tic tac toe game.

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.

Thyme code used to make Algodoo scenes does not need to be maintainable by anyone else besides the original coder. Therefore it doesn't need to be "tight" other than for the pride of the original coder. I'm sure you know that in the professional world maintainable software is an absolute must because a particular software engineer may not be working for the company down the road while the company's product life is still active. So, other engineers would need to be able to quickly learn how the s/w works in order to maintain it. At one particular company I worked at, the s/w department manager insisted that we programmers engaged in periodic code reviews of the source code for the new products we were working on. The code reviews were actually very helpful not only to make certain that the s/w was maintainable, but also as a learning tool.

I concur about user Little's coding abilities. She does incredibly well for being a recent high school graduate! The young people now have much better tools and many more resources than you and I had during the same time period for us.

I cannot end our discussion of s/w coding practices without mentioning the most talented (in my opinion) s/w designer and coder here on Algobox: Kilinich. I don't know why he is no longer active but, as you know, many of his scenes that make use of Thyme code are amazing. I have learned many useful things while studying his code. I can only hope that he will decide to return here and become active again.

I feel the same way about everything you said above.

Wow! Thanks!