Mechanic #117 - Programming Contest|
Program small problems, let the computer judge your success.
This will be the last quickie entry for a while.
I was looking for a way to incorporate programming into gaming. Traditionally, the only time you find programming in video games is when you are programming little AI bots to fight each other. Core Wars, RoboWar, Carnage Heart, Bolo, Omega, Robocode - heck, Final Fantasy XII to some extent. Occasionally, you'll find "educational" games which involve programming a series of instructions to solve problems. Stuff like LOGO (not really a game, but back in the day, every child started programming with that turtle), RoboRally (boardgame), Rocky's Boots, Robot Odyssey, or Mind Rover.
There's nothing wrong with those games. In fact, many of those games are considered classics. It's just that the use of programming in games is very limited. After all, there's a point where you are no longer playing a game and you are instead modding it. Certainly, I've had plenty of fun writing mutators for Unreal Tournament, or creating exploding trashcans in Duke Nukem 3D. But how do you make programming into the goal of the game itself. I actually have a solution to that, which I'll share in the next entry, but before I do that, I want to point out something very obvious.
Programming Was Already Made Into a Game|
Programming already is a game. In high school and college, I was on competitive programming teams. Basically, we'd be given a series of small programming questions. Stuff like computing bowling scores or finding words in a word search grid. Each one of these problems would be a small word problem describing what you were expected to do, along with sample input and output. We'd write the programs, in whatever language we could (I preferred Perl, due to easy string manipulation) and then email it to a judge sitting at another computer. We'd have three hours to finish these questions, though the winner would be the teams that finished them the fasted.
As it turns out, there's an archive of some of these contest problems. It's a lot of fun. Try some.
The way the judges would grade a contest entry was simply to have an expected output. Since every program had the output expressly identified, the same input should always produce the same output. The judges would just run a diff between the program's output and the premade answer output they already had. If the files were identical, the problem was solved. It should be noted that the judges kept their inputs a secret, so the programmer could not fake an answer by just printing the answer with no actual coding.
Making It Into a Video Game|
Something like this could be easily turned into a packaged game. The judging is already automated to a large degree. Running a similar batch process for checking the output could be used without the use of a person to be a judge. To make sure the code is legit, the application could check the code directly to make sure it isn't just print statements. This could be done by putting checks into the interpreter itself.
So, basically, the entire game is just a sort of IDE for programming in a specific language. The difference is, the input files will be provided with you, and running the program will result in a success or failure based on unknown input.
I probably wouldn't put the programming problems in the context of a programming contest. It's fun to be competitive, and the time limit does add a bit of a thrill, but when you judge someone based on the time they took, there's absolutely no incentive for them to not just copy a program from the internet. Or at the very least, do the program on their own time and then past that in. Even if you remove the ability to copy and paste, doing the same problem twice is considerably faster. Also, if you run out of time the first time you attempt it, do you lose? Do you have to do it again? Because these problems can take between 10 to 45 minutes to complete, and nobody wants to lose that because a buzzer went off.
A better approach would just be to make the questions into a pass/fail, where the player can continue to poke at a question until they succeed. Some sort of hint system can be made where the player can see the hidden inputs and his output with the incorrect parts of his output highlighted red.
Finally, a player would probably only do one or two problems at a time. Few people are going to do a full three hour, seven question contest. Free time and entertainment are rarely built that way. So you need a system of tracking progress between sessions, allowing the player to go back and continue half finished projects and what not.
I think you could theme it like the Super Mario Bros 3 map, with each node being a specific programming problem. These maps could be broken into themed "worlds" based on programming constructs, like Stack City or Linked List Park or String Manipulation Hellhole. Non-essential nodes on the map could be programmers who could give snippets and hints that could be useful in upcoming problems. Perhaps the "boss" of each world could be a full three hour programming contest, with three randomly selected questions. If your opponent beats your time, you need to challenge him again, but with a fresh set of questions. The time limit should be very liberal though, and the player should be able to revisit his failed attempts to complete them if he wants.
Yeah, this isn't the most amazing, set the world on fire, sort of idea, but I think programming can be a game. In many ways, it's just a more involved puzzle. It's more complicated to checks whether the player is correct or not, but with standardized inputs and outputs, it helps somewhat and puts a little bit of the burden on the player to format his work appropriately. Truth be told, programming contests are a lot of fun and if you could "game-ize" the experience somewhat, you'd have a fun game that would make you a better programmer. You can even call it educational, if you want. I'd still play it.