Play Home Contribute GitHub Join Us Discourse Staff Members GitHub Contribution Guides Team

UI Idea: Creating a tab system for code prototypes

#1

Imagine if you would, a head-to-head multiplayer battle in CodeCombat. The sides compete in a Starcraft-esque battle, each writing the code that determines the behaviour of their respective units. As far as I know, such a concept is more-or-less on the books for CodeCombat’s future.

However, creating such a system using the current UI would present a problem. As you and your opponent(s) write your respective code, you’ll obviously be wanting to test it. But if you just click the Cast button and your opponent’s code is run in its current state, chances are they’ll be halfway through typing a series of commands at the time, and your opponent’s code will return a syntax error or just be completely ineffectual.

I hence propose a system of multiple code ‘areas’. Each player could have a working area, where they can alter and improve their code. However, at the same time, they could have a functional, past copy of their code stored in an ‘active slot’, and it is this code that will be used when an opponent casts a spell to test their work. Having multiple ‘active slots’ could furthermore be useful for storing backups or running side-tests without having to comment out large blocks of code- It would be essentially analogous to keeping a bunch of backups in text docs.

I personally think a tab system (perhaps with each tab being an array entry?) that works in conjunction with the current drop-down system would be effective. It would be quite straightforward to have an option to set which tab as being your ‘active competitive slot’ at any one time. What do you guys think?

#2

I like the idea, but does it solve the problem you pointed out?

your opponent’s code will return a syntax error or just be completely ineffectual.

The code in your opponents “active slot” could just as easily have a syntax error couldn’t it?

#3

CodeCombat currently remembers the results of current and last-good spells, so it would play your good spell against their last-good spell even if they had a problem in their active slot.

I really like this idea and am brainstorming how the UI could fit in really well.

#4

Is there currently a way to test or preview the existing multiplayer functionality? I only see two branches (master/production) but would love to give the current iteration a spin if it’s at all playable.

#5

Co-op multiplayer should be working now from any level. There’s a little Multiplayer button at the top, which should allow you turn multiplayer on and send your multiplayer URL to anyone.

The competitive multiplayer would have to have a level created with opposing Programmable teams and a way to assign players to teams. Will be working on that soon.

#6

time is an important part of competitive multiplayer. And also the level design needs to be adapted to suit multiplayer. Then again, I think the status quo of the game isn’t missing much for a first version of 1on1 battle.
You could imagine a board split in two by a barrier with “creeps” to test your algorithms on after a countdown phase 1; then in phase 2 the barrier would fall and the sides could compete. both teams can together skip the countdowns by hitting “ready” early, but the need for a time limit on tinkering is obvious.

#7

After thinking about it extensively, we decided that although synchronous PVP will be great, it presents a replayability challenge until we either have a ton of arena levels or a good way to randomize them. So we’ve actually started building, for a first draft, an asynchronous competitive multiplayer style, where you can code on your solution for a particular level as long as you like and then pit it against foes in automated rankings, watch the results of the battles, tweak it, see it compete some more, etc. The first level will be kind of a StarCraft / DotA thing. Should be ready for early Adventurer testing pretty soon.