In Spring 2013, myself and a fellow student at SUNY Potsdam decided that we would
host a text editor tournament where people would represent their favorite text/code
editor to see which is the best of them all. Notable competing editors included Vim and
GEdit. To make it work, we needed to write software that would allow each individual
participant to connect to a central server, and receive and submit different
tournament challenges. We got to work and created a server-client system that was able
to administer the tournament, and distribute files, check submissions, and time each
active participant, and then display the results in real-time on a projector screen
using a web-based GUI.
This is an automated demo of the web-based GUI (scripted):
In this video, the values sent to the GUI were automated by a script running on the
server. For the actual tournament, the display server forwarded real-time updates
to the GUI as the tournament was going on.
Source code for this project is available on GitHub!
The tournament was hosted on Friday, May 3, 2013, as a part of the last meeting
of the academic year of the ACM student chapter at SUNY Potsdam. We had about eight
participants in total, with several others observing. It was a lot of fun!
Click on an image to enlarge.
The challenges of this tournament were designed to check how quickly an editor could
manipulate various text files, usually filled up with code. For example, a very simple
challenge might be to fix up bad indentation in a Java file. A powerful editor may
offer tools to do this quickly and/or automatically, and such editor would likely win
that challenge. The idea was to see which editors are the best to work with on different
code editing tasks.
Challenges were packaged as a directory, and included a simple description file, the
bad (unedited) copies of the files that needed fixing, and solutions, which were the
files as they should be when fixed. Solution files ended with ".sol". When a challenge
was loaded, all files in the directory were automatically sent to the server.
The ".sol" files were not given to participants, but were used by the server to check
Once each participant sat down to their computer, they connected to the main server,
and awaited further instructions. The tournament manager (admin) also connected to the
server via a special manager client. When the manager decided it was time, he/she loaded
up a challenge, and sent it to the server. Each participant then received the challenge
description and decided whether to accept or reject it. The manager could then start
the challenge, at which point each participant who accepted the challenge would receive all
of the necessary challenge files (automatically downloaded into their "battlefield"
directory). Each participant modified the file(s) with their editor of choice, and once
finished, uploaded them for checking (simply by hitting ENTER on their command line).
The server would either accept the answer, or reply with a simple diff file to show the
mistakes. If a participant was unable to fix the file(s), they could forfeit. The server kept
track of all of the submission times, and once everyone was finished (or forfeit), everybody
would see their editor's best time and overall rank on the GUI score screen.
The main server was responsible for keeping track of every active
tournament participant, and distributing challenge information and files to
each of them. When a participant submitted a potential answer, the server
checked it for accuracy, and if correct, noted the submission time. The server
also sent real-time event updates to the display server.
The manager client sent challenges (that is, all relevant files and the
description) to the server, and then initialized them. The manager received
feedback on how many participants accepted, and could choose to start or cancel the
challenge. If a challenge was started, the manager would wait for it to be
over, and then start up another challenge. The server handled all interactions
with the participants, including sending them the unedited challenge files.
The participant client was for everyone who wanted to participate in the
tournament. This client connected to the main server (providing the user's name and
editor of choice), and waited for the manager to initiate challenges. Once a challenge
was initiated, each participant had to choose to accept or reject it. If they accepted,
the challenge files would be downloaded automatically once the challenge started. The
participant client then waited for the user to hit ENTER to submit their fixed files,
or type "forfeit" to give up. The participant software interacted only with the main
The display system was split into two pieces. The first piece was a display
server, which simply translated raw text sent by the main server into bytes transmitted
to the web page via the WebSocket protocol.
were drawn using the HTML5 Canvas element. We enabled it to go fullscreen, and
so it could be projected onto a large projector screen. The audio was played using
HTML5 Audio. The display also featured text-to-speech, which was acquired as needed
from the Google Translate online text-to-speech engine. The text-to-speech voice announced
real-time updates regarding the current challenge, as well as the occasional friendly
insult if a participant gave up, or if they were taking too long.
The server, manager client, and participant client were all written in Python, as was
the display server (which merely forwarded our custom text protocol data to the WebSocket
We created the software over the span of about three and a half weeks, mostly during some
spare time over weekends. It was an interesting exercise in learning more about larger-scale
network programming, getting some practice with Python, and learning how to implement a WebSocket
server. Much of the web GUI using the HTML5 Canvas was already easy to implement due to my
experience with Cosmos Fight.