Visual programming game: gladiabots, helps you appreciate many core values of programming (and projects in general).

Brief description: define a decision tree (it mostly can be translated in nested If sections with statements) that behaves better than the enemy decision tree.

Link: http://ift.tt/1XCNkwY
wiki: http://ift.tt/2fTtr6Z

Although simpler than many other games (see screeps or spacechem and many more ), the game - especially in multiplayer - push creativity a lot given the relatively limited amount of commands.

In my opinion the game is great to teach the following concepts, especially if one accepts to play in multiplayer:

• persistence. The code very unlikely is good at the first try and needs a lot of refinements over time. Working out bugs, working out design errors and so on.
• small steps. If one is going to make the definitive decision tree at the first try, he is doomed to fail. Instead improving the tree slowly but constantly helps a lot to climb the rankings or to keep the score (since other players improves too).
• technical debt and maintenance cost. Do you have a decision tree that is not quite what you want but it is too big to change? Then you incur in technical debt. Being unable to change the code because too much work to rewrite it from scratch, still paying a lot to maintain it.
• debugging. Your decision tree is failing somewhere? Use the debugger, without it would take way longer to sort out the problem.
• refactoring. Reorganize the decision tree over and over to achieve the same result with easier to maintain code.
• readability. You would like to use the same node of the tree from different places? You can, but after 3 days you would start to look at the decision tree saying "why in the world I did that?"
• organization or naming convention. Having a flat folder for decision trees, you need to come up with a clear naming convention to sort old trees, tests, specialized trees and so on.
• Translating thoughts to code: What do you want to achieve? First it has to be clear to you, then you can translate your idea in nodes.
• basic but nevertheless crucial boolean logic. and between options, or, not, xor, and many other. Sometimes de morgan will come in handy.
• rubber ducking. Do you want to debug why a certain actions is not done? Explain it out loud to yourself while reading the decision tree, find the problem, fix it.
• documentation. Although not yet possible within the decision trees, you need some sort of notes to keep track of what you want to achieve with something.
• Agile. Like small steps but with an objective. "I want that my decision tree achieves this, nothing else at the moment". First reach the subgoals to get nearer to the main goal.
• versioning. Do you keep just one version of your decision tree? And who said that is better than the previous version? What about keeping different version to compare them? How to handle the names given different versions?
• Failure as chance to learn, to improve and ultimately to succeed. Do you not accept failures? You will likely be not much competitive. The ones that gets defeated and learn the most from defeats will climb the rankings fast and be a reference point for the others. No failure, less learning, less learning, lower quality.
• Effective first. The decision tree first has to do what you want, then can do it better than any other decision tree.
• Effective in time. Some players may spend a lot of time to optimize and debugging everything, what do you do if you do not have so much time? Figure out clear ideas and get the most from the games played to improve your decision tree in short time.
• a couple of more concepts that now I'm forgetting because I should care about the cooking dishes.

Submitted December 24, 2016 at 04:51PM by pier4r http://ift.tt/2i6imAp