Heyas!

Sorry if this is a duplicate post, I'm having trouble with the web interface.

I've been very busy writing an implementation of Monopoly for the Commodore 64.

I've decided that it would be acceptable to upload it at this point. It is only in ALPHA condition, please be aware. That said, I have tested it quite a bit but I can't say exhaustively.

I thought it might be nice if other people wanted to play and could help me with the testing.

AFAIK, it is the most standard rule compliant version ever written. If you haven't read the standard rules, please read the documentation thoroughly. I don't actually include a list of all of the standard rules in there but do discuss them enough that
if you aren't aware of certain details, you should be able to understand how the game is supposed to be played by them. In particular, trade and elimination rules may be unfamiliar to casual players.

There are some outstanding issues...

Firstly, eliminations aren't being done as I propose in the documentation. I implemented them "strictly" (more like blindly) according to the rules at first
but have since (after doing the trades) decided to do them slightly differently. I will rework
them soon. I discuss the issues in depth in the documentation.

Secondly, there is no ability to quit as I propose in the documentation. I will get to that soon.

Thirdly, there is no joystick support which I really want to have in order to better play "on the go" from VICE on Android.

So, enough of the preamble, where do you get it?

Its available from my GitHub repository. https://github.com/M3wP/Monopoly

You'll find a .prg and a .d64 in the /C64/bin directory.

I'm open to any and all suggestions and comments.

Please enjoy!


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Oh, I should mention that there is no real "user documentation". Some of the interfaces are a little complicated and may not be fully understood at first glance. I may get around to writing some at some point in the future, if there
is a demand. I'm a
little tired from writing some 500 pages of code with about 10 pages of documentation already.


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Oops, I realise I should post a bit of background, especially since there is a version of the game already available for the C64.

I love the game. I wanted to be able to play it when I was travelling but it costs $10 USD or so to purchase for the Android tablet. I wasn't prepared to pay that much (I've bought it for an Android phone before and the PC already).
I wanted to have a
standard rule compliant game which I've found no version to actually be. There
are also no networked versions I know of that are worth playing.

I figured I'd give myself a programming challenge and write it. It had to be for the Commodore 64, of course!

Initially, I wanted to make the game networked, multi-player. I looked into how to use Contiki for this but once I realised it was too complex a task to begin with, I decided to implement the game stand-alone first so that I could see what might
actually be required to do it the other way.

It was a bigger challenge than I realised...

I wanted it to be fast and actually playable. The original C64 version was neither, IMHO. I wanted a version that could challenge the PC version I have for authenticity and desirability. It had to be standard rule compliant. Also, the PC version I
have has the American place names which I really don't like so it had to have the proper English ones. I think I've succeeded in all these goals.

If you enjoy the game, you should enjoy this version too.

I should mention that presently there is no CPU player. It wasn't a goal, initially. I was going to write the server on the PC side only and have the CPU player there. I feel that writing a decent CPU player on the C64 in assembly may be a rather
difficult challenge. I have only about 7KB of memory left unless I switch out the Kernal and do some tricky things. There are also some optimisations to be done. It would possibly be enough (I think I know how to approach it) but I will leave it for
another version. Help with this would be greatly appreciated.

I intend on writing the client/server version next and writing a Mega65 network
client as well. I no longer intend on making a C64 network client. I might be
persuaded to do this but I think I would also prefer some help with this as I'm
very
unfamiliar with Contiki and how to build it with cc65/ca65.


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2018-07-01 21:39, Daniel England : All wrote:

I should mention that presently there is no CPU player. It wasn't a
goal, initially. I was going to write the server on the PC side only
and have the CPU player there. I feel that writing a decent CPU player
on the C64 in assembly may be a rather
difficult challenge. I have only about 7KB of memory left unless I
switch out the Kernal and do some tricky things. There are also some optimisations to be done. It would possibly be enough (I think I know
how to approach it) but I will leave it for
another version. Help with this would be greatly appreciated.

This could be viewed as "the fun part" as seen from other persons
viewpoint. The hard part would be to figure out how much of the
internals a bot should be able to see or not, I seem to recall that was
one of the things the computer opponent in FreeCiv gets on "hard", it automatically knows where your cities are, which of course helps it
become a much tougher opponent.

But good luck on the game in general, nice to hear about the effort to reimplement the game once more.

---
* Origin: - nntp://news.fidonet.fi - Lake Ylo - Finland - (2:221/6)

Heyas!

I also forgot to say that the game is in active development. I guess I thought
that would be obvious given that its an ALPHA.

Anyway, if you do test the game, be sure to check for updates regularly.

If its acceptable, I'll post about significant updates here, too.

Since I'm already posting and there are some potentially interesting/important updates already, here is the change log from the commit:

Incremental Update
- Fixed PStats dialog values
- Tweak a few things (optimise trade data area)
- Fix PlyrSel menu returning functionality
- No trades when in debt!
- More options shown on more menus
- House Rules config & implement Free Parking Taxes
- Best fix for some sound issues
- Disable debug keys by default


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Heyas!

Well... I've reached another milestone with the game.

The joystick input driver and interface changes I wanted are now in. I must say that controlling the game with the joystick is a dream. Its just how the game should be played! Playing full-screen on an Android tablet with the joystick overlays is
awesome. Please give it a try! You'll be delighted.

Also, I have reworked eliminations such that they now work as I propose in my deductions and use the trade interfaces. This was an important step. It means
that I am now 100% of the core rules implementation that I want.

So, now there are only a few relatively minor tasks left before I can move the game into BETA state. I need to implement quit requests (additional rules, not
core), give a bit more feedback in certain cases and tidy up the button order on the trade
selection dialog.

I have also forgotten to say that I'm interested in getting feedback from anyone testing on the real machine, especially now with the interface changes.
What do you think of the input sensitivity? How does the configuration fare on
an actual joystick?
Also, what do you think of the sound (keeping in mind the limitations)? I haven't heard it on real SIDs.

Thanks for your time!


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Another bit of a milestone... There is now the ability to build a version that
has a CPU player.

It knows how to play some of the game, namely rolling the dice, buying deeds, getting out of gaol and out of debt. It can't buy improvements nor participate
in auctions, trades or eliminations just as yet. If it had improvements, it would know how to
sell them in the debt handling, though. The feature support is coming in stages.

I don't include the CPU player in the build on GitHub so to use it, you need to
build it yourself after changing the DEBUG_CPU define to 1 instead of 0. Player 2 will then be set as a CPU player. There are some limitations and if it gets lost, you can
sometimes press the keys to control the (now invisible) menus. If the CPU gets
stuck, it will produce an error message and stop running (human control will resume). Its quite rough but I'm working on it. I may be able to help if you want to use it and
are having trouble building it.

I've done a lot of bug fixes, optimisations and feedback enhancements as well.

Oh! The strings data is now loaded into "high memory" at launch so the game has to be run from a disk. I haven't been able to get the compression I want working just as yet so the entire load process is far longer than I desire. I apologise to anyone
on a real machine with a 1541 for having to slow load 195 blocks. Its a fair while.

All but one of the tasks on my list for moving to BETA state have now been completed. I will be doing this soon.

Please enjoy!


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hmmm. and I have to ask why you would want to do this game when there
were several IIRC nice versions of it (IMHO) for the C-64 done 25 years
ago? Sincerely,
--
J. B. Wood. e-mail: arl_123234@hotmail.com

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2018-07-10 05:15, J.B. Wood : All wrote:

Hmmm. and I have to ask why you would want to do this game when there
were several IIRC nice versions of it (IMHO) for the C-64 done 25 years
ago? Sincerely,

After seeing the Donkey Kong 2016 remake for C64, the question "why
would you reimplement something from 25+ years ago" got totally invalid. ;)

---
* Origin: - nntp://news.fidonet.fi - Lake Ylo - Finland - (2:221/6)

On Tuesday, 10 July 2018 20:15:40 UTC+10, J.B. Wood wrote:

Hmmm. and I have to ask why you would want to do this game when there
were several IIRC nice versions of it (IMHO) for the C-64 done 25 years
ago? Sincerely,
--
J. B. Wood

Because they don't follow the standard rules nor are they actually playable, IMHO.

If you play my version you'll see that its a greatly improved experience over the Waddington's version.

My version is rather "no frills" but its fast and true to the standard rules. I have a 10 page document detailing how it is probably the best, in terms of rules compliance, version out there.

Besides all of that, I wanted to. I wanted to make a version I could play on VICE on Android and that had better rules compliance than any other version I know. It had to be as a good an experience as the modern versions which meant it had to be much
faster than other releases of it on the C64 and also that it had to be fully turn-based (all the modern ones are).

I had initially wanted to make it a networked client but it was too difficult a
task and I probably won't be able to do this for the C64 but intend on giving it a try for the Mega65 once I write the PC-side server. There are currently no networked
versions worth playing, AFAIK. This version was something of a stepping stone.

In short, its because I didn't like the other versions and wanted something better. I think if you play my version and compare you'll agree that it is. I'm quite passionate about the game and the other versions just don't do it justice, IMHO.


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Heyas!

Another milestone has been reached. Most of the CPU player functionality has been implemented and you can now select how many CPU players you want in the game.

The CPU can do everything except initiate/approve trades. The game is quite playable with the CPU players and they do try to win. If you enable DEBUG_CPU,
the CPU player will blindly approve all incoming trades but you will need to build that version
yourself.

I have also made extensive enhancements to the trade and elimination transfer menus and selection dialog based on user feedback.

There have been many bug fixes and other improvements, as well.

There is only a few minor changes and testing required before I can move the game into BETA status. I am preparing the list of final changes for RELEASE and it is not that long so far.

I'm really impressed with how fast the game runs, especially the CPU player "thinking" time... It doesn't get in the way of a good game.

Enjoy!


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Heyas!

I didn't expect it to come so quickly but another milestone has been reached.

The CPU behaviours are all now finished (with some notes about possible improvements) and all of the core functionality is now implemented.

I have been furiously testing, debugging and optimising as well and the game seems to be quite stable now (all of the major functions seem to work correctly
in as many combinations as I've been able to come up with).

So, I'm happy to say that I have also moved the game into BETA status.

If you've been waiting for it to be stable to play, it certainly now seems to be.

I'd love to hear from anyone playing it and about your experience.

Unfortunately, I am running quite short on memory and so a few items on my TODO
list won't make it for release but I'm hoping to get some more real estate after another few rounds of optimisations.

I hope you will enjoy!


Daniel.


PS: If you're interested in doing some stress tests or trying to check off items on the "need to test" list then you may want to enable DEBUG_HEAP, DEBUG_GSTATE and DEBUG_ACTIONS and compile. Having those enabled will tell you
if anything goes awry.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Incredible work here. I played the game and checked out your repo. Well done sir. Keep up the good work.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thursday, 2 August 2018 16:27:11 UTC+10, xlar54 wrote:

Incredible work here. I played the game and checked out your repo. Well

done sir. Keep up the good work.

Hey cool, thanks very much! I've enjoyed making it.

There is a user manual for it now, too.


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hi Daniel, congratulations for this work.
I been looking the source code of c64client.s, it's very large.

what source code editor do you use?

1-Why write floating point routines if they already exist on ROM?
For example I write an application for GEOS-64 using geoProgrammer to plot 3D functions, using the floating point routines in ROM.
-
2-Why doesn't use the natural PETSCII characters through CHROUT kernal routine? -
Suggest:
1-In "initDataLoad" section, load the X register with the last device used.
For example on VICE for c64 I have the device 9 pointing to a Windows/MSDOS directory
I can load the "c64client" but fails to load the other files.

2-The drivers for mouse and joystick on external files




bye
alvalongo

P.S. It will take me a while to fully understand the source because this ar65 assembler has some advanced features geoProgrammer doesn't have like "struct"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Friday, 3 August 2018 23:37:07 UTC+10, alvalongo wrote:

Hi Daniel, congratulations for this work.

Heya! Thanks!

I been looking the source code of c64client.s, it's very large.

what source code editor do you use?

Yes, its gotten very large and almost monolithic. I do intend on fixing that.
I have already marked out where I need to break the source up. 1100 A4 pages in the old listing format with a normal font. Not a bad effort!

I use SciTE but in plain text mode. In whatever editor you decide on using, you'll want to use a mono-spaced font and tabs set to 8 spaces.

I did make a patch for EMacs so that it can deal with my files in its ASM mode because someone else was using it to edit my files (with my specific indenting). I can provide this patch if you require it.

1-Why write floating point routines if they already exist on ROM?
For example I write an application for GEOS-64 using geoProgrammer to plot 3D

functions, using the floating point routines in ROM.

I needed to reclaim the other 7KB or so of memory you get by switching out the BASIC ROM. I couldn't afford to keep the ROM just for the floating point routines. I currently have only 3KB of free memory or so after switching out all the ROMs... I'm
pretty happy to have some Woz code in my game...

2-Why doesn't use the natural PETSCII characters through CHROUT kernal

routine?

Ummm... Is this in the bootstrap/init or for the whole game? I needed to draw
the characters in my own way and without the line-breaking functionality. And I always suspected that I'd need to drop the Kernal ROM, too.

In the early init, it seemed to be just as much code to directly write the characters to the screen as it was to use the Kernal so I just used my own routine. I use Pascal-style strings...

Suggest:
1-In "initDataLoad" section, load the X register with the last device used. For example on VICE for c64 I have the device 9 pointing to a Windows/MSDOS

directory

I can load the "c64client" but fails to load the other files.

Yes, that would probably be a good idea. At the moment, the game has to be run
from drive 8. There is no error handling on the file load, either. Terrible.

2-The drivers for mouse and joystick on external files

Hmm... I'm not sure... If I do that, I'd need to reserve specific memory for it and "high memory" has only 700 bytes free or so in total if I consolidate the areas and pair-back the actions cache/heap to whats actually minimally required.

I guess I could do so but I didn't want any more loading after the initial load, either.

It may happen but will need to wait until later. I have to disentangle the device driver code from the IRQ handler as well.

bye
alvalongo

See you! Thanks for looking at the code! I've been the sole developer and I probably need another pair of eyes on the source...

P.S. It will take me a while to fully understand the source because this ar65

assembler has some advanced features geoProgrammer doesn't have like "struct"

Yes, I'm using it because it seems to be the best in terms of what it can do and the syntax is not confused with strange symbols. I'm not even using it to its fullest potential, just in its "none" target mode.

I've started the process of fully documenting the code now, too. All of the new routines have good commenting but the older ones are a little dry. My apologies. I have tried to use meaningful names for everything, though.

Structs are just a way of declaring scope-bound constants (the offsets). Quite
handy.


Daniel.


Oh! Feel free to contact me directly if you like, instead of going through the
newsgroup. I think my address is "discoverable". I'll add it to the readme soon, anyway.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I forgot!

I'm using a tool to build the strings.inc file from a data file and a header list file. This affects the screen and rules files, too.

Presently, the tool is only available on Windows but can be ported quite easily. The main problem is that it is in infancy and is too simple.

I also used a custom tool to generate tune.s from tune.sng (and then hacked tune.s).

I have some Windows command shell scripts to build the program and disk image.
For a complete build, it has to be done in two passes since there is still a manual process editing the strings.inc file. I hate C/C++ and makefiles but if
someone else
wants to convert them, I guess I wouldn't complain.

I can provide what I have if you need it. I haven't put it all in the repo yet
because it isn't really finished but if someone else is needing all the tools, I can upload them (and grit my teeth at how poor they are).

One more thing, the resource files for the sound effects are really out-of-date. I edited more than a few by hand, directly in the include files.
I think one is entirely hand made.


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

So, how is this game coming? Is it ready for beta testers? I am wanting to try some new games under WinVice.

// Gary McCulloch of Reign Of Fire BBS.
\X/ JoinLink - RetroNet - C=Net - FidoNet
--- CNet/5
* Origin: Reign Of Fire: rofbbs.ddns.net:2300 / (931)494-9100 (1:154/50)

On Sunday, 23 September 2018 14:26:27 UTC+10, Gary McCulloch wrote:

So, how is this game coming? Is it ready for beta testers? I am
wanting to try some new games under WinVice.

// Gary McCulloch of Reign Of Fire BBS.
\X/ JoinLink - RetroNet - C=Net - FidoNet

Yep, its in beta state but I think it may be fairly close to release now.

Please have a try! Let me know what you think!

https://github.com/M3wP/Monopoly/tree/master/C64


Daniel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)