Jump to content
IGNORED

WIP- Space Taxi


Just Jeff

Recommended Posts

It would probably have to do without the voice, yes?

I think the Atari 5200 would actually be a more appropriate console to port this to. I actually think the analog joystick would be an interesting gameplay element (in a good way, if I'm being unclear. :P And steering mechanisms in motor vehicles and aircraft feel "analog" anyway). And Berzerk--and I think Realsports Baseball?--showed us what was possible with voice synthesis.

Link to comment
Share on other sites

I wasn't thinking so much about the voice. It could be left out entirely, or used when the screen is blanked out which I think might be worth the effort. Even the C64 pauses during speech. I was thinking more about the kernel. I would think that flicker could be used to draw the cab and the passenger as Player 0 and then player 1 could be used to draw lots of stationary objects such as pad numbers and the gas can and other objects. The game isn't really known for great graphics, so I think some of the harder to draw playfield objects could be changed to suit the strengths of the 2600.

 

I am a little surprised it hasn't been tried. Was Space Taxi not very popular?

Link to comment
Share on other sites

Damn, this thread really got me thinking... :)

 

I don't think a true port of the original game is possible. There are just too many objects (taxi, passenger, fuel pad, target pads with numbers, level-specific objects), or it would look really ugly (15 Hz flicker or even worse...).

 

But a game heavily inspired by Space Taxi would of certainly be doable, with its own level design tailored to the VCS' strengths and weaknesses. This is what I have in mind:

 

  • Restrict the playing area to PF1 and PF2 and use PF0 only for the enclosing border. That gives you 32 blocks = 128 pixels horizontally for level design of the interior area, and you'd only need to update PF1 and PF2 twice per scanline (in mirrored mode, that would need perfect timing, but it's doable).
  • Restrict the height of the playing area to ~20 blocks (each block being 8 scanlines high), again without the enclosing border. This allows for an 80 bytes framebuffer to keep in RAM making dynamic levels possible, with gates appearing/disappearing, walls moving etc.
    Not sure yet, but might be possible to use the framebuffer as an AND mask, allowing for higher resolution graphics stored in ROM where whole blocks can be switched on/off.
  • P0 would be the taxi. P1 would be either the passenger (if he's waving or walking), or the target pad (in quadruple mode) if the passenger is on the taxi. That means not all possible landing pads would be visible normally, only the current target would be, but that way you avoid flicker. To compensate, and give the player an idea where all possible pads are, the game will cycle through and show them during the initial "new level!" melody.
  • The refuel pad I'm not yet sure how to display. I'll probably have to construct it with M0, M1 and the ball somehow, as it has to be wide enough, but that's an ugly solution (visually and technical). I'll have to think more about that.
  • To make visuals more interesting, it would be good to be able to set a new color each block, either for the playfield or the background. Might be doable.
  • For fine-tuned controls and a good feel of gravity, ideally the resolution for the taxi's y position should be so that it could be on any scanline. I already have some ideas how to make that work within what is basically a 2-line-kernel inside an 8-line-loop, but I'm not sure yet if it will work.
  • Speech would cerainly be possible if the game will be bigger than 4K. Which most certainly it would be in any case if I want to have enough interesting levels, which would need individual blocks of code (moving walls, having different gravity, ...). During speech, the game might show a more simplified version of the level (without colors for example, or without some objects), but it should be doable without having to switch the screen off.

Right now I'm working on a prototype kernel for this and will report back if it works. :)

  • Like 3
Link to comment
Share on other sites

Alright, I would appreciate some input from those of you who have already published a game.

 

I have a kernel more or less working now (will show that soon) that displays a level, taxi, passenger or target pad, a refuel pad and which can set a new playfield color and background color every 8 scanlines. There are two versions: A small one which displays the level at a resolution of 32x20, similar in looks to Tanks (but with varying colors vertically), and a bigger one where levels have a resolution of 32x80. The latter allows for better level graphics, but obviously requires much more ROM per level as well.

 

There are different ways I could go forward now:

  1. A 4K game with low resolution, no speech and a medium amount of levels (about 16)
  2. An 8K game with low resolution, speech, and more levels (about 25?)
  3. A 16K game with high resolution, speech, and a medium amount of levels
  4. A 32K game with high resolution, speech, and more levels

I would strongly prefer variant 4, as I can be much more creative with level designs and more levels means more fun for the player. However, I have no idea what this means for a potential cartridge release, if it ever comes to that.

  • Would a 32K cartridge be more problematic production-wise than a 16K, 8K or 4K?
  • Is there a difference in acceptance among the player base?
  • Are there any other problems that I've missed?

Since the kernel architecture has such a big impact on the rest of the development, I'd really love to hear back from more experienced people. :)

 

(Damn, looks like I'm going make my first VCS game, yay! :D )

  • Like 2
Link to comment
Share on other sites

Alright, I would appreciate some input from those of you who have already published a game.

 

I have a kernel more or less working now (will show that soon) that displays a level, taxi, passenger or target pad, a refuel pad and which can set a new playfield color and background color every 8 scanlines. There are two versions: A small one which displays the level at a resolution of 32x20, similar in looks to Tanks (but with varying colors vertically), and a bigger one where levels have a resolution of 32x80. The latter allows for better level graphics, but obviously requires much more ROM per level as well.

 

There are different ways I could go forward now:

  1. A 4K game with low resolution, no speech and a medium amount of levels (about 16)
  2. An 8K game with low resolution, speech, and more levels (about 25?)
  3. A 16K game with high resolution, speech, and a medium amount of levels
  4. A 32K game with high resolution, speech, and more levels

I would strongly prefer variant 4, as I can be much more creative with level designs and more levels means more fun for the player. However, I have no idea what this means for a potential cartridge release, if it ever comes to that.

  • Would a 32K cartridge be more problematic production-wise than a 16K, 8K or 4K?
  • Is there a difference in acceptance among the player base?
  • Are there any other problems that I've missed?

Since the kernel architecture has such a big impact on the rest of the development, I'd really love to hear back from more experienced people. :)

 

(Damn, looks like I'm going make my first VCS game, yay! :D )

 

Awesome Kylearan! :) Your demos are fantastic, I'm looking forward to seeing what you create.

 

I think you should target all of the consoles including the portable which is gaining momentum.

 

4K is really cool but it's fine to use more - I think the only difference in acceptance is among other programmers.

 

How about going with 32K plus the extra Sara RAM? I bet you could make good use of it :)

Link to comment
Share on other sites

I remember checking it out back in the day because of the speech samples, but the stock PETSCII graphics with a handful of sprites flying around didn't hold my attention for long.

 

 

After watching a longplay, skipping ahead to check the various levels, the game looks to be much better than I remember.

Link to comment
Share on other sites

 

 

After watching a longplay, skipping ahead to check the various levels, the game looks to be much better than I remember.

 

Ah!.. I have to say, I was a little surprised when you said it didn't hold your attention. I was pretty heavily addicted to it myself! I think I have a pretty good kernel idea I might work on this weekend. I'm super busy, so who knows if I really will..

Edited by BNE Jeff
Link to comment
Share on other sites

  • P0 would be the taxi. P1 would be either the passenger (if he's waving or walking), or the target pad (in quadruple mode) if the passenger is on the taxi. That means not all possible landing pads would be visible normally, only the current target would be, but that way you avoid flicker. To compensate, and give the player an idea where all possible pads are, the game will cycle through and show them during the initial "new level!" melody.

IMO we don't need the passenger at all. Only the next pad to go has to be marked somehow (e.g. a blinking platform created by a missile). That would help reducing flicker.

 

The game needs an intelligent flicker kernel, which allows reusing sprites. So I would use P0 and P1 for all types of sprites (taxi, obstacles, fuel, maybe even the pad).

 

BTW: Go for 32K if you like. No problem here. IIRC everything above 4K has about the same production costs.

 

You should also think about the bankswitching you are going to use. Which is somehow determined by the amount of extra RAM you require. The standard Atari bankswitching has some disadvantages, because you either have to duplicate code (e.g. the kernel) or your amount of data for the kernel is limited to 4K minus kernel code size. So I would look for a more flexible bankswitching, where you can switch 1 or 2K slices and combine them freely within the 4K.

Edited by Thomas Jentzsch
  • Like 1
Link to comment
Share on other sites

IMO we don't need the passenger at all. Only the next pad to go has to be marked somehow (e.g. a blinking platform created by a missile). That would help reducing flicker.

 

The game needs an intelligent flicker kernel, which allows reusing sprites. So I would use P0 and P1 for all types of sprites (taxi, obstacles, fuel, maybe even the pad).

 

My current version of the kernel has no flicker at all. It displays the taxi updated each scanline (for smooth vertical movement) using P0. If the passenger is waiting for the taxi, he gets displayed using P1, updated every other scanline. If he's on the taxi already, P1 displays the target pad instead. The refuel pad is shown using M0, M1 and the ball, but this is updated only every 4 scanlines - but then the refuel station doesn't need a very high resolution. Playfield and background color can be changed every 8 scanlines.

 

The playfield is used to display the rest (the maze and obstacles, moving walls, blinking gates, magnets that pull the taxi closer, whatever). The playfield gets updated every 4 scanlines, for a playing area resolution of 32x40, where individual blocks of size 1x2 can be masked for the moving walls etc.

 

I think a lot of interesting levels will be possible that way even without using player sprites for high-resolution objects.

 

I hope I'll be able to showcase the kernel this weekend, for a less abstract discussion. :)

 

Besides the extra ROM (32K), right now I'm aiming for no extra RAM, DPC+ or whatever - at least there I'd like to stick to the original, for the challenge.

Edited by Kylearan
Link to comment
Share on other sites

Have a look at later levels (e.g. 10:20, 11:30, 26:20) in the longplay video Darrell posted above. There are a lot of moving obstacles (sprites!) in those levels.

 

True. But I think that an intelligent flicker kernel would make compromises in other places necessary that would diminish the overall experience too much for my taste. Updating the taxi sprite on every scanline is a must IMHO, or otherwise the feeling of fine-grained control which is very important in a gravity game gets lost. I'm also not a fan of playfield graphics with empty scanlines inbetween, which would almost certainly be needed for repositioning objects. And that doesn't leave much room for more hi-res objects.

 

What I'm trying to say here is that my game will not be a true remake of Space Taxi, more a game heavily inspired by its game mechanics. :) I'd rather concentrate on the abilities of the VCS and try to make a game that looks and feels good on its own than trying to recreate a game faithfully while making too many compromises along the way. That means some levels like the one with the shooting cannons at the bottom might shoot lo-res PF pixels instead, and some levels like the raining snowflakes might not make it at all, or only in spirit (raining blocky hail instead of hi-res snowflakes ;)).

 

I know people who'd like to have a true port of Space Taxi on the VCS will be disappointed (maybe BNE Jeff succeeds in that!), but it also means I can add completely new level ideas, free of the original's constraints - and I know I will have a lot of fun letting my creativity run wild. :-D

  • Like 1
Link to comment
Share on other sites

You should also think about the bankswitching you are going to use. Which is somehow determined by the amount of extra RAM you require. The standard Atari bankswitching has some disadvantages, because you either have to duplicate code (e.g. the kernel) or your amount of data for the kernel is limited to 4K minus kernel code size. So I would look for a more flexible bankswitching, where you can switch 1 or 2K slices and combine them freely within the 4K.

 

Oooh, if there are bankswitching methods that allow me to combine a 1 or 2K slice containing my kernel with a different 2K slice containing level data, this would be sweet! Thanks for the hint, I'll have a look into that.

Link to comment
Share on other sites

True. But I think that an intelligent flicker kernel would make compromises in other places necessary that would diminish the overall experience too much for my taste. Updating the taxi sprite on every scanline is a must IMHO, or otherwise the feeling of fine-grained control which is very important in a gravity game gets lost.

That's completely feasible, even with sprite repositioning.

 

I'm also not a fan of playfield graphics with empty scanlines inbetween, which would almost certainly be needed for repositioning objects. And that doesn't leave much room for more hi-res objects.

Yup, in a asymmetric PF, empty scan lines cannot be avoided when you reposition sprites. Unless you find an area with symmetry.

 

What I'm trying to say here is that my game will not be a true remake of Space Taxi, more a game heavily inspired by its game mechanics. icon_smile.gif I'd rather concentrate on the abilities of the VCS and try to make a game that looks and feels good on its own than trying to recreate a game faithfully while making too many compromises along the way. That means some levels like the one with the shooting cannons at the bottom might shoot lo-res PF pixels instead, and some levels like the raining snowflakes might not make it at all, or only in spirit (raining blocky hail instead of hi-res snowflakes icon_wink.gif).

That's fair. And its good that you make that very clear now, so we other people can start thinking out of the box too. icon_smile.gif

 

I know people who'd like to have a true port of Space Taxi on the VCS will be disappointed (maybe BNE Jeff succeeds in that!), but it also means I can add completely new level ideas, free of the original's constraints - and I know I will have a lot of fun letting my creativity run wild. icon_biggrin.gif

If your game is different enough, there should be plenty of room for a true port.
Link to comment
Share on other sites

 

My current version of the kernel has no flicker at all. It displays the taxi updated each scanline (for smooth vertical movement) using P0. If the passenger is waiting for the taxi, he gets displayed using P1, updated every other scanline. If he's on the taxi already, P1 displays the target pad instead. The refuel pad is shown using M0, M1 and the ball, but this is updated only every 4 scanlines - but then the refuel station doesn't need a very high resolution. Playfield and background color can be changed every 8 scanlines.

 

The playfield is used to display the rest (the maze and obstacles, moving walls, blinking gates, magnets that pull the taxi closer, whatever). The playfield gets updated every 4 scanlines, for a playing area resolution of 32x40, where individual blocks of size 1x2 can be masked for the moving walls etc.

 

I think a lot of interesting levels will be possible that way even without using player sprites for high-resolution objects.

 

I hope I'll be able to showcase the kernel this weekend, for a less abstract discussion. :)

 

Besides the extra ROM (32K), right now I'm aiming for no extra RAM, DPC+ or whatever - at least there I'd like to stick to the original, for the challenge.

If you want to stick to the original, there's a magic cutoff point somewhere around 1983 that RT wrote about.

 

That limits you to 4K, 8K with Sara or 12K CBS RAM. The SuperCharger format is contemporary too but the portable doesn't support it - same for the exotic bank switching schemes.

Link to comment
Share on other sites

If you want to stick to the original, there's a magic cutoff point somewhere around 1983 that RT wrote about.

 

That limits you to 4K, 8K with Sara or 12K CBS RAM.

 

Thanks for the info!

 

I realize I have worded that poorly (or probably more precise: Never thought that through completely :) ). I don't want to emulate the conditions of a certain time period, let's say 1982. I never owned a VCS back then (my first computer was a C64 in 1985), so that holds no meaning for me anyway. Instead, I'd like to preserve what makes the VCS special in comparison to other home computers.

 

What I mean by that is that the lack of RAM, the lack of a framebuffer and the weird sound chip in combination with only having 76 cycles per scanline is the main challenge that attracts me to the VCS, that makes programming for it so special. If I add more RAM, ARM support or a special music chip, I feel like I could simply move to the C64 instead and have a similar, but more "original" experience.

 

To me, adding a moderate amount of ROM is different however. All this allows is more data for levels, graphics, and music, but the fundamental way of how to make use of that data stays the same. (The exception is that more ROM also allows unrolling loops which gives you more computing power, but I'll stay away from that in this game.)

 

I hope that makes sense. :)

  • Like 1
Link to comment
Share on other sites

 

Ah!.. I have to say, I was a little surprised when you said it didn't hold your attention. I was pretty heavily addicted to it myself! I think I have a pretty good kernel idea I might work on this weekend. I'm super busy, so who knows if I really will..

 

 

I ran a BBS, so would have to take it offline if I wanted to play a game. If a game didn't catch my attention I wouldn't take the board down for it. Based on the longplay, I only made it to level 3.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...