Let me at 'em!

4th November 2012

It's been a small session on Amazon Tales today, but the game engine's getting around quite well although pretty slowly. I feel I should commit a lot of free time on this during the upcoming 3 weeks or so, due to the deadline for the RGCD 16KB cartridge game competition, which is looming closer, and closer. Since last week's major problems. 

So then what was done today? You may ask. Well, for a start off, now that I am aware of the correct table settings I decided to do two things today. Well, actually 3 things. First of all, I wanted to make the game feel pretty fair - regarding the enemies, when they are on screen. I wanted to check to see whether or not a sprite had left the screen. If it did then it is classed as an offset. I created a few pointers to check whether any enemies are not offset. If not all enemies are offset, then they can move. However, if all enemies are offset, the next group of enemies come on screen. Basically, I check to see if the X position (even when enemies are inside the border) equal the end area - they are classed as being offset. I also had to update the enemy movement routine by stripping out the small loop, and expanding the code. Mainly for setting the offset values per enemy's X-position.

Purple rainforest - Getting darker as your progress

Finally, we wanted to get more of a game feeling to this project, so I worked on the sprite/sprite collision settings. For now, I used the usual box collision routine (as I don't know the pixel perfect collision very well). I typed in the collision routine for each enemy (as this will be expanded later on for scoring points). Where if a bullet hits an enemy object, that enemy will be off the screen. Also for now, I repositioned the bullet as well. So nothing special is happening at the moment. Hopefully when the death animation is set some time later on this week. We'll have more of a game. :)

Table of Errors!

1st November 2012

What a day! A stupid one in fact for Amazon Tales. Last week I spent hours setting up the low byte and high byte pointers of the data tables. Unfortunately when I was doing more programming to get the routines to work. It was just a plain waste of time. After completing the routines to set the low and high byte of the level table to read. The enemy sprites were all over the place, and enemies had their mind of their own. I tried different methods, and was totally fed up and decided to have my lunch. Looks like I'm really going to be stuck on this problem. 

After fuelling myself with some ham sarnies and a cup of tea, I was still concerned about the problem in the program. I went back upstairs to find out if I could solve this issue. I looked at the code, and thought carefully to myself. THIS IS BOGUS - THIS CODE DOESN'T WORK AND THERE IS NO NEED FOR THAT ROUTINE. DOH!. There has to be a more simpler way to get the sprites working according to level. Well, a solution came up. I should have done that in the first place. How embarrassing ;o). I solved the problem, simply by removing the low byte/hi byte tables for each level, and just reproduced the same level table for level 1 - it also saved a bit of memory as well. I also set the enemy pointer values to read 126 bytes from each table. It is now up to me to put new sprite pointers/objects into different tables. (21 bytes x 6 levels per table).

When I progress further adding more varied enemies to the game this Saturday, I might be able to snip the table down even more. Hopefully next week I should be ready to add sprite/sprite collision, and also a small routine that will not cycle through the the next batch of enemies. Until all enemy sprites are offset. :)

A bit of polish and a few balls as well.

9th-10th September 2012

The BETA Testing of Trance Sector took place over the weekend. The game felt really good, but sadly the game required polishing. The good news is that not much work is required for the game. In fact, only a tiny bit of work was required - I actually got started on the polishing of the game this morning, two hours before I set off to work 12pm-8pm. So what were the problems that were pointed out:

First of all, one job was done yesterday. My beta testers spotted a minor bug with the high score name entry routine. The first problem was that after pressing fire on the game over screen a letter 'A' was already stored on the name for the first character. This was because of the Game Over routine forgetting to 'refresh' the fire button routine. Using fire button detection without refreshing the values to zero can make the control very sensitive. Secondly was the name entry itself. I forgot to reset the last character with the first character and vice-versa, depending on which character was detected. I quickly fixed both of those routines and tested it to ensure it worked right.

More improvements were being made today. Both BETA testers pointed out that the game can be off putting to the audience. If on each level the player lost a life, they would have to start the game all over again. I was quite reluctant to not have the player start all over again. Considering last week when I was testing the levels in cheat mode - I was really frustrated trying to complete some of the levels, although found it to be possible at the end. Since both Frank and Vinny pointed out the same issue, I updated the code to make sure the game screen didn't reset after a life was lost. It didn't require much code one bit. A simple reposition and re-spawn of all sprites per life lost. I also had to update levels 7,9 and 24 - repacked them all and - success.

I wanted to improve something else in the code, which I just had time to do. So I dug out the game character set in Cuniform and I drew 5 1x2 ball characters, with EXTRA inside each ball. Then I stripped the charset size and imported it into the game source. Then I altered the EXTRA routine so that the balls were dark blue (rather than green), but they are still white after one of the letters get picked up from the bonus ball object.

Now it was time to go to work - and maybe work on polishing the explosion sprite positions for the ending screen. Then hopefully final BETA testing this coming weekend.

Trance Sector - Continues

15th May 2012 

This week I decided to work more on the game graphics for Trance Sector I wasn't too sure what to draw the game levels with as I didn't want to experience another crash with MSCK. Funnily enough, I found that Charpad was unsuitable to build the levels, because putting the level objects (as single screens) was more difficult. Plus the type of tiles would have been too limited. So instead, I worked on MSCK V2.0 and hoping this time the program won't crash. I managed to rebuild the objects, opened my mind, and built 20 levels. That was Yesterday of course.I even did a new title screen, according to what was written on my little note pad, when I attended RetroVision 2012 Saturday, last week.

Today I worked on installing the new game graphics library into the game's source code, and updated the amount of pods for the player to collect. I even tested the whole game, hoping the library source wouldn't crash. Thankfully it didn't crash. After the 20 levels were fitted in to the code, nicely (Apart from some shield tiles which haven't been programmed yet) I tested through the whole game and found no problems. After I was happy with this, I worked on an ending tune using GoatTracker. Then I ported the music data to the game again. I tried to do some in game sound effects for Trance Sector using GoatTracker, but there were delays before a sound effect played. I think I should program my own sound effects instead, like I did with Sub Hunter and Sheepoid instead. It might be more helpful ;)

The last part of the day was programming the new title screen for the game. In which looks completely different to how I normally program a front end. I usually program a front end using a plain black screen with a logo on the top of the screen, with flashing text, and a scroll text at the bottom. That's nothing unusual. Instead, I decided to work on a more epic title screen, in which displays 1x1 char bricks forming the name Trance Sector on the screen, an upward scrolling ticker tape routine (Like Monty on the Run) inside the window, and also a sprite scrolling message at the bottom of the screen. I was unable to open the borders because for some reason, it kept flickering and delaying when the sprite was there ... So I left it out for the time being. The new title screen looks retro and hopefully the gamers will like it as well. :) 

More work on the game tomorrow or Wednesday. Well I have another 44 levels to build up, and probably add some brand new tiles as well, such as seeker switches. Also to get the shield working as well  ;)

Here comes Mario :)

5th June 2011

It's official. Mario is coming to the Commodore 64. Okay, I fibbed there. I bet that caught you attention huh? Well, I guess so, who else would be reading this? So then, I have a week off work this week (as I have to use up ALL my annual leave before 30th June 2011). I decided to work on a brand new game project, which should hopefully be a free download from my web site once finished and tested.

This time round it's a new genre puzzle game (or probably not new) for the good old Commodore 64 called "Pipe Pressure" (Probably would sound a lot better if it was called "Pressure Pipe". You decide for yourself :o)). The concept is a very simple concept, which could probably become an addictive puzzler if all goes to plan. The idea I come up is a very simple concept and was sort of an inspiration from those PC flash games you tend to get on line.

Anyway, the concept is pretty much straight forward. (Yawn). When you start the game, a series of four balls of a different colour will appear on to the screen for a few seconds. You must then memorize what colour balls should go into which pipe (indicated with arrows). Then you get to play the game. You have to race against the clock to get 40 correct coloured balls into the pipes within a certain time limit. To increase the confusion. There will be additionally different coloured balls appearing. If none of those match the ones which you had to memorize. The user would have to throw those into the disposal chute at the bottom (simply by pressing the fire button). To make the game idea more confusing if a wrong ball ends up in the disposal chute, or a wrong ball enters the pipe. A life will be lost. At the moment, it is planned to have 10 levels, but if I find that 10's not enough, then levels can increase later on in the game. Tomorrow, I shall work on the game's graphics. Then maybe later on, I shall program the game.