KRIEG3

Keys:
← : move piece left
→ : move piece right
↓ : drop piece
Z : rotate piece counter-clockwise
↑ or X : rotate piece clockwise

⌘R : reset game

---

The KRIEG series of prototypes are probably the oldest of my projects which will run on machines not now found for sale only on eBay, being the first projects I developed when I was teaching myself SDL* back in 2003; the KRIEG series of prototypes are quick-and-dirty clones of Puyo Puyo with an AI bolted on top; whilst playable, the prototypes were developed not to be good games, but to be test-beds for several ideas for AIs I was entertaining at the time…

The difference between KRIEG3 {video|source code & compiled:Mac OS X} and the earlier prototypes in the series is that this prototype is capable of creating chains.

A chain is comprised of cells which must be filled by blocks of the correct colour; one of those cells must be filled last, the filling of that last cell resulting in the complete elimination of the chain, eg.

A cell in the chain cannot be adjacent to a similarly coloured block which is not part of the chain, as that could result in the chain being prematurely, and possibly incompletely, eliminated.

The differences between KRIEG3 and the later prototypes in the series are: that the chains in this prototype are predefined (refer to the file ai3_patterns.hll), not learnt; that the chains in this prototype use predefined colours (ibid), not colours determined through analysis of the playfield to not cause the chain to be prematurely, and possibly incompletely, eliminated by adjacent blocks which are not part of the chain; and that the chains in this prototype are created fresh, the playfield is not analysed to determine whether any existing blocks can be used in the chain.

If the AI is not trying to create a chain (such as if there is not enough free space in the playfield for any of the predefined chains to fit into), the prototype falls back to using an improved version of the AI from KRIEG; whether to use the KRIEG or the KRIEG3 AI is reevaluated every time a piece is spawned under the control of the AI player.

The chain that the AI is trying to create is rendered as a slightly transparent overlay to the AI player’s playfield.

---

With regards to the KRIEG3 AI…

1. If the AI has not selected a chain to try to create, a list of the free space in the AI player’s playfield is created, eg. for the playfield below the list would contain the nodes (in the format [leftmost X-coordinate, width:height]) [0, 1:6], [1, 2:4], [2, 1:4], [3, 1:5], and [5, 1:6];

   

2. traversing that list, the AI creates a second list, of those chains which could fit in the free space without having any adjacent blocks of colours which could cause the premature, and possibly incomplete, elimination of the chain;
3. if there are any chains in that second list, the AI selects at random from that list a chain to try to create; if there are not, the prototype reverts to using an improved version of the AI from KRIEG;
4. a prediction is made in much the same manner as in the AI from KRIEG, where a duplicate of the AI player’s playfield is created, the piece under the AI player’s control is attached to that duplicate playfield at the correct X-coordinate and with the correct rotation for the prediction, and that duplicate playfield is updated as the original would be, with blocks being dropped and eliminated until no more changes will occur within the duplicate playfield without the attachment of another piece;
5. several values are then passed back to the AI: whether the attachment of the piece under the AI player’s control to that duplicate playfield exceeded the height of that playfield, which would result in gameover for the AI player; whether the prediction was ‘illegal’, viz., whether the prediction resulted in a cell of the chain being filled by a block of an incorrect colour, or a block not part of the chain coming to rest adjacent to a similarly coloured cell of the chain; the ‘legality’ of the prediction (a prediction which has more of its cells filled by blocks of the correct colour has a higher ‘legality’); and whether the prediction resulted in the completion of the chain;
6. a. if every cell in the chain has been filled by a block of the correct colour but the last, and if there is a prediction which results in that last cell being filled by a block of the correct colour, which is not ‘illegal’, and which does not result in gameover for the AI player, the AI takes the X-coordinate and rotation of that prediction as its targets, attempting to move/rotate the piece under the AI player’s control to that X-coordinate and that rotation.

   b. if there are any predictions which have a non-zero ‘legality’, are not ‘illegal’, and do not result in gameover for the AI player, a list is created containing that prediction with, or those predictions which share, the highest ‘legality’; the AI then selects a random prediction from that list, and takes the X-coordinate and rotation of that prediction as its targets, attempting to move/rotate the piece under the AI player’s control to that X-coordinate and that rotation.

   c. if the targets for the AI cannot be set in 6a. or 6b., the targets for the AI are set in much the same manner as using the AI from KRIEG: a list is created containing those predictions which have a ‘legality’ of zero (so as not to affect the chain the AI is trying to create), are not ‘illegal’, and do not result in gameover for the AI player; the AI then selects a random prediction from that list, and takes the X-coordinate and rotation of that prediction as its targets, attempting to move/rotate the piece under the AI player’s control to that X-coordinate and that rotation.

---

With regards to the modified KRIEG AI…

1. For every possible combination of piece X-coordinate and rotation, a prediction is made, resulting in a score for attaching the piece under the AI player’s control to the playfield at that X-coordinate and with that rotation, and – in an improvement on the AI from KRIEG – a flag indicating whether the attached piece exceeded the height of the playfield, which would result in gameover for the AI player;
2. when predictions for every possible combination of piece X-coordinate and rotation have been made, the AI creates a list containing that prediction with, or those predictions which share, the highest score and do not result in gameover for the AI player, and – in an improvement on the AI from KRIEG – selects a random prediction from that list; with a prediction selected, the AI takes the X-coordinate and rotation of that prediction as its targets, and attempts to move/rotate the piece under the AI player’s control to that X-coordinate and that rotation.

With regards to the predictions made by the modified KRIEG AI…

1. A prediction is made by creating a duplicate of the AI player’s playfield, and attaching the piece under the AI player’s control to that duplicate playfield at the correct X-coordinate and with the correct rotation for the prediction;
2. that duplicate playfield is then updated as the original would be, with blocks being dropped and eliminated until no more changes will occur within that duplicate playfield without the attachment of another piece;
3. several values are then passed back to the AI: the height of the highest column in that duplicate playfield; the total number of blocks eliminated from that duplicate playfield; the number of blocks of the same colour in the groups formed by the attachment of the piece under the AI player’s control to that duplicate playfield; and – in an improvement on the AI from KRIEG – a flag indicating whether the attachment of the piece under the AI player’s control to that duplicate playfield exceeded the height of that duplicate playfield, which would result in gameover for the AI player;
4. the score for the prediction is then determined by multiplying those first three values passed back to the AI by the importance of those values to the AI’s decision-making process, summing the latter two values, and subtracting the first value from that sum.

---

(I’ll note that there is at least one bad bug in KRIEG3, a potentially long-to-infinite loop in kriegPlayfield::Spawn(); that bug has never triggered on any of the occasions I’ve used KRIEG3, but it is there…)

KRIEG3 was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

KRIEG

Keys:
← : move piece left
→ : move piece right
↓ : drop piece
Z : rotate piece counter-clockwise
↑ or X : rotate piece clockwise

⌘R : reset game

---

KRIEG {video|source code & compiled:Mac OS X} is probably my oldest project which will run on a machine not only found on eBay, being the first prototype I coded when I was teaching myself SDL* in 2003; KRIEG is a quick-and-dirty clone of Puyo Puyo with an AI bolted on top; whilst playable, the purpose of KRIEG was to be a test-bed for several ideas for AIs I was entertaining at the time…

With regards to the AI…

1. For every possible different combination of piece X-coordinate and rotation, a prediction is made, resulting in a score for attaching the piece under the AI player’s control at that X-coordinate and with that rotation.
2. When predictions for every possible different combination of piece X-coordinate and rotation have been made, the AI player will simply take the X-coordinate and rotation with the best score as its targets, and attempt to move/rotate the piece under its control to that coordinate and that rotation.

With regards to the predictions made by the AI…

1. A prediction is made by creating a duplicate of the the AI player’s playfield and attaching the piece under the AI player’s control to the duplicate playfield at the proper X-coordinate and with the proper rotation for the prediction.
2. The duplicate playfield is then updated as the original playfield would be, dropping and eliminating blocks until no more changes will occur within the duplicate playfield without the attachment of another piece.
3. When no more changes will occur within the duplicate playfield without the attachment of another piece, several values are passed back to the AI: the height of the highest column in the duplicate playfield; the total number of blocks eliminated from the duplicate playfield; and the number of blocks of the same colour in the groups formed by the attachment of the piece under the AI player’s control to the duplicate playfield.
4. The score for the prediction is then determined by multiplying those values passed back to the AI by the importance of those various values to the AI’s decision making process, and summing the multiplied values.

(I’ll note that there is at least one bad bug in KRIEG, a potentially long-to-infinite loop in kriegPlayfield::Spawn() – that bug has never triggered on any of the occasions I’ve used KRIEG, but it is there…)

KRIEG was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

glass_castle

Keys:
↑ : thrust
← : rotate ship left
→ : rotate ship right
space : fire

⌘R : reset game

---

Ages ago, iDevGames.com held the 21 Days Later : Vectorized contest, a contest to – unsurprisingly – develop in twenty-one days a game making use of only vector graphics; I had several original concepts planned for the contest, but wasted precious time before I accepted that none of those concepts could be completed within the time-limit; instead, I decided to develop glass_castle, a clone of Star Castle (which I was introduced to by its clone, Cyclone, on the Apple Performa 460); unfortunately, I wasn’t able to complete development of glass_castle by the deadline of the contest, although I had developed three playable prototypes of increasing complexity and completeness.

Now, just a few years later than the deadline of the contest, I’m releasing the third and last of those prototypes – glass_castle {video|source code & compiled:Mac OS X}, a quick-and-dirty clone of Star Castle – to the public. Probably to the ridicule of the public. But to the public nonetheless. The major feature missing from this, the most complex and complete of those prototypes, is an increasing difficulty level: the prototype will begin playing at a predefined difficulty level, and continue playing at that predefined difficulty level no matter how high the level increases; it would be the work of maybe half an hour to implement an increasing difficulty level, but that’s half an hour I’m not willing to spend…

glass_castle was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

gun_dance

Keys:
↑ : thrust
← : rotate ship left
→ : rotate ship right
C : fire light gun
X : fire heavy gun
Z : fire missile
(You only have two, and only one missile per ship may be on screen at a time.)

⌘R : reset game

(If you’d like to watch two AI-controlled ships duel, change the line .human="no" to .human="yes" in the file main.hll.)

---

Ages ago, iDevGames.com held the 21 Days Later : Vectorized contest, a contest to – unsurprisingly – develop in twenty-one days a game making use of only vector graphics; I had several original concepts planned for the contest, but wasted precious time before I accepted that none of those concepts could be completed within the time-limit; instead, I decided to develop glass_castle, a clone of Star Castle (which I was introduced to by its clone, Cyclone, on the Apple Performa 460); unfortunately, I wasn’t able to complete development of glass_castle by the deadline of the contest, although I had developed three playable prototypes of increasing complexity and completeness.

Now, just a few years later than the deadline of the contest, I’m releasing the second of those prototypes – gun_dance {video|source code & compiled:Mac OS X}, a quick-and-dirty duel between a Human- and an AI-controlled ship in an Asteroids-like environment – to the public. Probably to the ridicule of the public. But to the public nonetheless.

The AI is simple-and-quick-and-dirty and will…

1. Check whether it is too close for comfort to an asteroid (if so, it will turn to face away from the asteroid and thrust); if it isn’t, it will…
2. Check whether its opponent has launched a missile (if so, it will turn to face the missile and fire whatever guns the missile is in range of); if they haven’t, it will…
3. Turn to face its opponent, firing whatever guns its opponent is in range of (and launching a missile if its opponent is in range of the heavy gun – why I implemented that condition I don’t know…), otherwise thrusting towards its opponent if its opponent is not in range of any guns.

It would be the work of a few minutes to implement controls for a second Human-controlled ship, or to implement more than two opponents; but those are minutes I’m not willing to spend…

gun_dance was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

rocks.in.space

Keys:
↑ : thrust
← : rotate ship left
→ : rotate ship right
space : fire

⌘R : reset game

---

Ages ago, iDevGames.com held the 21 Days Later : Vectorized contest, a contest to – unsurprisingly – develop in twenty-one days a game making use of only vector graphics; I had several original concepts planned for the contest, but wasted precious time before I accepted that none of those concepts could be completed within the time-limit; instead, I decided to develop glass_castle, a clone of Star Castle (which I was introduced to by its clone, Cyclone, on the Apple Performa 460); unfortunately, I wasn’t able to complete development of glass_castle by the deadline of the contest, although I had developed three playable prototypes of increasing complexity and completeness.

Now, just a few years later than the deadline of the contest, I’m releasing the first of those prototypes – rocks.in.space {source code & compiled:Mac OS X}, a quick-and-dirty clone of Asteroids – to the public. Probably to the ridicule of the public. But to the public nonetheless.

rocks.in.space was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

placebo

Keys:
← : move pill left
→ : move pill right
↓ : move pill down
↑ or X : rotate pill clockwise
Z : rotate pill counter-clockwise

⌘R : reset game

---

Ages ago unknown (a member of the iDevGames.com forum) ran a mini-contest to develop a Tetris-like game within a week; I developed LOF, an original spin on Tetris Attack merged with Stack Attack by The Caffeine Kid (a member of the YakYak.org forum)…

…which sucked.

So I developed placebo {source code & compiled:Mac OS X}, a clone of Dr. Mario, which sucked ever-so-slightly less.

Now, just a few years later than the deadline of the contest, I’m releasing placebo to the public. Probably to the ridicule of the public. But to the public nonetheless.

The code could be a lot better organised and there are a couple of potential bugs (in the right circumstances long-to-infinite loops), but maybe someone, somewhere, will learn something from the code.

placebo was developed on an Apple iMac DV (Summer 2000) in C++ using SDL*, OpenGL, and sealfin*, compiled with Apple Xcode 1.1.

Happy birthday to ‘shivering kittens’ – two years old!

shivering kittens is a panic-inducing puzzle game for Mac OS X – rescue the kittens from their icy imprisonment! Download the free demo of shivering kittens for Mac OS X by clicking here!^*

A block-matching puzzle game, shivering kittens tasks you with forming lines of frozen kittens to release them from their icy imprisonment, and then with forming groups of those thawed kittens to rescue them!

Click to watch a video of "shivering kittens"

Click to enlarge

Click to enlarge

Design & code by Mark Bishop, art by Alexander Goulkin, and music & sound FX by Ricardo Balderas.

Testing of shivering kittens 2.x by Zwilnik, igame3d, ThemsAllTook, unknown, gatti, & Malarkey of the iDevGames forum.

Testing of shivering kittens 1.x by Malarkey, hangt5, CarbonX, imikedaman, kodex, Bachus, & Byron Clarke of the iDevGames forum.

---

As of November 2008, shivering kittens has been acquired by Information Appliance Associates, Inc., who have discontinued the Mac OS X version of the game, and released an iPhone/iPod touch version of the game; shivering kittens for iPhone/iPod touch can be found here, whilst a video of the last update to shivering kittens for Mac OS X, 2.3-1, can be found here.↩

‘shivering kittens’ 2.2-1 released for Mac OS X!

shivering kittens is a panic-inducing puzzle game for Mac OS X – rescue the kittens from their icy imprisonment! Download the free demo of shivering kittens for Mac OS X by clicking here!^*

A block-matching puzzle game, shivering kittens tasks you with forming lines of frozen kittens to release them from their icy imprisonment, and then with forming groups of those thawed kittens to rescue them!

Click to watch a video of "shivering kittens"

Click to enlarge

Click to enlarge

Design & code by Mark Bishop, art by Alexander Goulkin, and music & sound FX by Ricardo Balderas.

Testing of shivering kittens 2.x by Zwilnik, igame3d, ThemsAllTook, unknown, gatti, & Malarkey of the iDevGames forum.

Testing of shivering kittens 1.x by Malarkey, hangt5, CarbonX, imikedaman, kodex, Bachus, & Byron Clarke of the iDevGames forum.

Changes in version 2.2-1 of shivering kittens (1^st January 2007):

• fixed a bug where pieces would not fall if they were rotating or if they were moving horizontally.

Changes in version 2.1-1 of shivering kittens (7^th November 2006):

• fixed a minor bug where the screen would be set to the wrong colour-depth when playing the game in fullscreen.

Changes in version 2.0 of shivering kittens (19^th September 2006):

• the falling blocks now fall much more smoothly (with sub-pixel precision);
• the falling pieces under the control of the player now rotate much more smoothly;
• the falling pieces under the control of the player now fall much more smoothly (with sub-pixel precision);
• the falling pieces under the control of the player now move to the left and right much more smoothly (with sub-pixel precision);
• the highscores now show…
  • …the number of kittens rescued during a game;
  • …the best ‘chain’ of kittens rescued during a game;
  • …the level the player started playing the game at;
  • …the level the player game over’d at;
• fixed a minor bug where the left-’⌘’ and right-’⌘’ keys were interpreted as a single key;
• the ‘escape’ key now pauses the game;
• the game will now pause if the player switches to another application or minimises the game to the Dock;
• the game now has multiple levels of difficulty;
• the game now has a title screen, from which the player can choose the level of difficulty to start playing at;
• the player status panel now shows…
  • …the number of kittens rescued;
  • …the best ‘chain’ of kittens rescued;
  • …the current level;
  • …the number of kittens needed to be rescued to advance to the next level;
  • …the player’s current position in the highscores;
• the game can now be played in fullscreen;
• implemented a dialog which is shown whilst the game is paused, with an option in that dialog to return to the title screen;
• lots, lots more.

---

As of November 2008, shivering kittens has been acquired by Information Appliance Associates, Inc., who have discontinued the Mac OS X version of the game, and released an iPhone/iPod touch version of the game; shivering kittens for iPhone/iPod touch can be found here, whilst a video of the last update to shivering kittens for Mac OS X, 2.3-1, can be found here.↩

‘shivering kittens’ 2.1-1 released for Mac OS X!

shivering kittens is a panic-inducing puzzle game for Mac OS X – rescue the kittens from their icy imprisonment! Download the free demo of shivering kittens for Mac OS X by clicking here!^*

A block-matching puzzle game, shivering kittens tasks you with forming lines of frozen kittens to release them from their icy imprisonment, and then with forming groups of those thawed kittens to rescue them!

Click to watch a video of "shivering kittens"

Click to enlarge

Click to enlarge

Design & code by Mark Bishop, art by Alexander Goulkin, and music & sound FX by Ricardo Balderas.

Testing of shivering kittens 2.x by Zwilnik, igame3d, ThemsAllTook, unknown, gatti, & Malarkey of the iDevGames forum.

Testing of shivering kittens 1.x by Malarkey, hangt5, CarbonX, imikedaman, kodex, Bachus, & Byron Clarke of the iDevGames forum.

Changes in version 2.1-1 of shivering kittens (7^th November 2006):

• fixed a minor bug where the screen would be set to the wrong colour-depth when playing the game in fullscreen.

Changes in version 2.0 of shivering kittens (19^th September 2006):

• the falling blocks now fall much more smoothly (with sub-pixel precision);
• the falling pieces under the control of the player now rotate much more smoothly;
• the falling pieces under the control of the player now fall much more smoothly (with sub-pixel precision);
• the falling pieces under the control of the player now move to the left and right much more smoothly (with sub-pixel precision);
• the highscores now show…
  • …the number of kittens rescued during a game;
  • …the best ‘chain’ of kittens rescued during a game;
  • …the level the player started playing the game at;
  • …the level the player game over’d at;
• fixed a minor bug where the left-’⌘’ and right-’⌘’ keys were interpreted as a single key;
• the ‘escape’ key now pauses the game;
• the game will now pause if the player switches to another application or minimises the game to the Dock;
• the game now has multiple levels of difficulty;
• the game now has a title screen, from which the player can choose the level of difficulty to start playing at;
• the player status panel now shows…
  • …the number of kittens rescued;
  • …the best ‘chain’ of kittens rescued;
  • …the current level;
  • …the number of kittens needed to be rescued to advance to the next level;
  • …the player’s current position in the highscores;
• the game can now be played in fullscreen;
• implemented a dialog which is shown whilst the game is paused, with an option in that dialog to return to the title screen;
• lots, lots more.

---

As of November 2008, shivering kittens has been acquired by Information Appliance Associates, Inc., who have discontinued the Mac OS X version of the game, and released an iPhone/iPod touch version of the game; shivering kittens for iPhone/iPod touch can be found here, whilst a video of the last update to shivering kittens for Mac OS X, 2.3-1, can be found here.↩

TUMIKI Fighters

I’m just posting a link to the Mac OS X version of another excellent shmup by Kenta Cho/ABA Games, TUMIKI Fighters; this shmup brings a cute new-ish¹ concept to the genre – if you can catch pieces of destroyed enemy ships, they will stick to your ship, boosting your firepower and acting as a layer of armour…

¹Well, Zero Wing let you grab an enemy ship to use as a layer or armour, but with the tradeoff that whatever enemy ship you grabbed increased the weight of your ship, pulling your ship towards the ground… ↩