Path to Wizard of Wor

[beamrider]

Very nice conversion! Might it be too optimistic to say that now that you've created this game engine, you are half-way toward finally realizing Wizard of Wor on the VIC-20?
It seems to be a very similar type of game - shooting enemies while walking around a maze. "Sprites" (or whatever the moveable graphic objects really are) seem to be about the same size as the ones in Wizard of Wor, etc.

Ha ha - haven't I heard that game mentioned before on here?

I think the reqirements for that are quite different and from my rough sizing mockup below would require tall 3x2 smooth moving sprites..

[rhurst]

You're such a tease!
Just played a few rounds, a sweet action game with good intensity. Never played this before, but it does makes me think of Tron and also Front Line.

[bills442]

Very nice conversion! Might it be too optimistic to say that now that you've created this game engine, you are half-way toward finally realizing Wizard of Wor on the VIC-20?
It seems to be a very similar type of game - shooting enemies while walking around a maze. "Sprites" (or whatever the moveable graphic objects really are) seem to be about the same size as the ones in Wizard of Wor, etc.

Ha ha - haven't I heard that game mentioned before on here?

I think the reqirements for that are quite different and from my rough sizing mockup below would require tall 3x2 smooth moving sprites..

Nice. I like WOR quite a bit. I'd be interested in helping out with programming or other on a such a project ; maybe a github thingy... should you catch further interest in it. Maybe Denial community members could sketch out needed details like this of such an effort and start something on github; even if it languishes in incompleteness ,lol.

[beamrider]

Someone else will have to take the reigns on that one. I'm afraid its not really my favourite game.

[tokra]

[Wizard of Wor]

I think the reqirements for that are quite different and from my rough sizing mockup below would require tall 3x2 smooth moving sprites..

Topic drift ahead... I've always wondered why most games stick to the video-screen setup of chars by the VIC (8x8 pixel blocks) even when using soft-sprites. I realize it makes things easier because you can place different character-tiles around the screen easily. But this also means the game will have the "VIC"-look of very wide characters because of the screen and character-format.

When you are doing soft-sprites you will be changing more than one character at a time anyways, so why not just bitmap the whole screen area and modify the bitmap instead an area of characters. When you have more than a few moving objects the penalty should not be too bad I think. I am thinking about your excellent Pooyan-game. This one has lots of moving objects in it. Does it obey char-boundaries or modify the full bitmap?

The closest VIC-game to Wizard of Wor yet I think would be Berzerk MMX. It has a similar looking maze, and multiple monster sprites as well.

[beamrider]

Pooyan actually uses the Vic SSS by Robert Hurst and therefore "character" mode sprites.

...but yes I can see the advantages of a bitmapped aproach for some things. It depends on the game I suppose, certain operations would be problematic, scrolling for example comes to mind.

Indeed, we have gone a bit off-topic, perhaps a mod could move these Wizzard of Wor related posts to a new thread - "Wizard of Wor design chat" or similar?

[Jeff-20]

PAL only?! Haha It really looks great. I think I first discovered this general game design from the original Gameboy.


Sent from my phizzone

[orion70]

Indeed, we have gone a bit off-topic, perhaps a mod could move these Wizzard of Wor related posts to a new thread - "Wizard of Wor design chat" or similar?

Done

[beamrider]

Thanks.

Been playing this game a bit, and warming to it...

If you look online, it seems the Bally Arcade version is regarded as the best conversion, beating the C64 version despite blockier graphics. I figured the Vic-20 verision could look similar.

https://www.youtube.com/watch?v=862HtcniQk8
https://www.youtube.com/watch?v=mIuXQE893m4

IMO a border would ruin the game, so multi-colour mode could be used with the black border colour filling up the background leaving the other three colors for the game. Using a single character color throughtout would speed up sprite rendering removing the need to update color ram and elimiate any potential colour clash.

As a test case for recent changes to my screen/character editor [to allow sharing content], I created up a rough mock-up of how this might look on the Vic. It's based on a layour of 24 rows/26 columns. This should work on PAL/NTSC but the width may need to be trimmed down a bit to fit on a CRT. Haven't checked.

http://87.81.155.196/vic20sdd/Vic20SDD. ... %3Fraw%3D1

.. slight delay after loading before the image apppears.

[joshuadenmark]

Looks really fine, I like this design and colors, impressing work.


Sent from my iPad using Tapatalk

[Mayhem]

If you look online, it seems the Bally Arcade version is regarded as the best conversion, beating the C64 version despite blockier graphics. I figured the Vic-20 verision could look similar.

The Bally Arcade version is mightily impressive for the hardware, but I'd have to disagree, the C64 conversion is the best of the lot, and in my opinion, a better game than the arcade! A bit more fair, a bit more playable, less obvious a money grab heh. Add the Magic Voice for the "full" experience

[bills442]

Hi BeamRider;

My first question to the discussion was going to be what to do about colors and see how people felt about multi-color mode. This makes it look doable as a multicolor mode game; although my initial concern was the probably the same as everyone else's when a multicolor game it put on the table: will the resolution be enough and will the relatively chunky movement allow the gameplay to be ok. The latter is a harder question to answer until actually playing.

Is this something that Robert's sprite library could be used for again, or As Tokra was talking about; mapping the entire screen in Hi-Res? What would the advantages and disadvantages be? One advantage of the 'character' based approach would be when the screen goes 'crazy' for the 'Double Score Dungeon'. It would be easy to rapidly change the appearance of many tiles on the screen using the character based approach.

Robert did the cool sampled voice playback from his Berzerk game. I assume we could either steal the sameples from the MAME roms for WOR; or resample them again?

Another interesting feature is second player support. One option of course is keyboard control for a second player; or even the 'second' joystick wired up to the user port on the VIC. Some more interesting options are using the 'net play' thing I saw in VICE ( which I know nothing about beyond seeing its name and guessing it was for internet two player games). Finally, even more silly is a little interface using a 9 dollar Arduino I've sourced off ebay that allows cheap communication from the VIC user port to USB. I was imagining a way for people that had real VIC hardware sitting next to an internet enabled PC to play with other people; but that's stuff that would be way far off -- although fun to think about.

I saw your last game was written in C? Is that something to consider again for a WOR project? Did you use CC65 for that?

Did you develop in Windows or Linux? What emulator do you like to target during development?

[beamrider]

Hi Bills442

Whilst multi-color does reduce (horizontal) resoloution, it has the advanatage of elliminating color-clash and also the border. IMO these are very wothwhile tradeoffs (I can't stand colour-clash), but yes this is very much a matter of opinion. As for the smooth movement issue, we are only talking about a two-pixel horizontal stepping which looks fairly smooth anyway. Also, I'm not sure whether the Vic even has the horsepower to animate those 3x2 sized sprites at single pixel stepping.

As it stands, Vic-SSS doesn't handle 3x2 sprites (up to 2x2), although we do have the source code. Bit-Mapping the entire screen is another option as well and I belive Robert Hurst may even be working on something along those line. My mock-up was just to illustrate one possible approach.

Yes, multiplayer would be an option. I think a user-port joystick/or keyboard would be the easiest to support. Not sure about the speech, but I'm guessing that would push it to a 32K game without external hardware being used.

[edit] - Just found this...
http://www.geocities.ws/cbm/doc/weekend_vox.html

I developed Tank Battalion in 'c' as I wanted to try it out after Pooyan (written in assembler). It took me just over a month (compared to 9 months for Pooyan) so there are definitely productivity gains. However the code it produces takes up a lot of space - I think that Tank Battalion would have been an 8K game in assemler. Also, I guess performance is reduced having to exectue those additional instructions.

See below - I develop in Windows using NotePad++ and CA65/CC65 (with the NppExec and Explorer plugins) giving a Visual Studio like experience. I can switch between files on the left, edit and then just hit Ctrl+F6 to compile the code. Compiler output is shown in the section at the bottom and then it starts Vice if successful. Of course I now use the Vic20 Screen/Character designer as well

[tokra]

This looks very nice already! I love the idea using 3 char high, 2 char wide sprites as these would due to the pixel-aspect-ratio actually look like square sprites on a PAL-VIC20 and not like your typical VIC-game.

I would probably go for blue for the maze (aux color) to keep the arcade-feeling, red as background and yellow as char color for the whole screen. The arcade only uses these three colors and black as well:

https://www.youtube.com/watch?v=D780JHlQxxs

Apart from the star background this lends itself perfectly to multicolor-mode

[bills442]

A couple of quick thoughts before we retire on this side of that Atlantic.


The Balley game I looked at on the link you sent didn't seem to have a sprite much bigger than 9x9 or so?
I like the idea of using existing tooling ( like Rob's SSS ) and also the super labor savings of using the C language. I hear you; with a day job, hand coding stuff in assembler is quite a time consuming thing; although often more fun than (my) day job.

On the other hand; everyone really seems to love your larger sprite idea. As to the horspower thing; I was thinking, there is no 'playfield' we have to preserve when moving the sprites in this game; it's always a bleak black background; so we could save all the cpu work of loading and masking and what not to preserve the background. We could just blit the pixels and set them back to black when done. That might make moving such big sprites possible. Didn't that Atarisoft pacman move some massive sprites around without much trouble?

So I guess the big decisions are:
smaller sprites usable with SSS and C to actually get a game done quickly and with less suffering
or a custom solution?

I'm kinda interested in trying something in C for the same reasons you stated you did. Just let the memory model be as large as needed, ha ha. I'm done pinching bytes.

I like your windows environment! I did my last vic project in windows -- but my laptop died this year with some windows virus and I went ballistic on Windows and installed linux. I've sort of been rediscovering my unix roots again ( spent my 90s on unixes of various flavors) , so I've been hacking in emacs. Vice is great though and works on both platforms effortlessly. If we ever get to setting up a github for this; I'd could take extra care to make sure it has a nice multiplatform build system format that could build on any system.

My desktop is still windows anyway, so I'm playing both teams right now.