Where's My Browser Based?!
Most Internet game play is divided into three categories: true browser based, browser plugin based, and client based. Client based is the most predominant, plugin based comes next with Java and Shockwave creations, and true browser based is sadly last. WHY THE HELL IS IT LAST, DAMMIT!
The primary focus on a lot of developer's minds these days is the Internet. Internet game play, we need it. Internet game play, we can't live with out it. Internet game play, forget about the stability of the servers, can they play without lag?
Most Internet game play is divided into three categories: true browser based, browser plugin based, and client based. Client based is the most predominant - you buy or download a game that connects to the server over a specific port, and you play through the game's interface, rarely seeing your desktop behind it all. Most client games require a halfway decent machine to run them.
Browser plugin is the next most popular - most of them require Shockwave or Java. Although it's not a prerequisite, I've yet to see a decent Java or Shockwave game run reliably on anything less than a 133. And it drives me absolutely nuts when people say their game is browser based. No. The browser is the launcher into your Java or Shockwave game, much like the Start Menu is a launcher to get into your client based.
And finally, you get to my favorite - true browser based. These games require no client software - the user surfs to the site using their favorite browser, and all game processing occurs on the server. The output is then sent to the browser.
It's clean, it's simple, it's fast and can be used on any machine with a crappy Internet connection. And everyone else seems to hate it, simply because there's a severe lack of true browser games.
That simply annoys me.
I mean, sure, you've got your Earth:2025, you've got your ArchMage, you've got Utopia, Shilla, and the like. But where the hell is the expansion in these games? One company creates them, there are no player mods, the graphics suck (because well, uh, they're free, probably), and you can't expand the realm to your own liking!
This incredibly marketable world of gaming is important. Think about it: there are tons of backward schools that are still using Windows 3.1 or browsers that don't have "Back" buttons. True browser games can be played on these dinosaurs. No more solitaire, no more QBASIC attempts at laughter.
You know what needs to be done to create a really good true browser game? I'll tell ya:
- Open source the damn game. Very important. Browser based games are ignored by everyone and their microphone. By open sourcing, it'll be expanded upon much faster than closed code. You can make your money later - what's important is to create a market that realizes money can be made.
- All data files must be XML. If you're going to do a game, you want to make it as expandable and as insidious as possible. Nothing is more insidious right now as XML. XML really has a future - by creating data files in XML, you allow the rest of the world to create tools to help your game. Tons of XML editors, parsers, documentation, and utilities are already available - they save you the time of creating your own. And XML is a piece of cake to learn for anyone wanting to expand or help. Which brings me to the next point.
- Make it expandable. Old folk gamers will remember the BBS days and something called "door games". Legend of the Red Dragon was one of the most popular games available and had a wonderful little thing called IGM's. IGM's were "inner game modules", and through a common API available for C, C++, Pascal and even QBASIC, anyone could add onto LORD. 400 IGMs later, BBSs started fazing out. The important thing to remember is "400". 400! We're not talking Starcraft maps here people.
- Make it generic enough. You've got to make the base code support fantasy, science fiction, steam punk, Water World, horror, etc., so that anything can be created (although if someone wanted to recreate Water World, they've got problems). If people hate Water World, and your code is filled with Costner, you've just wasted your time (badly). Much like the Quake III and LithTech 2.0 engine, developers create what they will. You've got to create a generic, easily usable engine whose purpose is defined with XML data files.
- Let other people create servers. Release the server code. Make it simple to install. ISPs and web hosts hate working for you. They don't want to install anything nor do they have the time to care about your crappy little game. Make sure it takes five minutes to install, and doesn't required any additional modules or libraries that aren't part of the standard distro. Make sure that the user can modify everything - ISPs hate being called up to change something, only to be called a day later to change it back. Make the server code generic enough so that one installation can serve as many games as created. If your user has to bother his ISP to create a sequel to his first game, you've inconvenienced the wrong people.
- Make a central player database. If players all register their character with one database, that character can be used in any player's world on any server. If one player's favorite game stops, they can take their character to any other game, and continue their history. Of course, pulling this one off is going to fun (how do you handle character conversions from a medieval game to sci-fi? Or handle characters adventuring in their player's own created world, getting zillions of special abilities, and then trouncing everyone's Care Bear ass?)
Five of the steps above were written from my very own game notes. I've started the process multiple times in the past - but have always been sidetracked by other delays. The sixth step, open sourcing the game, was added for this article. I've gotten to the point where I just want to see a game made. Perhaps now something will blossom?
If you're interested in continuing and contributing to my efforts, leave a comment below. Interested people would definitely inspire me to get things going again.
If you're looking for existing open source, web based games, take a gander through SourceForge - there are a few, but as of this printing, none that deal with XML or are as generic is what I intend.
- Login to post comments
Wow! Finally someone else who gets the clue! Did you ever play Ultracorps? It was a massive multiplayer browser-based game by VR1. Microsoft ended up buying the game and putting it on MSN, but because it was pay-to-play, it fizzled. Too bad because it was quite revolutionary (though with some balance issued).
I am actually writing a spec for a game similar to what you describe here. It's strictly a free-time project and I'll probably never start writing the actual code as long as I have to hold down a real job. :)
Ultracorps? Nope never heard of it. I do know that I *hate* pay-to-play games. I play games when I have time, not religiously. Perhaps 20 hours one week, and not again until three months from now.
If you want to share the spec, I'd love to see it. What language you coding it in?
Describe Ultracorps to me. You played it? What do you remember most about it?
The answer to your point #6 -- differences between technological ability between worlds -- is to simply allow each server operator & team change the laws of physics between worlds, making different advantages important, etc. This is where us tabletop geeks come in handy.
Oddly enough, what I remember most about Ultracorps was the universe map. They used a fractal equation to create it, so the layout was quite varied (this feature was dropped when MS got the game).
UC was a 1 turn per day build and conquor type game. Planets produced minerals (called Ultranium) and had licenses for various ships you could build. A simple economy made popular ships rise in price. Each race also started with certain licenses, making for some interesting economic strategies. Fast aggerssive tactics dominated.
The entire game was ASP-based and included discussion formus and messaging as an integral part. The entire universe was updated daily at midnight. The interface and supporting graphics were quite lavish and attractive as well.
Phloighd: My initial concern was how to actually change the law of physics. When does a BFG in your world become a "PissedOffStick+3" in my world? How can I legitimately strip your characters of all their tech armor, if I'm dealing in a stone age world? Sure, the laws of physics and matching scalings can come into play, but in some worlds, there simple is no equivalent for a BFG (bow and arrows +20?)....
Anyone have inspiration to create a web based game?
Morbus: A charecter should only retain it's learned and inate skills when being "transported" to another world. You can explain this as being similar to the movie "Terminator" in that when a chareter travels to a new world the process strips them naked. Only organic matter can pass through. As for the player experience points and stats, each world would have an experience point and skill table. The experience point table would show the rules for experience point incrementation for the given world. The skill transfer table would show the closest aproximation of your current skills on this new world. The skills should probably have a bunch of parent categories i.e. my skill with the molecular disrupting vibro sword would be a child category of TwoHanded LightWeight SwingingWeapon. So when this charecter goes from it's sci-fi world to a fantasy realm the charecter's could choose from a list of weapons under the TwoHanded LightWeight SwingingWeapon for that realm. Mabye TwoHanded LightWeight SwingingWeapon .LongSword for example. It would also be easy to do that within the XML framework that you want to use, I think. The experience point thing would require more thought but I think it could work out in a similar manner. Just an idea.
I have lotza pencil and paper games that would fit the points above but #1) I dot have and cant afford even a windos 3.1 comp (stuck on webtv) #2) I have a hard time with JavaScript, so id never be able to make a game. So im stuck with IRC based games.
Well I have a browser based RPG. I don't live up to most of the suggestions in this article - but it does do some fun stuff www.sourceofmagic.com
I was just wondering is how you make these games, cause i was planning on making one but i know nothing about it, what i mean is i don't know anything about making them so if u guys could like tell me i'd be grateful :)
Describe to me the interface. I've tried some "Wizardry" like web based interfaces, but the latency of net connections made them unusable. I could imagine text interfaces with a couple of symbols after each noun (for "explore", "get", etc) kinda like a text adventure, but it seems like that's better served with a telnet session, and could quickly lead to exploring the object hierarchy rather than immersively exploring the environment. There are some issues with a centralized player database and security, but I think that could get worked out. Re point #3: "yes, yes, yes!" I've never gotten into MUDs as social experience, I like having time to edit my thoughts (not that that really helps), but I've enjoyed building environments with MUD engines.
The interface, I think, would have to me a mix of both the Wizardry and text based interfaces. Lots of MUDders love to speed walk - typing something like "n n e w n" to move five rooms in one burst. I've never seen that in any browser based game nowadays, and that slowness of click, wait, click, wait, click, wait, (without speed walk) can certainly contribute to the perceived latency of the game.
So, include a magical text box that would cover all the same things you could do with the GUI. This is really nothing new - MS has been recommending for years and years to program a keyboard interface to every application, and since we won't override the key commands of the browser, we'd have to to provide the next best thing - a command line.
But there'd be the Wizardry interface too. Magical cardinal direction buttons surrounding the image of whereever you are, buttons to pop up your equipment window, your stats, etc... You could definitely "reduce" the design and perceived latency by using frames - I still haven't fully played that battle out in my head, however (I hate frames)...
Continuing to ramble, I'd want to include a GUI customizer. Not a skin type (although that'd be neat), but rather a "what do you want to see and where" type... If we can allow the player to remove the "how many munchkins like me" portion of the screen, then we've made them happy because of the customize, added some white space for clarity, and also reduced download times.
Thoughts?
Perhaps http://www.skotos.net/games/marrach/ is on the right track to what you are looking for. it's not open source and they do not appear to be encouraging 3rd party development but the interface and genre seem be what you have in mind
I looked a bit through the documentation for Castle Marrach and I'm wondering a bit about the environment. If one has the skills and drive to create a graphically rich world, why stop at web graphics? Why not plug the graphics into an engine like Half-Life? Or, if you're going to take the time to write an engine that'll do the compositing and take care of the other issues, what's the advantage to making it all server side? Not to be too cruel, but as a market people who can't afford computers aren't a demographic that are going to support your business.
I guess I see graphics and text as largely exclusive, or there has to be an engine that allows both views of the world and lets the person experiencing the world take one or the other. And from a little poking around, the Gamegrene audience seems to be people who'd find a good text interface as compelling as a compromised graphical one.
So ignoring the graphics, the web still has problems pushing asynchronous information, "bob has left the room" and the like, and makes things turn based. Which is fine, but that's a different game model than I'm envisioning for moderately multi-player socialization environments.
Welp, sure, if you're planning on making money, you can't focus on Windows 3.1 computers. But, if you're planning on making a browserbased game, then you can't focus on complicated 3D graphics. In essence, your game display is already built - it's the confines of a browser and the ability of HTML, DHTML, CSS, and what have you.
If you're into frames, you could async info to a 15 second refreshing window. Cheap, to be true, but as asynchronous as you'll get without a java client (which would break the browserbased name).
You bring up an interesting point, though, about two views. It'd be practically impossible with FPS's like Quake and Diablo2, but not so true for hacks of Ultima and Everquest. Why not make a text based, browser based version of those games, that simply send equivalent commands to the server, the server responding with equivalent command and a wrapper merely dummies it into the browser?
Grrr... I love parts of Opera, but 4.0b3/Linux blew away 3 attempts to write this response by crashing at inopportune times before I switched over to writing this in Emacs.
I've been diddling with the colored pencils recently, and doing some work with business graphics in Flash, and it takes a hell of a lot of work to build any graphical environment. The difference between building a mostly static 2d environment and a fully fleshed-out 3d environment is quite a bit less than making that first leap from text to graphics.
If I'm going to spend months of spare time drawing textures and fleshing out an environment, it's hard for me to imagine justifying building a web interface to a graphical environment versus going that little bit further and putting the environment into a more dynamic engine.
The least of my 'net connected environments, my Palm Pilot, still has telnet and ssh, and doesn't support frames, so if I'm going to put effort into development of online environments that aren't based on either Flash or some real-time 3d engine, using telnet because it gives me the asynchronous bits without hammering my server every 15 seconds whether something's changed or not seems like a good thing.
Yes, this does leave out some WebTV and similar players, but non-shoot-em-up genre games are already limiting the market for my efforts a lot, trimming that audience further by keeping a game off the leading edge seems like a bad idea.
I think the 2 views idea deserves some thought and prototyping. Even the action games I like playing are based on solving puzzles within the environment, outsmarting, and not out-reacting, my opponents. There's certainly room here.
Slight back-pedal: Server push is still alive and well, even if it seems that people don't fully understand the processes involved. There would be some issues with configuring the server to run it effectively, but a frame with server push properly implemented could allow for a non-polled web window that updates when content changes.
Hmm... so it would be more swallowable to people that they develop a telnet version and a webbased version concurrently, than a 3d graphical and a webbased? Part of the issue I'm still fighting with in my head is trying to stay close to the definition of "true browserbased" I give above.
You mention Flash. Theoretically, one could make a browserbased game using the HTML and PNG's and blah blah blah. And then someone could come along and make a flash-enhanced version, one with more glitz and more interaction (although I profess to knowing little about creating flash movies)...
I always thought server push was dependant on the browser for supporting it? That'd probably be a better way to go than a Meta Refresh, but it would need some sort of ability to "maximum once every 15 seconds". We wouldn't want an especially busy game to be pushing new data every second onto a lowly player with a modem...
My contention is that it'd be more swallowable to do a telnet and a full-on 3d engine rather than trying to do a telnet and a web based engine. Graphics are graphics, and if you're gonna do them then using an engine which really shows 'em off seems like the best play. The "true browser based" you cite above doesn't allow offloading enough of the processing onto the clients to give an experience worth spending lots of time and money in development.
Server Push: Points taken, the problem is it still depends on browser support and needs frames (lest you get a new push midway through filling out a form). Doesn't do anything to help the aforementioned WebTV users or me on my wireless Palm and such.
On Flash: Most estimates put Flash market penetration at around 94% right now (had to look at this 'cause we're trying [grumble] to use Flash as an interface for some web tools). So using Flash limits market probably about the same as server push or frames or even PNG (which hasn't been supported that long).
I'm one of the developers of Unweb (http://unweb.milclan.com) so I have something of an insider view on this.
I think there are a lot of great points in this article. There should be more web-based games out there. Hanzo and I are currently thinking about developing some more, which we'll keep under wraps until they're ready to go :)
There's a lot to consider when you're on the development side. Open source is great, but it has drawbacks. Money is one consideration, but there's also the love of what you have created. What happens when you put your hard work out as open source, and you see someone else's version that has all kinds of broken code, horrible graphics, or worse, is based on a racist or sexual theme? No developer wants to see his hard work turned into something disgusting or dirty or hateful.
XML has good and not so good points, and it's something to look into. At the same time, we have to decide how much do we use the tools we have, and how much time do we spend learning new tools.
Expandability and hosting on other servers have some of the same potential drawbacks as open source, that your work will be corrupted and that you won't get anything from it, even if it is kept in beautiful, working order.
A central player database is an interesting idea, but also a lot of work. If making the game open source and letting everyone modify and host it really does drive up demand, how big a database do we need? How complex does it have to become to insure that it will work with every possible permutation of the game? Is it worth our time and effort to host and maintain it if only 5% of the characters are running on our version of the game?
The problem is, I agree with most of the points made in the article. I do want lots of people to play web-based games. I want people to make their own personal versions of Unweb, or possibly other games that we develop in the future. But there are a lot more things to think about when you're the one putting all the time and effort into making the game. Too bad nothing's ever simple.
Perhaps at this point in juncture, I can merely bow out in disagreement ;) ... Your last sentence concerning "offloading enough processing" doesn't really come into play - a telnet client does no processing for what goes on in the MUD server, much like a web browser would do no processing for a simple CGI script.
It also depends on the "experience" you're trying to achieve. Earth 2025 (cited in the original article) is played by thousands of people. Hanzo's Unweb at http://unweb.milclan.com was getting a new signup every second when PlanetDiablo mentioned it rather pathetically on it's front page. (I''ll pathetically ignore the statement of "a thousand people. ooh. how many people play the sims?" for right now).
You're exhuding the "not what people expect, yawn ho hum" sort of attitude. "It's not like a MUD, so phoeey". "It's not like Quake, so phoeette". I (I, I, I) could care less if I lose a lot of time or memory in developing the stupid thing - lord knows how much of both I've wasted on Disobey and Gamegrene.
Concerning your wireless Palm - that's why a core portion of the game would be done in XML - so that it'd be easy to convert to WAP, or whatever else the standard would be when the game rears it's ugly head. I've been drafting various ways of integrating the game with other technologies - using Jabber to hook into instant messages, SOAP to talk to different servers (in a peer to peer-ish way), and so forth...
MightyCow - you'll have to excuse my following exhuberance because I'm a big fan of open source... But the drawback you site for open sourcing doesn't really fly with me. Sure, I could take the latest source of Apache, rename it Sexpache, and make it a huge porn related snuff source. People are still gonna know what Apache is, and where to get Apache from. I won't waste more bandwidth on that discussion - it's been beat to death by many other people, and I'm in agreeance with them...
I'm a sad fan of XML too, even due to it's increasing complexity (didn't Dvorak call it the geek's revenge to the crappy page filled hell the internet is now?). My initial designs for the XML sheets for the game I'm working on are totally attributeless. No [character name="bob" /], but rather [character][name]bob[/name][/character]. It may diminish the "greatness" of XML, but it virtually certifies that existing parsers and code for many different languages will be able to read and write the XML quite simply (primarily, I use XML::Simple to suck in the above within perl).
As for "getting anything" from my work (concerning your server argument), it's something you have to deal with. You run into the same sort of thing as Napster - there are certain Napster servers that the Napster client recognizes. Then there's OpenNap, and people who realize Napigator exists can reach into them. Napster hasn't gotten any less popular, and hasn't diminished any less.
Which doesn't mean I haven't *thought* about those aspects of releasing the server code - that's detailed in the bible I've been writing concerning browserbased games. It's just a matter of telling people that these are trusted servers, and those over there aren't. People can make their own decisions rather nicely, and I'd rather have flexibility than "no! that's not what I intended!"...
Central player database - lots of questions. How big a database? Not a flipping clue. I haven't gotten to that point in the design. As for complexity and permutations - that's not our responsibility. If the game is open source, and the character XML is open source, and we release the server code, a couple of things happen: 1) if someone changes the character XML for their own use, then they'd code their own wrapper to convert between the standard XML and their XML. Again, it's a matter of flexibility and "opting in" to the feature they or they're players want. 2) various XML guidelines suggest pointing the doctype to domain.com/version#/doctype.dtd. If the db XML does change, then backwards compatibility wouldn't be an issue - old servers would still reference the doctype that is applicable to them. Players determine how a game evolves - there's a good chance that if the players know that there is a new version of the game out (that uses a better doctype version) they'll beat the admin into submission for upgrading.
Is it worth the time and effort? That depends on the coder ;) ... I still create webpages for the 1% of the population that uses 640x480 resolutions. If even 10 people think a central db is a good idea, then it should be considered. If 5% is 10, then the load ain't gonna be jooky. If 5% is 1000 people, then that's a pretty sizable audience of gamers (do you have 1000 friends?). It'd be bad to upset them.
So, MightyCow, you code in perl at all? Whistle, whistle [g]... Your concerns of "things to think about" are well founded, and taken to heart - that's where this stupid open source bible is coming in...
Mea Culpa: You're right, I was falling into the "do better what we've seen before" trap, I think mainly because I see the reason I don't play more (online) games as a genre issue rather than a medium issue.
I see Counter-Strike as an example of a game which takes an established medium and breaks the genre. It takes the first-person shooter style which all of us have played, and which I left because after a certain level 12 year old "l33t g@m3rz" smoke everyone, and changes it so that it becomes a thinking game rather than a reflex one. Thus while Quake deathmatch was something "those people" played, Counter-Strike is something the people I hang out with play.
@DEITIES help the economy if someone figures out how to alter a MUD's demographic appeal to that same set of people.
I've looked at a few of the browser based games mentioned here, and none of them seemed to break that mold for me. So I guess what I'm really asking is "why is the browser going to offer me a more compelling format with people I want to socialize with than telnettable MUDs or something based on the Half-Life engine?"
XML: I'm less a fan, in most cases it seems like needless complexity, but whatever, as long as the format's easy to parse and documented I don't care.
On seeing your game used for things you'd rather not be associated with: I'd bet that for every Counter-Strike the guys at Valve see a gazillion "chase the Penthouse Pets" game come and go. Sometimes you've gotta give artists the freedom to play in order to see really great things evolve.
browser based games rock
my brother plays runescape (runscape.com) which is client but it is slow ans sucks anyway. i found this browser based thing called Alien Adoption Agency (alienaa.com/web-docent.com) its kinda like pokemon but MUCH denser and more stuff. basically you "adopt" and alien, make it hard in the gym them beat the Sh** out of other aliens.
try it people. also it FREEEEE!!!!
There is actually another form of online RPG that is quite active and tends to be an interesting blend of hack-n-slashers and your more storyline based roleplayers as well as a mix of free form diceless roleplay as well as dice driven roleplay. This is the extremely popular chatroom RGPs. It's a strictly text based gaming but you can put together all sorts of webpage sites together with maps, character info, city/town info, etc, etc, etc for all the people who wander thru to use for reference. Since chatrooms are fairly open, they tend to be lighter on rules than most tabletop RPGs but they also have the added side effect that as many storylines can be running at one time in the same room as there are people in the room. While the hack-n-slashers go at it in the middle of the room, some thief type go sneaking along thru the crowd doing his dirty work. You basically have a lot of the NPCs now becoming played characters with their own ideas and agendas which throws in all the intrigue of Ultima and Everquest without having to payfor and try to keep running all the software. Also, this sort of RPG tends to be very easy for people to run and is an easy way for those new to RPGs to work out the wet behind their ears before sinking all sorts of money into all sorts of books and manuals that they might not care for in the end. Actually, thats a market that I don't think many of the RPG companies have really looked at yet, slimmed downed/cheaper versions of rulebooks to sell to the chatroom RPG community. I'm a regular when it comes to roleplaying in the AOL chatrooms and there is anywhere between 40 and 150 public chatrooms of roleplay open at any given time and there always seems to be 5 or 6 times as many private chatrooms going for the same things for those who wanting a more serious storyline going without the wilder types roaming thru.
I wrote LORD (Legend Of the Red Dragon) in web based format, instead of typing characters to move around, you just clicked a link (F)orest and the like, it was fine, had many players, but the waiting for each page to load caused players to complain, people want instant gratification, after a while, people started leaving, and i had 5 players left, so i shut it down. I included support for IGM's, which were made using a custom scripting language. But like i say, people want instant gratification, webbased games are too slow...
As a side note, i've written a server side scripting language for the facilitation of online games, i have a friend working on a linux/unix interpreter, it's simple, with commands like "Link(label, "This is a Link")" very simple easy to understand, i hope this will help over time...
Primarily, most of the problems with "slowness" of a browser based game are because a browser based game wasn't specifically designed to be such. In the case of LORD, I agree, it'd be hella slow to go to the forest, attack, wait, attack, wait, attack, wait. That's why you add things like "attack til near death" or "attack for five rounds" or what have you. That's why you have to use the evil of frames or caching - so that people don't have to constantly look and reload their stats or weapons.
Some of the games mentioned above have thousands of users, and there's no slowing down. With a bit of work and modification to the underlying code of LORD itself, I think it'd make a decent online game, personally...
I have been reading all of the post on this site and I would be really interested in helping with the design of a browser based game. I don't know much about Perl or XML, but I can learn. I do I have exp. in GFX, GUI's, and just web design in general. So if there is anyone that thinks I could help I would be glad to.
One other thing. On the load times I have an idea, have it set-up so someone can choose to either have everything load off of the server or be able to download like a GFX package and have the code just load the files from the local HD. This would help out alot with the load times and also lighten the load for the server dramatically.
well i was reading the posts and if you go way way back to the top someoen says something about ultracorps well it did cost money but now it doesnt so go try it out its my favorite browser based game. ultacorps.vr1.com
What about graphics. I am an artist, and I'd like to think that roleplaying games gave me the ability to access my imagination. All the broswer based games you all talk about are low in eye candy. Flash is a great tool to supplement any web site, or game with its actionscript. Which is very close to Java.
Imagine if you will a game that everyone has a profile pic, a 3 Qrs view, and front view pic. Which all could be turned into background less PNG. Those pics could be pluged into "view" areas that the player clicks. That put the character pics into set backgrounds. There is even a possibility to insert those pics into anime style run-by fight scenes. I am an art major, and a animator at heart. I guess what I am saying is to not count out the ability of Flash or director.
On the AOL chat gamers: I dig that style of play. What if there was a site, the was a site map. with links to different parts of a "City" for White Wolf, or a "World" for any other game. One could go to a specific place and play chat style rleplaying. Rules could be base on any system with a log set by both the player, and the webmaster of the set area. IT would have endless possibilities. Even cross area events that could........I feel myself rambling on....(((Gets an evil look in eyes))..
Anyone feel free to contact me.
Laters,
Tung Lei
What's your opinion on RaceWarKingdoms. Is this the style your looking for. It's web based, has a fast hack and slash appeal, it includes the chat feature for the Role playing types, and easy to start.
But that about it, the quests are quick and easy and after that its just a clicking game. Its also a free / pay sight, you can play for free but you have to pay to get any where in the game. There is to big a gap from the players that pay and the players that don't.
To me it looks to have a good basses but it dose not go any further. Just thought I'd if anyone had an opinion.
Just thought Id mention to everyone that Ultracorps is running again, and for free back at the vr1 site. (One of the folk at vr1 is running it in their spare time). The url is http://ultracorps.vr1.com
SpaceTrace is going into it's third round. spacetrace is a free space warfare browser based multiplayer online game. You are the commander of a planet and three fleets - fly through the galaxy and fight other planets - join alliances.
this game differs from all other games in this category, because you dont accumulate resources or stuff like that, but it is more, that you measure your tactical skill with other players like in magic the gathering. actually it is inspired by this card game, planetarion, masters of orion and some more the URL is: http://www.spacetrace.org/
I really, badly want to create a multi-user dimension that is browser based. I plan to start it on tripod then pay for a server and move the game. My only problem is.....I suck at Perl! Please, I need help!!!
E-mail me...*weeps*
Yeah alienaa.com was fun for a while. But- the only problem is that its so repetitive, its not fun. Its also daily. If you miss something one day, you can lose up to 5 or so stat points that you could have had from the gym. And, sometimes its hard to stay alove, there are too many players, you die almost every second. I'd recommend for people: www.bots2.net and games.swirve.com. Those are my favorite aming sites as of now.
I have a browser based games website, truly browser based but the drawback is there are not graphics! So unless you enjoy MUD, I don't think you'll like it. Anyway, here goes the url for anyone interested.
http://www.dailyfreegames.com/
Very Good site!
I only miss: http://www.astrowars.com
http://www.dailyfreegames.com/ ?
can you make a code for this game and send it to me
You should probably try http://www.x-kings.com which I think is the best free game I ever played. It has got a fantastic technology system which allows you player to grow day after day. Addictive.
So...how can i create a text-based rpg???? i don't want to download anything, anyone got any ideas?
So, you wandered into Dragonprime and posted a link back to here, so I'm gonna comment.
1) All Data Files should be XML -- Sorry, but XML is not a magic bullet. For most of these games, the *correct* location of data for the game is in the database backing the game, NOT in some XML text file. XML is good for things which require hierarchical, nested data. For things which are expressable best as key/value pairs or some other format, XML is NOT the best representation.
2) Make it generic -- Sorry again. Making something truly generic is a TON of work. Most times, it's not worth it. For instance, LoGD is most definately a fantasy game. Someone wanting to make it into a stone-age or a space-opera game would need to do a LOT of work. It is not my responsibility to take the time to make those things possible. It is my responsibility to make a fun game for the players. Period. Especially if I'm not getting paid for it, since LoGD is open source.
3) Central player database -- Again, this is a bad idea. Different servers have different rules, different economies, differently lenient or strict game masters. Transferring from one server to another, ESPECIALLY when most players want to keep all the stuff they have previously earned is unbalancing in the extreme (potentially). Just a bad idea all around.
4) Open sourcing the game/making it extenable/letting anyone create a server -- These are all pretty much interlinked, especially the first and third of those. It's a choice plain and simple. There are reasons to make it open source, which you point out. It drives adoption by others, and broadens the possible base for it, but even LoRD wasn't open source! It was share-ware. However, by making it open source you have a completely different problem. Hordes upon hordes of clone-servers. If you go and look on lotgd.net and the logdnet server list and go and investigate them, 90% of them are generic clones. Most of the GMs don't invest the time and energy and effort to make those games unique. In the world of the internet, where every server is easily accessible from every other, this really makes for a diluting experience. Unlike the days of BBS's where you likely called only a few local boards, and so it didn't matter if other boards in other localities had exactly the same setup of their generic LoRD game, now you have hordes of generic LoTGD servers all of which look much the same. Yes, the ability to make the game extensible is good, but ultimately, people share the extensions (which is good) and the good ones wind up on all the servers (which is good in a sense) but this leads to more of the same. Hordes of similar and identical servers. Keeping the code private and the community centered on one server has benefits in both eyeballs (if you are trying to support the server by advertising) and in uniqueness. Also, you have issues with licensing. The GPL doesn't correctly apply to browser-games since sticking the game on your server isn't distributing it and thus there is no legal requirement to share any changes (which is a strong disincentive for me to do the grunt-work if I don't get stuff back!). The Creative Commons 2.0 license addresses that somewhat. Also of course, you have the occasional idiot who tries to rip off your code and claim it as their own which you then need to go and beat about the head and shoulders with the legal book :)
I certainly (and obviously) agree that browser based games are viable and fun. And for a lot of it, LoTGD follows the things you set out. I'm merely trying to point that there are tradeoffs to some of them and that those tradeoffs need to be looked at very carefully.
If I were to create another BBG (browser-based game) tomorrow, I would likely NOT make it open source having seen some of the problems that having LoTGD open source caused. I would however make it extensible because that helps *me* as the author to quickly add features and content.
Sorry if this seemed to ramble, but I figured having a practical and pragmatic response from someone who's been there and done that wouldn't hurt.
1) I agree. 2000 was a much different year for "expectation that a database is a common web server offering." But, that doesn't mean that XML can't be used as an I/O format. Regarding Legend of the Green Dragon (the "wandered into dragonprime" comment, for other readers), it seems a waste to see 50% duplicate code in all the race modules (one shining example that comes to mind is the uninstall code -- code duplication almost always means poor design. but, this is generally not a discussion for Gamegrene - meet me at dragonprime? ;)), when people could define the good stuff in XML and have it imported (or even have a module generated automatically). Once you define an XML file, you only need to change one script/importer from source version to version, which removes the need for constant "Is someone gonna update Vampire!? HelloO?" maintenance issues for players long gone.
2) I don't really believe that it is a lot of work (and someone is already attempting it with a Star Wars total conversion, right?). Sure, it's further compounded by the number of modules you're currently using, but a simplistic race/creation/item editor would ease things along (one of my planned fiddlings are SQL packs keyed to specific genres that could be easily imported), and if the translation system had "English" as a translation file (not as a default), then it'd be easy to change fantasy descriptions ("pub" to "seedy spaceport bar") to something else too (realize, however, that I've not delved into the planned trans of LoGD, so I'm not entirely sure it's capabilities).
3) I also have come to agree with this.
4) Using LoRD as an example against open source is inane - very few people knew what "open source" was (I'm not even sure that term existed back then) so it wasn't a popular mentality to take.
Anyways, here's hoping your monitoring this article for responses ;)
Incidentally, I'm /not/ suggesting that XML should replace the current stuff you've got now - merely that it could be a "higher up" format for users who don't really want to learn programming (often the mere thought of it will turn someone off as "too difficult" or "I don't have the time"). If, on the other hand, someone could go through a generator, or even a "cut and paste this block of XML for every attack you'd like to describe", I suspect it'd be easier to defeat the mass cloning of servers (one idea which I'd like to experiment with is a random "you trounced $enemy so much that you've earned the ability to add a death rattle to their repertoire!", allowing customization not from additional time-out effort, but during the actual play of the game, where it flows with the mood.)
Even with the above said, I'm not entirely sure that LoGD would be "ready" for the XML in my head (keep the scare quotes in mind - it's not like I have anything "ready" to read or react to said XML); creatures, for example, are nothing more than key/values, as you've suggested. I'd much prefer (as one of my dragonprime posts hints at) creatures having multiple attack and descriptions, further finessed per level of the attacker (allowing a creature to get "scared" and fight more desperately or even run away against a higher ranked foe). Same with death rattles, fatalities, victory dances, blah blah blah.
For year 2000 era giggles, here is a sample of XML attacks from a Smurf character I designed for one of the browser based games I began working on. Naturally, nowadays, I look back and this and chuckle at the thousands of design problems I shoulda forecasted, but, merely an example:
[attack name="punch"]
[description]%c% punches %o% savagely for %d% points![/description]
[description]%c% punches %o% with glee for %d% points![/description]
[description]%c% winds back and clobbers %o%![/description]
[skill]1[/skill]
[damage]1d2[/damage]
[/attack]
[attack name="bite"]
[description]%c% bites %o% voraciously for %d% points of teeth damage![/description]
[description]%c% gnaws on %opponent's% foot. %d% points of damage![/description]
[description]Yowtch! %c% bit %o%![/description]
[skill]2[/skill]
[damage]1d2+1[/damage]
[/attack]
Honestly, imho, if someone isn't willing to learn to program they shouldn't be running a server. There will always be bugs, there will always be glitches. If you aren't competant to diagnose and resolve those problems, you probably shouldn't ever run a server. I know that's an elitist attitude to take, but I truly feel that way a lot of the time.
You mention the races and that you feel there is redundancy there. The problem is that while the current ones are to 'some extent' cookie-cutters, to a lot of other extents they aren't and then you have things like the Felyne race which has completely different abilities. These things *are* code, not just different data, and because they are code, they need to be treated as code. That is why they have install/uninstall functions rather than just being table entries in the database. I debated with Eric for a long while and by doing them as code we allowed for far greater flexibility than if they were just data. The cost for that is that you have what you could consider to be duplicate boilerplate code. So be it.
I won't go into here, why I think having players add death rattles to monsters during game play is a bad idea. Let it suffice to say that there is a reason we have moderators for common areas. While most players are helpful and considerate, there are the few bad apples which would make a feature like this SO open to abuse that it wouldn't even be funny. It's the same reason that user-uploadable avatars will never be part of the core distribution.
I'm extremely interested, and yet, I find myself shuddering when I read things like:
[attack name="punch"]
[description]%c% punches %o% savagely for %d% points![/description]
[description]%c% punches %o% with glee for %d% points![/description]
[description]%c% winds back and clobbers %o%![/description]
[skill]1[/skill]
[damage]1d2[/damage]
[/attack]
Why...? Because I've been spoiled with the literary delights of play by post, where I can describe, in an entertaining way, my attempt to do something...factoring such elements as the sweat dripping off my brow, hefting the weighty hot steel with my battle-weary arm in my attempt to defend myself against the oncoming hordes for one last time before I succumb to exhaustion.
I want to keep this with any game I work on. Making "Gauntlet" a GPL MUD is not exactly what I envision something that is a powerful content manager to be aspiring for.
In which case, you're a little off from what I'm seeing in my head - check out http://www.lotgd.net/ for a closer (but much nicer looking, more generic, more powerful, etc.) version at what I'm aiming for. I don't see a strict interpretation of a real-time MUD being possible in a web-based/PHP environment (and I had hoped to have stressed that enough with my "No real-time" talk in the original RFC).
OK, let me take it back then...an online Gauntlet (GPL version...) is not what I see Drupal capable of aspiring to...
Actually UltraCorps lives again.
See http://ultracorps.sjgames.com/
Im actually embarking on a true web based mmo - the spirit of lotgd.net along with many of the open qualities discussed here. It'll really be a sorta web 2.0 meets mmo's. However the language of exchange will probably be json instead of xml since it is much less "verbose". I'll post a link here if it gets off the ground.
There are so many browser based games available, so with all the other mmorpg out there it can be pretty hard to pick. But i think the good news is that there are genre to fit every player. The good thing too is that many of these games are free, i used this free browser rpg games list and i am quite amazed to see the quality of free games available on the net. They make their money with online shops and stuff like this, but it's still great for casual players to be able to play at no cost.
Steve Jackson Games now has the rights to Ultracorps and is working on bringing it back: ultracorps.sjgames.com/
You know what is an awesome browser-based game? Land of Destiny. You can build up your villages, conquer other villages, pillage your neighbors, and make outposts to protect your villages. Military, Economy you have it all. Click this link to sign up: http://www.landofdestiny.com/
I got into your post from your drupal module i just wondered to see the date of posting, year 2000 , and game module 2005
anyway i have a game http://www.kicktakers.com , which i built in php, planning to redesign in drupal once i get time hopefully within 6 months (it have lot of bugs , i didn't keep track on it as i have other job) i will go through your articles, to see whether i can make it as an api based. Thank you for the post its really helpful to me
sarath
http://drupal.org/user/190746