I hosted the Capture the Flag AI Challenge that had been going on from Mar 20 - April 24, 2017. It was super fun to host and I learned a lot in terms of communication, logic, and practicality. This was one of the few times I was able to hold myself from making changes and making additions to things I’ve created. There, however, were a few changes in the beginning as I was getting the project ready for everyone to use that I believe caused some people to become discouraged from joining for fear that they may have to re-do their entire project due to a change.
Here’s a list of things I wrote down as the competition went through.
Listen to people but listen to yourself and figure out a good end date and stick to it
This is something that I forgot at times during the competition. At first with the suggestion to move the date further. I should not have extended the time for over a month, however, two weeks was unreasonable as well. I think three weeks would have been good enough to keep people’s attention and for people to have enough time to create their entries. Another example is when some members suggested extending the ability of soldiers like adding snipers, etc. Another suggestion was to change the map and implement different elevations and barriers. I didn’t think these suggestions would add that much to the challenge and might just further complicate it for no reason so I decided to listen to myself and not add them. This brings me to my next point,
Don’t add features once you’ve released the competition
This is crucial because if you make changes it is a huge red sign for experienced developers and anyone in their right mind. “Why would I join a competition that makes a bunch of changes? I may end up having to start from scratch at the last day because someone decided they want to have another feature.” You want to avoid having contestants having to ponder that question, this is step one of a successful competition.
Prepare and plan for things such as prizes, criteria, and rules, before hand
During my competition, midway in I was emailing asset developers asking for a voucher to add as a prize to their competition. I was able to convince Apex to donate a voucher code to their Apex Pathfinding asset by leveraging the fact that I had acquired over 800 views on my thread in the first few weeks and had a fair amount of comments. You cannot reasonably expect a developer to hand over a key because you’ll have a competition, they have to have something in it for them, whether it be a half purchase, a good reputation, or the promise of advertising and marketing for them. @LaneFox was kind enough to throw in three of his awesome asset, Cleverous’s Deftly: Top Down Shooter Framework. I think this was able to help gather attention to the competition and gain followers and potential competitors. So to recap, make sure you are able to have some rewards available for people to receive beforehand if you decide to have them apart of the competition.
Criteria and rules should also be planned before you even announce the competition. This is to be assured that people will have a clear idea of what they can and cannot do as well as how the winner will be decided so they can develop around that.
Make things simple, seamless, and easy to understand.
Changes are bound to happen, it’s nearly impossible to release something without any bugs. Something I stressed during this competition is that my changes were as seamless as possible and would not cause anyone to refactor code or make changes. Things should just work. An example of this is when I switched to using the unity navmesh rather than the A* algorithm that I had developed, luckily, as standard I had separated pathfinding into another class and would handle movement of the entity itself with input from the soldier class. So the only thing I had to do to upgrade was to modify the pathfinding class and have it utilize the soldier class’s input and I had navmesh AI set up and anyone could just copy and paste their script into the new version or just pull from the GIT branch.
Document things
Make sure to document things in an organized and clean fashion, especially with larger more complex challenges. This allows people to view how things work in the “backend” and use them to their advantage. I kept everything documented in github’s wiki system and can be seen here, GitHub - 1samuel411/CaptureFlagAIChallenge: Unity AI Challenge for a Capture the Flag scenario. Hosted by Samuel Arminana. I haven’t received too much negative criticism from the documentation really. Only include things that may be relevant in the competition and that is allowed in the rules, for anything not allowed specify it so no one is confused.
Survey
One thing I did not do was survey the community to see if this was actually something people wanted. Had I done so I may have seen that not as many people were keen on the idea or they may have simply been scared off by the complexity? Changes? I’m not sure but I ended up with only 3 entries :x So figure out if what you will be running will be actually interacted with the community.
Thank you for reading, I hope to see more people create these types of things, I would definitely be open to participating. Feel free to contact me privately via my website, http://samuelarminana.com/ I’ll be happy to answer any questions or talk in depth on anything I may have missed.