Where have all the aliens gone?

14th March 2020

Great news. Cruiser-X 79 continues this month. Today has been quite a long session. You might probably notice that the game was delayed for a very long time over several months period. This was mainly because of some other game projects I was working on. Happy Blocks DX, Amazon Tales, Mega Tank Blasta, Toxic (2020 Edition). Amazon Tales was made as a practice piece in order to attempt to develop custom enemy movement patterns which didn't require wasting $200 bytes of data. Plus I wanted to add a mixed batch of enemies in to the game project.

Since the game engine in Amazon Tales was successful. I have decided to try a similar attempt for Cruiser-X 79. In order to do that. I have to start the enemies attack patterns from scratch. Before I could do that, I had to delete the existing alien attack patterns. Therefore on today's build of the project, I concentrated on setting up table values per enemy type.

For example:

Alien1SpawnX = The starting horizontal position for the alien to spawn from
Alien1SpawnY = The vertical horizontal position for the alien to spawn from
Alien1Dir = Direction for the alien to move whilst in operation. 0 = Up, 1=Down, 2=Left,3=Right. This consists of a table of 8 bytes (Since the aliens are supposed to switch to the next direction every time a path limit has been reached).
Alien1Speed = Speed of the alien which is moving, once again 8 bytes.
Alien1ChangePosition = Horizontal or Vertical position in which the alien must reach before it can change to the next direction (or leave the screen)
Alien1ObjectLo = Low byte of the animation frame read from the sprite animation subroutine
Alien1ObjectHi = Hi byte of the animation frame read from the sprite animation subroutine
Alien1Colour = Alien sprite colour
Alien1Lives = Amount of lives the alien has before it can be destroyed
Alien1Score =  Multiple number of points to be scored per alien destroyed

I also made different lo/hi byte tables which should somewhere in the game code (once implemented) copy the self-modifying pointers in to the correct self-modifying code. For example, after the last change position has been breached, and all aliens are off set. A new group should spawn.

For now, there's no aliens in this current build, because the code needs to be started from scratch. This will be continued during my next coding session on this game project.

Let the Invasion Commence [Part 9]

25th September - 1st October 2016

Let's Invade was currently in the testing phase. Unfortunately not everything is quite ready yet although I do feel confident about an Autumn release of this game. Parts of the game code needed to be tweaked, the Health and Safety notice needed to be updated, and also the game char set needed a quick change. So I fixed those, however, I came across another obstacle. The alien bullet firing isn't random enough, and it seems the same alien shoots the bullet. Sadly this is still the obstacle I haven't got over with this week.  

During that obstacle, I felt slightly demotivated, and decided to code a little something else. That was of course a mini music demo called 'Mix Box 1'. Featuring 5 new unreleased tunes, and some oldschool look, despite the raster timing issues. I've never really liked timing raster bars.

Thirdly a disk menu for Reset's Craptastic was programmed, near complete, but requires raster bar timing.

Today, I got back to Let's Invade and once again, it was another frustrating session. I did some how manage to get the enemies to drop bullets randomly, by creating the wrapping round routine, but after a while, the same aliens were dropping the bullets. Yet again, I didn't manage to get over this obstacle yet. One day climb over the wall that blocks me, but it is a matter of when....

The end is near - Can we me make it? ...

18th + 19th December 2015

Wow. Some more free time at last. Well, more work on Vortex Crystals then. Before any more programming had taken place in the game project. I asked Alf if he'd like flashing lights animation added to the background. After he suggested that it was a great idea. I worked on mapping the values of the char colours for the flashing lights. After compiling the code, the animation turned out quite nice. I sent the new build to Alf and he liked it.

The next step was to work on the end screen (since the whole game engine is finished right now) . A couple of months back, I designed the end screen using the example background, and crunched it - but didn't actually test it until yesterday. The result turned out pretty well. So I worked on the animation scenes. It involves the player attempting to make an escape from the V-Tex complex (After completing room 16). What happens next, I will not tell you, but the ending turned out GREAT. I even had ENOUGH memory to fit the ending into the code and compile a 16KB cartridge.

After finishing the end screen, I worked on doing a phase of bug fixing. I felt the player was jumping too high in the game, so I halved the jump duration on the player. Unfortunately that didn't work out that well. The jumping height was too little. It made things more impossible for the player to be able to jump high enough on to some platforms and conveyor belts. So I increased the jump height by a quarter. It looked and felt much better.

I wanted to add some bonus scoring to the game code, so that the player gains a bonus number of points, according to the number of bullets the player carries. Of course if the player dies - default bullet amount will be 40. Only at the start of each level, the player starts with 50 bullets. I also had enough space to add a flashing text routine. After finishing with the project (for today) and email Alf the latest build. I ported the game on to my USB dongle, and play tested it on my C64, via the 1541Ultimate 2. Really happy with the result so far. ... but is the game finished yet? ...

Not quite. Although I can say it is probably  99% finished, it needs a little bit more bug fixing, a pause+quit game function, and then pass it over to one of my C64 scene buddies to NTSC fix it before the final compiling and submission. :)

After the compo - I intend to extend the code a bit more, to give out more frames for the in game animation. Add additional in game options, a better looking front end presentation, hi-score table, etc. Apart from those - the main game stays the same.

Darker than Light

3rd-8th July 2014

Back in January 2014. I worked on a SEUCK game co-op with Alf Yngve called "Dark Force". The challenge was originally to get a first release out for new year's day. It failed and got released later on during that month. February/March saw a re-relase of the same game, with a few extra enhancements. Only major drawback was the SEUCK slow-down syndrome... Eurgh!

Now today on 8th July 2014 before I set off to my work place. I am very pleased to reveal the that the final version of Dark Force. It is Dark Force - Redux. The whole game data was imported into the SEUCK Redux frame work, which Martin Piper supplied on github. I also did a lot of additional hard work programming this production the past 4 days. Including re-programming the new front end. Enhancing the background level settings. Here's the overall result.

- Black/Blue loading screen with loading picture and music (Music from the TND intro on the disk version 'Emotions from Heaven')
- New front end with Hi-Score table, as before, but logo had to be carefully downgraded to 3 colour logo mode, due to lack of memory space for bitmaps.
- Slight tweak of an instrument on the front end tune
- Different background colour schemes for each level
- Intelligent enemy fire (Fires bullets in the direction of where the player was last positioned).
- Most important of them all ... No more SEUCK slow-down syndrome

What originally was meant to have been an experiment with SEUCK, turned into a fun 'game inspired by 'Light Force' by FTL.

If you would like to try out the SEUCK Redux engine, then check out:

Martin's C64 Repository on Github

For the C64 game Dark Force, please visit:

The New Dimension - Download games page

Production slowed down, but at least something

14th June 2014

Production on Honey Bee has slowed down, as I don't know where I am in the project now, since new graphics are still being worked on this game. I still have the 1x1 chars to play around with to build various screens for the game, but this will take some time. Slotting 1x1 chars together to form detailed level screens is taxing. Steve has sent me a PM a long while ago and he has come up with a preview snapshot of the new status bar for Honey Bee. It looks very nice. :) I hope you all like it :)

Into the 4th Hive

8th March 2014

After a successful backup and restore process on Thursday, and Friday when moving to Win 8.1 on my desktop PC. I was ready for yet another programming session. Last time, I managed to get 2 levels set up, now another 2 levels were to be built up. 

I setup the position and enemy types for levels 3 and 4. Once they were positioned, and all pointers were setup for them. I decided to work on something completely new. When enemies moved left and right. They were facing exactly the same direction as they were moving. So a major tweak was required. Frames should change if an enemy changes direction. We don't exactly want a game in which an enemy moves forwards and backwards without flipping sprite frames. A solution to this problem was built. I programmed a few subroutines, which checked if a sprite was moving left / right if it is a worm, a bird or a hornet. If the low byte of the chosen frame was stored to the actual low pointer of the frame. The subroutine should point to the correct low / hi bytes of the frame of the enemy. 

After I tested this subroutine routine, enemies moved correctly, and the frames changed correctly. No enemies look as if they are moving forwards or backwards. The all move forwards instead. I also thought about setting tables for the background colour, as I am pretty much sure that Wayne wants a different background colour according to level. Yogibear also did some sub game tunes. So I created a table that switches between two different in game tunes. 

Since I now have 4 levels set for the game, I think it is time for me to tweak the background graphics slightly more. Ste86 has given me some mock screen examples of the graphics that could be used as an update to the game. His idea is to help me as a guideline - I'm not really a GFX person :) The trees look much better than mine. So after my morning walk, and my lunch, some time tomorrow afternoon will see the design process in action.

Stay tuned

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 :)

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

ATTACK!

10th - 11th November 2012

With the deadline coming closer, and closer. A lot of work is required to be done for Amazon Tales. I'm not too sure whether or not I will meet the deadline for the 16KB cart compo, due to extended hours at work - through to Christmas (Reducing my free time even more). I will try my best to get Amazon Tales ready in time for 30th November, but cannot really promise anything spectacular.

Yesterday I have been working on some additional routines and also behaviour tables for each of the enemies. Each byte in the behaviour table has a different type of behaviour for the enemies. They vary from moving up and down at the bottom part of the screen, or the top part of the screen. Or shoot a bullet at a certain direction. I didn't get round to getting the enemies to shoot yet, as I wanted to concentrate more on the attack movement speed, and position. I got myself lost with this attack wave thing yesterday, so I had to rewrite the position and speed tables to how they were beforehand.

Today I have been working on getting level 1's enemies positioned. At the start of the game we originally had four enemies moving across the screen (Two going a different direction). To make things easier for the first level, I updated the tables, where at the start, you have 2 enemies to attack, then the number gradually increases it. I also got the great big tigers to move up and down via the behaviour patterns. This worked quite nicely :)

On Wednesday/Thursday, I shall be working on adding enemies to level 2 (The dark forest), which will include the monkeys at a certain height. Introduce another new enemy, then as the week progresses, work on the remaining four levels. 

The Player Dies at the End

6th November 2012

Don't mistake yourself with Alf Yngve's latest Sideways SEUCK masterpiece, which I released on the TND web site on Wednesday last week. Nope. This is basically a blog update about what I have been doing this morning. Well, yesterday, I got the enemies to die when the player throws an object at them. Now today I did the opposite.

The Player Dies at the End by Alf Yngve

A few days ago, I got the collision registers programmed in (The usual box collision register). Yesterday was the bullet/enemy sprite. Today was the enemy/player sprite. I first added subroutines to check whether or not each enemy hits the player and test flash the player - if a collision was spotted. The routine sort of worked, but I thought about making a loop for all deadly objects to collide in any area to the player's sprite's X-Y axis. :) That was much shorter, compared to repetitive comparing values for each sprite. It worked quite nicely as well.

Now that I got the player's sprite to change colour when an enemy collides into it. I worked on building a routine that will check for the player, to see if it was already dead. Followed by adding a routine to do the actual death animation. All worked fine, and the player can die.

The player lies dead, after being bitten by a jungle snake

There were just two more things to be added to the shooting and death routines. Which were to add points to an enemy killed, and also a lives subtraction counter. I got those to work fine. Next came playing the GAME OVER jingle after a life has been lost. I was going to get the player to have a short term protection (flash) but I with the short amount of time I had, I didn't get round to it. So Thursday is a possibility. I might be taking a little break from programming tomorrow. We'll have to wait and see.



The game's engine seems to quite positive, but I can be sure that things WILL eventually turn much better when this Thursday or Saturday, I will be adding some more extra routines to enable some of the enemies to shoot - according to what object they are. Followed by additional behaviour of enemies. Some will walk across the screen in a straight line. Some will move up and down while slowly moving across. Some will shoot, and some will have interesting and quite impressive features.) More about it when I get round to doing exactly that.

Give it some POW

5th November 2012

As I said yesterday, from now through to the deadline. I am going to committing my free time available in the mornings (before work) to get this project finished. Mainly because the deadline for the 16KB cartridge compo is getting closer and closer.

Yesterday, I got the player to shoot at the enemies, and kill the enemies. Now today, I did some more to the shooting routine. The player shoots bullets but the enemies had no death animation whatsoever. Alf also didn't supply me with a proper death animation for the enemies. So I drew a POW style explosion sprite, consisting of 2 frames. Then I created a subroutine which will animate the explosion sprite on the player bullet, if an enemy is killed.

Well, that routine was quite effective. However, I noticed a small bug in which turned the player's bullet pink an displayed that for a short time while flashing the explosion. To resolve this problem, I altered the sprite settings so that the bullet sprite is NOT available until after the explosion has finished and the bullet sprite has been homed.

Wammo - Take that you dangerous creature!

The last thing I did today (since time was pressing on) was correct the settings for the sprites. (Big tigers) so that they are linked together correctly, and also the player can only shoot if the fire button is pressed, and not held.

My next task will be to get the scoring to work, enable the enemy/player collision and then get the player to die and lose lives.But that can wait until tomorrow morning. As I have to get ready and go and work 12pm-8pm soon.

Hopefully on Thursday, during my day off work  I can get the enemies ready for all of the levels. Then work on enemy shooting (As I want monkeys throwing stuff at the player, the pygmy's firing darts and spear throwing guards as well.

I think although the free time I have is too short (due to 12-8 shifts in a busy warehouse) I am feeling quite positive that I can reach the deadline for this a 16KB version of this game project.

On today's menu - Trance Sector

15th September 2012

After sending BETA V3 to the BETA testers, no problems seemed to have occurred. So now BETA testing has passed. It's time for me to add the final touches to the disk version, while Daniel Kahlin's working on the finishing touches for the tape version.

During this week I have been working on a TS music demo, which goes with the Trance Sector game, and today I have been working on the disk menu system, and final linking to the intro. The menu is really colourful and quite attractive. The worst part to programming the menu was the raster timing. When I created the colour bars they were all over the place. After playing around with the raster bar timing tables the overall result showed perfect looking raster colour bars. I was pleased with the final result.

Once the disk menu was finished, I implemented Martin Piper's IRQ loader system (and the TS loading picture) to the menu, and set disk drive initialise at the correct point so there wasn't a pause during the IRQ loader part - and so that the music will continue playing as well. I used the tape loader tune for the disk menu system / disk loader, as I thought it would be really cool for it.

I put all the files together on to the disk, altered the load addresses of each PRG file (So that the loader can load the game to a specific address). Now the disk version of Trance Sector is finally ready for release to Psytronik Software.

All I have to do now is get the raw versions of Trance Sector and Challenger's Edition for Daniel Kahlin, and finally I shall release both DISK and TAPE versions to Psytronik Software.

... And the bonus ball is ...

27th June 2012

I only had 2 hours spare, which gave me some time to work a little more on Trance Sector, since finishing Escape from Zaphod  using the 3D construction kit last week (Hard work).. I took a look at the sprite data to work out what the ball's value should be, and created a frame table in which would indicate the colour for the particular bonus object. I created a few values to check the direction of which direction the ball should be bouncing. A few subroutines were also programmed in to get that ball moving according to direction. Yep, it bounced around the screen how I hoped, but was a bit too fast. So I slowed it down by adding a speed delay to it. I also created a sub routine that could cycle the colour of the bonus ball. The same was done for the frame type. Since I didn't want the ball colour and frame cycle to go too fast, I just had to sort something out to stop this. So I created a delay. Now the objects and colours are cycling to how I hoped they would. 

... and here's the result so far. :)

As you can see, I have a ball bouncing around the screen, but what use is it where there's no way of being able to touch the object to destroy it? Well, because of being short of time I had because of work. This will be resolved hopefully some time this Friday, if I don't get called or text into work that is :) The plan in general will be to get the bouncing ball to disappear if one of the seekers/missiles hits the ball. Whatever frame the ball last had will result 100 points, 200 points, 500 points, an automatic bomb to destroy all seekers or a lit up E-X-T-R-A (In which, when fully lit will award the player an extra life). I better work on the collision and checks for what's resulted from the ball.

Engage Shield, Panic Stations

19th May 2012


Well, this is where the fun begins :). I worked on a 1 screen test level (To get the tiles working) and imported the test level library from the Multi Screen Construction Kit. Then I started working on some more programming aspects to the game engine.

There were two new tiles for the game. One which was a temporary shield, and the other which was the switch. I loaded up VICE and the game's graphics work files to work out which character indicated the shield, the switch (on) and also the switch (off). Then I added more to the sprite/background collision register routine. Some of the routines check for the value of the character. If it was the shield tile then to test this was working I added INC $D020 to increment the border colour (test). Then I did exactly the same thing for the panic switch, but DEC $D020 to decrement the border colour (test 2) instead. I also got the tiles to change. The shield tile turns into a standard tile (Shield disappears). The switch on tile turns into the switch off tile. I assembled and executed the new code and tested the test level. The increment/decrement of the border worked. Now it was time to add some more routines to make the code work how it should have.

Some more variables and timers were added for the shield routine. The idea was to create a timer that will give the player a temporary invincibility mode. I also created a table which should flash the player (silver/grey flash scheme). A routine to time the shield counter was also added. I also created a routine to check whether the timer equals 0, indicating that the shield has been disabled. Otherwise the sprite/sprite collision would be bypassed. After I assembled and tested the routine. I had the player flashing for some time (after collecting the shield) which was perfect. Especially for the harder stages of the game, where there will be tiles with panic buttons surrounding the pods.

Now the invincibility mode was sorted out. It was time to add some interesting features into the panic switch routine. I decided to make it look as if the alarms were going off - and the seekers speed up during a short period of time as well. This was to make game play more frustrating and fun. Like with the shield routine, I created a timer and also two colour tables for the background multicolour. Yes that's right, the background multi colours flash on panic mode. The effect turned out nicely, and also the background restores to its normal colours after the panic alarm's switched off (automatically).  :)

20th May 2012 More level designs ... and the master of disaster strikes ...


I have been doing some more levels using Multi Screen Construction Kit today, and have 25 working levels done so far, but the bad news is that after level 26 was stored to the MSCK library and I wanted to view all of the levels through MSCK, the program crashed (CPU JAM at $C107). It was very complicated to look at the code. So I'm not sure whether or not it will be possible for me to recover the level. If it is not recoverable, I will have to redesign the same levels using a different utility (I might try Delight by Color7 productions), but it will be a longer process in designing all of my levels (Using 2x2 tiles). Here's a snapshot of what Level 26 could have looked like (if I'm accurate enough).

It looks as if there will be no more work on Trance Sector until the end of this week because my week's holiday finished on Friday. Unfortunately now I'll have less free time to do what I enjoy doing the most (C64 activities), due to working 12pm-8pm shifts again. I can put my mind off this game for a few days or so, until Friday/Saturday morning. :)

Scroll it the hard way

18th May 2012

Something more interesting to be added to Trance Sector. A 4-directional scrolling field. Well, that's what I have spent most of today's Trance Sector session with. I wanted to get the scrolling movement to move according to the direction the player uses with the joystick. I created a new counter which can check which value will indicate the direction for scrolling background field. Then I stored values of 0 - 3 into the scroll counter. Where 0 = Up, 1 = Down, 2 = Left, 3 = Right, then I added a routine that could check for what value the counter is and added subroutines, which would scroll the characters that formed the background field, according to direction. This took quite a lot of programming to get implemented into the game, but I still have plenty of memory of additional code, since sacrificing the logo to build a new title screen. (The logo will be used for the intro instead). My next task (Possibly tomorrow) will be to activate the shield for the player, for any time it hits a shield tile. (On later levels), then hyperspace (Warping) to a different area on the same level screen.

Fixing phase! ARGH!

13th November 2011

Okay then, most of today I have been working on trying to get the game to be finished. First of all some adjustments needed to be made to the game code. First of all, the front end logo needed to be updated as Shaun sent a much nicer looking version of the same logo, which I originally resized. That really made a huge difference. How on earth did I forget about Shaun's logo?

Most of today was a frustrating session. I kept getting more problems (or probably causing those in the game code). I adjusted the player's shield so that the player didn't flash, when it was wearing a workers helmet. I also updated the get ready text and positions of the rocket. The end of levels 2 and 3 looked very odd. I also had to fix the start screens for levels 2, 3 and 8. After fixing those, Shaun gave me an idea where scoring points (after shooting the enemies) should be based on the size of the bullets. So I added a routine that can work out how many points the player can score according to the following:

Weak bullet = 100 points

Medium bullet = 200 points

Mega Bullet = 500 points

Shaun didn't like the idea of having the cattle prod in the game, which caused the player to lose a life, so I removed it and replaced those with the other 3 collectables that are used in the game.

To finish things off, I added a routine in which drops a whistle to the central of the end platform. After the player picks up the whistle, a rocket will appear on screen, with yellow flames and pick the player up. I also had to find a way on how to get those enemy bugs moving in a different sinus wave to the other enemies. Well, the solution was finally found. I used Elwix/Style's WixBouncer tool, in which allows you to chose the sinus mode you want. Then you manually type in the start / end and length of the sinus. I then imported the sinus data into the source code. It made the pink bugs' move quite more different and interesting. Much better now.

Hopefully now I have sent a new .D64 to Shaun, we could say that this game is finished. If it is, then all will be revealed on this blog. The game will be sent to RGCD for submitting to the 16KB cart. Then I and work on expanding this game in time for a Christmas 2011 release.

Tried it on my C64C. It works great on a real C64 with joystick in port 2 :)

Sheep enters a high risk site

4th November 2011

First of all, it was quite an embarrassing bug fixing session, due to the fact that I tried so much to try and fix a problem with the platform jumping issue, which Shaun pointed out. It turned out that I didn't need update the code by retyping the sprite/background collision detection. It turned out that I had forgotten to reset the timer which controlled the player's jump. How dumb was that huh?

Anyway, I imported the new graphics update of Shaun's into the game code. It looked much better. Shaun also did some very nice in game sprites as well. The sheep now wears a builders/warehouse high risk helmet when in Shield/Invinicibility mode, and the rocket now shows the sheep inside. Once the shield wears out, the loses helmet and is no longer invincible.

Hopefully either tomorrow or Sunday, I will concentrate on updating the enemy attack patterns, according to Shaun's diagram illustrations. Re-enable the sprite/sprite collision and then work on an ending for when the player completes the game. Just under 4 weeks until the deadline. ARGH! Hope I can make it :o(

Clumsy sheepoid.

17th September 2011

No screen shots or videos to show you this time, but I have still been working on Woolly Jumper. It is still sort of shaping up quite nicely, apart from that I came across some design faults in the game. (Go on, blame the coder). It turned out that the sinus mode which I originally used for the game wasn't all that good. The sinus was all over the place. That's not what we really want for a game don't you agree?. Well the good news is that I have renewed the sinus movement for the aliens, and after they get shot - they will disappear as they should (and not reappear on screen).

The second issue was the background. When the player jumps out of the screen, it seems to mysteriously die outside the border. This was quite a weird thing that was going on. I do have to admit. Anyway to resolve this problem I lowered the border jump height. So that no collision's made up there.

The next issue was that I programmed the lives and sprite/sprite collision. The sheep has too much on it's plate (Thanks for pointing this out Shaun) where the enemies appear on screen frequently. Oh dear :( We don't really want that to happen do we?. So I have come to a decision to add a delay/timer before letting loose the next batch of aliens. This will give the player chance to jump over platforms on to the next one. To make the player die. I added a little routine which made the sheep jump to the top of the screen, then fall into the water. The basic idea is to have an amusing frame, for where the sheep goes up, then add a splash sprite to make it look as if it had jumped into the water. I also did some jingles where one made the sheep scream if hit, then a splash sound for when it ends up in the water.

One final issue which I spotted, but pointed it out to Shaun, was a mapping fault. Basically the platforms were too far from each other in parts of the map, making it virtually impossible for the poor sheep to jump over. I also noticed a silly bug today in which killed the sheep when on top of the shaded area of the platform where the meat hooks hang. That will be simple enough to fix. Simply locate the charset number

I also had two .D64's from Shaun, featuring his new sprites for the game. So I loaded up the Sideways SEUCK (As Shaun used this to make them) and attached the .D64 with (what was meant to have been) the source files. Sadly I could not get those to load. It turned out that the disk image was corrupt as the file name ended with a *PRG inside the disk directory. This is known as a splat file. Perhaps the .D64 wasn't detached from VICE before I received it. Anyway I received the latest disk with the sprites. Those were Power Ups, alien species and of course the player animations. Looks absolutely great :) I will be looking forward to the final sprites :)

The Cyber Sheep are coming

Friday 7th January 2011

Laser Zone. What a classic game that was for the Commodore 64. It's quite a memorable little Arcade classic, which was on a compilation of crazy and really fun games, called "Yak's Progress" by Llamasoft. After playing Laser Zone, I came up with a nice idea for a tribute game. The game's name is Sheepoid, and last night I was just playing around with some raster splits and experimenting. Okay, so no game yet, but I ended up building a front end for the production instead. Probably a wrong move.

Anyway about the game. Laser Zone had two satellites in which had to blast aliens that appeared on screen before they reached to right or bottom surface and captured one of the satellites. The plan for "Sheepoid" is pretty much similar, except for that the game will have some differences. The starting levels may be quite similar, but the actual game itself will have some differences in attack waves - causing this game to be more zany and psychedelic than before. Instead of satellites, the player will be controlling laser powered sheep. Also instead of a small screen area being used. The sprites will use expanded positions. Therefore the game area's going to be pretty much big.

The official release date of this game is not really known as there's quite a bit of work to do, but I doubt that it'll take longer than 2 months or so. I will not be rushing on this game for a sake of a quick release, as there is seriously no point in rushing it for a sake of a quick release. Hmm. :)

When the game is finished, it will feature a variety of different aliens/psychedelic objects to battle against, wacky sound effects, bizarre get ready , level complete, life lost, game over messages, a possibility of an end sequence. Plus a nice looking psychedelic IRQ tape loader system as well. The final production will be uploaded on to my web site at: http://tnd64.unikat.sk.