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.

A week of disaster

20th - 24th November 2012

Over the week or so. The enemy movement patterns were being worked on. I thought that things were looking pretty good for this part of the project. Unfortunately I ended up getting myself completely lost with the enemy tables, and their behavior. I programmed a routine to allow certain enemies to shoot, according to their behavior table. The shooting turned into a big disaster. Wrong enemies were shooting, and on level 3 the enemy tables didn't work right. Perhaps I missed entering one or two of the values of the element for one of the enemies. Because of this fault the entire enemy table turned into a complete disaster.

I was hoping to get a 16KB cartridge version of the game finished this week in time for RGCD's 16KB cartridge competition. Unfortunately the overall result turned sour. Therefore, due to lack of time - because of work. I have made a decision that I shall withdraw my entry from the competition I am aware that it is very easy to fix, but it unfortunately takes a long time to process. The enemy tables will have to be restarted from scratch. That will probably take another 2 weeks. I am still determined to get this game finished, but sadly not in time for the RGCD cartridge compo.

Update 25/11/2012
After the success of fixing the problem with the enemy shooting, and nearly past the half way mark with this project. There is a positive side that there could actually be an RGCD 2012 entry of this game. I think it is possible that some of the elements will have to be ignored for the game, until after the competition entry has been submitted. Additional elements such as a high score table, a decent ending, etc. will have to wait longer. 

You Cheeky Monkey

15th-19th November 2012

Despite having less free time last week, I've gained more free time this week in the mornings, before my 12-8 shifts (Friday 10-6). I still have Thursday and Saturday free. Last week through to today I have been working really hard on setting the enemy movement pattern for the game.Mainly by creating byte tables to represent the enemy object type, start position (X and Y), movement speed, direction and their proposed behavior patterns. 

So far I have gone as far as the beginning of level 2 - but other levels seem to be somewhat shorter to play - but those will be a lot harder. Especially when I add the mean deadly spiders into that stage. So hopefully as soon as all enemies are in place, I can start getting them to shoot and have more of a proper game by next week.

Today, I added a new enemy to the second level. Take a guess what that one is? ... That's right it's a cheeky monkey. My target is to get all enemies in place by Friday, (I have all day Thursday and Saturday this week). I can work on the shooting tactics for the enemies, and also add some additional game play and a quick front end. Sadly it looks as if the game will not be 100% finished for the RGCD game compo, but who knows what could happen next week?

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.

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