9:00 am
A "code war" is a competition between teams to see who can write the best code. We are having one today where everyone in development (it was voluntary but everyone signed up) is competing to see who can write the best code. They are give the problem at 9:00am (ie now) and have until 5:00pm to turn in their code (all times mountain time). I created the problem and am administering the contest.
The Problem
The first issue I faced was what should the problem be. All of the initial problems I thought of would favor different groups here at Windward because it would match the expertise of that group. It's also critical to come up with a problem that does not have solutions all over the internet.
Well, after a couple of days I came up with it – writing an A.I. component for the board game Broadside. No one at work has any experience writing a computer A.I. so we have a level playing field. And this is a problem that cannot be brute-forced, working out even three turns for six teams to look at every combination will take too long. So it will require coming up with a clever way to determine what to do on each turn. I think this is more a contest of critical thinking than coding ability – and I like that.
I created a computer version of the game (yes horrible graphics but it gets the job done). It calls each player one at a time for their turn, and then the next player, and so on. So each team will write their code (I have a very poor AI implementation already for each to work from) and then all will give me their code and we'll run the game.
10:00 am
It took about 1/2 hour to go over the game with everyone and then another 1/2 hour as they got set up and hit me with a bunch of individual questions. I could tell from the reactions that it is definitely outside everyone's knowledge set. So I think it is a really good problem.
And it has never been quieter here - every door shut, every team totally focused on the problem with the world shut out. When productivity really matters, developers do know how to work :)
I came up with this idea because I played this game as a kid and had lots of fun doing so. It was a popular game so I figured the rules work well. But at the same time it's a very simple game so the logic of an A.I. player does not get wrapped up in complex maps, weird rules, etc.
12:30
We had pizza delivered and I've never seen people eat so fast. Lunch in under 5 minutes. Some of the teams grabbed their pizza and took it back to their offices - clearly still working through the problem in their mind as they grabbed the food.
One team said they have an awesome solution - but it apparently needs an infinite number of clock cycles. Two teams asked if they could have the weekend. And everyone is worried about what they can get done by 5:00. So I think it is a good problem for this kind of contest.
The Code
The program is downloadable below. It's broken up so that the player A.I. code does not have access to the internal structures. (The teams are on the honor system to not use reflection to hack the game.) So we have the game engine & UI project, the common API project, and a project for each player.
The art and rendering are atrocious. But for the purposes of the contest it is fine and doing this well would have added a lot of time and effort. I haven't touched DirectX in 15+ years so I would have had to learn it all over. And decent art would have cost a couple of hundred (I have zero artistic ability).
I also made one rookie mistake in the API. You can access the map either via a Point(X,Y) are as an array [Y][X]. Even with it being 15 years since I've written game code - this is horribly dumb. For anyone just starting in game programming keep it X,Y everywhere.
I also create a copy of all objects passed to a player on each turn so that they are getting a distinct object and it does not have any internal information. I think in a commercial game a better approach would be to keep the per player structures and update them. That would be a lot faster and have less memory fragmentation. But again, this works and I wrote this program in ~ 6 hours.
The A.I. I have in here is awful - it goes for any combat, even if it is one that the ship will lose. That gave me a fast way to test combat resolution and the end of the game logic.
The combat engine I think I did pretty good on. It walks each step of a ships move to determine if there is any combat and if so, assesses the results and sends the results as events to the players. Very straightforward and not that complex. I think it also does a good job of illustrating how to use LINQ to make code a lot simpler and more straightforward.
For the timer I used a Forms.Timer. It is not as accurate as alternatives and it has more overhead, but I am writing to the windows using Forms calls on each tick and so I need to be in the context of the UI thread. This is the most efficient way to get events in this situation. It also has a nice benefit that you do not have to handle re-entrancy. You may get another tick immediately upon returning from the event method - but you will not get an event in the middle of processing an event.
There is a tick for each sprite animation frame and then every N of those ticks, there is a move tick. The move tick will move a ship one map square (and assess any battery damage). If it is the final square, it assess ship fire and then the next move tick it gets the next player turn.
Calling the player code I wanted to make sure that a player taking too long to return or throwing a exception did not end the game. The exception part is easy, wrap each call in a try/catch. For the too long issue I make each call using an in-line Task object and then calling Task.Wait(1000). I really like how this works. Because it's in-line I can use local variables which keeps the code very simple. And if after a second they haven't provided a turn, the task is ended and I give them a random turn.
I don't know how useful this will be for others. I think the use of Task and LINQ is a good example. And the timer approach is exactly what you want if you are drawing to Forms objects. You are welcome to use the code in any way you wish.
5:41
And we have a winner. The criteria was you had to win twice. And the games went En-jay's team, Craig's team, and then En-jay's team again. So En-jay's team is the winner - congrats.
Everyone had a really good time. Most of the company watched the final play (the free beer didn't hurt) and there was lots of cheering and commentary as the game played. And the shot clock was really important. Without that each team would have stayed in their base waiting for others to fight it out.
We'll continue to do this. It's an incredible morale boost. Highly recommended.
Full source code including player AI's at: Download Broadside
Blog by Tomas about his team's effort - Tomas' Perspective, or What the F*ck was the Yellow Guy Thinking?
Comments