In search of...

[wimoos]

for the real VIC-20 with 64HDD but no joystick:

- Sokoban
and
- Lemmings

(or is this too much too ask for a VIC)

and also a good arcade look-and-feel of
- Pacman

Regards

[Mayhem]

Lemmings would kill the poor Vic probably. Sokoban? I'm sure that's feasible but don't think anyone's attempted it. Now there's a challenge...

As for Pacman, you might be wanting this thread if you're after something looking like the arcade and not just playing like it (aka Jelly Monsters).

[carlsson]

Someone ought to have made a Sokoban clone? Some years there are thirteen a dozen in the MiniGame compo, but alas not for the VIC-20. While I generally like puzzle games, the Sokoban style bores me out totally so I wouldn't spend my time making a such game.

Lemmings... You are joking, right? But well who knows, by using rhurst's new software sprite library it may inspire someone to have a go.

[English Invader]

Would it even be possible for a game as complex as Lemmings to be programmed by a single individual?

I imagine any VIC-20 version would be greatly reduced from the original concept. The C64 might be a stronger bet.

[DanSolo]

The C64 might be a stronger bet.

http://www.gamebase64.com/game.php?id=4344

[English Invader]

I didn't know they made a C64 version. I always thought it was an Amiga thing like Zool or Sensible Soccer. I know the Mega Drive version very well.

[English Invader]

Here's a thought. How about a Ghostbusters game for the VIC-20?

It should be possible, and it certainly couldn't be any worse than the piece of shit they released on the Spectrum. They even released Ghostbusters for the Atari 2600 (and Ghostbusters II, for that matter).

Graphically, the VIC is definitely capable, but some of the extra features like the equipment shop would have to be omitted. It would be down to sheer gameplay, which is the VICs main strongpoint.

[Mayhem]

I didn't know they made a C64 version.

It came right at the end of the C64's commercial life in 1993. There's also a Spectrum version too for the 8-bits.

[shem]

I said it before but now that there are plenty of vic 20 programmers with a megacart (memory ) for me it would be bruce lee it can be done surley the graphics and sound wasnt amazing as it was an early c64 game but very playable so for me bruce lee is the way to go

[English Invader]

Has anyone ever made a VIC-20 version of Chuckie Egg? That would be simple enough.

[channelmaniac]

Am I the only geek reading this stuff in the voice of Leonard Nemoy? (The TV show "In Search Of...")

[TarkaTOtter]

Am I the only geek reading this stuff in the voice of Leonard Nemoy? (The TV show "In Search Of...")

In the UK I am obviously deprived - I think Nemoy is an excellent presenter/actor and I would have loved to see at least an episode of that show. Are there any clips floating round?

Tarka

[Mike]

Are there any clips floating round?

On YouTube: In Search Of... Bigfoot.

Back to OT: I've stored the 90 original level designs of Sokoban somewhere on my HD. They all fit in a 20x16 character screen, so a faithful port to the VIC is possible. It's just a Small Matter Of Programming ... The main program easily fits into 3.5K, even with user defined characters. And the levels can simply written as single files onto disc.

Alternatively [off to count the files ... back again]: the levels sum up to ~21K (no compression), so a one-file Sokoban should be possible as well, and could be fit into +16K if moderate compression would be applied.

Greetings,

Michael

[Richard James]

In Sokoban there are only 4 tiles if you discount the players starting position. This means you can use 2 bits to store each tile. At 20x16 you need 20 bytes + 2 bytes for storing the player start. 22Bytes x 90 levels is 1980 Bytes.

It can actually be done smaller than that. The size of the playing area is only 18 * 14 because the sides take up one position. The player start is also only within 18x and 14y needs 4bits + 5bits or 9 bits.

Edit
That's wrong oops.
The size is 82 bytes usings 2 bits per tile + 2 bytes for start. So it uses 82 * 90 = 7380Bytes. If you lower the area to 18*14 you can use 65 Bytes to get a total of 5850Bytes to store all levels. Further compression may be possible.

[Mike]

In Sokoban there are only 4 tiles [...]

Actually, you don't get below 5 different tiles, because you have empty tiles, walls, boxes, targets, and boxes already on target.

And that's concerning the level definition only.

Within the game I'd use a relaxed, but still efficient encoding that maps well to user defined characters:

Code: Select all

%000: empty
%001: player
%010: box
%011: wall
%100: target
%101: player on target
%110: box on target
%111: not used

This is so that the information, whether the player or box stood on an empty tile or a target field can be easily reconstructed.

The size of the playing area is only 18 * 14 because the sides take up one position.

But the levels do not always fill out the complete 20x16 area. You'd be going to put an "artificial" wall surrounding the 18x14 screen anyway. IMO this only complicates the game implementation unnecessarily.

If you're interested, we can collaborate towards a working game - I'd propose to make the unexpanded version, with levels read off disc.

Using this joystick routine, the main loop could be as short as this:

Code: Select all

zz D=USR(0):A=PEEK(P):B=PEEK(P+D):C=PEEK(P+2*D)
   IF(BAND3)=0THENGOSUBxx:REM move player to empty tile, or target
   IF(BAND3)=2AND(CAND3)=0THENGOSUByy:REM move box
   IFN<MTHENzz:REM repeat loop

with N: current number of boxes on target, M: number of targets

The level files look like this:

Code: Select all

    #####
    #   #
    #$  #
  ###  $##
  #  $ $ #
### # ## #   ######
#   # ## #####  ..#
# $  $          ..#
##### ### #@##  ..#
    #     #########
    #######

with:

Code: Select all

 : empty
#: wall
$: box
.: target
*: box on target
@: player, starting position

Greetings,

Michael