Monday, 25 December 2017

It's Christmas ... Time to Follow that Starfysh

25th December 2017
 
First of all, Merry Christmas (Happy Birthday to me ;o)) and a Happy New Year. This will be my final Blog for 2017, and I have decided to talk about the production of my LATEST game release Starfysh. This is basically a horizontal scrolling shoot 'em up - which is not a SEUCK game, although I have released some enhanced SEUCK titles as well today.



Starfysh is a simple 4-level scrolling game, in which Earth has been severly damaged by an alien battle. Humans and dogs have been transported on to rescue stations. The stations are now being attacked by aliens. You are a commander of the Starfysh Elite. Your mission is simply to battle through 4 different zones, fighting the aliens. After you reach the end of one stage, you'll move on to the next. This game has no particular power ups, but it was inspired a little on some classic games like Hewson's Subterranea, and Mastertronic's Star Slayer. The player can be controlled using a joystick plugged into port 2. That's the fun part. Now for the production notes:

Programming

The game was programmed using C64Studio, while I had a lot of free time spare between October - November in the evenings, and weekends (Excluding Sundays). The game consists of only 4 different maps which are quite large and caused me to play around with moving data to different areas of memory. 256 tiles in fact. All levels were transformed from bitmap format to charpad, using the map importing option. At first there were some technical problems. There were too many tiles and chars. I wanted a limit of 256 tiles/chars. The tile + charset compression option was a very good help.

Graphics and Design
 
I managed to fit 3 levels in, but adding the fourth stage was really challenging.  Each level was squeezed down using the Exomizer level/memory compression mode (exomizer.exe -l mem $xxxx source.prg -o dest.prg. The example decompression source was used to extract the compressed graphics source. (Charset, tile set and map).

Before I had the game sprites by Shaun, I created some test sprites of my own (Which were created in Sprite Pad, and then imported into the C64Studio source code). The sprites later got imported into my little weekend SEUCK project 'Space Crumpets' (Along with test sprites for Cruiser X-79, which I also drew ages ago). Creating the sprites wasn't much of a problem, but moving them was quite a challenge. I could have used the Alien Formation maker, which I wrote about a year ago, but I didn't want to make this another X-Force type of game. Instead, I worked hard on programming sprite movement patterns, based on timing and sense of direction. Some aliens will just move across the screen, but some aliens will move in a different formation. Also, unlike X-Force, I added alien firing. I also wanted to do something different to the game. The player should have a shield at the start of the game, or every time a life is lost. Shaun came up with an idea, which was to create a damage count before the penultimate death for the player.

Shaun did some new sprites for the game. The sprites were designed and created using the Shoot Em Up Construction Kit. Shaun used this editor for sense of a purpose (Not for creating a SEUCK game this time). The sprites were imported inside sprite pad. Sprite animation had separate subroutines to animate at different speed. Shaun's sprite example in SEUCK had to be followed. This was so that I could match the actual speed of the alien sprites.

Designing the front end with logo and scroll text was pretty much straight forward. Shaun sent me some bitmap mockups, and I was able to port them to C64 charset and screen format, using CharPad. This helped me a lot, however the title screen data had to be split into two separate charsets. The reason being was that manually creating the HUD design was a really difficult and painful task. I had to find a way to cheat and save time doing this. So I captured first the text charset snapshot, which included the HUD design. Then I capatured the main title screen presentation mockup. I imported all of the graphics assets into the source code, and programmed a new front end, and a working score panel, which uses the HUD. EXCELLENT!



Music

Sound and Music was done using GoatTracker V2.7. The in game music style was slightly inspired by some tunes from the demo scene in the very late 1980's - early 1990's (The Dutch USA Music Assembler/Voicetracker era). This time round I didn't want to make any techno/trance music. I wanted to try a different style. The title music was a slight remix of one of my older tracks, I originally composed in the 2000 year. (Space Techno I think it may have been called). I made the remixed title tune sound more disco style, rather than techno. For the up scroll ending music, I went for an epic space ending theme.  Sound effects were also created using Goat Tracker.


Mastering (Tape+Disk)

The final mastering of the production. Before I could do that I asked Shaun if he was able to make a loading picture. He suggested that I contacted JonEgg. I spoken to JonEgg and asked if he was interested to draw the loading pic, JonEgg was. However Shaun drew me a temporary loading picture for the mastering - also just in case there was no loading picture at all.



I decided to do the first master, using my pre-built C64 tool 'Tape Master Pro V3.0'. Before I could do that I imported the assets 'Loading music', 'Shaun's picture' and game, and used a black screen with thin dark blue loading stripes scheme. This was Shaun's suggestion. A good result. However, when I was on the 1541Ultimate 2 page, I discovered that someone else used Tape Master Pro V3.0, on a C64 game, but the loader caused a few problems. I contacted Martin Piper to find out, and he introduced me to a new version of TapeToolBuild.

I had to recreate the tape loader using the TapeToolBuild source in scrollermusicloader.a as the source code had no ability to display a loading picture or use any additional code I would have wanted it. So I re-programmed some of the features from the Tape Master Pro V3.0 tape loader (The flashing text, scroll text, picture display and PRESS SPACE option). I also created my own source files to import/relocate the game and picture data through a PC. Also a custom loading stripes scheme. The result turned out how I wanted it.

The disk loader was pretty much straightforward. I used the exact same loader as I did for Let's Invade (A Space Invaders game, which I wrote last year). I placed a loading picture and music for Starfysh into the game. Bolted a TND intro before the loader. I chosen the latest intro I created earlier on this year (Rippled Dreams), and added a brand new tune to the intro. I imported the main game and used Excess' Dir Master V7.1 in VICE to change the load address of the main game to $2000.


Eventually I received an email from JonEgg, which he attached a new loading picture for the game. I loved it. :). This replaced Shaun's loading picture, but I felt that Shaun's pic should still be used. So I made a timed splash screen which quickly display's Shaun's pic and run i through the Exomizer.  Not a bad result.



I showed the Disk + Tape version of the game. He suggested that the disk version should have loading stripes. He wanted dark blue loading stripes. I tried implementing this feature into the .D64 version of the game. Sadly adding the function to the IRQ loading code LDA #$06 : STA $D020 : LDA #$00 : STA $D020 caused the Exomizer decruncher to crash instead of decrunch. Instead I replaced the border flash with INC $D020 and DEC $D020. That made a huge difference and the program worked absolutely fine. :)


Starfysh can be found and downloaded on to your C64 1541Ultimate2, Turbo Chameleon, CCS64, VICE or whatever at:

THE NEW DIMENSION - GAMES PAGE - STARFYSH

other presents (new releases) can be found at:

 THE NEW DIMENSION




Also, to support SDIEC users, the game has a kernal loading option (With stripes), but you still will be able to listen to the loading music after loading has finished.

MERRY CHRISTMAS, Enjoy the presents, see you in 2018 and have a HAPPY NEW YEAR!

Saturday, 7 October 2017

Cruiser X-79 Update #12

7th October 2017

This is a just a quick update. You may remember a couple of days ago, I mentioned about having trouble getting the tape loader to work using multi-load, and  the game crashed. I finally managed to get my way around this problem, simply by not triggering RTS after the loader had finished loading a file. Of course, I had to edit the game code, where RTS was originally called for setting up new levels. This was replaced with a jump start to the main game code. I also implemented the same code with the disk multi loader.

The tape turbo code also needed a slight altering, so that it could switch off the tape motor, call Exomizer to level-decrunch the program file loaded, then call a subroutine to check whether or not all files have loaded. If so, then jump to the main game code, otherwise keep on loading the level graphics data (Charset, tile set, map) until all 3 files have loaded in and run through Exomizer's decruncher. Thankfully, it all worked.

Now Cruiser X-79 can have digital disk and tape versions. :)

Thursday, 5 October 2017

Cruiser X-79 [UPDATE 11] - Not much ... Or is it?

5th October 2017

I really should have back dated this Friday+Saturday last week, as nothing had been done today. I've been running late. Anyway, last week, I was doing some brain storming, and slight of hand updating of the game code.

Originally Cruiser X-79 used a 3xIRQ interrupt, but since that was just UNECESSARY, I decided to reduce it to a 2xinterrupt instead. Reason being fixing the smooth scrolling, so that it could scroll smoothly.

Other implementations which had taken place last week was related to access to levels. The size of the game map 320 blocks in height. That is way too much for one file - even compressed. Now imaging having to pack 16 levels and try to cram that into a single file? Not really possible, due to the memory restrictions.





In order to solve this problem, I decided to implement a disk load subroutine, along with the Exomizer level decruncher. Each file to decrunch has to be a game character set, tile set and also a map. To make the level packing more simpler, I decided to create a project in Endurion's excellent C64Studio suite, and call Exomizer to compress each level file, and then import the files on to a .D64.Then I set up the file names, low + hi-byte of the END address of the program for Exomizer to decrunch. At first I had crashes, probably due to some silly mistakes I made into the code. After several attempts the code worked, and a working game / preview was in place. Brilliant.

This may sound as if the game is turning out to be disk only? Well, not necessary. I had a bash at making a 2-sided tape version of the game with TapeToolBuildV2, and my modified  version of Martin's source. Where after loading the game with picture and music. The front end comes on, then a message on screen should prompt the user to flip tape to side 2 and rewind (Or in .tap form, simply eject side 1 or the tap file, and then start side 2  - Since I use 1541Ultimate more than a tape - in order to reduce loading programs and finding load errors :D ).

Although this felt like a great idea. I had to disect Martin Piper's turbo loader system, through his source. So I created a second source, which made two loads for each file. Basically, the idea is to load a test pilot $0200-$0240, then load in the selected charset/tile/map file. After each file has loaded, the loader should point the end low/byte address to the decrunch address. Then call the loader again, another two times, then after the last decrunch. Run the game. Sadly this didn't work for me. The turbo did load the data to the correct end address, and the low/hi byte of the end address, did get stored to the correct self-mod decrunch from address of Exomizer. However, instead of actually running the decruncher, after loading (Where I added an RTS at the end of the loader (The loader is mean't to be a subroutine), the program crashed completely with a CPU JAM. I will need to investigate further into this issue. The test disk version loads fine. I'll let you know how I progress through making a .tap version of my game.

Saturday, 19 August 2017

Cruiser X-79 - Update #10

19th August 2017

More action has been taking place today. First of all, Saul suggested that I should reduce the animation speed for the aliens and also the explosion. Basically double the delay of the animation. Also I had a go at setting up level pointers, where after each level advances, the game sets up the next level settings. For example, pick out the chosen alien type, formation, level colour scheme, etc. I tried compressing a test level map, using Exomizer, then imported it into the source code 16 times, to set each level. Sadly this trick didn't work and caused a memory overflow.

In order to solve this issue. I have decided to make this game multi-load based. This means that after 1 level is complete, the disk or tape image should load the next game file.There is just not enough memory for me to place even 8 level compressed versions of test maps that exceed $0300 bytes (Compressed). I will make sure disk loading will also be SDIEC compatible as well. Tape version is intended to be mastered using Freeload or the Thunderload Multi-Load companion tool.

You will notice a slight difference in the game during this test video of cheat mode below.  :)

Friday, 18 August 2017

Cruiser X-79 Update #9

13th - 18th August 2017

Not much happened on the game programming front, but at least I made an effort to do something for the production. While I was away from this project for a few weeks or so, I recently received some new graphics for the game. It wasn't more levels, but graphics for a new front end. Saul Cross designed a great new logo for the title screen. So what happened this week? I programmed a front end and bolted it to the game, itself. Hope you like the result.

While I am waiting for the new level maps, I will be working on the order of alien attack patterns according to levels, and of course re-use the test level's map and setup different colour schemes for each level. Each alien attack pattern consists of 26 bytes, so hopefully I should have enough memory to store compressed levels of each map, then extract each level to address $4800-$5800 (since $5800 is the start address of the game's code). Each level should not exceed 320 4x4 blocks in height, as at the end of the 320th block row a level complete is automatically detected. :)

For now, here's the result of the title screen - although it is not official at the moment :) Enjoy the video.





Saturday, 24 June 2017

Cruiser X-79 - Update #8

20th-24th June 2017

It has been too hot this week, apart from yesterday and today. Despite the really hot UK weather I had recently, still that hasn't stopped  me from doing more on this game project. Quite a big update as well.

So then what has been happening this time round. For a start off I continued from a couple of weeks ago. This was where code was based on sprite / background collision. I originally worked on a subroutine where the player crashed should it hit a deadly character. Now this time I focused on the player bullet shooting to deadly background. I tried doing the bullet/background table read method, but that didn't quite work out. There were times where the player bullet kept on missing the deadly background and the bullet just flew over. A bit of additional hard work was required to this. I created a large listing to compare to a certain character to the bullet object position. If the central bullet reaches the deadly background, the bullet will disappear. Thus allowing the player to fire again. After testing this phase, things looked much better.

The next step was to do a little something different. I worked on the new title music for the game, using GoatTracker. I was unable to combine the title music with the other sounds, as there was a memory overlap. So I trimmed out the title music and placed it into a separate position and put it in the temporary preview title screen. I also programmed built in option where using a joystick in port 2 selects the sound mode (Music + SFX, Music Only, SFX Only, Silence).

Today I have been working on fixing some of the bugs in the game, and also adding some additional sprites. The sprites which represented Game Over and Stage Complete. In the stage complete phase, the player ship is automatically central before the Level Complete message appears on screen. During the player moving or the game over scene, all sprites get switched off, then after fitting the Game Over, Well Done screen, only 2 sprites are switched on.

The main game had some problems with the alien formation test. There were aliens that appeared incorrectly on screen while moving. I had forgotten to update offset code to reset the formation counter, so that aliens started in the correct position. After trying the game out, things looked very promising indeed. That was until, I came across the camel head aliens. They were flickering everywhere instead of using a proper formation. I managed to fix this problem by updating the low+hi byte tables for alien formation and properties. I tested the whole thing again and things looked a whole lot better.

As my final task today. I took a look at IRQ source code and tried to implement some subroutines. Reason being - The aliens and laser sprites were still visible over the black raster, that covers the scrolling background. In order to fix this problem, I altered the background colour to black (So no grey raster line could be seen). Then after that, a new subroutine was added to mask existing sprites as blank sprites. The trick worked, and the result was pretty good - although there is a minor glitch inside the score panel raster. It flickers for a split millisecond, but all in all, the game is playable.

Still no selected alien formation for each level yet, but that will be happening some time soon. Enjoy the latest video of what has been resulted this week.


Sunday, 11 June 2017

Cruiser X-79 Update #7

11th June 2017

Not much time has been spent on this project this week, due to other things, but at least I did put some of my commitment into this game project today. I did have a long weekend, but I have been working on some stuff for the demo scene, also been learning a bit of Unity PC Game development . This won't stop me from continuing C64 game projects. Anyway what has been happening today.

Although it doesn't really sound like much. In fact a lot of work was put into the game code. A new sprite/background collision had to be made, which corresponded to the player's bullet. The idea is basically to allow the player to shoot certain background objects in order to destroy them and score a few more points.

I used a similar approach to the player/background collision, but this time assigned the player bullet's central area to the background object. Should the centre of the player's bullet hit the background object, it should destroy it. I added a few JSR statements to check which background the bullet sprite should read, and then generated a subroutine which transformed the 4 chars of the background into a destroyed object. The player can shoot and destroy shutters, parked ships, stripey buildings and also the glass domes.

This is called by assigning a row+column into a zeropage, check the char co-ords and the char value of the zero page, then modify the charset to an actual new value.

See you Saturday next week (Hopefully) with another blog update to this project, where I update the bullet sprite/background settings to remove the bullet every time it fires at a high deadly background, and maybe setup the first level attack waves.