"Sierra Maestra", an Early WIP

[vidak]

Hey! This is my first game. Please find attached my first 2 hours of work. I basically took some code from Kirk Israel's intro and changed it to make a simple yellow revolutionary move around the screen.

 

This is a game about the guerrilla war that lead to the socialist Cuban Revolution. I'm a Communist, so I thought I'd made a game about communism!

 

Most of the game is like "Snake or Surround with guns". You have a squad of revolutionaries who follow you in a line. There is an overworld where just Che Guevara walks around, and then when you touch a Fascist Batista soldier, you enter into the "snake/surround battle mode". It's a bit like Zelda 2. Zelda 2 had an overworld with randomly generated monster icons, and when you hit them you went into a side-on battle environment.

 

I have to figure out how to draw a "snake" like in Surround, except having it at a set length. Surround just drew a continuous line, I want a line of a set length on the screen.

 

I figured should have something to show, so I modified Kirk Israel's code to draw a little revolutionary Che moving around on the screen. I have to figure out how to draw different lines of colour. I now realise I can't draw multiple different colours on a single line without great difficulty. I suppose you could consider the little Che graphic to be "concept art".

 

This is a big step for me, I've been wanting to do this for a long, long time!

 

PS. I believe in open source / free software / the GNU movement, so I will always release my source code. Even for the finished game.

 

 

***************************

• Quick skill tester game to determine the initial strength of your revolutionary forces
• Your guerrillas follow you in a line, and the length of the line is determined by the skill tester
  • OR the guerrillas could be displayed as icons on a panel on the bottom of the screen

• You’ve now landed on a beach. You need to avoid detection. This is a stealth mini-game. You need to sneak past Batista’s soldiers combing the beach. You have three grenades you can use to stun guards and sneak past them. It is a maze.
• Next you must attract a peasant guide. There will be several screens you can traipse through, and you will come across a randomly generated number of peasants. Each peasant you come across will have a randomly generated level of sympathy for you.
  • Most peasants will not trust you, and will transform into a group of Batista soldiers you need to run away from. The soldiers will chase you until you run through three screens. You can use grenades to slow their path.
  • The number of revolutionaries you have with you will determine the average level of sympathy peasants will have for you. This is just a guide. The lower the number of revolutionaries you have, the more erratic the distribution of sympathy will be among the peasants.
  • Peasants will be coloured according to their sympathies. The more red their colour, the more sympathetic. The more brown, the more likely they will be to be an informant.
  • There will be randomly generated groups of Batista soldiers in the mountains, and these soldiers you can defeat. If any kind of Batista soldier touches you, you will lose HP on your guerrillas. Each guerrilla has 3 HP.
    • If you touch a group of roaming Batista soldiers, you enter another skill tester game.
    • Your number of guerrillas will face off against the randomly generated number of soldiers.
    • You face off as two snaking single-file lines of soldiers. The point of the game is to shoot the other line of soldiers starting from the end of the line. The soldiers snake from the top to the bottom of the screen, and then snake around the screen. You can move your line of guerrillas anywhere around the screen, and you shoot in the direction you last moved.
    • When you shoot the end of a line of soldiers, they break off the line and then fire at you when you enter their 90 degree field of vision.
    • There will most likely be anywhere from 3 to 5 soldiers.
    • Once you have separated all the snaking Batista soldiers, you enter a new phase and must grenade them. Once they are grenaded they disappear and you re-enter the jungle.
    • Each soldier you have has 3 HP. If they get hit they turn progressively black, and when they lose all their HP they drop off your line, and it becomes one soldier shorter.
    • If you lose all your soldiers in this mini game, you are returned to the jungle with one of your soldiers having lost 1 HP
    • If you manage to beat all the Batista soldiers, you have the chance to recruit a new revolutionary from the jungle.
• The lower down the mountain range, the more Batista soldiers. The distribution of peasants will be even, however.
• A peasant with high affinity will lead you right to the other side of the Sierra Maestra, to the next battle, the Battle of Las Platas
• A peasant with a low amount of affinity will take you part of the way there before ditching you. There will be an animation showing the peasant guide ditching you, and returning you back to the Jungle, where you must repeat the process of finding a new guide.
  
  
• THE BATTLE OF LAS PLATAS
  • This will be like a tower defence game.
  • There will be three waves.
  • First wave: three snake/lines of Batista soldiers. Second wave: three snakes, then two snakes shortly afterwards. Third wave: A very strong/thick snake that takes three times as much damage.
  • Defeating a snake of soldiers will add bonus guerrilla sentries.
  • INCOMPLETE. MORE TO BE ADDED.

guerrilla.bin

guerrilla.asm

[StanJr]

I like your game play concept. I am curious to see how this develops and to see how much of it you can implement on the VCS.

[TheHoboInYourRoom]

Neat! Interested to see where you'll go with this.

[vidak]

Could someone explain to me how to change the colours of a GRPX line by line?

 

I assume the kernel would set the colour of the GRPX before STA GRPX-ing it?

[TheHoboInYourRoom]

You can set the color by writing to COLUPx any time you like. To avoid the appearance of "shearing" in the colors, you would set the color before the leftmost position the player could occupy.

[vidak]

Ah rad! That makes total sense.

 

I'm actually thinking of using an old kernel from the 90s made by Piero Cavina - the "multi-sprite kernel".

 

Or I could just study it first. I feel like I'm getting the concept of how 2600 games are meant to work.

 

The kernel is the display "kernel" of the entire game, and you construct your game around it.

[Thomas Jentzsch]

The kernel is the display "kernel" of the entire game, and you construct your game around it.

Exactly.

[Jinroh]

Sounds like a fun game, and interesting gameplay mechanics mashed up. I'm liking the design of the soldiers too. :3

[vidak]

Thanks!!

Going through the Stella Mailing List has introduced me to many useful kernels, so I'm sure there's something I can adapt for the situation.

 

I'm obsessed with the game Commando, and I really want the jungle of the Sierra Maestra to look very similar to the desert in that game.

 

The screens won't scroll though, but I still feel like attempting a disassembly so I can work out how to draw trees with such a high resolution.

[vidak]

here's a disassembly of commando!!!

HAPPY DAYS

 

http://atariage.com/forums/topic/195381-commando-only-3-levels-mistake-remedy/?p=2520899

[vidak]

Since I have returned to coding after doing quite a bit of work on my thesis, I have started going through the kernel of Commando and commenting it.

 

It uses the SBC #15 and lookup table method of horizontal positioning.

[vidak]

Okay, good news and frustrating news.

 

Good News

I have learned how to write to the playfield. I am equal parts indebted to Kirk Israel, SpiceWare, and Andrew Davie.

 

See attached the screenshot of the small program I wrote to write 192 lines of the PF1 portion SpiceWare's first Arena in Collect.

 

I also attached the source code. I think there may be some small errors in it, but I'm very happy that I was able to achieve some sort of result.

 

So I now know how to write player graphics and playfield graphics to the screen.

 

Frustrating News

 

Commando is far far too complex for me to disassemble. What I really want to know by looking into Commando was not:

 

1. How to scroll the screen
2. How to animate the characters

Because Collect already shows you how to do that. What I wanted to know out of Commando was how to change the colour of the player graphics line by line. But after actually looking through Random Terrain and looking at Andrew Davie's Programming for Newbies, I can see that you just need to load the colour of the graphics in before you start writing the player graphics. You could store the player's colour in a table and point to it with a pointer.

 

Things Yet to Do

 

My first goal is to get a quick demo of Che Guevara running around in the jungle. A lot of the graphics in Commando are quite nice and I will take them and mutilate them into something like looks like the Cuban jungle in the mountains. That's my immediate goal.

 

I hope to have some sort of kernel which can display trees with different lines of colour, and a little Player0 Che Guevara who can run around them.

 

Anyway this is my update!

playfield_basic.asm

[JeremiahK]

This is a promising project! Looks like you've done a lot of work on the story of the game.

Edited November 11, 2017 by JeremiahK

[vidak]

Hahaha yeah - I basically read a biography of Che Guevara, so I know how the guerrilla war against the fascist Batista dictatorship went in the late 1950s.

 

I'm working on a new kernel now. This one is a version of SpiceWare's DoDraw kernel, except it can draw differently coloured playfield and player graphics, line by line.

 

I'll show a bit of the code here:

; Priming of Player0 graphics here before we enter the first scanline of the screen.

	
PFLoop:
        sta WSYNC
;---------------------------------
        stx COLUP0              ; 3  3
        sta GRP0                ; 3  6 (Needs to be updated @0-22)

	lda #PL0_HEIGHT-1	; 2  8
	dcp Player0Draw		; 5 13
	bcs DoDrawGRP0		; 2 15 - (3 16)
	lda #0			; 2 17
	.byte $2C		; 4 21

DoDrawGRP0:			;   16
	lda (Player0Ptr),y	; 5 21
        ldx (Player0Clr),y      ; 5 27
	dey                     
	bne PFLoop

I haven't tested whether this works yet, but I feel like it might. I think I may have to make the kernel a Two Line Kernel in order to make sure I can draw the Playfield, Player0, and Player1 not just in terms of their graphics, but in terms of their line-by-line colour.

 

The problem I have with this kernel is that the ".byte $2C" trick only skips the VERY NEXT instruction, which loads the player graphics from the pointer. The instruction to load the colour of the graphics will still be loaded. I think this will not be a huge problem because if we are writing #0 to the player0 graphics anyway, there will be no player0 graphics to colour.

 

Still, this is not an optimal solution, but I think it still might have to do.

Edited November 11, 2017 by vidak

[vidak]

I'm a little bit stuck.

 

I'm attempting to write a kernel for the "mountain climbing" part of the game.

 

I am attempting to write a kernel that can do multi-coloured playfields, and multi-coloured players. There will only be 2 Player0 and Player1.

 

My problem is that I'm running out of cycles. I have only completed up until halfway through Line 1 of this 2LK, but I end up updating PF0 by cycle 23, which is too late.

 

This is how I want to update the 2LK. I want to draw the Playfield every line, but the Players and Missiles every other line:

• Priming routine: CALCULATE Player0 (Graphics and Colour), CALCULATE Missile0, CALCULATE Playfield (Colour)

• Line1: DRAW Player0, Missile0, and Playfield (Graphics); CALCULATE Player1 (Graphics and Colour), CALCULATE MISSILE, CALCULATE Playfield (Colour).
• Line2: DRAW Player1, Missile1, and Playfield (Graphics); CALCULATE Player0 (Graphics and Colour), CALCULATE Missile0, CALCULATE Playfield (Colour).

My main issue is that SpiceWare's Collect tutorial uses the Y register to hold the scanline index, and I need to use 2 variables as indexes in order to draw the Playfield at a single-line resolution, and the Player graphics at a 2-line resolution, offset with VDELPX.

 

Should I give up drawing the playfield at a single-line resolution? Or is there a better way to draw the playfield? I'd like to have some nice jungle trees at a single-line resolution, but I'm not against giving that up.

 

Please find attached my source code.

coloured_guerrilla.asm

Edited November 21, 2017 by vidak

[vidak]

More work today. First off: you can't use indirect indexed addressing with the X register (hah).

 

I wrote out a huge post here but I accidentally hit the "delete tab" hotkey. I have decided to sacrifice having single-line resolution for the playfield graphics. I don't think it's possible to have a multi-coloured, asymmetrical playfield with single line resolution anyway. That said I'm not sure if my playfield actually is at 2-line resolution because it's drawn over 2 lines. I can't actually tell if it's single or 2 line resolution.

 

I'll attach the source code of what I've got so far.

 

What I've managed to achieve is a rough first draft of the 2 Line Kernel.

 

Feel free to have a look.

 

I haven't updated all the cycle counts.

 

The main issue is that drawing a multi-coloured GRPX and a multi-coloured playfield at the same time is difficult. I want to use the playfield to draw trees and environments.

 

I am currently too slow by a matter of one or two cycles loading the Left PF0 after loading the multi-coloured player graphics.

 

I think I have a few options:

 

• Don't make Player1 multi-coloured. I would have to make the NPCs with Player1 all one colour.
• Change the left hand border of the screen, and make the horizontal width of the screen smaller. (EDIT: This actually won't work, you MUST load PF0 before cycle 22, you can't load it later and expect it just to draw less)
• Draw PF0 before I draw the Player1 graphics, and stop the Player1 graphics from ever reaching the left hand side of the screen

I am still experimenting with whether I should load the playfield graphics in on the first line of the screen. I think I'll have to sacrifice that because it's making the stub-beginning of Line 2 at the top too slow to calculate the Missile1 and Player1 graphics.

 

What I COULD do is copy the use of Player graphics for trees like in Halo 2600. I could place the player graphics in strategic locations. The problem with this is that I really like the trees in the 2600 Commando, and I'm pretty sure they're drawn with playfield graphics. I'm not experienced enough to disassemble Commando, so I'm not sure whether my guess is correct.

Anyway I made good progress today.

coloured_guerrilla002.asm

[vidak]

1. I think the trees in Commando are drawn with player graphics
2. I think I have found more interesting pieces of the Commando kernel since I last looked at it.
   1. I think my skills have developed since last looking through the source code of Commando, I may understand more of it now.

[TheHoboInYourRoom]

• I think the trees in Commando are drawn with player graphics

Indeed they are.

[vidak]

Gosh! How did you do that? Is that using Stella?

 

I am very confused as to how it's able to draw so many sprites at once.

 

I suppose I better run Stella in debug mode to have a look at the kernel.

[TheHoboInYourRoom]

That's the fixed debug color mode, toggled with Alt-comma in Windows and Linux or Cmd-comma in OS X. It ignores the values sent to the color registers and colors the objects according to which objects they are.

I haven't looked at Commando's code, but my first guess is that it probably uses a list of sprite IDs to set pointers to graphics and color tables, along with a list of horizontal positions to move things to (note the long strip of HMOVE bars on the left).

[vidak]

I still haven't quite mastered HMOVE. I guess I should go through the Stella Mailing List.

 

What's happening on this first frame is that this is a reflected playfield.

 

Those two mounds close together are PF2 reflected, and the bottom ones are PF1.

 

The two trees at the bottom are NUSIZ x 2 copies with WIDE spacing.

 

I think here are different mini-kernels for each layer of the screen. A different routine in the kernel is drawing the two copied palm trees down the bottom.

[vidak]

ALSO I think the game may be "cheating".

 

It MAY be that the kernel is drawing the colours of the enemies (blue) even when there aren't any. This leads me to believe that the enemies appear in "bands" as the game scrolls.

 

So the enemies move up and down a little bit, but they're actually confined to bands on the screen. I just played the game and I think I can confirm this. This is very interesting.

 

I am still curious as to how the game is drawing both the P1 sprite of the player and the P1 sprite of the palm trees.

 

It seems as if there is a whole number of NOPs at the same horizontal position as the player character is drawn on the screen. I wonder what this means...

[vidak]

Sorry to keep spamming this: but I think I've figured it out.

 

The player character is GRP0, and the palm trees and enemies are GRP1.

 

The palm trees are never on the same band as the enemies. There are distinct bands of the screen that scroll, and the enemies are never drawn in the same band as the palm trees.

 

That's the solution.

 

If you wanted to recreate this game, you'd basically need a kernel that draws bands of objects.

[+TwentySixHundred]

Really like the backstory and you're progress so far. I have noticed you're writing this in asm which is also a impressive feat in itself. Will be watching how your game grows and cant wait to test thought the process.

[vidak]

Can I ask for some help?

 

I'm having some trouble conceptualising how I draw Player1 a second or third time down the screen with different graphics.

 

Would this require branching out of the kernel?

 

How would I set up the Y position offset? Do I change the offset after drawing a previous Player1?

 

What I want to do is something like this:

DRAW PLAYER0 THROUGHOUT THE WHOLE SCREEN

BAND 1-----------------------------

   GRP1 -- ENEMY GRAPHICS

BAND 2-----------------------------

   GRP1 -- TREE GRAPHICS

BAND 3-----------------------------

   GRP1 -- TREE GRAPHICS, 2 COPY MEDIUM SPACING

END SCREEN-------------------------

How do I write a kernel that draws 1 or 2 lines repeatedly, but changes the Player1 graphics for multiple bands of graphics down the screen?