Thursday 25 April 2013

Programming a copyrighted dice game 1

My most recent missive was about the torment of learning, or at least of not learning when attempting to. It was borne entirely of frustration because I'm trying to learn quite a few things at the minute, and getting stuck on any of them feels like time wasted.

One of the things I'm trying to learn at the moment is c++. It's not the easiest thing to stick at when it's going badly, but is so rewarding (as if I'm honest, is any form of programming) when it's going well. I am quite a sharer though, in that I like to talk about what I'm up to, but with this I find that I only get 5 or 6 words into what I'm trying to say before a glassy look appears in the eyes of whoever I'm talking to.  As a result I thought I'd share it here.

Firstly I haven't started from scratch; I've made some rudimentary flash games before and as a result knew all about the basic programming concepts. So having learnt the syntax specific to c++ I decided to test my knowledge by trying to code a simple game. In this case Yahtzee.

The target is firstly to create a console version of the game. This means that the game will be entirely rendered in text and as a result absolutely dreadful to look at. It will however have all of the functionality of the real game, enabling the user to 'throw' 5 dice, hold those that they would like to keep for the following throw, throw any unheld dice, repeat and then score appropriately. If that goes well, I can then look to install a graphics library and make something that looks a little less 1980's.

So far it's going OK, I've had a lot of success this evening writing some functions to test the users input and throw the dice. I haven't though really made any sort of game out of it, and I'm frankly dreading the scoring bit.

I'm a little bit unsure if I want to keep this as a progress log, or if I should also throw in a tutorial as I go. For now I'll just talk through the class that represents the in game dice, and if (laughs to self) there's any demand I'll add more code snippets through my write-ups.


1 class dice{                                  //represents the dice of the game
2     bool held;                               //is the player holding this die?
3     int pips;                                  //what is the score on this die?
4 public:
5     void throwd(){                                             //Throws the dice object
6         pips = rand() % 6 + 1;
7     }
8     int getPips(){return pips;}
9     bool getHeld(){return held;}
10    void setHeld(bool dec){held = dec;}             //Tells this die if it is going to be thrown
11 };                                                                     //again


So on a line by line basis:
Line 1 - Tells us that we are creating a new reusable object (class) called 'dice' and that everything between the '{' on this line and the '};' on line 11 is the definition for the object.
Line 2 - Creates a new variable called 'held'. Every instance of this class that we create will have its own copy of this variable. The 'bool' tells us that the variable is of type 'Boolean', that is it can only have one of two values; true and false.
Line 3 - Creates a new variable called 'pips' which is of the integer type, that is it can only hold whole numbers.
Line 4 - It's a little awkward to describe the 'public' keyword to an audience that may not know programming. In short it says: 'let other objects see everything from here onwards'.
Line 5 - This is a function (or method) definition (as are lines 8, 9 and 10). It defines something that can be done to any instance of the dice class we create. The void means that we should not substitute the function call for anything when we use it later in the program. The function ends with the '}' on line 7.
Line 6 - This is the body of the function defined in line 5. It sets the variable 'pips' to a random number between 1 and 6. Remember this is a reusable class, so 'calling' this function will only effect the 'pips' variable  in the instance the call took place. This will make more sense when seeing the call on a later date.

Line 8 - The classic 'getter' function. We can use this later to see what the value of 'pips' is for an instance of this class. The reason we need a function is because the variable 'pips' is defined before the 'public' keyword.  The 'int' means that when we put this in the code later on, we can treat it as an integer.
Line 9 - Very similar to line 8, except we are expecting a Boolean value back this time.
Line 10 - This is the inverse to a 'getter' in that we are using it to set the variable 'held' from outside the class. Notice that the brackets aren't empty this time, but have 'bool dec' inside. This means that when we write the function in the code later, we have to include either true or false inside the brackets. This tells the class what to set 'held' to.

Seems that language tutorials (even very basic ones like that) take a lot longer to write than I thought! I shall at the very least keep this going as a progress log, and maybe post little code snippets up every now and again. If you have any questions please let me know.

Thanks for reading.


Monday 1 April 2013

The plateau

I love learning. Always have. Not just the facts and figures bit or the book smarts, but skills, physical abilities, so many things that it's possible to do I like to try. See if I'm good at them. If I'm not I try and get good, if I am I try and get better.

I'm a bit like a magpie though. A new idea crosses my mind and it's like a shiny trinket to be chased to the detriment of whatever I'm currently improving at.

I can accept this. When I'm into something for a while I normally come back to it. What really bugs me though is what I call a plateau. This is when despite all my best efforts an improvement seems elusive. Like trying desperately to stakeboard up a steep slope, all the effort seems to be for nothing.

It may be no more than an illusion, and I've no idea why I'm committing it here, it just bugged me today and I hope expressing it will rationalise it a little. I probably expect results too quickly, but here is the magpie issue. If I get bored I worry I'll drop what I'm doing, but I don't want to. How do people keep the motivation going when success seems a distant dot on the horizon?