06 Feb, 2011, Runter wrote in the 1st comment:
Votes: 0
I've been toying around with the idea of building a mud-type-game using a web app framework using a persistent restful MVC paradigm. It's not exactly a new idea. I've seen some proof of concept and shoe horning of old codebases into webserver attempts. I guess where I diverge from those ideas is I want to significantly change the gameplay of typical muds to reflect the different medium. I also won't support telnet/mud clients connecting to the game at all. It just isn't practical since I'm not making a web server for a mud. I'm building the mud into the web server. The specific technology I'll use will be Ruby based. Either Ruby on Rails or Sinatra, or maybe even just Rack. But anyone with experience in html/css/javascript/ruby/flash or just mvc frameworks in general would be useful. Also if you're a graphic artist interested in having your work featured and credited I'd love to hear from you. I'll probably be using a github repo for the project. So, If you're interested please either respond here or get in touch with me on messenger. I'd love to hear some ideas on the subject.

aim: jeffreybasurto
msn: a_beautiful_paradigm@live.com
06 Feb, 2011, Idealiad wrote in the 2nd comment:
Votes: 0
What kind of gameplay are you thinking of? Something like this, or this?
06 Feb, 2011, Runter wrote in the 3rd comment:
Votes: 0
I'm not sure yet. Those two examples look interesting, and probably similar to the direction I'm wanting to go. I'm considering a flash and html based interface where instead of using a one-page-app approach that we're familiar with when it comes to "flash clients" I could modularize it into these views which are stand alone flash gui elements. To me, this is a much more interesting way to build a web application than a single embedded flash mud client.

edit: fwiw I'm also considering html5 stuff instead of flash.
06 Feb, 2011, Idealiad wrote in the 4th comment:
Votes: 0
But you're still thinking of a classic synchronous main text window, or something more like a browser game?
06 Feb, 2011, Runter wrote in the 5th comment:
Votes: 0
Idealiad said:
But you're still thinking of a classic synchronous main text window, or something more like a browser game?


No, I'm not thinking of a classic main text window.

edit: but to clarify, I'm not thinking of a "main window" at all. Like I explained each component of the game will be rendered in different views and possibly different technologies. For example, an auction house might be an html with ajax rendered with partials. Combat might be a full page experience with flash. Navigating the game might be something else. Just examples.
07 Feb, 2011, plamzi wrote in the 6th comment:
Votes: 0
Flash is horrendously slow to load, even after it's cached locally. Even if it's very lightweight in terms of graphics, the Flash for such a game would need to get data from the server in order to init or resume a player state, which may be a headache not only for your user ("Waiting to load…"), but also for the server, which would have to be able to handle different init and resume requests. If you absolutely insist on switching between HTML/JS and Flash, I would highly recommend doing so without actual page refreshes (i. e. load everything up in a smart order at page load and then show/hide as needed).

Also, if you end up doing hybrid technology, the Flash and JS don't have to communicate with your server separately–you could send/receive everything through the Flash, e. g. Otherwise you'd have a lot of duplicate code inside and outside the Flash.

If you're not married to the Ruby & MVC paradigm, take a look at the light Flash Telnet object I posted a few months ago here. It's used in the background of an HTML/JS UI you can see here (IE is not fully supported yet, so use any other browser). If you decide to use something like that, you will not need to write your server in a web-server script–you can start with any existing MUD telnet server and mod it as needed.
07 Feb, 2011, Runter wrote in the 7th comment:
Votes: 0
plamzi said:
Flash is horrendously slow to load, even after it's cached locally. Even if it's very lightweight in terms of graphics, the Flash for such a game would need to get data from the server in order to init or resume a player state, which may be a headache not only for your user ("Waiting to load…"), but also for the server, which would have to be able to handle different init and resume requests. If you absolutely insist on switching between HTML/JS and Flash, I would highly recommend doing so without actual page refreshes (i. e. load everything up in a smart order at page load and then show/hide as needed).

Also, if you end up doing hybrid technology, the Flash and JS don't have to communicate with your server separately–you could send/receive everything through the Flash, e. g. Otherwise you'd have a lot of duplicate code inside and outside the Flash.

If you're not married to the Ruby & MVC paradigm, take a look at the light Flash Telnet object I posted a few months ago here. It's used in the background of an HTML/JS UI you can see here (IE is not fully supported yet, so use any other browser). If you decide to use something like that, you will not need to write your server in a web-server script–you can start with any existing MUD telnet server and mod it as needed.


With all due respect, I do it every day, all day and it's not a problem even on crumby platforms. So, I don't know what you're talking about. Maybe you're making some assumption that's different from what I'm actually doing. Flash is trivial to load and communicating with the server is also trivial when it's embedded in a regular MVC web application.

edit: but maybe you aren't thinking about the same type of game as I am. I'm not really looking to build something as fast paced in real time interactions as a mud necessarily. For the places that is required there indeed will not be any type of requests needing to be sent.
07 Feb, 2011, plamzi wrote in the 8th comment:
Votes: 0
Runter,

Setting aside for a moment the tone of your post, which I thought was a little off, I think you need to share more details about what you expect the Flash to do, what exactly you mean by "rendered in different views and possibly different technologies", and what the overall pace of the game would be. What you've shared so far raises more questions than it answers: If not real-time, then why a MUD server? If not networked Flash, then why Flash? Does "different views" have to involve more than one page load and why (not Ajax)? Etc.

Also, if you're hoping to attract artists, you should at some point very soon share details about what type of setting/theme/feel the game would have. Most good artists are thematically narrow and would need to know that a project is exactly up their alley before they would consider joining (especially if it's for glory only). Take a look at some of the projects posted on http://www.conceptart.org - I recommend it as a resource.

A side note:
Although I'm not considering joining your project, I think you'd do better in attracting coding partners if you don't discard the experience they bring to the table, and stay open to modifying your approach to their skill set, whatever that may be. This is especially true for enthusiast projects. It's very bad form to dismiss someone's work without taking a look at it and then go on to say how the technologies you favor make all that trivial. That just begs the question: if everything's trivial to you and you do it "every day, all day," are you really posting here for help?
07 Feb, 2011, Runter wrote in the 9th comment:
Votes: 0
A) Don't care what you think about my attitude.
B) Don't care what you think about this project.
C) I dismissed your links because I clearly said what technology the project is using. So no thanks. What's so hard to understand about that?
D) You're wrong. Most of your post was angle-shooting-first-class-nonsense about perceived limitations of technology that don't apply to the type of project I'm working on. Which I clearly said more than once. I'm not plugging in a mud server to a web server. You should have just went to the defacto nonsense that someone seems to bring up about web applications of this sort all the time: It doesn't scale well!
E) I love hearing ideas. What I don't like hearing is someone trying to dismiss the few constants around the program I set up as gospel truth. Those constants will be used. That's why I mentioned them. If you don't like it, feel free to say that. But seriously, lawl. This is as bad as people asking for ORM help and getting folks saying don't use ORMs. Also, People have already responded to me favorably on messenger and the project is doing fine without your condescension. This wasn't posted in recruitments intentionally.
F) Whether or not you think it is trivial, it is.
07 Feb, 2011, plamzi wrote in the 10th comment:
Votes: 0
Are you always this angry at people why try to help you? You could have just said "No, thanks" or ignored all of my advice, including the links I shared which I thought would save you time on the server, help you find artists, etc. Instead you go off on a tangent about who you do and don't care about. That's just juvenile and will not help your cause of trying to attract quality help. Maybe you're a great coder, but as a project manager you're failing miserably so far.
0.0/10