Download

I made it possible to download the game file with a new feature of Google Docs. Click HERE to download the game! [Update - the rules clarification is there now as well].

I was deceived

I was so happy to be done, I actually forgot a bit of the game. However my testers group (including Michal and myself) played the game yesterday and I realized I have not implemented the ending sequence. Whenever I was checking how I'm doing with the program, I would simply check whatever I was working on - e.g. displaying, moving, captures. I never actually got to the last stages where a player wins and that part of the game kinda got lost in my head. Now that I remembered it, I decided to send a MessageBox once the game ends. It makes it very clear that the game has ended.

It was actually an interesting fault - it proved the usefulness of a testing team for one! :D It also shows what is true about the plan - I have been using it heavily in the beginning, but later I depended on my head more and more until I stopped using it. I also stopped putting changes into it, as they just all happened in my head (and here). Finally, once I finished I did not go through it and check that I've done everything, and because I've changed many things, it wouldn't be perfect either. In projects bigger in scale such approach would probably not work since it would be too hard to keep all the info fresh in the mind (as the situation showed, even at this scale wrong-do's happened).

Now the game is officially tested and finished :)

Work officially finished!!!! ... or is it?

I have finished the code!

Even the final changes did cause me some problems, but I managed to overcome them and now the game is completely finished. I've also added a bar on the right which shows whose turn it is. I also added a bonus! When the up arrow is pressed, the color of the white field -> It gets more and more bright, until it reaches perfect white. If it is pressed again it "skips" to complete black and then gets lighter and lighter, circulating as above. This bonus took me about 4 minutes to make and it is an example of how I am going to keep this project "live".

Now that I have finished the whole game, I will not have as much time for programing and will not be able to make such big projects for quite a while. But I will be able to teak this game and play around with it, adding functionality and appearance to it! This is a great way of keeping the learning going even after the project.


Final thoughts:

I am really glad I managed to do this project because it certainly was very challenging! Although I have changed some things from the initial design, some ideas I had to throw out, I am really happy with it and in fact I didn't really expect it to be much more than what it is. This has been a huge leap in my programing skills and I hope to keep up the development (although not as rapid) in the manner described above.

work almost done

i have programmed further today and i was very pleased with the
results. I have added turn system which makes the game almost
complete. I even thought so and i went to another computer to make
sure it will wort everywhere. It worked well there with the only
exception of the wrong note message.

Anyways the code is not yet complete, as I found/remembered commu
thing that needs to be added - the ability to do continuing captures
in one move. When i started implementing that, I've felt the reality
of a thought i had a few days ago; that my and does not have enough
functions. That it has to much code just thrown into it instead of a
neat division into "working units". For what i was doing now, such the
functions did not only structure the code, making it easier to follow
and edit, but also came to be pretty much essential!

Therefore i am right now in the midle of restructuring a part of the
code. Then I'll look up one more concept (overloading functions) which
will be handy here and will be a good practise use. I simply need to
remind myself what the notation in this case is.

The structure of the code is a perfect example of a case job. The
better is done, no matter the amount of effort, the easier the further
work is (just like the design was)

Another step forward

I have just finished implementing the beating rule into to the program. Now when a player has the possibility to capture he is not allowed to make a normal move. I wanted to notify the player of it. I tried writing out text on the window, but it was erased right after the spot only where I could put it.

So I made a windows message box come up. I was reluctant to do it - I think it's a bit too disturbing - but it actually came out alright. Although now that I thought about it, I think there might be a way to make the writing stay for a few seconds if I make the program simply wait. I'll research functions that could help me to do that and I'll see which solution I like more.


UPDATE [16:12]
I managed to do what I wanted with a very simple Sleep() function. Unfortunately the text is quite small and somehow I didn't manage to change that, even though theoretically I should be able to. But never mind that - I placed it in the middle and make the colors visible making it quite noticeable and at the same time not too disturbing.

Today's work

I have written a large, complicated piece of code today. Unfortunatelly, it is only a part of it's... "unit". Therefore, not only it doesn't work yet, I'm also not really able to check weather it works. This makes the work no it harder and more frustrating. That's why my next note will be to set up a way of checking it, even if it's not the final one yet.

What was even more frustrating about all this, was that i all that confusing code I made a small mistake in th begining, very careless. Then, once I finished writing, the whole moving mechanism broke. It took me a long time and a lot of trouble to figure out what was wrong. This problem fixing was not exciting like many before - this was mainly frustrating.

Small changes

I've got to the point where I'm setting up the rules of the game. There are many variations of the game and so I searched for official rules. I've found a standard set HERE. I was thinking I'll do huffing (removing a piece that could beat if the player does a non-capturing move). However even without that my code is getting really large and complicated and I think I will leave that rule out - especially that it does not figure in the official "tournament" rules. Now the player will simply HAVE TO beat.

Back to work again

I have paused the work for Christmas and new year. I was planning to come back to it slightly earlier (about 2-3 days) but it didn't quite work out (which MIGHT have something to do with me receiving a new season of Heroes, but that's just a theory ;)). Anyways, I'm back home now and I'm starting the work again.

I am using different IDEs on the home computer and the computer I was using in Poland, which was virtually the entire time I programmed until now. When I moved the code there were a few errors which were not there on the laptop, but I managed to overcome them (the previous practice was very useful here). Some of the problems I kind of know where they are coming from, but I'm not sure why. But I managed to get rid of all of them and now can keep working on the actual program.

Solved!

I solved it!!! Before asking for help I decided to work on it a bit myself. I slightly changed the system, so that dead pieces instead of being assigned no field, get assigned a special field  for dead pieces. I really still don't see a reason why the previous solution would not work, but since everything is fine now I'm simply going to stop worrying about it :)

Problems solved, come back twice as bad.... :/

I've been working a lot today again. I have added the limit of not being able to go backwards, I added kings (crowned pieces, those can move back and I've allowed them to). I also solved the problem of not being able to beat. I even played a match with my cousin, although the game is NOT finished, so we had to remember the rules ourselves - the program does not have all the functions needed just yet.

Unfortunately, the breaking mechanism somehow broke. I found out EXACTLY which line of code makes it break, but I have NO idea why it does so and how to fix it. The weird part is that I  have not changed this mechanism between it working and it breaking. I have added other things, but this part was not changed. I'll probably have to ask for help with this one, because I really don't know what is wrong with this.

The Pieces are Moving!

A few more hours of work and I arrive at the stage where I can move the pieces. Unfortunately not correctly ;) For some reason white pieces move where i direct them, but when i mark a black one, a white one moves instead. I need to experiment with the code to see what is wrong there and hopefully i will be able to move the pieces the way they are supposed to even today.


UPDATE [15:50]
I found the mistake! What's interesting is that the new bits were (in most part) correct and it wasn't these that caused the problem. Once I went through them over and over and was sure that they are correct, I started looking back and found the mistake in the set up of the board. It was just a wrong list given in one spot that didn't influence anything until this spot.


UPDATE [18:55]
I kept improving the code and right now all the pieces move well - only diagonally by 1.
However some of the things which I have implemented don't work yet - the pieces don't beat yet and I have to see what is wrong there.
Lastly there are some things which I simply didn't put into the game - for example the pieces move backwards as well as forwards at the moment.


I think I am well on at least 30% with the game. The following is a quick list of what I still have to add (not strictly ordered):

• Beating Pieces and further movement restrictions (as above),
• Kings,
• algorithms for the program to make sure the game is run properly (so the program can "see" if there is a piece that can be beat etc.)
• the order of the game - start and finish, checking if ended (won), turn system.

Keep on working

The problem I mentioned at the end of the last post I've already found a solution to - I had to JUST NAME the dependent class before describing the one depending on it.


Yesterday and today I kept working on the code. I realized that I get so much fun from the challange. Every problem I solve leads me to a next one. But only sometimes I feel frustrated - that's when I have no idea what is wrong. But when they are all a series of problems that I keep moving through (that doesn't mean that they're easy!!) then it all really does bring me joy (especially once I solve something particularly difficult ;) ).

Already yesterday I've started setting up the pieces on the board. It made me realize a problem which you might have noticed on the previous blog if you look at it carefully, but it was in fact very easy to overlook. The board I had was 7x7! I've digged through pretty much the entire code that I've wrote by now and finally realized my mistake. C++ in many cases counts from 0, not from 1. It is a rule I've remembered to watch out for, however once I got too mixed up when also using variables that I've subtracted 1 from them ending up with what I did. It can be thought of as if the board was moved up and left by one square so 1 column and 1 row got hidden behind the window border. I've fixed that by now as well as many other obstacles I met these two days and I have the board set up!

Now I will search for a solution to another problem - the pieces flick as if the program kept redrawing the board, than the pieces over it then the board again and so on.




UPDATE - found out the problem, it came from the fact that I am building the program slightly differently than I saw and practiced before. I needed a good description of a Windows message WM_PAINT and I found it easily on MSDN as well as more functions which let me solve the problem.


So now this stage is completely done and I can move on to the interaction stage - adding the implementation of functions that will let me move the pieces. Then algorithms that will serve as rules.

Code work kicked off!

Today I’ve spent 3 hours coding. I’ve come across a BUNCH of different problems, but most of them I was able to solve after sometime. A lot of these problems were simply syntax or ‘layout’ – I would not be sure how to put some stuff together for it to make sense etc. Part of it are also small pieces of information that are not important until one tries to use them. E.g. I had to change a constructor of Field because it had to be empty for me to be able to put it into the array of Board. It is just a requirement of the language because one excludes the other. This problem and many other I had to look up and the C++ dla każdego book was indispensible here, especially that I was working in the car, without internet.

I was heavily using the tutorial to code the window creating code. A lot of it was pretty much copied, with just slight changes, because this part of the code does not differ from program to program much and it is also quite lengthy, so it takes a lot of time to be able to remember and write it all without reference.

Once I’ve finished the making of the window, I created a function which would display the board in it. It was going step by step – I had to implement the Field function; then create an abstract board as an array of Fields; then write the code which would go through the array and display the fields one by one (I could have made this easier and shorter, but this lengthy approach takes off some load from future – I would have to do it sometime anyways). Only once I had that ready and tested I made the colors alternate making it a real checkers board.

This concept is really important for me right now. I can’t make everything right away at the same time. So being able to separate the process into some steps which are than developed is the way to go. It is quite a challenge, because the different parts of the code are inter-related and intertwined which makes it hard to take only a part  without having to drag the rest with it.

For example, I’ve had to create the Field class to be able to create the board. But my main focus of the moment was to create the board not the fields in their full detail, so I only wrote the most important parts of the Field class that allowed it to function. As I was expanding the program I was adding more and more functionality to Field AS I NEEDED IT.

The process I showed last post is only somewhat correct. The basic idea is correct, but all the steps are really blended together and really only the first one was the only one I did by itself. Later all the steps are too much connected for me to keep the rigidity of a step-by-step plan – it is much more dynamic than that.


Right now I am stuck on one quite big problem - I want to create the two classes of Field and Piece which both point to one another. The problem is that the second function in the code can recognize the function that comes before it. However  the one that is first can not point to the one that comes afterwards because at that point the compiler doesn't know that it exists.

In my initial start of the program I started with writing the classes of the object. I thought it would be a natural step to create the building blocks of the program first and then connect them and use them to make the actual game. However I have now realized that this way I can't test things as I write them, because I can only run a program, not a part of it. I decided I need a different approach. I have changed it especially because of not much experience with programming, in terms of not actual amount of code I wrote in the past and the time that has passed since my last bigger programing project. Another thing is that I never used some of the components and functions before.

The actual change was that I will start with the frame of the program - the Windows' protocalls which actaully create the program in Windows' "memory". This way I will be able to run the program at early stages of development to test the components as I add them. Another advantage is that the Windows' functions are mostly the same for all programs, so they are not really the hard part of the coding.

So the coding in terms of time will look somewhat like this (latter parts might change):

1. Windows "frame"
2. Basic graphics (The board)
3. Classes (pieces, fields)
4. Movement graphics
5. Structure of the game
6. Final improvements, fixes, etc.

 This process could be compared to making a jig-saw puzzle. It is the easiest to start with the boarder for two reasons. One, you can work from outside to inside, having everyting much more organized and in relation to each other. Two, the larger components are easier to check against the boarder if its ready.

December update

Unfortunately due to a sickness right after the 3 week long school clousre I've fallen behind with some school work and had to catch up on that, so my PP has been pushed out of the way by some more urgent matters.

Now I  have 1.5 month to finsh the game. I believe I can finish the game in this time, although with quite a big effort. I will use the winter break to its full extent for this. However, even if it so happens that I do not manage to create the full game, it should not hurt my PP, because my goal is to learn from the creation, not to create. I will finish the game anyways, weather it will be within PP or already afterwards.

I figured that when I have a problem with my code, it would be a great help to have someone I can actaully physically come up and talk to - online tutorials and such are good, but when there's a specific problem this kind of help would be much much better. I have contacted an IT teacher, Mr. Vitaly, who has some experience with C++ and making games. He is happy to help me if find any obstacles that I don't know how to tackle.

Code work started

I have just started working on the code of the checkers. I have no idea how long it will take me to write the game, so I am not going to plan any deadlines other than specified by the project. At least for now - later when I will know how much I have done and how long it took me, I shoudl be able to see the time that I need more clearly. I have already modified a few things from the notes I initailly had, some becuase I reallised I need to and some because I found a new, better way of doing it.

Notebook update - ready for Programing

I think I have done enough design work and that its time to get to the programing. Here is what my virtual notebook looks like at the moment. Again, it will change throughout the programing - some features might change, but mostly i'll be adding details that I didn't feel necessary to create just yet.

I can't post the notebook contents here, because of some things saved as images. It would also interfere with the blog's width. So I've put it up as a Google doc, here is the link. It took quite some working around, but its there :D. Oh yeah - there is a bunch of hyper-links there - i use them to ease the navigation around the notebook. They won't work here, so don't try. :)


Just a quick note on the way I have kept my notes. I am the only writer of the program, so I am the only one who needs to understand these notes :). Of course it is a good thing to keep them coherent and make them make sense, but since it is a small project (in terms of programing, not school :)) I could make them a little... spontaneous. Most of the notes will not be understandable to someone without programing/C++ knowledge and much of it won't be understandable to anyone but me. But there they are. I'll probably include them in an appendix to my essay.

Design Update

I am just about 2/3 done with the design preceding the creation. I have set up a few more pages in the oneNote notebook and it is working just fine. When i was thinking of using Visio - it would be for procedure diagrams. However the biggest of such diagrams that I needed was the general program outline which I have created with oneNote(see two posts ago). Perhaps it is not the neatest outline ever, but it suits my needs just fine :).

Once I'll have done enough design to start the creation I will post all my notebook pages here. I am glad to see that the designing process is in fact taking me just about the amount of time that I wanted it to and planned for it, despite the fact that it was a fairly unprecedented thing for me to plan for :).

I have just learned a lesson is object oriented programing (OOP). Not read a textbook chapter on that, no - I have known the concept before. But I have just realized something myself while trying to solve a problem and the fact that I have realized it myself should make that lesson all the more valuable.

C++ fully supports OOP and therefore not using it is usually a mistake and complication of one's task. In OOP the idea is to make the code a virtual representation of the reality as close as possible in order to simplify the code. The main tool of OOP are classes - sets of variables and functions that represent a single object. For example, a car class would have variables such as size, current speed, brand, etc. and methods (class' functions) such as accelerate and break. Code represented in this way is set up much more the way we think than a procedural code and therefore easier to write and edit.

I was planning to have a single class in my game - the piece. It would have a color and the position, an indicator that would say weather it was a king piece and an indicator of weather it was still in game or not. I was not planning to make a class of a player, simply because I was not going to implement a lot of player specific options. The other possible class would be the board. The reason why I did not want it was the fact that then the information would double - the board would know what piece is where and the pieces would know where they are standing. Therefore if a piece was moving I would have to change the piece's variables as well as the boards. However when I was planing out my algorithms I realized it would be very useful to be able to refer to the field instead of search through the pieces to find the one that has the specific coordinates.

I also did not want to have the pieces be variables of the fields' (which is, however perfectly possible) because

a) it was not a good representation of reality - a piece is NOT a part of the field and

b) it would mean that every time piece is moved, it would have to be destroyed at one field and re-created at the other.

I thought about how to solve it for quite a while and then I realized the perfect solution - it was even than my initial plans.  I realized that it is in fact NOT the piece's duty to know its coordinates - it only stands on a field. So the field will be the only class storing the position. So I needed a way of letting the piece "know" where it is and the field to "know" what's on it. I remembered the perfect way to do this - through pointers. Pointers are a basic type of variables, which, instead of a number, stores the address of a different variable. It is in fact much easier than it sounds and all it means is that I can have every field have a "link" through a pointer to the piece which is standing on it. It is in fact the most exact representation of the reality - the physical contact takes the form of a pointer. That last sentence is much more important than it might seem - it points to the moral of the whole problem. OOP is not just a fancy way of manipulating the information - it is in fact a great facilitation and the more accurately it is used the more helpful it is.


PS sorry for the bore but it is a really important point for my reflection - this is the kind of learning experience which I can't get without making and is so valuable. :)

Initial design brainstorming

I have written out the basic structure that the program will follow. Then I went through it picking out some relationships and obvious structures/functions that I will have to implement. You can see those on the right of the above steps.

Those, of course, are only a part of all the classes, variables, functions and algorithms that will make up the game, but they are a good start. I should try and design most of them before starting to write the code yet. As I have now, I should be using OneNote for that. I will create a page in the OneNote notebook for each object/group and connect them with hyper-links for the easiness of use, which is essential since it is something that  I should be using throughout the coding, not just a beginning step.

I will keep updating the pages in the notebook as I think of new things, also during the course of writing the program - it is a help tool, not a strict plan I cant adjust. It is all very flexible and similar to the design cycle from D.T.