I started working on The Bitchy Witchy around year 2007. It is already 8 years ago – pretty unbelievable. It supposed to be point&click adventure like no other on Atari. Basic idea was to create game that will be similar to Gobliiins where you control hero on single screen and after you solve puzzle you will be able to move to next screen.

I introduced this project on AtariAge couple days ago also with screens so you can find some info there. This blogpost is mainly behind the scenes.

Whole game was idea of Vladimir Vostenak, he somehow “appeared” in 2007 and started to literally pouring one graph2font picture after another. His pictures were quite impressive because he often (maybe always) used DLI changes of background color so there was not single color register same in whole picture. Also his pictures were not exactly pixel-precise, which somehow added kind of artistic style.

Anyway, Vladimir prepared many in-game screens which were basically g2f pictures, my job was to make game of them. What a crazy idea… It required many hours spend on what could be possible and what it means to code it. There were several ideas floating around, but we decided to make it really point&click so I had to find and implement some nice algorithm that will calculate path between actual position of player and position that was clicked by cursor. As we have already learned in elementary school, shortest path between to points is line… but that is something we could not use, because our game character is human and there were obstacles on every location so it had to look like in reality so we said that our hero must be able to avoid obstacles and find way to target position.

This of course required some underlying mask that would define which places are reachable and which are not. I created small tool just for this called PathMaker:

I just loaded BMP of game location and selected reachable positions with mouse. Then I transferred it to mask in GR.5 mode… and then I started working on pathfinding engine. I don’t really remember where I found algorithm that I eventually used, but it was sort of flooding algorithm that also kept information about distance from source point so it was able to follow shortest path to target.

You can see it working here, first binary has delay between two steps so you can see how it proceeds:

Second binary is running full speed:

Here is also binary that has joystick control implemented, but it will allow you to make only one target point (there is no loop, it just hangs):

Hmm.. that’s basically all that was implemented in this stage. This path “engine” was never actually used together with g2f picture (in real game screen).

For some time I was occupied by coding intro sequence that contained 6 g2f pictures and some story texts:

That time I was not able to implement g2f into my projects using actual g2f ASM export so I coded my own DLI generator that was used in this intro and also in Summertime demo.

Couple of changes to original game idea was made, specifically we decided not to do that Gobliiins style game (single screen), but something different where player can go from one screen to another so he can explore several locations, collect items and use them in different location. Problem was that this approach required robust engine, it was never intended to be like i.e. Goonies where every screen was prescripted and coded separately, basically every “level” in Goonies is different game – this might be possible if we would stay with that Gobliiins style, but it was quite hard to prepare puzzles in single screens. It looked like player will be able to crack all those puzzles very fast so game will be very short.

So I had to think of some engine that will be under those g2f pictures running our magical world of Bitchy Witchy. This was very hard to decide and I was quite afraid what might I ran into. I was not ready to do reworking to I tried to think thoroughly every aspect… and basically that was the reason I put this game on “shelf”. I was thinking about additional hotspots that might be added into pathmap so there would be clickable areas that will cause some action other than walk. But it always went into prescripted stuff and I really wanted to avoid such approach.

BTW Jakub Debski (a.k.a Ilmenit) later created his own adventure framework called Adventure Studio, which output was sort of similar to what we wanted to achieve. Unfortunately no one except him ever created game using his framework. I spent one evening studying how it works, but it was quite evil :D. Of course we did not plan to make cross platform framework that will generate Atari binary according to XML configuration files like Adventure Studio, we planned to do something much simpler, it just could not be simpler, but I did not realize it before… so I had to start working on it and found so many problems to solve…

So this project was frozen for 1 year.

I tried to get back to this game in 2008 by complete change of game idea. I abandoned whole path engine and created tool for prescripted paths:

Using this tool I was able to add waypoints and link them into routes so player will “walk” only by these routes. Heh, I really like the bottom text that was inspired by H.P.Lovecrafts Call Of Cthullhu and Scooter (yes, that German rave band) :D.

Anyway, idea was to change player controls, leave pathmask and retain only those hotspots. Game was in meantime changed to text adventure:

Here is also version of this first screen with routing engine example:

…and that’s all folks!

Not a single byte was added to this game since then.