Dan's crazy ideas #1 - Collaborative contest

Introduction

I have a set of CRAZY ideas that I’ve been mulling for a while now. These crazy ideas are based on the observation that there are elements of the “professional programmer” experience that are not represented in the CodinGame of today. I will attempt to briefly explain the missing element, why I think it’s important, and my recommendation for how to incorporate it.

Disclaimer: These ideas really are out there, so I’m not necessarily expecting any action based on this. Just trying to stir the creative juices a bit.

Concept

The first lacking element that I want to address is collaboration, and I want to specifically hone in on collaboration around creation and integration of software components. This includes architecture, role / responsibility discussions, API definitions, etc.

In any moderately sized software undertaking, you need to decide what components will be present in the architecture, what those components will do, how components will be integrated, and who will implement what. In CG, all contests and puzzles are monolithic / black box. The inputs and outputs are pre-defined.

Proposal

I propose a contest that is of sufficient complexity that it would strongly encourage collaboration. I know, this would be difficult to design, but I think the payoff would be worth it.

Here is how I envision this. The contest would still have a fixed set of inputs and outputs. However, each user would register to code one of N (3-4 ??) tiers of the solution. At first, the inputs and outputs of each tier of the solution would be pre-defined, and there would be a default implementation of each tier so that a user could test out their code in a complete solution.

At this point, the user can submit their code to what I am calling a “staging ground” where it will do battle against others’ submissions for the same tier. All rankings in the staging ground are based on being paired with default components for the other tiers.

I next imagine that combatants can recruit from the staging grounds to form ad-hoc teams. Once teams are formed, they would have the flexibility to rework the inter-tier APIs to their hearts’ content. Do they want to use JSON or XML instead of the plain text approach? That’s fine. They could even come up with some kind of API negotiation scheme so that their components could talk well to each other, but could fall back to the default API if they want to switch up the teams.

Once a team is formed, they can agree to collectively submit their N-tier code into the arena where the various team-based solutions do battle.

I know that there are many logistical questions around implementation of such a beast. It’s half-baked at best. Thoughts?

  • danBhentschel
8 Likes

Cooperation and communication are two related but different things.

Let’s imagine a multiplayer challenge based on the well known Left 4 Dead game (4 bots, an exit to find and reach and a lot of zombies you can’t handle alone). Making your bot move in circles following some untold convention to notify your team about approaching zombies is communication. Helping a teammate assaulted by half a dozen half deads, healing a wounded partner or leaving a nice spot to a sniper is cooperation. You don’t necessarily need communication to achieve cooperation (but you probably do for long term planning however).

Also note that cooperative challenge are best when players truely need the help of others to reach their goal (like in older MMORPG, not so much in newer, casual ones, which make solo play always possible), but it doesn’t imply that they all can win. Temporary alliances are so much enjoyable than longterm relationships. Having a cooperative challenge is possible, potentially fun, but also probably hard to rank properly. A communication challenge is a lot harder to come by and would probably ends in some kind of war of the standards which is not fun at all.

One last thing: wouldn’t be cool to have some kind of cooperative league system with a single arena where gold players play alone, silver players by two and bronze saints players by four whereas wood players take on the roles of ghosts/zombies/trees? When a side win, the XP would be shared by all members of the team.

1 Like

That’s not exactly the type of thing that I was thinking of. In your example, all components receive the same, or similar inputs, produce the same, or similar outputs, and can work together or not as they see fit. I was thinking of a project where different components get different inputs, produce different outputs, and must work together or nothing gets accomplished. Let me try to fabricate an example to illustrate.

Let’s consider a tank combat game with three components:

  1. The navigation component has access to a map, GPS coordinates, and a list of goal locations. It is in charge of directing the overall strategy of the tank.
  2. The mobility component can detect terrain and obstacles, and controls the speed of the tank treads.
  3. The targeting component can detect threats, move the turret, and fire.

In order to do well, these components must talk to each other in some fashion or other. At first glance, it may seem as if each component is simple enough that you can program them all yourself, but if the map is complex then a good navigation component could be a significant undertaking. Same thing for mobility if the type of terrain you need to navigate is complex enough. And if the targeting component has to deal with elevation, wind speed, enemy movement, obstacles, etc. then that too could require a decent amount of effort.

You see where I’m going with this? It’s not optional cooperation. It’s forced collaboration.

  • danBhentschel

I’m afraid that I’ve followed my train of thoughts a bit too far from your initial idea. In particular, I’ve overlooked the fact that your cooperation is more about players working together outside the arena than bots acting together inside it.

That’s another kind of cooperation that the one I was spontaneously envisioning and I don’t know how it can be done harmoniously. Notably, the “recruiting” phase seems difficult to manage. I hope we won’t end paying the best coders using our earned XP :wink: In fact, it also quite possible that some players will simply use multiple accounts and handle all the work by themselves.

On the other hand, there is so many ways to imagine this. As an example, we can have a more opensource-like kind of module repository where anyone can pick the parts it want for the 2nd stage bot.

I’m a huge fan of crazy ideas! :slight_smile: I’d however prefer for codingame not to go into the “professional programming” / enterprise direction, I like that it’s aiming for quite the opposite right now.

I do think that forcing some or a lot of collaboration could be really interesting though, I just don’t feel the same way about the premise that CG needs to include elements of the “professional programmer” experience that are not represented today. Obviously all very personal :slight_smile:

I can see a very big problem in this idea.

Let imagine Codingame create a very complex contest. Forcing the average coders to works together to perform in it. But while average coders are forced to works in group, top coders can still code alone. I let you imagine how hard the average coders will feel crushed. You work in a group of 5 (or more) and you are still beated by a lonely coder.

Let imagine Codingame create a contest so complex that even the top coders are forced to work in group. The average coders will just be clueless. And they can’t really join the team of the top coders because “lol it’s a contest i want the prize, i don’t want any noob in my team”.

1 Like