WIP: Vic M.U.L.E.
Moderator: Moderators
Very crude mock-up, can be improved a lot with custom graphics:
A bit better, using custom graphics that would work in the playfield:
The double width vertical lines are because I'm planning to add black mountains (multicolour #4) and those characters would be low resolution. Perhaps it would even be possible to draw those characters on the fly when the game starts, or I pre-design a few different variations.
I'm thinking the graphic element to install your mule might be simplified to begin with, moving the mule stepwise instead of using a software sprite.
A bit better, using custom graphics that would work in the playfield:
The double width vertical lines are because I'm planning to add black mountains (multicolour #4) and those characters would be low resolution. Perhaps it would even be possible to draw those characters on the fly when the game starts, or I pre-design a few different variations.
I'm thinking the graphic element to install your mule might be simplified to begin with, moving the mule stepwise instead of using a software sprite.
Anders Carlsson
Let's see which properties we need to store in a matrix:
Type of square: plain, river, 1-3 mountains, store (6 values)
Crystite value: 0-4 (5 values)
Owner: none or player 1-4 (5 values)
Installed commodity: none, food, energy, smithore or crystite (5 values)
Commodity value: 0-4 -- or are all commodites worth at least one dot?
Of course production will also be stored, but only temporarily for each round.
I'm trying to represent this as compact as possible. I'm using a matrix of 56 bytes (8x7) and three ASL to multiply row by eight. That is a slack of at least six bytes, but I doubt I can come up with a routine to multiply a number by seven in nine bytes. I'll see if the code to shift high nybbles out of a byte is small enough so I can store at least two of the properties above into the same byte. Maybe aiming for unexpanded VIC is too much, but even if it becomes a +8K game, saving space is a good idea.
Type of square: plain, river, 1-3 mountains, store (6 values)
Crystite value: 0-4 (5 values)
Owner: none or player 1-4 (5 values)
Installed commodity: none, food, energy, smithore or crystite (5 values)
Commodity value: 0-4 -- or are all commodites worth at least one dot?
Of course production will also be stored, but only temporarily for each round.
I'm trying to represent this as compact as possible. I'm using a matrix of 56 bytes (8x7) and three ASL to multiply row by eight. That is a slack of at least six bytes, but I doubt I can come up with a routine to multiply a number by seven in nine bytes. I'll see if the code to shift high nybbles out of a byte is small enough so I can store at least two of the properties above into the same byte. Maybe aiming for unexpanded VIC is too much, but even if it becomes a +8K game, saving space is a good idea.
Anders Carlsson
- Mayhem
- High Bidder
- Posts: 3031
- Joined: Mon May 24, 2004 7:03 am
- Website: http://www.mayhem64.co.uk
- Location: London
Just aim for +16K RAM tbh. Today most people either have or can get RAM expansion that size quite easily (unlike back in the day!).
But saving space programming wise is a good idea anyhow, leaves more room for graphics and stuff!
I like the idea of using each byte for 2 values. Given there are four players helps here...
0000 0000
plot owner - installed commodity
0000 = no owner or nothing installed
Then you can have 1000, 0100, 0010 and 0001 for the players and what is on the plot (food, energy, smithore or crystite).
Depends if the programming process to interpret that storage method outways the memory needed to just store everything per byte
Commodity value wise, I believe you can have value 0 but it's been a while since I played MULE I'd have to recheck. I think it goes above 4 as well (this is the dot indicator about what the plot should produce), but certainly you can have actually production at least up to 6 or 7 if the conditions are right.
Look forward to a playable code version, definitely interested in helping to play test
But saving space programming wise is a good idea anyhow, leaves more room for graphics and stuff!
I like the idea of using each byte for 2 values. Given there are four players helps here...
0000 0000
plot owner - installed commodity
0000 = no owner or nothing installed
Then you can have 1000, 0100, 0010 and 0001 for the players and what is on the plot (food, energy, smithore or crystite).
Depends if the programming process to interpret that storage method outways the memory needed to just store everything per byte
Commodity value wise, I believe you can have value 0 but it's been a while since I played MULE I'd have to recheck. I think it goes above 4 as well (this is the dot indicator about what the plot should produce), but certainly you can have actually production at least up to 6 or 7 if the conditions are right.
Look forward to a playable code version, definitely interested in helping to play test
Lie with passion and be forever damned...
Yes, production has a maximum of 8, but commodity value is at most 4 (food on river, very high crystite, some smithore on three mountains). Later on I will need to investigate how land value differs too; some plots are worth a few more points than others but it was long ago I played the game.
FWIW; maybe I'll make a similar game that is not trying to be a perfect copy. I've been playing with the idea of making a M.U.L.E. like game where the plots are ordered in a hexagonal pattern instead:
Since the game honors plots next to eachother beloning to the same player, and perhaps of the same commodity type, it could be an interesting variation to have up to six neighbours to each square instead of four. It also opens for more artistic freedom.
FWIW; maybe I'll make a similar game that is not trying to be a perfect copy. I've been playing with the idea of making a M.U.L.E. like game where the plots are ordered in a hexagonal pattern instead:
Code: Select all
___
| |
_|_ _|_ ___
| | | |
|___|___|___|_
| | |
|___|___|
Anders Carlsson
- Mayhem
- High Bidder
- Posts: 3031
- Joined: Mon May 24, 2004 7:03 am
- Website: http://www.mayhem64.co.uk
- Location: London
I'll take your word on the production dots, though I could have sworn I've seen higher. Memory and age, you know, that sort of thing
I think producing a Vic20 version of MULE would be an excellent tribute to Danielle Berry and show that the game can live on, even on hardware more underpowered than when it was originally written
Fortunately the design of the game does not conflict with the control availability on the Vic. You only really need the joystick for the first section and that's done one by one, so the single joystick port isn't going to affect matters. You just need a good keyboard reading routine for the up/down controls of the auction section.
Have a good Google about for MULE pages, there's one out there that lists all the random events for example and other details for reference and inclusion into the game. Tbh I never quite figured out the routine for land prices either.
The version on the C64 had the intro and setup in one load, and the main game in another, so you've got some freedom I'd say to not consider having to try and cram everything into one load. Maybe try and recreate the theme music if possible heh.
The hardest part imo is going to be writing some AI routines for the computer players...
I think producing a Vic20 version of MULE would be an excellent tribute to Danielle Berry and show that the game can live on, even on hardware more underpowered than when it was originally written
Fortunately the design of the game does not conflict with the control availability on the Vic. You only really need the joystick for the first section and that's done one by one, so the single joystick port isn't going to affect matters. You just need a good keyboard reading routine for the up/down controls of the auction section.
Have a good Google about for MULE pages, there's one out there that lists all the random events for example and other details for reference and inclusion into the game. Tbh I never quite figured out the routine for land prices either.
The version on the C64 had the intro and setup in one load, and the main game in another, so you've got some freedom I'd say to not consider having to try and cram everything into one load. Maybe try and recreate the theme music if possible heh.
The hardest part imo is going to be writing some AI routines for the computer players...
Lie with passion and be forever damned...
- Mike
- Herr VC
- Posts: 4901
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Should the result fit into a byte as well? Then (xx = temporary ZP):carlsson wrote:I'm using a matrix of 56 bytes (8x7) and three ASL to multiply row by eight. That is a slack of at least six bytes, but I doubt I can come up with a routine to multiply a number by seven in nine bytes.
Code: Select all
STA xx
ASL A
ASL A
ASL A
SEC
SBC xx
Michael
Edit: An even better solution of course would be to make the screen having 24 columns. It's no big deal to recenter the screen regardless of PAL or NTSC, if you use the ROM values at $EDE4 ...
Mike: cool idea about multiplication by seven, but it only saves one byte in this application, assuming XX is a zeropage address. 24 columns would give room for eight real columns, but it would put the store off-center.
Mayhem: in case you missed it, I already converted the music in 2002 (with exception for simplifying the triplets into eighth notes) and it was used in VIMMII, the plasma part IIRC. Certainly a rehaul is in order.
Mayhem: in case you missed it, I already converted the music in 2002 (with exception for simplifying the triplets into eighth notes) and it was used in VIMMII, the plasma part IIRC. Certainly a rehaul is in order.
Anders Carlsson
- Mayhem
- High Bidder
- Posts: 3031
- Joined: Mon May 24, 2004 7:03 am
- Website: http://www.mayhem64.co.uk
- Location: London
http://www.cs.tut.fi/~albert/Pu-239/vimmii/
Or on demodisk1.d64 at Zimmer's FTP:
ftp://ftp.zimmers.net/pub/cbm/vic20/demos/
ESC skips parts. First comes the intro, then a long slideshow, a DYCP part and the plasma part.
Or on demodisk1.d64 at Zimmer's FTP:
ftp://ftp.zimmers.net/pub/cbm/vic20/demos/
ESC skips parts. First comes the intro, then a long slideshow, a DYCP part and the plasma part.
Anders Carlsson