Hi there.

I'm a bit of a noob by the looks of thing so please be a bit patient and I'll try not to talk utter rubbish

When I was younger I always had a c64 around or nearby but was to stupid and lazy to learn to code on it .. Now I'm 28 and I work as a software developer writing apps in Delphi.

For some reason I have this overwhelming desire to do a project (A MMORPG - sheesh I didn't half pick a complicated starter project didn't I) on the c64 (maybe just to try to re-capture a squandered youth).But anyway .. I digress.

The purpose of this posting will be to get help with this project and also to report on its progress...

the tools I am using
********************************************************
CC65 - for C stuff (I'm still learning C)

64ASM - For the assembly stuff.

WinVice - for testing.

C64 with FD-2000 - For compatibility testing.

P90 laptop running HD64 - for bulk data transfer ...

dev c++ - I am using Dev C++ as a programmers editor as it has many functions that are usefull to me.
***********************************************************

Please check back here periodically if you're interested , as I will be adding bits as I get the time or as neccesity dictates ..

Ok, MMORPG. I had to do a search on this acronym. Massive Multiplayer Online Role Playing Game.

My first thoughts are processor power, or the lack there of. From what I saw during my search, these are graphic intensive. Also, do you plan on building this to be played online, or just as a single person interface?
Will there me sound to go with the pictures?

I'm not trying to shoot down your idea. I'll watch eagerly for your progress reports and even help where I can.

If you could expand on your idea with more details, it would help (me at least) to understand exactly what you are trying to write.

Good luck!

Daryl

Well .. I've put a bit of thought into this , some of my solutions are highly theoretical but here goes ..

As far as the client game is concerned ,I've seen this little beauty multiplex up to 64 sprites.That in conjunction with a scrolling background and some sound/music (Handled by Irq or raster interupts) and hey presto .. one diablo-style game ..I've done some testing and the results were pretty good

Now, I use an xe1541 cable to connect to 64hdd and I got to thinking .. hang on..if I can use a laptop to emulate a diskdrive, why cant I bypass the slow buggy IO routines entirely and down and upload information directly via the serial port ?? I realize that there are speed issues here but I plan to transfer just the game-state (managed by an irq-interupt {like in the old c64 irq tape loaders} so as not to disturb the main game loop) which would just be a couple of bytes, also I've been looking at a little job called Jiffydos (http://cmdrkey.com/cbm/prodinfo/jiffydos.html) , now as far as I understand, all this little chip does is replace the kernal IO routines and it speeds up IO by something like 400% (Dont quote me on that) this is an indication that the speed I need is THERE

.the c64 would interface with a middleware component written in delphi on a PC (sounds complicated dont it) but that section is already 60% done .. the idea behind this is to keep all the hectic number crunching away from the c-64, also the middleware component can serve as a gateway to existing services such as irc or icq, all the clever suff such as account management and client connections could be handled by the Interface..

well thats pretty much my proposal in a nutshell,Like I said a lot of the methods are very theoretical , If anyone can see any GAPING holes in the ideas I've outlined I'd be really happy to hear from you..But If I dont try this , I'll never know

A MMORPG need not be super-duper, 1024-fps 3-D so-immersive-you'll-drown environment. It can be as simple as a 2-D character map (such as in the multiplayer Rogue-like games).



If it's a single person, it's not quite Massively Multiplayer, is it?

ok..Update ..

I managed to get quite a lot done, even getting the C64 to Talk to a PC via an X1541 cable but I found that coms were a bit Buggy and unreliable, the speed I needed was there but after all the error correcting I was dropping too many net frames to make it viable at all so, just as I was going to pack it in and go leap in front of a bus , i found out that someone was importing the retro-replay cart ( http://rr.c64.org/ ) and RR Net ethernet board ( http://dunkels.com/adam/tfe/index.html ) into the UK ...YAY God bless commodore scene : HTTP://www.comodorescene.org.uk

Hopefully this little bundle will solve a lot of my problems .. I'm now going to be able to communicate directly with the net ... so I can host the game server on my home server .. and also , the features of the retro-replay cart will help me get some graphics done a lot quicker .. the only problem
is that only people with some type of internet connection (swiftlink, RR net etc) will be able to play online ..

BTW I was thinking of ripping the GFX from another game but if anyone wants to do original GFX for this project I would much prefer that..contact me on kline9[*AT*]yahoo.com or sregister with my forums at

Http://Bonesmoke.ath.cx

Looking forward to hearing from you ..

Bonesmoke
_________________
Music should be scene not herd

use 6502.h instead of c64.h in uip?

Not necessarily... don't forget before there were ISP's there were dialin servers/computers that allowed direct connections... as long as the have a decent modem and your phone number anyone can play. Tell the ISP to go take a flying leap.
Lyos Gemini Norezel

_________________
Mundus Vult Decipi et Decipiatur

Instead of using ARQ (Automatic ReQuest) methods for communications, you may wish to instead use FEC (Forward Error Correction) methods instead. The idea is that you send the data *and* error-correction redundancy data to the other end. If bits get mangled, that's OK, because there's likely to be enough information present to let the other side reconstruct the data. In short, no retransmissions of packets. But, again, you also have to make your packets bigger too. So it's a tradeoff.

You might want to read http://www.ka9q.net/papers/newlinkpaper.pdf; although it's intended for amateur radio use, the concepts are broadly applicable to any communications medium that has a propensity for errors. The idea is that it adjusts how much redundancy each node sends based on past error counts; ergo, real data bandwidth is adaptable to the current operating conditions, while still minimizing retransmissions due to packet drops.

--
Samuel A. Falvo II