Concepting a Conversion #2: The Dreadnaught Factor

[Cybergoth]

Hi there!

 

Do you really think that Dreadnaught Factor is doable?

Hm... maybe like the 5200 version, which is scrolling vertical?

 

Wow, look at the size of that thing:

 

Hm... well, so maybe it ain't doable with vertical scrolling either...

 

Greetings,

Manuel

[vdub_bobby]

Hi there!

 

Do you really think that Dreadnaught Factor is doable?

Hm... maybe like the 5200 version, which is scrolling vertical?

 

Wow, look at the size of that thing:

 

Hm... well, so maybe it ain't doable with vertical scrolling either...

 

Greetings,

Manuel

901776[/snapback]

I dunno...that looks eminently doable - with some compromises, of course.

 

Reposition sprites every 8/16 scanlines and set NUSIZx appropriately. Allow 30 Hz flicker and you could get up to six turrets in a single row, with some positioning restrictions. It wouldn't/couldn't look exactly the same, but I think you could get acceptably close. Maybe.

 

Main problem I see would be storing all the turret locations/states - seems like it would require a lot of RAM.

[ZylonBane]

The biggest problem would be creating a kernel that allowed so many objects in a line at once, and making it so they could be freely scrolled all over and off the screen, AND allow asymmetrical playfield graphics for the ship surface, AND allow the player ship to move anywhere within this kernel.

 

One way to pull it off without being an unplayable flicker-fest would be to scale the dreadnaughts down so their width fits entirely on the screen at once. Of course, then you'd basically have yet another version of Space Invaders.

 

Alternatively, you could drastically reduce the number of targets on the dreadnaughts, and change the gameplay so each target has to be hit multiple times. Since the name would have to be changed anyway to avoid legal repercussions, people wouldn't mind so much slight gameplay changes as well.

Edited August 1, 2005 by ZylonBane

[vdub_bobby]

The biggest problem would be creating a kernel that allowed so many objects in a line at once, and making it so they could be freely scrolled all over and off the screen, AND allow asymmetrical playfield graphics for the ship surface, AND allow the player ship to move anywhere within this kernel.

 

One way to pull it off without being an unplayable flicker-fest would be to scale the dreadnaughts down so their width fits entirely on the screen at once.  Of course, then you'd basically have yet another version of Space Invaders.

I was kind of going on the assumption that it would only scroll vertically, not horizontally. And 30 Hz flicker wouldn't be so bad.

 

So symmetrical playfield graphics for ship surface, say a 160-scanline playing area, with repositioning every 16 scanlines and up to six turrets per reposition, gives you up to 60 turrets on screen at once.

 

If you use the ball and one missile for enemy shots, both with 30 Hz flicker, that gives you 4 enemy bullets on screen at once - probably the most limiting thing.

 

Use other player and missile for the user-controlled ship.

 

I think that could be pretty cool. I don't think it would anymore a Space Invaders clone than the original DF; I don't agree that the only distinguishing feature of DF is the fact that it scrolls horizontally.

Edited August 1, 2005 by vdub_bobby

[Cybergoth]

Hi there!

 

The biggest problem would be creating a kernel that allowed so many objects in a line at once, and making it so they could be freely scrolled all over and off the screen, AND allow asymmetrical playfield graphics for the ship surface, AND allow the player ship to move anywhere within this kernel.

 

Ah, it's *slightly* less complicated, since the players ship is fixed at the bottom. For the gameplay it is not necessary that the players ships touch any enemy stuff, so you could probably cheat a bit and use both sprites for enemy stuff, having everything scrolling out of the screen the scanline just above the players ship.

 

But what I think is pretty undoable are the enemy attack ships that are launched at you every once in a while. But maybe the ball could do some SW-ESB like smart-missles...

 

I'd also think the horizontal scrolling is possibly overkill...

 

Just some brainstorming here. I'm not sure if I'd dare even trying to convert this...

 

Greetings,

Manuel

[vdub_bobby]

Ah, it's *slightly* less complicated, since the players ship is fixed at the bottom. For the gameplay it is not necessary that the players ships touch any enemy stuff, so you could probably cheat a bit and use both sprites for enemy stuff, having everything scrolling out of the screen the scanline just above the players ship.

Or just 30 Hz flicker on the scanlines overlapping the player's ship? Scrolling off the screen above the player's ship seems like it could make things look disconnected.

But what I think is pretty undoable are the enemy attack ships that are launched at you every once in a while. But maybe the ball could do some SW-ESB like smart-missles...

You could probably use the ball to create something that looked vaguely ship-like by manipulating the CTRLPF and HMBL registers.

 

Update a symmetrical PF every other line (if that often), write to ENAM0/ENAM1 every other line, write to GRP0 and GRP1 every line, and hit HMOVE every other line, write to HMBL, ENABL, CTRLPF every other line. It would fit. There are enough cycles, anyway; assuming single-color sprites. Might even be able to get line-by-line color changes on the sprites.

[Cybergoth]

Hi there!

 

In a first effort to VCSify the Dreadnaught a little, I converted the dreadnaughts shape to the VCS playfield. Also I grayed it completely. Regardless of wether the port will scroll horizontally or not, the original color scheme would definitely be overkill IMHO:

 

 

Greetings,

Manuel

[vdub_bobby]

In a first effort to VCSify the Dreadnaught a little, I converted the dreadnaughts shape to the VCS playfield. Also I grayed it completely. Regardless of wether the port will scroll horizontally or not, the original color scheme would definitely be overkill IMHO:

Probably have to restrict to two types of turret per scanline as well.

 

EDIT: Plus, your playfield is 44 pixels wide

 

ANOTHER EDIT: Ok, I took your VCSified pic and VCSified it further, restricting the number of types of objects on a scanline. I fudged a little in spots and also assumed that the bomb-shaped things could be created by the ball (with some tricky CTRLPF/ENABL/HMBL manipulation).

 

I assumed 30 Hz flicker for all objects and that both players could be used at any width/duplication.

 

Treated the big turrets as double-wide players (therefore not allowing duplication).

 

Anyway, counting up from the bottom, the 1st-8th rows all look possible. The 9th is kinda tricky; not sure how to do that weird shape in the middle, plus the black vents, plus the outer bombs. The 10th is fine. The 11th has issues again, though maybe doable if the ball can do the outer bombs. 12th-14th rows are fine.

Edited August 2, 2005 by vdub_bobby

[Thomas Jentzsch]

So the players ship cannot collide with any othe installations? That sounds pretty lame.

[Cybergoth]

Hi there!

 

You could probably use the ball to create something that looked vaguely ship-like by manipulating the CTRLPF and HMBL registers.

 

Main problem with the ball is that it has the color of the playfield, so it can't be used for any objects moving on and off the dreadnaught, not even shots. I think you might be able to do the "energy vents" with it though: Basically we'd just leave holes in the dreadnaught shape and have the ball do grey bars over it.

 

EDIT: Plus, your playfield is 44 pixels wide

 

Yeah, I wasn't giving up on the horizontal scroll so soon

But the more I'm thinking about it, I guess it has to be sacrificed. All those detailed sprites won't allow updates of a non-symmetrical playfield.

 

ANOTHER EDIT:  Ok, I took your VCSified pic and VCSified it further, restricting the number of types of objects on a scanline.

 

Some good ideas there, yes!

 

I assumed 30 Hz flicker for all objects and that both players could be used at any width/duplication.

 

I'd probably make that dependable on available RAM. If the many objects will consume too much RAM, I'd rearrange things so that no flicker is required.

 

So the players ship cannot collide with any othe installations? That sounds pretty lame.

 

You should try playing it first, before posting a review...

 

Greetings,

Manuel

[Thomas Jentzsch]

You should try playing it first, before posting a review...

Sorry, it was more meant as a question. I never played the game and automatically compared it to other games like Uridium (or Zaxxon).

 

IMO being able to hit installations is one of the key gameplay elements, which makes those games outstanding.

[Thomas Jentzsch]

Main problem with the ball is that it has the color of the playfield, so it can't be used for any objects moving on and off the dreadnaught, not even shots. I think you might be able to do the "energy vents" with it though: Basically we'd just leave holes in the dreadnaught shape and have the ball do grey bars over it.

How about a reverse color scheme? Where the playfield is black and and the background is grey.

[Cybergoth]

Hi there!

 

IMO being able to hit installations is one of the key gameplay elements, which makes those games outstanding.

I think it might be the way to go if the # of objects and enemy shots has to be significantly reduced in the conversion process.

 

Main problem with the ball is that it has the color of the playfield, so it can't be used for any objects moving on and off the dreadnaught, not even shots. I think you might be able to do the "energy vents" with it though: Basically we'd just leave holes in the dreadnaught shape and have the ball do grey bars over it.

How about a reverse color scheme? Where the playfield is black and and the background is grey.

Well, same problem reversed then, no?

 

Greetings,

Manuel

[Thomas Jentzsch]

Well, same problem reversed then, no?

Not necessarily! (can you say that?)

 

You could switch the scheme in sync with the vertical ball movement. So when the ball flies over the ship, the playfield is used for the space and when the ball is over the space, the playfield displays the ship.

[Cybergoth]

Hi there!

 

You could switch the scheme in sync with the vertical ball movement. So when the ball flies over the ship, the playfield is used for the space and when the ball is over the space, the playfield displays the ship.

 

Hm... or you'd constantly toggle that for each frame. Then it could even do smooth transitions between dreadnaught and background (@30Hz though).

 

Greetings,

Manuel

[vdub_bobby]

Main problem with the ball is that it has the color of the playfield, so it can't be used for any objects moving on and off the dreadnaught, not even shots. I think you might be able to do the "energy vents" with it though: Basically we'd just leave holes in the dreadnaught shape and have the ball do grey bars over it.

 

Of course. Using the ball for the vents is probably the best plan.

Well, same problem reversed then, no?

Not necessarily! (can you say that?)

 

You could switch the scheme in sync with the vertical ball movement. So when the ball flies over the ship, the playfield is used for the space and when the ball is over the space, the playfield displays the ship.

903678[/snapback]

Umm...help me out here, I'm not getting this.

 

Space is black, ship is gray, ball has to contrast with both.

 

So, two scenarios:

1. Ball over ship. Ship is background, space is playfield. Ship is gray (COLUBK), space is black (COLUPF), ball is black (COLUPF).

2. Ball over space. Ship is playfield, space is background. Ship is gray (COLUPF), space is black (COLUBK), ball is gray (COLUPF).

 

So whatever is represented by the ball changes color depending on whether it is over the ship or space? How am I looking at this wrong? It doesn't seem like it would work.

I'd probably make that dependable on available RAM. If the many objects will consume too much RAM, I'd rearrange things so that no flicker is required.

Yeah, I think RAM will be the biggest limiter in a DF conversion - but a too-sparse Dreadnaught would make the conversion not worth doing, IMO.

 

I'mma try another mockup.

 

EDIT: It just occurred to me (I always forget this): if you duplicate sprites on a scanline, then the missiles are also duplicated. Which means you either can't duplicate sprites or you can't let missiles cross from one "band" of the screen into another.

 

If you don't duplicate sprites, still allowing 30 Hz flicker, then you are limited to 4 sprites on a scanline.

 

With that in mind, here's another mockup. Even though this would be a stretch of the 2600's RAM*, I think this mockup is already too sparse. Oh, and I still don't know what to do with those weird central shapes (the command center?) and I VCSified the turrets and vents.

 

*Assume half of this dreadnaught can show on the screen at once. That's about 7 rows of enemies. Add another row in memory to scroll onto the screen. At four turrets per row (at 2 bytes each (X,type): 8 total) plus two vents per row (at 1 byte each (X): 2 total) that would require 80 bytes just to track the turrets and vents.

Edited August 3, 2005 by vdub_bobby

[ZylonBane]

IMO being able to hit installations is one of the key gameplay elements, which makes those games outstanding.

Trust me, Dreadnaught Factor is hard enough without having to worry about crashing into things. The idea of the game is that you have to completely destroy each dreadnaught by making multiple one-way bombing runs over them (you can slow down and speed up, but you can't turn around). Every time you complete a bombing run, the dreadnaught moves a little closer to Earth. If it reaches Earth, you lose.

 

There's quite a bit of tactics to the gameplay. You can destroy the engines to slow the dreadnaught down. You can destroy the command centers to degrade the effectiveness of the turrets. And if you manage to destroy all the vents, the dreadnaught can't fire its main weapon to destroy Earth. Plus, there are a lot more dreadnaught shapes than the simple wedge. At higher levels you get ones which are two screens across, which forces the player to make some tough decisions. Do I chip away from the ends to disarm it, hoping I can do so in time to stop the whole thing, or do I charge into a hail of bullets and try to reach the engines?

[Thomas Jentzsch]

So, two scenarios:

1. Ball over ship.  Ship is background, space is playfield.  Ship is gray (COLUBK), space is black (COLUPF), ball is black (COLUPF).

2. Ball over space.  Ship is playfield, space is background.  Ship is gray (COLUPF), space is black (COLUBK), ball is gray (COLUPF).

 

So whatever is represented by the ball changes color depending on whether it is over the ship or space?  How am I looking at this wrong? 

Not at all, you got the idea completely.

 

It doesn't seem like it would work.

Theoretically it would work, but probably it's not worth the effort. Just brainstorming, you know.

[vdub_bobby]

So, two scenarios:

1. Ball over ship.  Ship is background, space is playfield.  Ship is gray (COLUBK), space is black (COLUPF), ball is black (COLUPF).

2. Ball over space.  Ship is playfield, space is background.  Ship is gray (COLUPF), space is black (COLUBK), ball is gray (COLUPF).

 

So whatever is represented by the ball changes color depending on whether it is over the ship or space?  How am I looking at this wrong? 

Not at all, you got the idea completely.

That's good, anyway

It doesn't seem like it would work.

Theoretically it would work, but probably it's not worth the effort. Just brainstorming, you know.

903809[/snapback]

I suppose it would work if you mean that you would have a flying object that was visible at all times.

 

But what I meant was that having a flying object that changes color so drastically when it flies over different backgrounds wouldn't look good enough to be usable.

 

The 30 Hz flicker solution might be better, since the ball would look the same all the time, but the best solution might be to just restrict the ball to being over the ship or not for any given flight pattern.

[Thomas Jentzsch]

But what I meant was that having a flying object that changes color so drastically when it flies over different backgrounds wouldn't look good enough to be usable.

I am not sure. Probably a good contrast is more important than a constant color. Many Atari 2600 games don't care for bullet colors at all.

 

And then, you could still say, the object is always gray. And while it flies over the ship you can only see its black shadow.

[vdub_bobby]

But what I meant was that having a flying object that changes color so drastically when it flies over different backgrounds wouldn't look good enough to be usable.

I am not sure. Probably a good contrast is more important than a constant color. Many Atari 2600 games don't care for bullet colors at all.

 

And then, you could still say, the object is always gray. And while it flies over the ship you can only see its black shadow.

903829[/snapback]

Yeah, for a bullet it is probably fine. I was thinking more along the lines of using the ball (with line-by-line HMBL/CTRLPF manipulation) to create the flying enemy bombs/ships. In which case it wouldn't look so good to have switching colors over different backgrounds. Well, maybe.

[Cybergoth]

Hi there!

 

Under the assumption that we use the ball for the energy vents and nothing else, I made a new mockup, removing all mine and ship launchers.

 

Also I reduced the bridge to VCS size and did a very minor adjustment to the cannons layout. And I used Bobs VCS sprites.

 

I think it looks surprisingly good. Considering the fact that we still need to shift everything a bit closer together to come from 44 to 40 PF pixels, this is IMHO *almost* doable (with 30Hz flicker on everything...):

 

 

Greetings,

Manuel

[vdub_bobby]

I think it looks surprisingly good. Considering the fact that we still need to shift everything a bit closer together to come from 44 to 40 PF pixels, this is IMHO *almost* doable (with 30Hz flicker on everything...):

I agree - does look pretty good.

 

The real challenge would be fitting it all in 128 bytes of RAM.

 

EDIT: And getting enough action on screen with only 2 missiles for bullets/gunfire.

Edited August 3, 2005 by vdub_bobby

[Cybergoth]

Hi there!

 

I think it looks surprisingly good. Considering the fact that we still need to shift everything a bit closer together to come from 44 to 40 PF pixels, this is IMHO *almost* doable (with 30Hz flicker on everything...):

I agree - does look pretty good.

 

The real challenge would be fitting it all in 128 bytes of RAM.

 

Hm... I don't think it'll use as much RAM as it looks like.

 

-> Think about it, there's nothing variable in the arrangement!

 

Basically all you need to store is wether something is already destroyed or not.

 

The position can just come from ROM. I'd think about having a large table that's just saying "what" and "where" to reposition something on a particular repositioning scannline.

 

I think it would come down to a 6LK, organized somewhat like:

 

Line 1: Update PF

Line 2: Update sprites

Line 3: Reposition 1

Line 4: Update sprites

Line 5: Reposition 2

Line 6: Update sprites

 

EDIT: And getting enough action on screen with only 2 missiles for bullets/gunfire.

 

Did you ever see Erik Mooneys River Rampage demo?

 

Greetings,

Manuel

[vdub_bobby]

Did you ever see Erik Mooneys River Rampage demo?

No...[stella]?

 

And good point about the RAM!

 

EDIT: Found the demo in [stella] - Wow!

Edited August 3, 2005 by vdub_bobby