Oh YES, it's Honey Bee!

Saturday 11th October 2014 (Work still in Progress)

Poor old Wayne. He designs a new game, creates loads of graphics for it and then awaits a Commodore 64 programmer to write loads of code and then build a finished production. Suddenly the poor coder, erm, okay, me, ends up cancelling projects for some odd reason or something goes horribly wrong. The main casualties were Wizards and Warlocks, Up in the Air, and of course Crash Course.

Next on the list was Honey Bee. When Prime Suspect was working on Wayne's game. Things started to look quite promising. I saw a few videos of Honey Bee WIP, and I also play tested a few previews of the game myself. Just as I imagined this game was NEARLY up to the stage of completion. Disaster strikes. Due to a fatal computer crash on Prime's system, Honey Bee ended up as the next casualty of cancelled C64 game projects. Sadly there was no backup. All that could be salvaged were a few unfinished test previews, which Genesis Project had the pleasure of releasing into the C64 scene.

Honey Bee was almost a game that wasn't, until I received an email from Kenz about this game project. He asked me whether or not I'd be interested in working on this game with Wayne. Since there was the 16KB game cartridge competition announced spring/summer time. I checked out the preview of Honey Bee and thought. "Poor Wayne, his dream projects never seem to come true" and I took interest over the game, although the game will need a MAJOR make over. I tried designing the game with graphics of my own, but they looked too ugly. (See snapshot below). I did however agree to use Wayne's sprites for this game project.

 I started the programming process of the project by typing in the main game code from my head and following some example routines on codebase. I programmed things such as loops, interrupts, level settings, etc using Endurion's C64Studio with use of the ACME cross-assembler syntax. Which I am pretty much familiar with. Plus ACME is one of my all time favourite cross-assemblers for the Commodore 64, since it was introduced to me.

The post-build settings were edited so that I could run the fully assembled/compiled project through Exomizer for the best data compression rate where possible. The programming phase took me about  a few days before my summer holiday started in late July 2014- mid August 2014. The result turned out quite well. The mockup levels were created using Jon Well's Multi-Screen Construction Kit. Each screen was captured and compacted using Exomizer. The Exomizer decruncher source was also implemented into the source code.

 Before the Summer. I was discussing on facebook with STE86 about this game project, (also met him at Revival 2014 in Wolverhampton, where we talked and laughed about The Last V8). He sent me some mockup screen shots of how the game really should look like. The screen mockups then become actual character sets in Char Pad form. I was struggling to build levels at first using various PC tools. They were just unsuitable. I tried another program (Element Editor). The tool did quite well for building background objects, until "An unexpected exception has occurred in your program. You may choose to continue other wise click close to shut down the program". I clicked on continue, saved the work. Rebooted the program. Tried to load the work which I did so far, and sadly lost the graphics data, due to a corrupt file (even the backup). That same message popped by again. Was there any alternative?

As a last resort I decided to go old school and construct each object manually with the aid of Jon Well's excellent Multi Screen Construction Kit utility. What would have took me too much time building levels with CharPad and single 1x1 characters, had actually increased the speed of building objects and place them on screen as tiles. This took a matter of a few days instead of weeks.16 Levels were ready to be captured and crunched.

After new graphics were finished and designed (although they don't look exactly like the original graphics mockups which Steve sent me. They look quite effective. I worked on the main game code, updating the collision settings. So that characters which represented the deadly background will kill the bee, should it collide. Also the enemies will kill the player, using the $D01E routine. This was of course used to save memory.

Level setup is called through a series of tables, in which will also set up the position, speed, behaviour and animation frame of each enemy that is set in the game. Behavior patterns vary from moving up/down, moving left/right to just floating upwards off screen or dropping downwards from the screen. This takes effect on lava rocks and floating bubbles.

There are eight different enemies in the 16KB version of this game. They vary from worms, to bugs and birds.

Then there was the additional programming concept. I needed to get the panel working. Here's how the game should be played:

The idea of this game is to guide Honey Bee through 16 different stages, picking up pollen from flowers and then drop them (at any height) into the honey well. If he picks up pollen from a flower. 10 points will be given. However he won't be able to pick any more pollen until the honey, which he is carrying gets dropped into the honey well. If he drops the honey into the well, 50 points will be scored. Should he drop the honey elsewhere, then he'll have to start the whole level again. Should all flowers hove no pollen left, and Honey Bee drops the honey into the well.  A bonus set of points will be added to your score accoring to the amount of time that remains. If the bonus counter reaches 0000, you'll simply get no bonus points.

Honey Bee has a clumsy nature, and has to watch where he is going. Should he bump into a wall, rock, falling water, nettles, or moving nature creatures, he'll get hurt and fly away. Should he fly away, a life will be lost. This game is not just about picking up plants and avoiding enemies, but it requires precise timing and planning. A sort of a puzzle game one way or another.

Progress so far reports that Honey Bee is nearly complete. There's currently 12 functional levels so far, and just 4 more to do (putting enemies in place, setting up animation, behavior and getting them to move in the last 4 levels.) Hopefully the other 4 levels will be complete by the end of next week - which will result to just the final phase testing and bug-fixing, before entering this humble bee into the RGCD 16KB Cartridge Compo 2014. WARNING. THIS GAME WILL CONSIST OF BUGS - LOADS OF THEM - NATURALLY :)

Due to the size of the data and the code. The title screen is VERY basic and consists of 2 sprites for the logo. Some credits, with nothing else happening, except for animated bees next to 'Press Fire to Start'. Crediting myself for code, Ste86 and Wayne Womersley for main graphics and sprites, and Joachim (Yogibear) for the excellent music.

Despite that my spare time is going to be cut even more from tomorrow through to Christmas time. I am still happy to announce that Honey Bee WILL get finished in time for the competition deadline. Hope you reach the bee line for 1st December 2014. The bee will be unleashed from its honeywell. Then in 2015, the game will be expanded more with additional bonus levels, a picture by JSL and of course a better presentation, game intro and game ending (Of which I was unable to fit into the 16KB version of this project).

Here come the Chatters

17th-19th September 2013

I sent this game to Vinny Mainolfi to test, and come up with some more feedback. Unfortunately the main game engine needed some more things added to it. I agreed with what sort of improvements could be made to make this game more fun and playable. The general tile flipping puzzle against time idea of mine, won't really give good results for a 16KB game. The front end needed to do away with a scroll text. As I have always used that method (Logo with credits and scroll text). The changes were made to the front end. Instead of having a 1x2 scroll text, the game has a flip page. In which after a few seconds or so, the title flips from the main credits, to the high score table, then the in game characters (player, enemy, bombs). 

The main game also had some major changes added to them. The game now has enemies, called Chatters. The enemies run around the playing area lobbing bombs now and then. They don't bother aiming, as they are pretty much dumb. The player now has a different challenge. Not only has it got to flip the tiles to the correct type, but also has to watch out for the Chatters' flying bombs. The player can now protect itself from the bombs, by pressing fire to activated a limited shield. At the start of the game only 5 shields are given to the player. These have to be used wisely. There are also new tiles in which will give the player a shield if the player steps on it.

As well as the enemies and their bomb throwing. I started on redesigning the level layout, to make each level of the game look more tidy. I also programmed a high score name entry routine as well (which still isn't quite finished yet - one colour bug needs fixing). Additional things I intend to do during this project are the GET READY and END SCREEN as well as finish off designing the remaining levels. I hope to draw some new game sprites for the player and the enemies, as they are quite rough looking :) Progress is looking great so far.

Enter the Trap

29th-31st August 2013

Last time, I was working on the main game engine, hoping that everything was working. I was quite pleased with the result of the work so far. However, the colour of the tiles didn't look right on a CRT screen, so I changed the Blue+Purple tiles into Red+Purple. That looked much better. I had a great idea which was to add some kind of effect for every time the player is inverting the tiles. So I drew a sprite which creates a form of a dissolve/fade routine and added routines in the game to make this take effect. Basically, when the player hits a tile that inverts, the second sprite is used to form an animation over that particular tile. Now that I was very happy an impressed with the work done to the game so far.

I decided to move on to something else, related to the project. So I worked on a front end for the game. Unlike many of the front end title screens, where you have a static logo, credits and a scroll text. I wanted to do something completely different. I loaded in JSL's logo for the title screen. Then I converted the bitmap picture into a logo (Charset + Matrix) format. At the moment, this was just a static logo. So I decided to convert it into Swing Logo format. I downloaded Paramount's Shake It utility and converted the logo into a swinging logo format. 

Now I was happy with the swinging logo format. I exported the charset and swing matrix data into the project. Then I worked on the new front end. The 1x1 font was used to display the credits. I programmed in some multiple IRQ raster interrupts into the game's title screen code. Added the screen cuts. Top row of the screen has the first logo. The second row of the screen has the credits, which use the 1x1 charset, the third row has a 1x2 charset, which uses a smooth scrolling text message. Finally the bottom row has the second logo, which swings in reverse. I added some subroutines that would cycle the colour of the logo after a few seconds or so. This idea was inspired by common old-school C64 intros. The result turned out quite nice.

Now what about the game? So far I had 8 levels designed, so I decided to do some more tests on some of the newer obstacles. Unfortunately, for the blob, it stops at an incorrect position, causing the game to mess up. So to solve this problem, I added some simple checks and compared which direction the player was at. If the player was moving a longer distance, I had to trim the move distance slightly for a more accurate position. After I worked on the check subroutine for all 4 of those player directions (Up, Down, Left, Right), I worked on a few more levels, in which introduced the trap switches. If the player moves on to those either the trapdoors will remain closed, or they will all open. The T tile (correct direction) opens the trapdoors holes, and the T (upside down) represented the closing of the trapdoors. This trick worked, and some of the stages (up to level 12) are puzzling. As I positioned trap switches in various places to confuse the player.The result turned out great.

I also did some updates to the music. The in game music high notes part sounded pretty awful to the ears, so I changed the closing melody to the tune. The title screen instrument, which originally used sawtooth, was changed into a pulse ($41) and made the introduction of the tune sound much better. 

The assembled program is so far 10KB and it is going pretty well, and I seem to be progressing pretty quickly with this game. It may look as in the game could be ready for submission bby the end of September this year. Considering the extra free time I have been having recently :)

Here comes the Blob

17th-23rd August 2013

Last week and throughout this week, some people didn't hear from me for a while via email. Some people wondered what the heck happened to me. Well, I have been really busy on this project. As well as some classic gaming :) I also been on holiday for 2 weeks in Lydstep, Tenby as well, away from computers. There were wifi access points down there - but very limited. I wanted to get away from internet anyhow. It is too much of a distraction these days. Although the deadline isn't until 30th November to get the project finished and submitted to RGCD. I have a feeling that I will have it finished way before that particular date.

So then, what has been happening. Before I went on holiday for 2 weeks, between 27th July - 10th August. I was constructing the main game screen, using Jon Well's magnificent Multi Screen Construction Kit. This was only used to design one screen. When I checked the screen out, the size was 2 chars too small. So I expanded the grid and by adding just one more row of tiles to it. I also changed balls to blobs. The numeric counter was changed to blob symbols as well. Some different tiles were created. Those represented different obstacles, such as a normal tile, inverted tile, holes/traps, steel trapdoor, trapdoor switch, arrow pushers, and tiles that push you back to the previous tile. Then saved all of the graphics data, for just in case any adjustments or new tiles are planned. I also composed the title music for the game using Goat Tracker (See video below)

After finishing the game design grid, I captured the screen and transferred all existing screen and colour data directly to a memory location, using the T 0400 07e8 2000 (screen data), and T D800 DBE8 2400 (colour data) in VICE monitor. Then I closed down the VICE monitor and entered the Action Replay M/C monitor to save the data from $2000-$27e8 on to a .D64 image. Detatched the .D64 image and exported it to the C64 Studio project.Then I drew the sprites for the game.

The next step was to do some programming. The first thing I did was extracted all data into to the project directory, in which was called 'Invert'. I also added Exomizer to the directory as well. Compression is the key to starting a program :). I set up the main parameters inside C64 Studio to call  exomizer to compress the assembled binary, and  rename it to run via the decruncher, with no decrunch effect  (10 SYS 2061). Then I started the main programming of the level design. I based the level design on comparing which tiles are to be in place - as the level design was to be made manually by using the !byte command, using a row of 11 and a column of 10. Each number from 0 to 9 inside the table represented the object to be placed into the game area. I created a few routines in which read from the first tile character in each row, added 2 chars to place the next tile. I did separate low/high byte pointers to start from $0452, $0453, $047a, $047b, $d852, $d853, $d87a, $d87b and created a few loops which moved to the next tile character by 2 chars. Therefore with 2x2 chars, I used $0452 for the starting point of the top left tile, $0453 as starting point of the right tile, $047a as starting point of the bottom left tile, and the $047b as the starting point of the bottom right tile. I then added a few loops / subroutines to perform the action. Then it drew the correct test map on to the screen. The $D8xx + represented the colours.

My next step was to add the main player, a bluey blob in which was to be controlled by using a joystick plugged into port 2. I added some routines in which controlled the player. Basically, if the player was moving, and the joystick direction was being read at the same time. That process gets ignored, as the player is moved using a timer. After I was happy with this. I added the sprite/background collision routines, which compared which tiles the player was currently on after stopping on that particular tile. I got the effects to occur. One of which flashed the border (just for a test) if the player was on the hole tile. I was very happy with the overall result, I moved on to something else.

Now the sprite/background collision was ready, I loaded up Sprite Pad V1.8 and drew the player's animation frames. I originally had just 1 sprite for the player at first. Each frame represented the blog expanding and deflating. I liked what was done so far. So I saved the sprite data to C64 format again and inserted into the project. The next step was to program the sprite animation, where the player expanded and deflated at a certain speed. I programmed the routine in and it turned out quite nicely.

Back to programming the main levels. This time testing whether or not all tiles were correctly inverted to how they should look. After getting the routine working. I flashed the border again to say that the level was complete. I also programmed the clock routine. What a happy chap I was with this result.

Now came the nightmare, which I had for a few days. I designed 4 test levels, but after a level was finished. The tile data from the next level was out of place. I was pretty confused about how that happened. It puzzled me until yesterday. It turned out that I had forgotten to add the low and high byte values of the starting characters, which should initialise the first character and colour RAM position for each corner of the very first row of tiles. After that was solved. I programmed some messages to show LEVEL COMPLETE, LIFE LOST and GAME OVER. Then I was in the mood for doing some music.

I loaded up Goat Tracker V2.27 and worked on the in game music. Unlike the first tune which was used for the game, I wanted to do something pretty funky and quite cheerful. So I did a sort of funky cheery jazz type of tune as in game music inspired by demo scene musicians such as PRI, JCH, Drax, Syndrom, etc. Then added a game over jingle, inspired by the game over jingle from the "Artris" demo, by Scruffy Bits/Color7, which appeared in Commodore Format's cover tape #53. The result turned out pretty good. I generated a .SID file, and tested the .SID. Great, it worked. Now I transferred the music to the game project source, as .prg. I added some more routines in the game which plays the music. Awesome. It suits the game well. 

Now it was back to Sprite Pad V1.8 again, so I can add some explosions to the animation. This occur when the player loses a life, but first the blob sinks through the ground (or hole) magically. This can happen when time runs out or the player falls through a hole. I exported the new sprites to the project directory, then programmed the life lost routine, where the player gets killed. It looked quite good, but I wanted to add one more thing to the life lost routine. Shaking screen during the explosion. The pointers inside the explosion loop also read the animation table for the screen shake. Then restores the screen back afterwards. Wonderful. I love the overall result so far. So then what next? A real C64 test.

I copied the compiled .PRG to my 1541U2 and tested the game in action. Unfortunately, it looks as if I may need to adjust the correct tiles slightly as on the PAL monitor (TV) it doesn't look all that good. Still that won't really be much of a problem. Just a slight character change, and it will probably look much better. Everything else seems to be ok. More on this next week, as I am intending to get the FINAL touches done with Trance Sector Ultimate for RGCD tomorrow (Saturday) morning. Just a final bug fix for that.

I recently received an email from JSL offering me a front end logo for this game. Well, I am happy to take this, but I just hope it will be a 3 colour logo consisting of  7 or 8 chars down. There'll be no pressure either. After all, this is a hobby project - not exactly real life work :) I would like to to add one or two logo swing routines to the front end, so a 3 colour logo would ideal.For now, I shall enjoy a cup of tea. Then off to work in under an hour's time. Enjoy the game play video so far and tune in to another blog update, probably next week. Cheerio!

A new puzzle game is coming November 2013

26th July 2013

After the success of Trance Sector, and the two Sheepoid games for Psytronik Software and RGCD. I have decided to work an a 16KB game as my next main game project called "Invert". What is the game going to be all about you may wonder? First of all this gaame is going to be a 16KB cartridge game and downloadable / disk / tape format. It is not going to be commercially released - at the moment. Now what about the concept?

Invert is going to be a puzzle game in which you control a ball over the floor, in which should invert the black tiles to the correct colour tiles, consisting of 2x2 chars - but if you move over on to them again - they will invert again. Is that all the game is going to be? No, of course not. I have have some pretty interesting ideas in which will enhance the game play. There will be arrow tiles, forcing the player to move to a particular direction, also trap switches, in which will open / close traps and a couple of other surprises. The player will have to be racing against the clock to invert the tiles correctly. .

I started designing the graphics for the game earlier on this year. I did a redesign of the game area using Multi Screen construction kit, and the design looks much better. There is still a lot of work to be done, but I will be on to it in mid-late August, where all level data will be formed by using !byte tables, and those read are converted into the game tiles. I also did music for the game a couple of days ago.

Stand by your Llamas - The Alpacalypse is coming

4th February 2013

Stand by your Llamas. Engage defences as an Alpacalypse is coming - well, near your Commodore 64 and WinVice of course. I have been very busy the past few weeks (despite problems on get graphics in place) bringing yet a sequel to the Jeff Minter tribute "Sheepoid". It's called "Sheepoid DX". It is a fun cute game inspired by the classic Laser Zone, which Jeff wrote back in the early 1980's. Compared to Laser Zone, Sheepoid DX is somehow different. Especially when on later levels, the aliens start moving diagonal directions. One sheep would have to defend the other.

Sheepoid DX consists of 24 levels, in which the world is under threat of an alien invasion - or to put it another way an Alpacalypse. Two sheep have been transported into a incoming mother ship. A funny discovery was made, that there are 24 different neon vortexes, which give a strange vision for the sheep. One sheep is placed at the bottom of the screen, and another is placed on the far right. They have to defend themselves from ongoing invaders of each zone, simply by bleating pulse waves at them - so the aliens get destroyed. The player can also rescue sheep to gain smart bombs, those get activated with the space bar. The player's sheep has to try and avoid shooting the incoming sheep. If those poor little blighters get shot, 1000 points gets deducted from your score. No matter how far you get, it can be possible to end up with a very low score if you keep shooting the sheep.

Unlike the original Sheepoid. This game is more polished, with amazing graphics by Trevor Storey. The front end presentation looks similar to the original title screen from the first Sheepoid. The game has some better features installed. I still added the scrolling void in each neon vortex, but Trevor did amazing level graphics, which I am sure you would love a lot in this version of the game. I also removed the witty captions to make way for a better effect. The lazer beams. These are to make it look as if each invader is entering the vortex.

There are still some old Yak style favourites such as the camels (They still roam level 2 of this game), the Ancipital goat type of creature, but the majority of the enemies are completely different compared to the original Sheepoid.

I had a laugh with some of the ideas I wanted to implement into Sheepoid DX. I thought it would be quite funny to add a funny phrase for engaging a hidden cheat into the game (That was yesterday). I also had some fun playing around making music and sound effects using a music editor I had never used before. SidWizard in fact. SidWizard's awesome. So if you want to be a C64 composer, I recommend that you try it.

Well, the main game of Sheepoid DX is finished (I hope) and it is just the final mastering to finish off. I'm releasing this along with Woolly Jumper, hopefully via Psytronik Software and RGCD in a month's time or possibly over that period. It will be worth the wait I can promise you.


There are

Back on track again ...

25th November 2012 (Some good news about Amazon Tales)

Yesterday I was stuck on the enemy shooting and felt that there was no way I would be able to get out of the mess. I also thought that I could end up withdrawing my entry for the 2012 16KB Cartridge Competition. Later on before I went out. I came across an idea ... Why have a huge list of tables where you can easily get yourself lost - and simplify programming the shooting routine - To check whether or not the enemy object is a Pygmy, Monkey or anything else that was supposed to shoot.

Well, I put my theory to the test, and tried programming a small routine for each enemy (Can easily be expanded) to check whether the enemy sprites are the objects hoping to be placed in the game, and I also set the firing direction of the chosen enemies. Guess what happened then? It worked :). I was over the moon that the tasks I made were successful today. Now that part of the shooting phase was out of the way, I worked on a few more in game routines. The first one of which will display Get Ready and Game Over sprites for the levels. When I played the game with the enemies shooting - it was hard to play. So it was time for me to simplify things a little.

I programmed a little routine in which allowed the player to have protection for a short period of time. This occurs at the start of a level - or after a life has been lost. It was also to minimize the chance of a multiple loss of lives after one enemy or bullet kills the player and the player gets re-spawned in exactly the same position it died.

Now that was a good result :) Here's a video (with a crappy temporary title screen) of the game in action with the new features.

Since things are now looking quite positive. A submission of Amazon Tales is highly likely for RGCD's 16KB cartridge game compo, this Thursday.

Into the Amazon

29th September 2012

Finally the scroll engine has been updated a couple of weeks ago, with thanks to Achim's technical support. Now I have been working on the game's animation engine. Last week I got round to preparing the animation tables, but didn't get round to implementing them into a routine. So today I did exactly that. I animated the player so that it looks as if it is running.

I also added a routine in which the player shoots bullets. For some odd reason, the bullet sprite looked out of place. The player was shooting the bullet out of its head :) With a quick adjustment with Sprite Pad, I got the player to shoot the bullet at the correct height.

More work will be done on it later on this week or possibly some time next week - where I start adding the enemies in to the game.

Enter the Sector

1st-6th September 2012

Over this week I have been working on preparing and building the 32 levels for Trance Sector - fixing some additional bugs, building improvements for the game and programming the intro presentation for it. Now finally, the hard work is nearly done, it is on with the BETA test phase, which I hope will get great feedback.

I tested the new levels myself, and I'm not that good a gamer to be honest. I struggled on some of the levels in Trance Sector in cheat mode, but found that every single level in the game is most definitely possible to complete. I feel that this could be a real addictive game as well. If there's no major issues in the game for the beta testers, I can send the final masterpiece to Daniel Kahlin for tape mastering (As he's been doing a mega cool high speed tape loader system exclusively for Trance Sector. I shall be keeping my fingers crossed. :)

My next C64 project WILL be Amazon Tales, a co-op production by Alf Yngve for RGCD's 16KB cartridge game competition - and it won't be a SEUCK game this time round ;)