When writing grid based games (like checkers, noughts and crosses, tetris, etc...) would you have to start with writing the grid engine? Or are there pre-written grid engines out there?

I've been thinking of getting into the world of game programming but so far I only have a hlaf written light cycles game that I wrote about 6 years ago when doing a uni course in java.

I've been storing away several ideas for a few grid games in my head but I've never started any of them for fear of jumping into the unknown and going wrong (pathetic excuse but it's true).

The main things I have been worried about are things like creating maps with no "solved" squares in. (i.e. if the game is to line up 3 squares of the same colour then make sure none are created in the first place). And also making maps that are unsolvable.

Also I've never done any checking for things such as adjacent squares etc...

I know Nick did a chess game recently. Any input Nick?

The time has come to pull my finger out and created a finished game I think rather than having a half arsed mess around attempt and then giving up.

Just a little rambling from me.

I'm sure there are grid engines out there, and if there are non to be found through Google, I'm sure there are some open source grid based games you could go to and lift out the grid engine.
On the other hand, I suppose it could be fun to write one. You would know how it works and could reuse and expand it for other games you create.
Supposing the grid is just a two dimensional array then it's just array maths to figure out things like "get adjacent column", or "get above row".

Why would you need a grid 'engine'?

Surely your grid is just an x.x array with a set of game dependent rules?

The simpler way would be doing vector based movement then for calculating possible moves as opposed to checking every possible square when you can avoid it

It's not really an engine compared to a sound/graphics engine though

I was thinking along the lines of getting and setting what thing is contained by which square etc...

Now I think about it it prob isn't too hard just to write myself.

Vector movement would be fairly straight forward.

Just have to work out how to come up with valid patterns of starting positions etc../

I enjoy writing this kind of game. I usually break it down into a few simple bits:

1. An array to store the positions and one or more temporary arrays for calculations.
2. An algorithm to check if a move is valid and return the changed state
3. Another to evaluate a position. For example, it might return a value between -9000 and +9000 where either extreme is a win and a zero means both players are even.
4. One to render the graphics, preferably with irritating animation and noise.
5. User interface to get the input
6. The "brains" - I start with a 2 player mode only just to prove the basics are good, then add the interesting logic. It's often ridiculously simple, which explains why my AIs are so weak

Vector movement is good, also lets you learn overloading operands (if your language supports it and you haven't done it before obviously)

Valid patterns, try to examine it as an equation or similar if possible

If it's checkers from 0,0 to 7,7 then you know if it's odd it will be one colour, even another (if 0,0 is white then 1,1 is also white as 1+1 is even) and you can tell that valid moves are ONLY where it's on an odd square for instance

maybe store the moves for pieces in an xml file, say a rook can move +/-3x, +/-y or a bishop can move +/-x, +/-y for instance and find a way to store that