AI

Before summer break, I started working on the AI. I'd been thinking to present the various options in the order of importanct, then scroll through them with the various possible moves until I found something that worked. Here's an example of what that would have looked like for preventing your opponent from kinging to the right:


Click on the image for a closer look!

However, as I continued working, I realized that we had no way of dealing with multiple-jump scenarios. The way we had it set up, the list of possible moves the AI was going to be working with--which it was receiving from the hightlighting--only accounted for one or no jumps. If there was a multi-jump, it would create the highlighting list a second time, meaning that the next best possible jump calculated by the AI might not necessarily be the next jump in the multi-jump series, which is against the rules.

So Alan wrote class Command to enforce the multi-jump rule. However, that meant I was going to have to rewrite the AI. Also, the idea of weighting the possible moves finally made sense to me; for some reason, when we'd discussed in the past, it didn't sink in that the AI would add up the points for each criteria the move qualified for. I'm thinking the point values s are going to look something like this:

King piece: 150
Prevent opponent kinging: 85
Capture opponent king: 80
Move king out of harm's way: 40
Capture opponent pawn: 20
Move pawn out of harm's way: 10
Set up for a jump next turn: 5
Move with no consequences: 1
Put pawn in danger: -5
Put king in danger: -10

Each possible move will be assigned a point value based on how many of these criteria it meets. Then each move's point value will be compared, and the move with the highest point value will be the one selected.


--jess

Big Changes

A few weeks ago we decided to give up trying to learn Flash--it was taking up too much time better spent actually getting something done--and switched to C++ with the OpenGL library. We're thinking this should go a lot smoother, as we both are pretty comfortable with C++, and we were just using OpenGL last semester.

Alan, reinvigorated by the switch, immediately threw together the UI. I think it looks pretty good.


Click on the image for a closer look!

Alan tells me the highlighting and legal move checking are working, including jumps. The states aren't done yet, though. Alan is motivated and getting things done!

Meanwhile, I am plugging away at the AI component. Now that Alan's got a significant bit of coding done, that will help me write something that actually, you know, makes sense.


--jess

Catching Up

Note: All images are thumb-nails; please click for higher resolutions.

We procrastinated a bit getting this blog up and running. Here's what's been going on for the last few weeks:

Week of May 16

At this point we weren't sure if we wanted to do a board game or a card game. We knew that if it was a board game, we were going to develop an AI opponent; if we went with a card game, we were likely only going to facilitate two human players. We were leaning heavily toward Flash to execute our plans, but we were also giving the C++ OpenGL library some consideration.

Week of May 21

This week we decided definitively that we wanted to create a checkers game, and we wanted to do it with Flash. We defined our goal as to have both single- and mutli-player options. We scheduled ourselves to start getting acquainted with ActionScript.

Week of May 30

I went out and purchased Flash MX 2004 Game Design, which has chapters on multiplayer games and chess, so that should be a good resource. We created a class diagram and flowchart (pictured below) as a starting point, so that when the time comes, it will be easier for us to divvy up coding tasks and to in general give us a better feel for what it is we need to do. We decided to do a client-to-client interface as opposed to web-based.





Week of June 4 -- current!

Upon further inspection, it seems like ElectorServer3 might make a web-based interface easier than we thought! This week we will be deciding once and for all if the two player interface is going to be client-to-client or web-based. The book makes it sound like ElectroServer is a snap to use, so I've got my fingers-crossed that it's as straight-forward as they claim. I'll be focusing my energies on that this week, while I think Alan will be looking into that with a little less depth but also focusing on the structure of Command and getLegalMoves. I also got a good bit of work done on the UI, we just need to figure out how to manipulate it with ActionScript.






--jess

Introduction

Alan and I have decided to create single- or multi-player checkers using Adobe Flash. Flash ActionScript is a language that we are both minimally familiar with at the start of this project, but we recognize the usefulness of the language--particularly when on the job hunt!--and think it would be fun to learn; additionally, it seems to us that the UI will be easier to handle with Flash than with the other graphics tool we are familiar with, which is the OpenGL library in C++.

Our goal for this project is to having a working game of checkers that can be played with a friend on two different computers, or that can be played against a reasonably challenging AI opponent. Bonus if it looks nice.


--jess