Jim's heart will go on demo goes on...

[Kurt_Woloch]

Since in the last days, I made several attempts of telling everybody what kind of games could be possible in a 2600 kernel and what wouldn't be able to work (see the Bombjack, Bomberman and Smurf's Rescue in Gargamel's Castle threads), I somehow "wanted to know better", so I decided to pick up an old project I started back in 1998, the "Jim's heart will go on demo".

 

This was discussed in length on the Stella mailing list (back then, I did have e-mail access at my working place, but no Internet browser), but I want to recapture the main points for everyone who wasn't around back then...

 

1. The game was leaning towards the Nintendo Game & Watch game "Lifeboat"

2. The basic game mechanics are as follows:

A ship is sinking (the Titanic maybe?). People are jumping off board, hoping to land in a lifeboat which you direct. You have to place your lifeboat in order to catch the falling people. Since the boat only holds 4 people, you have to row to the left or right cliff in order to release the people in your boat. If you don't manage to catch people, they land in the water, and you get a second chance of picking them up from there. But hurry up! A shark circles the waters around your boat, and you have to get to the people swimming in the water before the shark gets to them and eats them.

 

Now, back in 1998, I managed to get something working... you saw a screen with the sinking ship, and some music is playing which you probably know as it was a huge hit back in 1998. However, you couldn't do anything besides watching the ship sink and listening to the music.

 

And here's the improved version. I've taken the next step and included some men jumping ship. However, the game doesn't offer too much improvement over the previous version. It's especially lacking in the following areas:

 

1. All men look the same, and they aren't animated.

2. All men come down at the same vertical position which shouldn't stay that way. But the repositioning routine isn't yet implemented...

3. The men simply jump into the water and disappear. There is no shark and no lifeboat, which means you still can't do anything.

4. There's a graphical glitch in the display of the men, in that the uppermost line of the men doesn't get displayed in 25% of the cases (that is, if the display starts on a certain one out of every 4 scanlines).

 

To explain what I did...

first I changed the display of the ship by stretching it out across four scanlines...

1. Display PF1 (PF0 doesn't get written to in that part)

2. Display PF2

3. Change foreground color

4. would be a management / repositioning line.

 

Each of the numbers above now happens on one scanline, along with displaying player data. Currently, it's only using player 0. As you can see, I tried to do realistic physics, that is, the falling men speed up as they fall. Theoretically, the program would be able to display a fair number of men underneath each other, though in this version no more than two appear at any time. This is limited by the fact that due to my programming constraints, there have to be at least 4 empty scanlines between one copy of player 0 and the next one. This could be changed, however... I've set the timing of the spawning men to about the fastest rate possible under those constraints. A bit faster, and a newly appearing man wouldn't leave enough free scanlines until the one below him gets displayed.

I'm still wondering if I should support the display of 2 men on one scanline or not. Technically, it should be possible in a 1-line kernal the way I've laid out the remaining writes now. The tricky part would be determining which player to use for the next man to display, and which one needs repositioning.

 

Anyway... I've attached the current version for you to enjoy. In this message, you'll find a BIN, a screenshot of the current version and a mockup picture I've drawn on paper back in 1998 which should show how the finished game is supposed to look like. Would you also be interested in the source code?

 

Anway... This is the binary. It's 4K at the moment, though only about 640 bytes get used up by data, and another 650 bytes by program code, so that's 1290 bytes, or 31,5% of the space available in a 4K cart.

 

ship7919.bin

 

This is a screenshot of the current version running...

 

 

And this is the hand-drawn mockup picture.

 

 

I know I "rounded" the score display at the top, and the man jumping down upside-down in that picture obviously is too large... it's higher than a row of windows, which means the men would have to duck to fit into their cabins! I think a size of 12 scanlines would be about right. Currently, the men are 8 scanlines high, but that could be expanded... however, maybe this would make using a 2nd player necessary...

 

Other than that, I think the mockup picture shows a bit of what I have in mind... the cliffs would be displayed at the bottom of the ship using PF0... the men in the boat would be 2 players which both get repeated... the boat itself would be a quadruple-width player (to leave the other player for a falling man), and at the bottom you see the shark and a man chased by it... the shark would be a double-wide player, and the other player would depict the man swimming from the shark.

 

What's especially important for me in that game is:

1. The display should be colorful

2. All players and sprites should use a 1-line kernel (however, the background graphics don't have to)

3. The movement of the sprites should be smooth (unlike games like DigDug, where the objects jump up and down in steps of several pixels, and games like Spacechase where they jump left and right in the same manner)

4. The difficulty should ramp up rather smoothly, not doing harsh jumps from level to level.

 

I don't know what I'll include next... maybe I'll try to include the cliffs, or get it on in the order of things appearing on screen. We'll see...

[PressureCooker2600]

Alright........more homebrews are always good.

 

And the graphics look awesome if ya ask me.

[Atariboy2600]

wow by the look of that shark on the bottom of that art work screen its amost like one of thouse Nintendo Game & Watch Parachute where you have to save them before they fall into the water^^

[Steril707]

For me it's a little bit unintentionally funny, this build i mean... Al these people jumping like lemmings into water, nobody there to save them...Alltogether with Celine Dions song.

 

And, good work, Kurt... Keep on, i am really looking forward to the finished version...

[+Nathan Strum]

Very nice start!

 

I agree that it's pretty funny - people jumping ship to get away from Celine Dion.

 

For the reflections of the ship in the water, it'd be great if you could do something like the Go Fish! title screen.

[Kurt_Woloch]

wow by the look of that shark on the bottom of that art work screen its amost like one of thouse Nintendo Game & Watch Parachute where you have to save them before they fall into the water^^

 

Yes, I thought of that too this morning... actually, the play mechanics of "Parachute" and "Lifeboat" are rather similar... but there still are differences:

- In "Lifeboat", you can move your boat into one of 6 positions (2 for letting people get out, 4 for catching them), while in Parachute, there are only 3

- In "Lifeboat", the men don't fall for that long (I think only 4 or 5 positions), while the parachuters have a longer trail

- In "Lifeboat" you have to let the people get out of your boat while in "Parachute" they just disappear if you catch them

- In "Parachute", in Game B parachuters in the rightmost line can get caught in a tree and free themselves after some swinging (which is dangerous because when they get free they're just one or two positions above your boat).

 

For me it's a little bit unintentionally funny, this build i mean... Al these people jumping like lemmings into water, nobody there to save them...Alltogether with Celine Dions song.

 

Yes... the Lemmings analogy isn't bad... especially since they all jump in one straight line one after each other.

 

Very nice start!

 

I agree that it's pretty funny - people jumping ship to get away from Celine Dion.

 

For the reflections of the ship in the water, it'd be great if you could do something like the Go Fish! title screen.

 

To GET AWAY from Celine Dion? That's a pretty new point...

 

As for the reflections of the ship in the water, I'm afraid they will have to be removed entirely. If you look at my fake screenshot, they're not to be seen there because that would take an additional color register which I don't have - the playfield graphics on those scanlines will get used for the cliffs on the sides, which are brown, and the two players and their colors get used for displaying the men in the boat and the boat itself (with one player left for a man falling into the water due to missing the boat). So, sorry, but the reflections will probably have to be sacrificed...

[Kurt_Woloch]

OK, here's another build... unfortunately, it's a bit faulty one. I tried myself at horizontal repositioning, and basically it works... but the results don't look too clean. I also redesigned the falling men... the ones displayed here are a bit higher (11 instead of 8 scanlines) and come in different clothes. In the end, I plan including multiple different possible men... maybe some of them will only appear in later levels.

This build is a bit "dirty" in that the top pixels of the men don't always get displayed due to timing constraints, which come from needing more lines for repositioning players.

Aside from that, I increased the height of the men to 11 pixels which seems to fit the proportions of the ship. The RMS Titanic had a draught of 10.5 m. If we calculate 6 scanlines to roughly be 1 meter, a man height of 10-11 pixels seems to be about right, and the ship draught would be 63 pixels. This, however, is the part of the ship under the waterline. Abover the waterline, it currently has 68 pixels at the most erected position, which would equal 11.3 meters. Wikipedia, unfortunately, only gives the draught, not the height above the waterline, but seen in proportion it still seems to be about right.

I also increased the acceleration of the men which I initially miscalculated. The new one is by about 300% higher than the old one, and is physically correct. This, however, means that a falling men hits the water surface in about one and a half second, which isn't much time to catch it. Therefore, I plan to (at least in the lower levels) have the men appear in their positions a few seconds before they jump off. This time, of course, should decrease with each level, and maybe also during a level. I'm pretty sure that at the rate they're coming out now, they can't reasonably be caught. :-)

Anyway, I've started to completely rewrite the kernel because the current kernel only supports one player, and it should support two... maybe it's not necessary to have them in the upper rows of the screen, but in those scanlines where the boat and people sitting in it appear, we definitely need two players to display them.

However, I figured that things might get pretty tight here... we have to do 5 writes in a line, and they have to be all finished by pixel 17, which is when the ship starts drawing. The player data even should be finished earlier because both players theoretically could appear at the leftmost row.

However, I think I found a way around this problem by moving some writes to the previous line. So, the new kernal probably will look something like this:

 

	LDA (MenGraphicsPointer0),X	;5 cycles
STA GRP0	
LDA (MenColorsPointer0),X
STA WSYNC
STA COLUP0
LDA (MenGraphicsPointer1),X
STA GRP1
LDA (MenColorsPointer1),X
STA COLUP1
LDA ForeColor,Y
STA COLUPF

 

This would be the code of one line, after which comes some deciding and branching. The trick is to activate VDEL of player 0 so that its player graphics actually doesn't change until GRP1 gets rewritten. The sequence above uses the first 28 cycles of a line and 12 more somewhere before that... which means it ends at 84 - 68 = 16 pixels into the line, which is exactly what we need. We only need to take care that none of the writes after the WSYNC occurs later than it does in this sequence.

We need 44 cycles for the sequence stated above (including the WSYNC), so that leaves 32 cycles per line to do some deciding and checking.

I'll see what I can do with that... I plan to do a rather complex kernel, where basically several different versions exist depending on which of the players are displayed and what else happens. This is because I don't have much time to decide in each scanline whether to display player 0 and 1 or not. We'll see if this is practical or not. Theoretically I could also do something like this...

 

 

	LDA DisplayPlayer0
               BNE NoDisplay0_1
               LDA (ManGraphicsPointer0),X
NoDisplay0_1:                
               STA GRP0
               LDA DisplayPlayer1
               BNE NoDisplay1_1
               LDA (MenGraphicsPointer1),X
NoDisplay1_1:
               STA WSYNC
STA GRP1
LDA (MenColorsPointer0),X
STA COLUP0
LDA (MenColorsPointer1),X
STA COLUP1
LDA ForeColor,Y
STA COLUPF

 

However, this needs 10 additional cycles, so we only would have 22 left for deciding and checking. We'll see how it turns out...

the next version I plan will probably display the currently 2 possible men by using both players and do the repositioning off-screen, providing no provision for on-screen repositioning, which will get re-inserted later, since it's rather tricky... we have to reposition player 1 while still displaying player 0 and vice-versa. But it will bring me closer to what I actually want to achieve... I only haven't got the time to complete it today.

 

 

ship7924.bin

[Impaler_26]

Nice stuff! I'm looking forward to see this develop into a game!

 

Keep up the good work!