Concepting a Conversion #1: Fire One

[Cybergoth]

Hi there!

 

Toying with ideas and thinking about game concepts is one of the major fun things when programming the 2600 I think.

 

Even when playing something completely different like some GBA game or an Arcade game on MAME or a NES game, I can't stop from thinking wether this or that can be done on the 2600 as well.

 

Well, while Andrews programming course is a rather serious matter and Roberts Assembly course is probably even more hardcore, this is probably rather fast-food, but hopefully also a little refreshing.

 

What you need for this course is ideas, imagination, basic knowledge of the TIAs grafics capabilities, and, if you want to go so far, a pixelated painting program of your choice like MS-Paint or Paint Shop Pro.

 

How will a lesson be like? Well, we'll just start with a screenshot from an "original" game and from there we'll do one giant brainstorm until we scaled it down to a "programable" 2600 concept. I will moderate this and document little design milestones in a series of mockup screens, until we're done. This is where it ends.

 

(If someone got so involved or interested in a concept to actually attempt this port, this was certainly brilliant.)

 

Now, for the first lesson I chose the Exidy arcade game "Fire One":

 

 

As you can see, a 1:1 port is impossible.

 

First phase, before we can seriously start talking about a 2600 port, would be a *research* phase. There is the original game on MAME to check out, and there's two home versions, one for the C64 and one for the 8-Bit Ataris available.

 

So, I'll wait three days from now to give everyone interested a chance to learn about the game, and to play it a little.

 

I'd be very interested to hear your reviews of the games versions, what elements you like of them and which should be kept in the 2600 port.

 

Feel free to post any questions, suggestions, ideas, mockup screens as you like. I'm also interested in any thoughts of how this game could possibly be ported, where you see the major difficulties, where you'd sacrifice things or alter the gameplay or design in order to make it fit the 2600. While this forum is for the newbies, I think any further insight from the pros might help here and there as well, so we all can learn from them and their experience.

 

Hope you will enjoy this as much as I will.

 

Greetings,

Manuel

[Susuwatari]

That looks similiar to Sub Hunt for Intellivision.

 

Graphic hacks are easy, it's a matter of knowing some images may be upside down and some image may be only half (second half are often mirrored)

 

Tweaking colors or sound require a bit more work

 

Rearrainging elements on the screen, tweaking the gameplay, or changing the sound, you might as well hit that programming for Dummies thread.

[Cybergoth]

Hi there!

 

Ok, so I'll help you with researching.

 

The C64 version is available as "Remember" release, complete with docs, get it from here (Release #197):

 

http://www.bitte8bit.de/newremember/htdocs...cs/releases.php

 

The Atari 8-Bit version is in the Vjetnam archive:

 

http://vjetnam.hopto.org

 

And finally the arcade version. This is a bit tricky...

Go here:

 

http://baudejogos.vetorialnet.com.br/downl...arq=FIREONE.ZIP

 

Don't panic! Go to the bottom of the page, and type the inversed word into the edit control, then press the button labelled "Donaldear".

 

Here's a little review snippet from an old Zzzap64 article I found. It's a good description of the basic gameplay of Fire One:

 

Fire One takes you under the water, where your submarine has to protect its fleet from enemy sub and ships. You do this in a series of battles that take place within a time limit and are decided by who can sink the opposite sub or the entire fleet.

 

You are equipped with nine torpedo tubes and unlimited torpedoes. These can destroy both enemy and friendly ships so you have to aim carefully.

The screen shows a sonar scan of the whole playing area, and a periscope's view of the local area when surfaced. Indicators also show your torpedoes ready to fire, time left, damage to both subs, direction and speed, and your tracking computer.

 

There are eight types of ship and, unless you score a direct hit in their dead centre, they will take several hits to destroy. Each hit and sinking will score points, with the sub being by far the most valuable.

 

Another essential reading is the KLOV entry for Fire One:

http://www.klov.com/game_detail.php?letter...=F&game_id=7809

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

Rearrainging elements on the screen, tweaking the gameplay, or changing the sound, you might as well hit that programming for Dummies thread.

 

You're absolutely right. What we do here shall happen before a single line of code is programmed. You'll see, thinking about things and making plans will save you a lot of time later, when actually programming a game.

 

One certainly can't plan everything, but you can always try to set up a good route, avoiding one or the other brickwall you'd run into if you'd start straight with the programming.

 

Hacking is also a good excercise. That means you're looking in detail at similar games and by this you're getting an idea of possibilites. I'd be very interested to see a few games hacked into Fire One along our way.

 

Greetings,

Manuel

[Tickled_Pink]

This is certainly one of the things I enjoyed most about my own newly-begun project. I took out MAME, had a look for likely candidates and eventually chose the 1977 game, Depthcharge - which is a similar style of game.

 

My own view on working on a conversion such as this is that you first have to work around the graphical capabilities of the VCS. When you know what you can adequately fit onto the screen and what you're going to use to display them (PMGs or Playfield Graphics), considering the limitations and possible problems while you're at it, you're in a better position to determine how to proceed with the gameplay. You really can't do it the other way around. You can't do the gameplay design and hope that the graphics will fit in.

 

Like I said, Depthcharge is a similar game but has less going on in it than Fire One. You have one large ship at the top of the screen and several Subs below you. What makes it an easier project to convert is the fact that each sub goes by on its own area of the screen. You cannot have more than one sub on each line of the screen. That makes using Players much easier.

 

In Fire One, that's one of the main issues. You can have more than one ship on each scan line, which brings about the issue of flicker if you're using Players. The original game itself is in a kind of 'pseudo-3D' environment. Moving it to a wholly 2D display (perhaps a view from above) would remove those problems. In the '3D' display, the ships are often encroaching on each other's scan lines because they're supposed to be at different distances from the player's sub. So moving the game to a completely 2D environment might need to be the first gameplay concession.

[Cybergoth]

Hi there!

 

In Fire One, that's one of the main issues. You can have more than one ship on each scan line, which brings about the issue of flicker if you're using Players. The original game itself is in a kind of 'pseudo-3D' environment. Moving it to a wholly 2D display (perhaps a view from above) would remove those problems. In the '3D' display, the ships are often encroaching on each other's scan lines because they're supposed to be at different distances from the player's sub. So moving the game to a completely 2D environment might need to be the first gameplay concession.

 

Those are very good observations. Did anyone analyse the Arcade resolution of the visible portions vs. the VCS resolution yet?

 

Since I'm away for ~48 hours now before we can start the real thing here, I will give you some homework/research tasks. These will provide essential informations for any further serious considerations.

 

- Find out the resolution of the visible(!) rectangle displayed in the arcade

 

- Compare it to the VCS resolution. (To prevent any further discussion here, we're assuming 160 double width pixels horizontal vs. 192 vertical pixels)

 

- Draw conclusions from the above.

 

- Fire One! seems to be an actionized game based on the Pen & Paper...

 

- How many vehicles are facing each other?

(Bonus question: How are they arranged?)

 

- How many variables are you assuming to be needed for calculating/tracking each(!) vehicle and which are these?

 

- Draw conclusions from the above.

 

- There is a lot of redundant information on the screen. Try to figure out why. Hint: Read the KLOV entry.

 

- This would have been the slot for the question about the most difficult task in this port. Yet Tickled_Pink already gave the answer: The high number of ships per line. There may be 3-4 ships on the same scannline (per player!), which is, simply put in one word: Impossible.

 

- Think of a solution for the above problem. Be creative. Surprise me.

 

BTW: I'm developing the whole "Fire One! 2600" concept right now, together with anyone interested. I haven't done anything yet, so the final result *can* be heavily influenced from any input or ideas posted in this thread. Don't be shy.

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

- This would have been the slot for the question about the most difficult task in this port. Yet Tickled_Pink already gave the answer: The high number of ships per line. There may be 3-4 ships on the same scannline (per player!), which is, simply put in one word: Impossible.

 

- Think of a solution for the above problem. Be creative. Surprise me.

 

Hm... since no one dares (or cares?) answering this, here's my 3rd and 2nd best solutions:

 

3. Tile the screen horizontally instead of vertically

 

2. Rotate everything by 90°

 

My best solution and the answers to the other questions tomorrow... one day more for you...

 

Greetings,

Manuel

[Robert M]

Here's a wacky idea that's been banging around in my head for a few weeks now. In single player mode, the kernel is a two line kernel and the one player's game fills the whole screen. For two player mode, split the screen horizontally one player on top and one on the bottom. Switch to a single line kernel repeated twice, once for each player thus filling the screen. That might be enough right there, but the graphics will be noticibly scrunched. You can take it a step further by using interlacing. You thereby restore each player's field to the same number of scanlines as the single player mode, but you are drawing only half of them each frame. Hopefully the interlaced graphics will appear less scrunched.

[Cybergoth]

Hi there!

 

Ok, so here's the answers for the research tasks:

 

- Find out the resolution of the visible(!) rectangle displayed in the arcade

 

It is 248*216.

 

- Compare it to the VCS resolution. (To prevent any further discussion here, we're assuming 160 double width pixels horizontal vs. 192 vertical pixels)

 

We're short of 88 horizontal pixels and 24 vertical pixels.

 

- Fire One! seems to be an actionized game based on the Pen & Paper...

 

Battleships

 

- How many vehicles are facing each other?

 (Bonus question: How are they arranged?)

 

If I count correct, both fleets have 16 ships, plus the 2 subs.

 

On the radar they're arranged like

 

8

1

8

 

8

1

8

 

Note: Through the periscope the enemy subs appear almost on the lower enemy line.

 

- How many variables are you assuming to be needed for calculating/tracking each(!) vehicle and which are these?

 

Each ship needs three variables for the horizontal position. We need 10/11 bits to represent of the actual position (2 Bytes) and another Byte for fractional adding. We need at least one more Byte for the current damage state and the direction the ship is going. Maybe even more, I'm sure I forget something right now.

 

So, that is at least 4*34 = 136 bytes RAM required.

 

- Draw conclusions from the above.

 

The "most difficult task" in this port just got a new competitor... :-)

 

- There is a lot of redundant information on the screen. Try to figure out why. Hint: Read the KLOV entry.

 

Let me quote:

 

The cabinet has a vertical divider allowing each player to only see their half of the video screen, although an onlooker standing behind the game could see both sides.

 

So, the redundant bits are required to make you see the stats of the other player.

 

Greetings,

Manuel

[Cybergoth]

Hi Robert!

 

In single player mode, the kernel is a two line kernel and the one player's game fills the whole screen. For two player mode, split the screen horizontally one player on top and one on the bottom.  Switch to a single line kernel repeated twice, once for each player thus filling the screen.

 

I think this idea is way cool. I really wonder why no game ever did that.

 

Unfortunately, in our case, it won't help too much. That is also why I ranked vertical tiling only as 3rd best solution. For one display Fire One needs already 216 scannlines, and having two of them is 432 scannlines tall. Scaling that down to 192 will most likely ruin the gameplay.

 

Ok. Here is the best solution I found. I assume it can be considered cheating, but I think in this case it's the best:

 

For the 2 player mode, 2 cartridges, 2 2600, 2 TVs and a link cable are required

 

Keep in mind, that the 2 Player modus is essential to this game. Also, the Arcade hides the screens so the each player can only see his own screen. That would be impossible to do with only 1 TV anyway.

 

As for the technical background: At this point, just believe me that it is possible to link two VCS via the Joystick ports. Worst case we just go to [stella] and ask the techheads there how it's done

 

Ok, it would've been fun to discuss some more other ideas, but so I'll continue this course with mine...

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

So, now that we only need to display the screen for one player, we're left with a block that is 120 pixels wide. I manually pixelated another additional 8 pixels to that, because I like powers of two, centered the image and added two 16 pixel borders, so that the display is now exactly 160 pixels wide. Then I doubled the pixels horizontally, so we're now seeing almost a VCS screen now.

 

It's still 216 pixels tall, so one of our remaining goals is to reduce that to 192.

 

Anyway, here we go, Milestone 1:

 

Any ideas where to go from here?

 

And here's another two research tasks for you:

 

- There's messages displayed in the bottom frame. I want to get rid of these, so what kind of messages do we get there?

 

- What is the time bar and counter for? Do we need that?

 

Greetings,

Manuel

[Thomas Jentzsch]

It's still 216 pixels tall, so one of our remaining goals is to reduce that to 192.

200 is ok too.

[Cybergoth]

Hi there!

 

It's still 216 pixels tall, so one of our remaining goals is to reduce that to 192.

200 is ok too.

 

We should keep that in mind as a "buffer" I think. There's many repositionings in this display, lot's of pointers to tweak and registers to write, I fear this'll eat even more than these additional scannlines.

 

Greetings,

Manuel

[Thomas Jentzsch]

Could you explain what the multiple (5?) score/message are used for?

[Cybergoth]

Hi there!

 

Could you explain what the multiple (5?) score/message are used for?

 

It's your score for this round, your score sum for all rounds played this far and the same again for your opponent. The fifth value is the timer. (Redundant again, as it is sitting right next to the timer bar...)

 

Scoring is one thing I'd like to discuss. I tend to think it's not required at all. The only score I'd keep would be who won a round, like in a Tennis Set. This'll reduce the score display on the main screen to nothing and the number of wins per player can be displayed on a separate title screen for example. This'd also reduce the required RAM from 8 (4 scores a 2 Byte) to 1 Byte, for matches from 0:0 up to 9:9.

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

Ok, let's start our next step with answering the research tasks first:

 

- There's messages displayed in the bottom frame. I want to get rid of these, so what kind of messages do we get there?

 

I think there's basically three different types:

 

1. Score messages

2. Damage report (enemy)

3. Damage report (own sub)

 

- What is the time bar and counter for? Do we need that?

 

When the timer runs out in the arcade you're required to put in a new coin. For the actual gameplay it doesn't matter at all. In our home version, we can play each "duel" to the end, so we don't need it.

 

Ok, regarding the earlier score discussion and the answers to the research tasks, I just pixelated our next Milestone:

 

 

The changes I did and why:

 

- I removed the timer bar and counter. It's not required for our home

version

 

- I removed all scoring. We will display an overall score (rounds won/lost), on the title screen.

 

- I also removed the border of the main action display, the "shadow" of the ship of our own fleet, some grafics looking like waves and the tracking aid. More or less unescessary details, but we gained a lot of room by removing these.

 

Issues now:

 

We need to visualize three things, that got lost with the changes I just did:

 

- The tracking aid

- The damage state of enemy ships

- The damages of our own sub.

 

Well, the tracking aid can be easily replaced by indicating a target in range via changing the color of the top arrow.

 

We can possibly indicate the damage state of an enemy ship by shading it. The more hits it get, the brighter it gets or something like that.

 

And for the damage on our own sub... well, if the tracking aid doesn't work, or the controls jam or the rader is distorted, etc... - the player will quickly find out I think...

 

Well, maybe someone can think of a nice way to indicate damages of our sub, any ideas?

 

Now, for a next brainstorm task, we should try to visualize all remaing required state displays in a VCS conform way. Well, standart would be packing it into 48 pixel displays, but maybe someone finds a more creative way?

 

What we have left to display regarding the game state is:

 

- The torpedo tubes and their loading state

- Our own subs health

- The enemy subs health

- (Maybe, if you have a nice idea: visually indicating technical damages of our sub)

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

It's been a while, so let me start straight with our next milestone:

 

 

As you can see, a lot of changes have been made.

 

- The sonar has been horizontally downsized. Well, most of all this had cosmetical reasons, since the main playing area now takes by far the biggest portion of the screen. This is where everything happens. The sonar is now exactly 64 pixels wide, so we can easily render it from the absolute horizontal positions of everything, simply by LSRing the data until we have all values between 0-63.

 

- Right between the sonar and the periscope view is a damage bar. I though this could not only be used for the damage of the enemy sub, but actually for every enemy vessel: Whatever you're currently shooting at, it's damage state gets displayed then.

 

- Last change is the state display at the bottom. It monitors 8 torpedo tubes, can display any damages of your own sub ( 'C' means damaged controls for example) and at the very bottom he damage of your own sub gets displayed. All fitting into a standart 48 pixel sprite display.

 

Well, that was it for this milestone.

 

For the next, we'll tackle the remaining issues. The main display and the sonar. Plus we're taking care of the severe RAM problems I mentioned earlier in this workshop.

 

Any comments and ideas regarding the current progress or ideas for the next milestone are as usual welcome

 

Greetings,

Manuel

[Cybergoth]

Hi there!

 

So, here's the final milestone for the Fire One 2600 porting concept:

 

 

Few... this is going to be a hard compromise, but my best solution for the main display will be... flicker. There, I said it.

 

No magic trick, no secret technique will help here, we're cooking with water only, i.e. plain old flicker.

 

Now, what do we get from the flicker?

 

4 8-bit wide objects anywhere on one horizontal line. The first obvious negative aspect is that bigger ships will loose most of their details. We can fake their size by doing double or quad width sprites, but the resolution is gone.

And they flicker. No other way.

 

The positive aspect: Well, the port is just doable with hat compromise.

 

We can do the two horizontal lines of attackers and can have 7 independent moving attacking ships and the enemy sub here on screen at once.

 

This'll also solve most of our RAM problems. Remember, making the fleets as big as in the Arcade is not possible, since they're way too RAM consuming.

 

Really? Now, how about this: Whenever one of the attacking ships gets destroyed, we replace it with another one, we just launch a new attacker! So we can make the fleets just as big as in the Arcade, they're only not all right there from the beginning!

 

Ok, I think we're done discussion the *possibility* of a conversion of the "Fire One!" Arcade.

 

We've found ways around any obstacle in the way of porting this game and we defined a set of compromises to make it possible.

 

As a final discussion, I'd like to know from you, wether you'd think doing this conversion as we just planned it, would it be worth all the effort involved? Would it be still as fun as the arcade? Or do we have too severe compromises planned, which'll most likely ruin the 2600 port? What do you think? Should it be done?

 

(Well, if the answer is "no": Lucky we are, since we didn't waste a single minute programming it yet )

 

Greetings,

Manuel

[Thomas Jentzsch]

Come on guys! Get rid of that "consumer only" attitude!

[Serguei2]

Should it be done?

 

Yes. Of course. I can't wait to play it.

 

 

Serguei

[Cybergoth]

Hi there!

 

Should it be done?

Yes. Of course. I can't wait to play it.

 

Fine! With 100% positive feedback so far, I'm very motivated to do another part of this feature.

 

Any general suggestions for the next lesson?

Like for example should it go deeper into programming details or less?

Was I too quick or too slow with developing the concept?

 

I'd personally like to see more discussion/communication/interaction in the next lesson, so does anyone have a good idea how I could motivate more "audience participation"?

 

Also I'd like to know wether there was any interest in really programming "Fire One" in follow-up lessons as a "learning project". Only it would have to be a "group" effort, where I'd only assist, plan and advise. (Only portion I'm really interested to program myself at the moment is the "networking/link" code.)

 

Greetings,

Manuel

[Galaga_Freak]

Hi there!

 

Fine! With 100% positive feedback so far, I'm very motivated to do another part of this feature.

 

Any general suggestions for the next lesson?

Like for example should it go deeper into programming details or less?  

Was I too quick or too slow with developing the concept?

 

Also I'd like to know wether there was any interest in really programming "Fire One" in follow-up lessons as a "learning project". Only it would have to be a "group" effort, where I'd only assist, plan and advise. (Only portion I'm really interested to program myself at the moment is the "networking/link" code.)

 

Greetings,

Manuel

 

Personally I would like to see more programming details as I am interested in applying any learned techniques to a few game ideas of my own Sprite tricks seem to be something that would come up in this project, and that is something that I have a need to learn.

 

This project definately interests me, especially the networking possibilities.

 

My only concern with your approach is the group effort plan. It sounds good in theory. I just wonder if the group is up to it. Obviously you have had problems getting even non-technical input so far, what kind of problems would arise if that were to continue into the technical phase of the project??

 

I'm willing to help, with what little time and knowledge I have anyway

[Cybergoth]

Hi there!

 

My only concern with your approach is the group effort plan.  It sounds good in theory.  I just wonder if the group is up to it.  Obviously you have had problems getting even non-technical input so far, what kind of problems would arise if that were to continue into the technical phase of the project??

 

Well, we can give it a try. I'll now attempt to project the realisation of this game by breaking it down into half a dozen smaller tasks. If we get most of these tasks asigned to people interested in contributing to or working on this part, I'll carry it further.

 

One more thing is to consider: If this game will be realized as a big group effort, it should probably get released royalty free and all work is also done for free. If that is clear from the start we would avoid most "sales" related troubles later.

 

Ok... also, to avoid fruitless discussions later, it should be agreed by anyone working on this project, that I have the final say on things. (That is, unless someone else will do the project on his own...) Anything can certainly be discussed, but someone needs to be in control of the "whole", giving the project a clear direction.

 

Getting productive. Getting Closer.

 

A Descission: This will be an 8K game.

 

The two 4K banks will have the following content/modules:

 

Bank1:

 

- Intro & Score screen

- Title music

- Networking code

 

Bank2:

 

- The Actual game code

- 3 different display kernels:

-> 6 sprite state display

-> Sonar

-> Main action display

 

So there'd be several tasks available:

 

1. Building the whole game framework inclusive bankswitching

2. Programming the intro screen

3. Developing the networking solution

4. Composing & Programming the music

5. Programming the 6 sprite state display

6. Programming the sonar display

7. Programming the main action display

8. Programming the game logic

 

The available Jobs:

 

Lead programmer(s):

One guy should best do both 7 & 8. This is the major portion of the whole game, it's heart. It can probably be done by two different people, but they'd need to work very closely together and need to be able to communicate extremely good and precise.

 

Programmers:

Tasks 2, 5, and 6 are relativly easy jobs. A lot of already existing code can be reused here. Also most of it can be preogrammed independently from the rest.

 

Musician:

Someone creative is required for 4.

 

Hardware Techhead:

There's few guys who could really do 3., as one'd need either an EPROM burner or two SC/CC devices. Also one would need to develop/solder prototype link cables. This networking solution can be developed totally independent from our game project.

 

If there'll be enough volunteers for the jobs/tasks so far, I'll provide the code framework (1) myself.

 

One more thing: Remember, this is the "Newbies" board. No one is expecting anything from anyone here. Just give it a try if you feel like doing it. I'm sure there's pros like Andrew, Paul, Dennis, Christopher, TJ or others available to assist and help when the going gets too tough for us...

 

Also, we can analyze any task or job in closer detail, if you're uncertain as to what is required / to be done there.

 

Ok, I'll wait a week from now for people to sign up...

 

Greetings,

Manuel

[Galaga_Freak]

I agree with the royalty-free issue, this should be a learning experience for us.

 

With that I volunteer for #2, the Intro screen. That should be within my skill level.

[Serguei2]

Hi Cybergoth

 

Will you release the game with the source code?

 

 

Serguei