[Adam13531]

There are three levels of scripting you can do:

* None - just ignore the scripting and let the default AI take care of everything. There are some items that can't be used this way, e.g. Teleport and EMP, because the default AI wouldn't know how you'd want to use them. * Blockly - use the block-based scripting to control your bots. This is what I suggest as the step for newcomers who still want to customize their bots' behavior. * BotLandScript - this is a subset of JavaScript that I only recommend for people who already know how to code.

Blockly and BotLandScript should have feature parity (not that they do right now, but the differences are somewhat minor given the target audiences for each), so you don't necessarily have to code (or even know how to code) to play Bot Land. Then again, scripting will certainly give you an advantage.

[nexuist]

For the record, the "figure it out" block is what kept me in the game instead of trying it once and moving on. A lot of these strategy coding games like to throw you in the fray and start you off with a blank slate.

I know how to code, but I don't know how to win a game of BotLand. Having the ability to just start a match right away is killer.

I played a dozen or so matches so far. Really excited to see how development progresses. Also surprised at how well the mobile app runs considering it's a web wrapper (but it doesn't feel like most web wrappers do!)

Best of luck, and thanks for the game!

[mch82]

Blockly (or similar methods like Blueprints in Unreal & Simulink) is how most people will program in the future.

You’re going to get negativity from “developers” about using Blockly, but unless they’re your target audience don’t let it get to you.

Lots of EE’s use graphical tools to layout the circuit boards anyway... so text is really just an unnecessary abstraction over schematics & you’re bringing programming back to its roots :-)

[Jach]

Want to make a timeframe for that prediction? I'd like to record it... While I agree to ignore the criticisms from people who won't even play the game (which includes me, so I haven't commented on it, even though I've played a number of variants on this during high school) I think your prediction here is a stretch. First a quote to consider:

"Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks."

-- Bill Garrett

Now a point about EEs/CEs... it's way nicer to write:

    module dff (
        q,
        d,
        clk
    );

    output q;
    reg q;
    input d;
    input clk;

    always @(posedge clk) begin:
        q <= d;
    end

    endmodule

than to actually lay out and route a flip flop. Of course you're going to simulate such modules, and use graphical tools (the least of which is just to picture signal waveforms), this isn't to say graphical tools are going away or are pointless, but I would readily take the other side on a bet about your prediction since I don't think programming will even in 100 years be something people think of as manipulating graphical elements rather than typing/chording expressions satisfying some grammar/syntax we'd call a language.