34 replies to this topic

[yuppicide]

Oh I'm not saying to hide it. I'm just saying if a friend came over and you plugged it into a system, they wouldn't be able to tell.

jrok, on Wed Jul 8, 2009 4:27 PM, said:

yuppicide, on Wed Jul 8, 2009 4:07 PM, said:

My advice is that when you're done you have a high res title screen done up in ASM. Then nobody for sure will know this is done in bB. Or maybe you're craftier than me and can do something tricky in bB.

Thanks, but I wouldn't want to hide the fact that this was made with batariBasic. I mean, at the very least batari deserves credit for making 2600 programming so accessible and fun for guys like us, you know? If I ever completed and sold this, I'd put "bB" on the box.

[yuppicide]

Latest version is nice. With version #1 I scored 1650. With the newest my score was 1900.

[djmips]

I like your game. Very cool and imaginative. I really like blue skies in a game. The scrolling hillside is very Atari.
Nice horse animation.

[yuppicide]

Is it me or do you have no "icing on your cake" in reference to playfield colors? How did you do that or maybe they're just arranged in a way that I can't tell?

[yuppicide]

I really have to learn multisprite stuff. So far everything I did involves only two sprites on the screen at the same time. I'm taking those castles are drawn with sprites are are the numbers showing how close the dragon is.

Heck, I can't even get sounds to work in my game. You seem to work out everything nicely. My sounds never sound like I envision them to be.

[jrok]

yuppicide, on Thu Jul 9, 2009 9:04 AM, said:

Is it me or do you have no "icing on your cake" in reference to playfield colors? How did you do that or maybe they're just arranged in a way that I can't tell?

I'm not sure what you mean by "icing", but the color rows are a background color table, although it has some limitations. See here for more info.

yuppicide, on Thu Jul 9, 2009 9:44 PM, said:

I really have to learn multisprite stuff. So far everything I did involves only two sprites on the screen at the same time. I'm taking those castles are drawn with sprites are are the numbers showing how close the dragon is.

The castles/mountains are virtual player 3, the dragons/numbers are virtual player 4, the enemy knight is virtual player 2 and the magic arrow is virtual player one. The knight and the dragonfire altternate player0 (when they are both on the screen). Virtual player 5 is unassigned while I make some decisions about what to do with it. Batari's multisprite kernel is really great and I highly recommend you experiment with it.

[Random Terrain]

jrok, on Thu Jul 9, 2009 9:58 PM, said:

I'm not sure what you mean by "icing" . . .

He's talking about this:

http://www.atariage....howtopic=125144

[Nati]

So what's the progress so far?

[jrok]

Nati, on Wed Aug 12, 2009 6:45 PM, said:

So what's the progress so far?

I forgot to update this thread, I guess. Below was the latest update from the Homebrew Forum (although, I 've done some additional changes since this)

Quote

I've been able to squeeze a bit more out of the standard RAM, so I'm trying to expand the depth of gameplay here a bit. There are a couple of different directions this project could go in, so I'm a little curious to hear some feedback on some of these ideas from people who are playing the game. Some of these are already implemented, but I won't post the changes until they are fully debugged.

1. Foot Soldiers

These are mostly implemented right now, and will be a part of the next build I post. This is an alternate enemy ground unit; Essentially the weaker, more prevalent sibling of the Knight. They travel more slowly then the Knight, and are easier to hit. Each successful hit diminishes their rank by one (25 pts) until there are no soldiers left. A dead center hit, however, wipes out the entire unit with a single strike for bonus points (150pts) and a temporary speed boost in the direction you are moving.

Over time, I had the thought that an alternate, stronger Soldier variant might begin to appear who can lay siege to castles and eventually overtake them. Unlike a destroyed castle, Enemy Castles will erect walls that impede your movement around the kingdom and release a powerful Wizard who must be destroyed to free the castle.


2. Castle Repair and Upgrade
This is partially implemented right now. At the start of play, each castle has 18 hit points which diminish to zero as they are hit with dragonfire. In between waves, each castle automatically recieves 4 hit points of repair (during which a little contextual tune plays letting you know how the kingdom is doing overall.) This counts for destroyed castles as well, which are ressurected and restored to four hit points. If you protect your castles well in a round, even destroyed castles can eventually be restored to abundant health.

Here's the part that isn't implemented, but that I'm partial towards experimenting with. Although Castles begin at 18 health, they will continue to add health between rounds, even if their total hit points exceed 18. However, when a Castle reaches a ceiling of 30 hit points, it is automatically upgraded to one of four possible "Super" Castle types:

The Monastery

This castle type functions as a sort of "gas station" for the Knight's health bar, gradually healing his wounds while the sprite is touching it.

The Ballista

This castle attempts to wound/kill any nearby dragons with a giant crossbow.

The Fort

This castle has special fortifications that shield your knight from incoming dragonfire when positioned near it.

The Wizard's Tower

This castle will teleport your knight to within a screen length of a dragon when the sprite is touching it and the player presses the fire button.
EDT: Teleport the knight to any position in the kingdon. Touch the knight to the castle, press and hold the fire button, then move left or right to rapidly scroll the screen in either direction. Release the fire button to teleport to that position.

Like normal castles, these will gain health between levels, but if they drop below the 30 hit point ceiling, they will revert to standard castle forms. This sort of system might add a layer of strategic depth to the game, particularly in the later levels when you will have to make snap decisions about which castle to defend. I am still unsure if I can steer multiple dragons without the aid of the SARA chip, but I am fairly confident I could implement something like this within the standard RAM limit.

Right now, the biggest struggle for me is smoothly clearing copied sprites in both directions (one direction works quite well, though, which I am now using in my SMB-style platformer). I've implemented a few powerups as well, but I really don't think I'll post another binary until I have the sprite clearing running very smoothly.

J

[Tempy]

jrok, on Mon Jun 29, 2009 12:59 PM, said:

I've made some decent progress over the past week. Thanks to batari's help, I am now coloring the background rows. This helps in the sense that with a slightly larger viewable battlefield, the player will have a bit more time to react before he is steamrolled by a dragon or a knight careening in from one side of the screen.

So how were you able to do different colored background rows in the multisprite kernel?

Edit: Ah nevermind, I found your thread

Edited by Tempy, Sun Jan 10, 2010 6:45 PM.