jrok

Castles are the dragon's first priority. But as I wrote in the Hints portion of the first-post, "Dragons are primarily concerned with destroying your Castles, but with a little coaxing you can lure them away with your Paladin, and get them to come after him instead." Dragons search for Castles when spawned. They see one screen to the east and one screen to the west, and if either of those screens (or the screen they are on) contain a Castle, that becomes their target. However, if any of those three screens also contain you, the dragon may choose you as the target instead. If you are chasing it and it is wounded, it will sometimes try to escape and then reset its target. So from your description, it's sounds like the dragons are working fine to me.

Playing with a joystick. Didn't realize it fired on release though. The momentum of the paladins speed when traveling also makes it challenging to shoot. So I think a possible straight shot variation wouldn't be too easy and still challenging. The problem with straight-shot is that you have to be directly beneath the dragon to hit it This is troublesome for a few reasons. For one thing, when you are moving at top speed, it's possible that the dragon will vanish off-screen to the left or right before its hit animation even gets a chance to play. Also, in later rounds the angled shot comes in handy, since the faster dragons move as fast as your horse moves at full gallop, and their columns of flame move much faster, too. So, if the shot is going directly up, you'll have to gallop directly under the path of their fire to hurt them. That seems wrong to me, and I have much more fun trying to draw a bead on those faster guys by galloping a few paces behind them, and I have a bit more reaction time to steer out of the path of their fire. So it's not just there for added challenge. Right now they can move downwards so that only their heads are poking up above the road. They can still hurt you if you run into them down there, but you can't hurt them because you can't line your lance up with their center. If that's really happening, then it's a bug I haven't come across. During the Repair Phase (while the wave number is on the screen), the enemies are moving, but they aren't attacking anything. The Knights and Grendels cannot hurt you during this period of time (you'll pass right through them on the Road), the Soldiers move but do not attack the Castles, and there are no Dragons in the sky. Can you be more specific, or double-check to make sure you're really being attacked/hurt while the wave number is still on the screen? Castles start with 20 hit points and can have up to 40 hit points. When their hit points are between 20 and 40, they look like this. When they are reduced below 20, each attack sinks them further into the ground, until only the flag is visible. After that, it is completely destroyed and becomes a flaming ruin. At the end of a wave, the flames are put out and you'll just see white smoke rising from the ruin. This means it can be rebuilt if you complete the current wave. Try sticking around on a screen with a partially sunken Castle or a smoking Castle when the wave is changing. After the tune plays, you hear rumbling sounds and see the Castle rise up by eight pixels.

That's part of the strategy, actually. It's a tad more realistic then shooting an arrow straight up, and encourages the player to stay in motion and anticipate the dragon's movements. I suppose I could put in a variant on the difficulty switches that changes the angle of the shot, but that would require some additional RAM and cycles, so I'll table that one for the final build, if I have any leftover resources. I agree that the arrows arching kinda like the stones in No Escape does add to the challenge and is welcome for the most part. The frustration comes mostly from when you are trying to hit the soldiers. Shooting them can be very frustrating since they are so much closer and the arrow arcs right away, I often find myself constantly going back and forth constantly just trying to hit one. Out of curiosity, are you playing with a keyboard or joystick. One thing to remember is the the arrow fires when you "release" the button, not when you press it. If it helps, think of it like pressing the button down draws the bow, and releasing the button releases the string. The Grendels are different from the Knights in a few ways, but I think I might differentiate them even more for the final release:

I guess I'm torn about this, because in some ways even a moment or two of invincibility after a hit might spoil the challenge. Maybe if there was just a little more predictability to what would happen after a hit, so you could take calculated risks (and maybe even calculated bounce damage?) Right now it feels a little bit random in terms of what happens in the wake of a hit.

If you have time, maybe you could collect the info and put it in a new thread. Then I could link to your new thread from the bB page. I actually think there *is* a thread dealing with this, but the AA search engine has always been resistant to my wiles. It's hard as hell to find old threads (probably some of which is owing to how big the batari basic section has become). Ironically, the closest I could find was another thread I started where I... asked where to find the topic! But in that one, SeaGTGruff offers a great explanation of how it works, including an outline of the way sprite data is stored and retrieved in general. Here's that thread: http://www.atariage.com/forums/topic/161923-help-with-ram-sprites/page__p__1996145__hl__ram+sprite__fromsearch__1#entry1996145

Thanks! I've never played Repton, but what I've seen of it looks very cool. I'm a big fan of games with multiple simultaneous goals.

If you need a character that is wider than 8 pixels, you use two sprites. If it just needs to be taller, you only need to use one sprite (unless you want to do some kind of crazy animation where the top part and bottom part need totally separate animations that can't be done with one sprite). That can be done with one sprite, if you store the sprite's shape data in RAM. With each sprite line stored in RAM, you can change individual lines using traditional 'if-then' and 'on' statements. I was doing something like that in Circus Galacticus, storing the shape and color data for P0 in the Superchip RAM. I'll see if I can dig up the relevant posts.

Thanks, man. I personally think it needs a lot more polish, especially when it comes scoring and bonuses, but all this feedback is invaluable for figuring out what's fun and not-so-fun about the gameplay. Hoping to add a bit more distinctiveness for the enemies and waves, too, so that players can expect to see new things the farther they get. The world feels about the right size to me too (although I wish there were a way to multiplex P0 so I could have more scenery objects to scroll! ) I agree about the bats, and am working on a new element to replace them. I'll be sure to update this thread when I have something test-worthy. Cheers, J

The sound effects need a lot of work IMO. I took some shortcuts with them, just so I could press on with other things. I really need to make the Soldier's attack sound and the explosion sound of a castle being hit more recognizable before I have a release version. Hopefully making the sound effects more distinguishable will help players adapt more quickly. The one part about this that makes me worry is that the moment one dragon dies and a new one is spawned is supposed to be sort of intense, since the new dragon's location is random and it begins it's attack hidden in the clouds. Not sure if anyone noticed, but when you first discover a dragon it "emerges" from the sky with a gradual wipe. While it's still hidden it does a lot more damage to Castles than normal, which is supposed to press you to find it before you do anything else (I guess it would help if I added this to the doc in first post ) You weren't happy with the way it looked or weren't happy with it all together? I think it looked fine and was simple enough to serve it's purpose. I would definitely like to see it come back and don't mind the loss of the bats, but I do think the soldiers should try to be kept. Btw, I haven't really noticed, can they hurt you? I wasn't very happy with either, I guess. It seemed redundant, since you had the numerical indicator to show exactly how far a dragon was from your position, and it was pretty flickery. If batari ever adds support for pfheights to the new kernel, I might try adding a simplified version to the top of the screen, but I'm still not sure it's all that useful or that it fits with the game's theme. I'll check. It's been awhile since I tested any older versions, but I'm sure they were buggy. Cheers, J

Played this new demo for the first time tonight, and here's my thoughts. General concept and execution is top notch. It looks great and controls well, with great character and enemy sprites/animation and a nice colorful playfield. Jousting on the road gives me a little trouble, but I'm sure it won't be a problem with a little more practice on my part. I particularly liked how the foot soldiers became skeletons as I progressed, and the larger dragon appears. For what it's worth, though, I don't care for the bats. They don't look terribly interesting, don't do much, and just disappear when they die. The dragons and foot soldiers are all well designed and animated, noticeably attack the castles, and have death animations. I would axe the bats to add something, whether it's the fabled princess or not. I'm ok with only one dragon at a time for the sake of more enemies types. First run through got me to the 5th wave. Thanks for the input. I think I'll ditch the bats, and find something else to do with those resources. I guess my main worry was that the player might feel like they were wandering around in empty space too much. Maybe making the world smaller (6 wide instead of 9) might help that a little. Cheers, J

Well, that's interesting. I didn't think of designing a game for deaf players (even though I am partially deaf myself). I do think it could be pretty easily explained through text though, and that maybe explanation isn't really that necessary in the first place (in real life, when you are closer to a sound's source, it sounds louder, right?) But these are definitely interesting things to think about. Maybe I could add a visual clue that shows which direction the sound is coming from, similar to the lance icon for road enemies? In some ways, this DPC version is a completely different game, which is why I started a new thread for it. I don't think of myself as some great game designer or anything like that. I'm just a hobbyist, like a lot of other guys here. But I think the main idea behind the original game and this one was to create a Williams-like "protection" game that split the player's focus between action in the sky and the ground, with a good risk-bonus mechanic to award brave risk-takers and scoring strategists. My main hope was to preserve and expand that with this version, while reducing some of the flicker that plagued the original version. That said, it's interesting how many aspects of the older version people seem to like that I was never very happy with. For instance, I was never very happy with the radar display. I mostly did it because the limitations of that kernel left me with not very many options for using the ball and missiles (at least, not in terms of the gameplay I imagined.) I guess if players though it was really critical, I could think of ways to bring it back. For example, if I sacrifice the bat and the soldier, I could probably cobble together an HUD radar from their sprites. Or if batari is able to include a pfheights option with the DPC kernel, I could probably create a radar from the playfield. I guess it's all about sacrifices.

Thanks for all the feedback, Legend. Well, I guess the short answer is that "radar" has been replaced with "sonar." I thought it was a bit of overkill to have radar to track one aerial enemy in a world with only three castles that was only 9 screens wide. I also think it made the display a little busy and drew the eye away from the action too much. Instead of a flickery radar, the player can now listen to the sounds of Dragon fire and the ringing sound of the Soldier's sword to track their positions. The closer you are to the enemy, the louder its sound becomes. There are different sounds to indicate different attacks, and even a sound to indicate when dragonfire hits a castle. I haven't seen those sorts of audio clues in many Atari games, so I think it's sort of unique. The longer answer is that certain RAM and ROM tradeoffs I made to create the radar display in the old version aren't as viable in the DPC+ kernel. I would probably have to sacrifice a chunk of gameplay to do it, and with a smaller world and a lone enemy to track, it seems like overkill. I agree that they are a little undercooked right now. I added them in almost as an afterthought before posting the build, since the world sometimes felt a little empty. But they don't really change or increase the challenge over the course of the game in their current form. I'm using almost 2 bytes of RAM for them right now (a full byte to track their world location and four bits to track alive/dead, hit location, flight direction, and bats remaining), so I could always scrap them and beef up one of the other characters. Maybe I could alternate between bats and soldiers, with only one or the other appearing at a time, and just use one bit to determine which enemy type is spawned after death? If that was the case, I could potentially make bats more interesting, and more of a threat without spending more valuable RAM. I believe in the build I posted, you meet your first Grendel in wave 5, and your first Wizard in wave 10. The highest I've been able to make it in this version is wave 18. My idea was this: Castles start the game with 20 hit points. After each stage, they regain 8 hit points, to a maximum of 40. If you are able to protect a Castle well enough for it to reach it's max 40 HP, the little flag on top will be replaced by a Princess, who will function similar to the humans in "Defender." When on a screen with a Princess, instead of attacking with fire the Dragon will attempt to kidnap the Princess and take it to the top of the screen. If successful, the Castle loses 10 HP and reverts to its Flag state. If you shoot the Dragon before it reaches the top, the Princess falls. If you catch her you before she hits the road get a bonus, and if you return her to her Castle you get a second bonus, and the Castle is once again protected from dragonfire. To make this happen, I think I'll minimally need to find persistent RAM to track the following: Princess in Castle (1-3): 3 bits Active Princess (1-3): 3 bits Princess Falling on/off: 1 bit Princess Dies / Princess Caught by Knight: 1 bit Princess returned to Castle: l bit Princess world location: 1 byte I might be able to swap the Bat for this element. I think I might try this in my next build to see how well it works. That's part of the strategy, actually. It's a tad more realistic then shooting an arrow straight up, and encourages the player to stay in motion and anticipate the dragon's movements. I suppose I could put in a variant on the difficulty switches that changes the angle of the shot, but that would require some additional RAM and cycles, so I'll table that one for the final build, if I have any leftover resources. Some of this is doable. The hills were just a pacer sprite (like the castles) resized to quad-wide. The one thing I didn't like about them was that repositioning them at the screen edge was kind of ugly (they had to blink out of sight far from the screen edge to avoid them wrapping to the other side, and I wanted to minimize that in the game.) Without a way to mask the sprite at the screen's edges, larger sprites hurt the illusion of smooth movement around the world IMO. I could try throwing the hills back in, maybe alternating them with the trees. The galloping sound fx might also be possible, as long as they don't interfere with other fx. I'm doing four channels right now, and since they contain pertinent information to gameplay, they'd take priority over galloping whenever they were playing (which are pretty frequently). As for the dragon fire, it was sprite-based in the older version. I'm doing it with the ball now, which I like better for the following reasons: - No flicker when it intersects with the Castles/scenery and soldiers. - Pixel perfect collision with the player Paladin, which is important with the Paladin's revised movement (Paladin is no longer "stuck" in the center of the screen, giving him more critical reaction time when dueling with Knights and Grendels) - Using sprite-based fire would make it impossible for me to have my detailed Paladins, Knights and Grendels. I'm using 30hz flicker already to get that done, so adding another sprite would turn the road into a flickery mess. While I understand that some people liked the old knight graphics better, I'm pretty proud of the new animations and don't want to sacrifice them for better-looking fire. The arrow was also sprite-based in the old version, so again I'm substituting the look of it for less flicker (everything the arrow passed by would flicker). Personally, I feel like less-flicker is more important. Thanks again! J

Well, like I said, I'm not sure how to change the missile's color, since COLUM0 doesn't seem to work quite yet (for instance, in the sample I uploaded, I set the color to $48, but it still displays zero/black). But even if it becomes possible in future bB builds, the sky changes LUM over the course of the game (midday, twilight, night, dawn, morning), so I might have to spend RAM to alter the missile color to match well with the sky. I didn't realize it was such a big problem, but I don't have access to a Harmony, so I can't see how the missiles look on real gear.

I can do this: ex_rapid_fire_scrolling_while_moving_thick_2011y_08m_10d_2119t.bin Instead of shooting up just thin lines, you'd be shooting up thin lines with a long-ish tail. Is that better or worse? I like it!

Well, I guess the main reason is that the sprite can't have a value higher than 165, and that if a terrain sprite wraps around the edge, you'll see a tree where a building is supposed to be and vice versa before the sprite shape updates. I'm thinking about just blanking them whenever they are within sixteen pixels of the right edge and maybe velocity+1 of the left edge to reduce the jumpiness, but I'm not sure if there is any way around it. It would be nice if they could be bitmasked at the edge, but I don't think that is possible with resized sprites, and the constantly changing velocity might mess it up anyway. You know, I'm not sure. I just tried using batari's COLUM0 designation, but it didn't work the way I expected. It doesn't color the missile above the P0 pointer to the color I chose, but it does seem to make the "black" consistent. Check out the attached binary and let me know if you notice a difference. ChargeDPC_testM0color.bas.bin On the subject of missiles, that was something else I was thinking about. If I sacrificed the Soldier or Bat, I might be able to get two (flickered) arrows on screen at once, meaning the player could fire two shots at a time instead of one. That might make the game easier, but I wonder if it would also make the game more enjoyable?

Well, most of these VCS games are pretty abstract. You could call them "Plasmatronic Inverter Rays" or "Cyanide Canisters" or whatever, and I don't think anyone would mind. Although, I imagine that with a little futzing you could make them longer than they are wide, by drawing a few pf pixels in front of each bullet. It's tough to make 4px look "laser-like" though. I remember with the earlier builds Circus Galacticus when I was still using the playfield to draw the beams, I was always hoping that someone would figure out a way to multiplex the ball, to allow for less-chunky diagonal beams. But either way, I think the playfield works pretty well with a vertical shooter. I thought that was on purpose, to represent the natural meltiness of butter!

Newest version attached. I also updated first-post binary and docs. Added a placeholder title screen using RevEng's kernel. Added "Grendel" road enemy. Requires two well-timed hits to kill, can hide out of range below the road. Added "Bat" air enemy. Each duo of bats in a swarm requires an arrow hit to defeat. Updated Wizard. Wizard casts barrier spell to protect him while dive-bombing (an arrow hit will stop the spell temporarily) New play mechanic: After destroying all air enemies (Dragons, Wizards), player must defeat a road enemy (Knights, Grendels) to advance to next wave. Updated Soldier strength and appearance. Castles can now hold a max of forty hit points. Castle damage is only displayed when hit points are below 20. Scoring is turned off after all air enemies are destroyed, or while at least one of your castles is destroyed. Revised sound effects game-wide. Also added a sound effect for when a castle is being damaged by dragon fire. I think I'm sort of at a crossroads in development. The gameplay feels mostly okay, but I've hit the RAM ceiling and I'm now wondering if I should consider sacrificing some gameplay elements for others. For instance, I don't think I can add the falling Princess mechanics without sacrificing the Bat or the Soldier. Then again, if I sacrificed all three I might be able to add a second simultaneous Dragon in the sky. What do you guys think? ChargeDPC_081011.bin

Thanks. If batari can get rid of the score jitter, maybe this can be turned into some kind of game. You know, the extruder looks a little like a top-down view of a pig's head. Maybe it could shoot truffles??? I haven't experienced the score jitter. Does it happen in emulation?

The excuse for that was that it takes too much power for the Extruder to move and shoot at the same time, so you must stop to fire the butter. The reason for the excuse was that I was getting smeared butter if I let the player move and shoot at the same time: ex_rapid_fire_scrolling_smeared_2011y_08m_10d_1521t.bin But I just remembered that I can use if playfieldpos <> 8 . . . to fix that problem, so I'll put the fixed version where you can move and shoot at the same time in the first post. Works great now.

Nice. It doesn't seem to work when the extruder is in motion, though. Not sure if that's intentional or not. Personally, I like to jiggle my joystick and move around a lot when I'm hosing something down with my butter.

This is great, Fred. Thanks! A couple of questions: * Would it be possible to include support for collisions between missile0/1 and a virtual sprite? * If we aren't using the playfield pixels in our program, is there a way to recover that memory for other uses? * I noticed that when we use the pfscore option, the pfscore2 bits are mirrored on either side of the score. Not sure if this is a bug or not.

I get the following errors when trying to compile the example: C_function 0000 ???? (R ) font 0000 ???? (R ) scorecolor 0000 ???? (R ) player0xcoll 0000 ???? (R ) EDIT: I think it's because I some older modified asm that was being included from my source folder. Haven't figured out which one yet, but when I compiled from a fresh folder with no includes it worked just fine

Why all three? It seems like pfpixel alone would do the trick. Conversion sounds like it would just be a matter of replacing all the "."s with zeros, all the "X"s with ones, then putting that into a data statement. You could get eight rows of pfpixels from each statement, so each array could form a third of your maze. For instance: playfield: XXX..X..X..XXXXXXXXXX..X..X..XXX X.......X......XX......X.......X X.......X......XX......X.......X X..XXXXXXXXXX..XX..XXXXXXXXXX..X X..............................X X..............................X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end ...could be: data MazePiece1 1,1,1,0,0,1,0,0,1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1,0,0,1,0,0,1,1,1, 1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1, 1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1, 1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1,1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1, 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 end You could make a bunch of those, then you could use a byte of RAM to determine which data statement to draw and when. Then use a temp variable to write the data. As a bonus, the screen would have a cool "drawing" effect as the pointer moved through the arrays

What if you just created three binary data arrays for the top, middle and bottom of the maze containing the on/off bit for each playfield pixel in a maze segment, then run a pointer through it that sets on the pfpixel whenever it encountered a "1" (think of the way you might run a pointer through a data statement for music; except instead of singing, this pointer draws pixels). Then, you could randomize the row at which each pointer begins to draw it's segment of the maze. Then once all the drawing is finished you could start the game level.

I am glad to inform you that screen bounces no more! Great! That's a big relief. For a moment there I thought I bit off more than I could chew, and was thinking of scaling back the gameplay. Thank you for all your help testing. Belated "thumbsups" to you and everyone else here who helped me out on this thread.