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.

Random Color

I have just finished another practice problem  - a window that changes its color when clicked. What is worth noting about this task, is when I tried one way of doing it and it didn't quite work, I simply did it in a slightly different way and it all worked very nicely. It shows the flexibility with which Windows GDI works and the amount of solutions I have to/can choose from.

UPDATE:

I have combined this with another practice problem to create functions that would display regular penta- and hexagons. The "regularity" is debatable, but I am not sure how to make it better - I've run through my math again and again and it is right. They seem to be regular but stretched - anyway, here are the results. they are put at a random point and with random color.



I have also clipped the window to a circle shape - although it doesn't really look like a regular window (no title bar, frame, x-button, weird shape) it's still in fact a window in its full meaning. Quite an interesting thing, which is possible and correct to do, yet it is not used much, if not at all by programmer - we don't see windows of shapes other than rectangles.
Tomorrow i will start the design of checkers. I will use M$ OneNote. This is quite unprobable, however if I feel like it will be useful I will download a trial of M$ Visio.

Chapter 4 Update

I have now completely finished reading through chapter four and therefore the entire tutorial. Of course it doesn't mean it was the last time i looked at it - on the contrary. It is going to remain the main source of my project. The goal of reading through it was not to learn everything right away - that would be almost impossible. Instead, it was more like a look around, an indexing of the possibilities I have. This way I can plan on how I will make the game, design it and when I'll be actually writing it, I will be heavily relaying on the templates, tables, examples and the exact definitions that I've met throughout the tutorial.

I have also completed one of the practice problems - since it was a long and final chapter, there's quite a few of them and they're more advanced. I may choose to skip some of them, if they are not directly relevant to my game.

The problem I have finished now was a modification of a given code. I was given a program that allowed one to draw lines with the mouse and I added to it color and line type change. I had the basic program ready, so I could concentrate on the new material covered only in this chapter. It took me quite a while to finish this program, but most of it was a one time research that I would have done sooner or later because I will be needing it for my game.