Poggle Patterns

I will be using two patterns in writing my program for Poggle. The first is a continuation of the one Microsoft use, the View-Document model. The View portion of the pattern handles what is presented to the user. The Document portion is the interface between the game itself and the rest of the program. The Game is in own part of the program.
In the future additional functionality will be added as distinct parts to the program as additional components are added. For example, a part to handle the players and their inventories, and others to manage the playing pieces and the playing field.

The other pattern that I will use is called the Singleton. Classes are often created when the additional functionality goes beyond the core of a enclosing class. The problem is that it is not a good idea to create a class for the benefit of only one object. (Think re-use.)
BUT, all too often only one instance of a class is necessary in a program. Thus, the Singleton.
Devised as a method to allow a program one and only one class instance, the Singleton keeps the idea on one object fresh in the programmer's mind.

In all honestly, a Singleton pattern is overkill for the Poggle program. It will be used in later programs, so I might as well introduce it here.

The name of the game is Poggle

Poggle is similar to a hand-held electronic game that was produced a decade or so ago. Press a button and lights change for several buttons. The player continues until all buttons are lit in particular manner. I believe it meant going from one colour to another.

In this version of Poggle the objective is to get all squares from 'off' (black) to 'on' (white). Selecting any square will change its colour in a set sequence, as well as the colour of its neighboring square above, below, left and right. As the playing field does not wrap to the opposite sides, squares on the border are treated differently.

The variants that this program will handle are changes in the size of the field (options ranging from 3-by-3 to 7-by-7) and number of colours that the squares will cycle through. The maximum numbers of colours mean that squares will go from black - red - green - blue - white and to black again.

Like I wrote earlier, there must be a way of proving that a solution exists. I just have no clue as to where to start looking.

Testify

The First Example

Over the next week or so I will go over a simple game to layout the basics of my approach. It will be a puzzle game, so issues about the computer making moves can wait until later. The only real problem that I have with it is that I have no idea how to prove or to disprove that there is a solution for some of the expansions. The math should be out there, I just do not know it.

Types of Games

There are about 5 - 6 classes of games. I will give only a brief description to provide a starting point in designing a game.

• Positional games are those games that players must position their playing pieces in a particular alignment or configuration in order to win.
• Connection games are like positional but deal in links instead of configuration.
  
• Capture games where the point is to remove the opposing pieces. Also known as war games.
• Hunting games are a little different. The point in this type of game is to immobalize the opposing pieces. Some classification will lump hunting and capture games together.
• Race game involve a set position or goal to reach. Or not to reach in some games.
• Mancala type games involve collecting neutral pieces, pieces that both players can move.
• Counting games (also known as dice games) are those games involving the accumulation of points.
• Card / Domino games involve matching pieces to further or to win the game.

A second classification scheme revolves around is there or is there not a theme, some story line that impacts the rule and winning conditions of the game. Chess is usually considered an abstract game. A murder-mystery game is thematic.

Did you know?

Did you know that 'Three Card Monte' was included in Hoyle's Games?

On Games

I would say that the first step in programming a game is to pick a game. That right, pick a game. You can design one from scratch too, but just pick a game.

Brainstorm a little. Will you go with a game that you are familiar with? How about a variant of a common game. Mabye you will go with a game from over the sea, or one from a couple of centuries ago.

Make sure you can nail down its rules. How many players? or is it a solitare -type game? What is the playing field like? Is there a playing field? Is it a race to be first? or to be last?
What are the pieces? And how do they move? Are there any limits to moving? Can you remove pieces? How? Are there conditions?

Go nuts. Go wild. Have fun.

First

Heh.

Or 'frist' as this bit of ego-boo is commonly marked in many comment list.

A small way of tagging one's achievement of crossing the finish line that a new blog entry allows. To plant a flag before settling down to the verbal fencing match that will soon follow. Like the ripple that follows a small pebble throw into a pond, it commemorates an fleeting event with the solemn silliness that is its due.

As this is my first post for my blog, I thought it appropriate to mark the occasion.

So, First.

Heh.