Charge!

[+SpiceWare]

Do the cycles the ARM code uses correspond solely to changes in sprite registers? Does anyone know if fast-fetch mode possible in the bB DPC kernel?

Wasn't talking about the fast-fetch stuff during the kernel. The ARM code that makes that work runs fast enough that the 6507 isn't aware of anything.

 

In DPCplus_kernel.asm you'll see:

 ; do a callfunction here
lda #255
sta CALLFUNCTION

<after CF>  <--- NOTE this is not really in the file
; copy modified data back (just need first 6 bytes, which is sprite sort data)
ldx #256-19
copyfromfetcherloop

 

the sta CALLFUNCTION triggers custom ARM code. The ARM remembers where it left off (the <after CF>) and then puts a NOP on the data bus. The 6507 sees the NOP and does nothing until the custom ARM code is finished running, at which point the ARM code puts a JMP <after CF> onto the bus (this is because the 6507 thought it was running real code, and thus was advancing where in the ROM it thought it was). The number of NOPs the Atari processes depends on how long the custom ARM code takes to run. What the 6507 on a real Atari sees is this:

 

lda #255
sta CALLFUNCTION
NOP
NOP
...
NOP
JMP <after CF>
ldx #256-19

 

 

Stella doesn't emulate the run-time for the ARM code, so what the 6507 in Stella sees is this:

 

lda #255
sta CALLFUNCTION
ldx #256-19

 

 

As an example, when the speech subroutines in Frantic need to refill the audio buffer, the real 6507 will see 200+ NOPs (about 6 scan lines) while the ARM is filling the buffer. The emulated 6507 sees 0 NOPs.

[jrok]

Do the cycles the ARM code uses correspond solely to changes in sprite registers? Does anyone know if fast-fetch mode possible in the bB DPC kernel?

Wasn't talking about the fast-fetch stuff during the kernel. The ARM code that makes that work runs fast enough that the 6507 isn't aware of anything.

 

In DPCplus_kernel.asm you'll see:

 ; do a callfunction here
lda #255
sta CALLFUNCTION

<after CF>  <--- NOTE this is not really in the file
; copy modified data back (just need first 6 bytes, which is sprite sort data)
ldx #256-19
copyfromfetcherloop

 

the sta CALLFUNCTION triggers custom ARM code. The ARM remembers where it left off (the <after CF>) and then puts a NOP on the data bus. The 6507 sees the NOP and does nothing until the custom ARM code is finished running, at which point the ARM code puts a JMP <after CF> onto the bus (this is because the 6507 thought it was running real code, and thus was advancing where in the ROM it thought it was). The number of NOPs the Atari processes depends on how long the custom ARM code takes to run. What the 6507 on a real Atari sees is this:

 

lda #255
sta CALLFUNCTION
NOP
NOP
...
NOP
JMP <after CF>
ldx #256-19

 

 

Stella doesn't emulate the run-time for the ARM code, so what the 6507 in Stella sees is this:

 

lda #255
sta CALLFUNCTION
ldx #256-19

 

 

As an example, when the speech subroutines in Frantic need to refill the audio buffer, the real 6507 will see 200+ NOPs (about 6 scan lines) while the ARM is filling the buffer. The emulated 6507 sees 0 NOPs.

 

 

Thanks, Spiceware. I think I understand. So, how can I count how many NOPs the 6507 sees at runtime in my program?

[+SpiceWare]

What I do is put the INTIM remaining on screen to show how much time left I have. You can see that in action here:

 

http://www.youtube.com/watch?v=wIrbCsqQEi8

 

The 2-digit hex numbers at the bottom are the time left - VB on the left, OS on the right. If the number ever goes negative (the first digit will be > 8 ) then I ran out of time.

 

You might be able to use the score display in bB to do something similar. I use a compile-time flag to enable/disable the display as I don't normally care to see it.

Edited August 2, 2011 by SpiceWare

[+Philsan]

Thanks, Scumsoft. Yeah, it's possible. I was updating all the virtual p1 x positions during Vblank, so I tried moving that into the main loop. Not sure if it fixed anything, but it's the only thing I could think to do.

 

ChargeDPC_080111.bin

I am glad to inform you that screen bounces no more!

[jrok]

Thanks, Scumsoft. Yeah, it's possible. I was updating all the virtual p1 x positions during Vblank, so I tried moving that into the main loop. Not sure if it fixed anything, but it's the only thing I could think to do.

 

ChargeDPC_080111.bin

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.

[jrok]

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

[+Random Terrain]

Maybe this was asked before, but why do the trees and buildings jump off to the left when they get close to the edge? And is there a way to make your shots a color that is easier to see?

 

The horse looks more real now than it did in the old version. I can't wait to start using these improved sprites.

Edited August 11, 2011 by Random Terrain

[jrok]

Maybe this was asked before, but why do the trees and buildings jump off to the left when they get close to the edge?

 

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.

 

And is there a way to make your shots a color that is easier to see?

 

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?

Edited August 11, 2011 by jrok

[+Random Terrain]

Since the background is made of dark-ish colors, would it be possible to make the missile a lighter color? Maybe try white to start with and see if that's too bright?

[jrok]

Since the background is made of dark-ish colors, would it be possible to make the missile a lighter color? Maybe try white to start with and see if that's too bright?

 

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.

[+Random Terrain]

Well, like I said, I'm not sure how to change the missile's color, since COLUM0 doesn't seem to work quite yet . . .

Oops, I read that part too fast. I hope batari knows about the problem.

[Brian O]

Lookin' good!

 

-B

[Legend]

I finally had the chance to try this newer version of Charge you've been working on. One thing that I really miss from the older version is the little radar type thing at the bottom that let me know where I was. I feel it added a sense of direction and destination. Without it, I feel like I'm just wandering a little aimlessly from side to side and hard to keep track of which castles have been cleared. I also miss the galloping sound fx.

 

Personally I don't think the bats are very interesting or needed. If something had to be taken out in order to make room for something else, I would pick the bats.

 

I haven't run into the Grendel or wizard yet.

 

You mentioned "falling princess". Does that mean you would have to occasionally catch a princess that is falling from a castle or tower or from the dragon's grip in the sky? If so, that sounds like a very fun and interesting addition to gameplay. Maybe the player would get a visual or audio warning that she is about to fall and and react quickly by positioning themselves under her and hitting the fire button at the right moment to catch her?

 

I don't really think being able to fire two arrows on screen at once is needed.

 

The graphics look awesome. But I kinda like how the old version looked better. I liked the hills in the back. The fire that the dragon shot looked cooler. The paladin was more simplistic but still looked good. Even the arrow that the player shot looked better. Talking about Charge! Rev1 in this thread: Charge! (A2600 WIP)

 

Speaking of the arrow, it's kinda a pain to aim now since it curves. Especially when switching directions.

Edited August 11, 2011 by Legend

[+Random Terrain]

The horse looks more real now than it did in the old version. I can't wait to start using these improved sprites.

I just tried the old version again and this new horse is much better, without a doubt. But as posted above, I kind of like some of the things from the older version.

Edited August 11, 2011 by Random Terrain

[jrok]

Thanks for all the feedback, Legend.

 

One thing that I really miss from the older version is the little radar type thing at the bottom that let me know where I was. I feel it added a sense of direction and destination. Without it, I feel like I'm just wandering a little aimlessly from side to side and hard to keep track of which castles have been cleared.

 

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.

 

Personally I don't think the bats are very interesting or needed. If something had to be taken out in order to make room for something else, I would pick the bats.

 

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 haven't run into the Grendel or wizard yet.

 

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.

 

You mentioned "falling princess". Does that mean you would have to occasionally catch a princess that is falling from a castle or tower or from the dragon's grip in the sky? If so, that sounds like a very fun and interesting addition to gameplay. Maybe the player would get a visual or audio warning that she is about to fall and and react quickly by positioning themselves under her and hitting the fire button at the right moment to catch her?

 

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.

 

Speaking of the arrow, it's kinda a pain to aim now since it curves. Especially when switching directions.

 

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 also miss the galloping sound fx.

...

I liked the hills in the back. The fire that the dragon shot looked cooler. The paladin was more simplistic but still looked good. Even the arrow that the player shot looked better.

 

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

Edited August 11, 2011 by jrok

[Legend]

Thanks for all the feedback, Legend.

 

One thing that I really miss from the older version is the little radar type thing at the bottom that let me know where I was. I feel it added a sense of direction and destination. Without it, I feel like I'm just wandering a little aimlessly from side to side and hard to keep track of which castles have been cleared.

 

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.

 

Personally I don't think the bats are very interesting or needed. If something had to be taken out in order to make room for something else, I would pick the bats.

 

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 haven't run into the Grendel or wizard yet.

 

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.

 

You mentioned "falling princess". Does that mean you would have to occasionally catch a princess that is falling from a castle or tower or from the dragon's grip in the sky? If so, that sounds like a very fun and interesting addition to gameplay. Maybe the player would get a visual or audio warning that she is about to fall and and react quickly by positioning themselves under her and hitting the fire button at the right moment to catch her?

 

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.

 

 

Thanks again!

J

 

Although I think the audio clues are a cool idea, there are some definite drawbacks to using "sonar" as opposed to the radar.

They are a little hard to figure out what sound means what.

Can't easily be explained through text.

Sometimes you have to play with the sound/ volume down or even off.

Deaf players.

 

Alternating the bat and soldiers sounds like a good idea if the bat gets beefed up somehow. Otherwise, I would leave it out all together personally. It doesn't really add much to the game as is.

 

I only got to wave 4. Explains no Grendel/Wizard

 

The princess mechanic sounds cool. I would definitely prefer it to the bats if I had to choose.

[jrok]

Although I think the audio clues are a cool idea, there are some definite drawbacks to using "sonar" as opposed to the radar.

They are a little hard to figure out what sound means what.

Can't easily be explained through text.

Sometimes you have to play with the sound/ volume down or even off.

Deaf players.

 

Alternating the bat and soldiers sounds like a good idea if the bat gets beefed up somehow. Otherwise, I would leave it out all together personally. It doesn't really add much to the game as is.

 

I only got to wave 4. Explains no Grendel/Wizard

 

The princess mechanic sounds cool. I would definitely prefer it to the bats if I had to choose.

 

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.

Edited August 12, 2011 by jrok

[DT Kofoed]

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?

 

 

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.

[jrok]

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?

 

 

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

[Legend]

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?

 

I thought I heard different types of sounds. That is mostly what I was referring to when I said it may be difficult to explain what the different sounds mean. As in trying to say a "whoop-whoop" means this and a "whaaa-whee" means that.

 

A visual clue would be nice. I liked the way the visual clues looked in the old version of the game too. They were obvious and helpful. Took me a little bit to figure out what the line (lance I guess) on the side of the screen meant in the new version. I didn't even really notice it at first and wrote it off as a graphics glitch.

 

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.

 

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?

 

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.

 

I think you are doing a good job so far in trying to create that type of game that splits the players focus. The addition of the princess would probably add to it even more. I think both versions do a good job. I don't think the original flickered that bad. It didn't bother me anyways.

 

Btw, on a related note, do you happen to have another build of the old version newer than rev1? I like bothe versions and will probably play both, but rev1 of the old version unfortunately has a bug that seems to make the game bug out sometimes when dying and just showing the dragon fire sprite scrolling up and down the screen.

 

Maybe you could even make two versions of it? One to build on the old version and one that keeps going in the direction you are now? Kinda like a part one and part and part two.

 

Either way, at the end of the day, it's your game and creation to make turn out how you would be satisfied with it.

[DT Kofoed]

Only shrink the world if you need to in order to add something truly compelling... given how fast you can gallop, emptiness is not a concern to me. I'd frankly be concerned if the world felt too small! This seems so close to finished, and there's a great polished feel to most of it. I look forward to seeing what you come up with to replace the bats.

[Legend]

Only shrink the world if you need to in order to add something truly compelling... given how fast you can gallop, emptiness is not a concern to me. I'd frankly be concerned if the world felt too small.

 

I agree with this statement mostly. The game only occasionally seems like you are just traveling though empty space. I suppose it could be shortened a little, but not much. Would it have to be to 6 instead of 9? or could it be like 7 or 8 instead of 9?

 

a little smaller might make it feel a bit more frantic and make the game play faster. I think it might be a good thing. It does seem to slow down and drag slightly towards the ends of the levels when there are only a couple enemies left. I wouldn't mind this too much personally. Still wouldn't want it too small though.

[jrok]

I thought I heard different types of sounds. That is mostly what I was referring to when I said it may be difficult to explain what the different sounds mean. As in trying to say a "whoop-whoop" means this and a "whaaa-whee" means that.

 

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.

 

A visual clue would be nice. I liked the way the visual clues looked in the old version of the game too. They were obvious and helpful. Took me a little bit to figure out what the line (lance I guess) on the side of the screen meant in the new version. I didn't even really notice it at first and wrote it off as a graphics glitch.

 

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 )

 

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.)

 

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.

 

Btw, on a related note, do you happen to have another build of the old version newer than rev1? I like bothe versions and will probably play both, but rev1 of the old version unfortunately has a bug that seems to make the game bug out sometimes when dying and just showing the dragon fire sprite scrolling up and down the screen.

 

I'll check. It's been awhile since I tested any older versions, but I'm sure they were buggy.

 

Cheers,

J

Edited August 12, 2011 by jrok

[jrok]

Only shrink the world if you need to in order to add something truly compelling... given how fast you can gallop, emptiness is not a concern to me. I'd frankly be concerned if the world felt too small! This seems so close to finished, and there's a great polished feel to most of it. I look forward to seeing what you come up with to replace the bats.

 

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

[+grafixbmp]

Something that struck me as rather cool was that this game somewhat reminds me of the game Repton (space ship game C=64) with the scrolling world and multi-layered events. That was one of my favorite games growing up and this brings back those memories. Good job!