ForumsHQ

*yawn* just got done writing a webcrawler in java that stores links in MySQL



:-p

I have already started on this kind of project.



www.wolispace.com/cow



I have had the frames/dhtml code working but its not online just yet (so dony try frames mode)



Its written in Perl using MySQL



I tried some basics in PHP but found no advantage so stuck with Perl cos I like it :-)



Im currently working on the parsing logic.



Right now you do things like:

create a small white cat

look

into box (go inside the box)

look

goto cat

into cat (go inside the cat!!)

etc..





My master plan is to have the actions and attributes as objects in the world so they can be managed via the unterface itself!



Any thoughs/suggests or offers of help are welcome.

umm... it's a start i guess?

refreshing once every 20 sec just isnt gonna cut it for a real-time game tho...:(





As for my project -- I decided to go with C++ and SQLite. Gonna do it as a normal doorgame first and then add in custom-written servers (telnet, rlogin, http) at some point in the future.

The refresh (naturally) can be user-configurable.. the refresh is for when you dont type anything in.. pressing Enter will do a refresh as well.



As soo as you start typing it stops the refresh so your not cut off half way through typing.



An interesting aspect of a web-based system is that each command gets added to a list of commands for processing. Each time a browser visits the site it processes the next command in the list then continues with the original request - which may be a user doing a command which is processed then and there.



This basically causes the server to click over as its used, so the more visitors, the more processing it does, but if noone is there.. nothing happens :-)



Without the luxury of my own server I have to resort to these remote tactics.



Thoughts?



umm... it's a start i guess?

refreshing once every 20 sec just isnt gonna cut it for a real-time game tho...:(





As for my project -- I decided to go with C++ and SQLite. Gonna do it as a normal doorgame first and then add in custom-written servers (telnet, rlogin, http) at some point in the future.

I think you can avoid using refreshes entirely (w/ the system I described earlier in this thread), altho I don't know if it'll work in all browsers... it'll only work in browsers that start displaying things before the page is completely loaded...



as for your processing system... I don't see how it works with a real-time round-based game :( you need to have the server do things even when no commands are sent (for example, to do rounds every 5 sec)... this can be accomplished by having pages that are still loading (hence a script is still running on the server), or via a background process running on the server.



I'm going for the latter, the entire mud web server will be its own stand-alone executable...

so your latest idea for this was javascript, sql driven?

Not entirely. The MUD server itself is C++ with embedded SQLite; I've already written some code (around 800 lines, which is decent, but I expect the total MUD engine to be around 10x that). I also plan on including embedded JavaScript (ie, server-side JS engine) for use as the scripting language in writing quests, NPC interactions, etc. This is the same approach that Synchronet's author used to support 3rd-party scripting and it works wonderfully.



The MUD engine itself doesn't actually handle input/output though, so then modules will be written to handle:

- Doorgame support (this will be the first one added, since it's easiest)

- Telnet server

- Rlogin server

- HTTP server (this will be done last, since it'll be a huge pain)



The HTTP server will take dynamic HTML spit out by the MUD engine and send it to the web browser, kinda the same way web scripts work. The stuff it spits out will have to include a buttload of client-side JavaScript in order for this all to (hopefully) work as a real-time game without resorting to using Flash or Java Applets.



Again, the key concept is that the "page" that's loading never finishes; the web server just keeps spewing more HTML (lines of MUD output) and JS functions to keep scrolling the window, like a telnet client. (Input would be a form in a separate frame, that's a whole separate matter)



The problem is, I'm not sure how cross-browser this is. I'm not sure if all browsers will display HTML "as you receive it", as opposed to waiting until the whole page as loaded. I'm also not sure which browsers eventually time-out the page and after how long :( So some refreshes may still be needed...



Kind a complex system + a long answer to your question but hopefully that made some sense. The core MUD engine, plus doorgame support, should be in beta sometime this summer... the telnet, rlogin, and http servers will come a bit later, altho I have no idea when exactly that'll be.

all browsers I know of display text as it's load, especially if there are no tables, images, etc. involved.



Timeouts should not occur as long as data is being transferred.



A problem I see here is memory. Until you close the page, everything you send to it continues to use up the RAM in the target system.



I suppose you can make it a user-configurable setting - for example, let them choose to auto-refresh after 1000 lines.... people with more powerful systems can choose a larger #.



Also, what do you do with processing time? This part i'm not sure of, but if you are, say waiting on user input, what do you send to the screen? This could cause time outs. I suppose you could start doing auto refreshes, but that brings up another problem.



What about latency in terms of establishing a connection? THe problem with HTTP connections vs. telnet is that connections must be established & torn down with each request. The overhead (and thus time involved) is far greater than telnet connections.



Finally, this isn't really related to this, but how do you organize such a large programming project? How do you design & plan it? Do you use software? I'm just looking for ways to plan my programming projects better :)

Hmm, yeah, memory on the client side would be a bit of a problem... definitely think your user-configurable refresh timer idea is a good one!



As for time-outs during processing time (when no user input) -- I think this one should be solvable by just sending some non-displayable crap to the browser... either html tags that are invalid (which browsers tend to just ignore), or just some javascript code that does nothing :)



Connection latency could be an issue, thats a good point. Won't be a huge problem for output (since that'd be one long connection), but might be one for input. I mean, http/1.1 can use persistent connections if your pages are non-dynamic (ie, can tell the browser the size length of the doc)... maybe I can throw that input textbox into an inline-frame rather than a normal one, and use a persistent connection for that.



I dunno, will be a while til I get around to coding a web server anyways, will definitely keep that stuff in mind in any case.





As for how to organize a large programming project -- it depends on the langage and the project itself I guess.



For large C++ programs, thesedays I usually doodle some stuff on paper and then write up the header files for class definitions and the like, and try to figure out how I want the classes to interact, which then lets me figure out the class member functions + variables. Then I code bottom-up (ie, lowest-level functions first, starting w/ the most core/vital classes)



I'm mostly following that for this massive DoorMUD re-write project. But keep in mind that the doodle-on-paper stage lasted like 2 years, as I tried to figure out what features I wanted and how I wanted to include them (and what extent of third-party libraries I wanted to rely on). So now that I'm actually finally coding, it goes quickly since I did so much random planning.



The original DoorMUD (ie, the currently-available versions) was designed very poorly, some of that code is ancient -- as in, some of the first c++ code I ever wrote. The code is horribly organized and a huge pain to add things to, which is why I need to write the rewrite so badly. Luckily, I can learn from all the design mistakes I made the first time around...!





For Java coding (which I don't really do much of anymore anyway), I pretty much plan like I do in C++... sometimes even more thoroughly, Java lends itself well to very well organized + readable coding.



As for other languages, I don't plan much... for PHP and Perl, I usually just code-as-I-go. Usually comes out horribly messy, I haven't gotten a great organizational feel for those languages yet. Altho, when using anything database-driven, I spend a lot of time figuring out my db tables before any other work.... imho, making major changes to the database layouts after you've already started coding the application is a huge pain, takes way more time...

yeah.. that's about how I do it.. though I never worked on a program with more than 3-5 files and total of more than 1500 lines or so.



I was kind of looking for a software program that helps with the design process. Something that helps organize basically - kind of hard to explain exactly what i'm looking for - but just something that I can make notes on, but in the end it will format & make everything neat and just easier to follow along with.