About this blog
Building Janthus, a Java MMORPG from scratch
Entries in this blog
I've started to build a simple conversation engine into Janthus, something I've never actually done before. I'm doing it from scratch, just to get the experience with thinking about the problem; but eventually I see this component of the game being replaced by something driven from Lua scripts, especially if I want 3rd parties to create content for the world.
At the very simplest level, conversations in Janthus will be structure in this way:
1. Player X initiates a conversation with NPC Y.
2. Every sentence transmitted from Player X gets piped through a list of ResponseParsers, which uses regular expressions to determine if its the correct response provider for the given sentence, and the world/player state.
3. A response is either simple, in that it provides text response to the user,
4. Or its complex in that it expects the next sentence from the user to be one thing or another.
5. Conversations will carry state, and the parsers that are available for response may be whittled down depending on the flow of the conversation.
I hope to make this as data-driven as possible, so conversations can be stored in a conveniently editable form such as text file or something (in XML, json, whatever).
Another significant problem to solve is how to express giving things or taking things from an NPC will happen in the context of a conversation...
Added the first quest-type point to the game: descend into the Rat Cave (entrance at 122,62 inside the small cave in the starter castle), and clear out all the rats (50 of them). If you survive (and you should, the rats are easy) -- the Rat King will appear in the cave to challenge you. Kill him (very tough) and his rat minions will return).
This represents several milestones in the game:
* introduction of submaps/subworlds -- no longer is the game restricted to one gigantic overworld, you can now go to different self container worlds, possibly hosted somewhere else
* introduction of the quest element, as opposed to random pillaging and exploration
I've also very much solidified the networking aspect of the game, so if you have a reasonable connection to the internet, the game should play fine.
Let me know what you guys think (and if you can kill the Rat King, whether or not he's too hard, etc.).
Creating an MMO (see http://www.janthus.com) is monstrously difficult, as I've come to realize. After literally spending hundreds of hours on the core game engine as a sole developer, I've just now started to make inroads into the horrible problem of lag, and fighting it to the point where people within 250ms to 500ms delays to the server can have a reasonably good experience as those below. The huge task of creating immersive content (art, story lines, interactions, puzzles, quests, etc.) hasn't even factored in how much time I've spent at this.
Here are the major highlights of my fight:
- when fighting lag, you must consider 2 sources -- lag from your client to the server, and lag from another client viewing your actions, to the server.
- turn of Nagle's algorithm (TCP_NODELAY), I forgot to do that, and was mystified why I'd get sudden unexplicable message bursts -- because they were getting cached
- don't implement the networking scheme where you move your client, and then broadcast each individual move to the other clients; this falls down especially quick with TCP
- a better strategy is to allow the local client to stop/start motions, and send comnmands to the server to update remote clients accordingly. But you've got to have smooth adjustment logic on the remote client side to handle the case where your remote avatar has overshot, and now has to backtrack!
- definitely localized messages -- only clients within 'viewshot' of each other should see things like attacks, movements, etc.
- very definitely track the amount of lag experienced by the clients ... this will help you debug whether or not slowdown is due to lag, or just bugs in your code, when people are playing the game in the wild.
- I've found that position corrections (for your avatar on remote clients) should be done with as little "zipping around" or "teleporting" a possible. To avoid the former, corrections should be animated at walking pace, if the delta between current and actual position is under something like 2.5 seconds. To avoid the latter, animated autocorrections should be made (with the previous statement in mind).
What I've found from people playing the game is that people are willing to forgive crappy graphics, generally, if the controls are smooth and intuitive. And making sure that you got lag beat is definitely a giant factor for the former.
I'm still hacking away at it, and I think I am chipping away at the problem. It seems to be reasonably playable in its current state for people in Beijing and Australia, with the server being in the US. So I am optimistic!
So the communication protocol in Janthus (http://www.janthus.com) is basically a custom solution, transmitting a simple text protocol over TCP. I wonder if I basically re-invented the wheel on this one. I've mused about using XMPP (Openfire, see http://www.igniterealtime.org), most of it written by one of my excellent colleagues over at Jive Software. One of the reasons I didn't go there was my (probably) irrational fear of the overhead of parsing xml streams. Also I was pretty sure that traffic to the server would not merit an ultraefficient communication protocol at first, a thought which has so far proved correct, as no more than 2 people log on every few hours or so right now. It would be an awesome problem to have, if I begin to have problems of scale Openfire would probably be my next stop, and perhaps the most logical one, as Janthus is design pretty much like a gigantic chat room at the moment, a shoo-in for the aforementioned technology.
Following my initial discovery that looks are indeed important, I've since striven to incrementally improve the look and feel of the world. For instance, I've severely curtailed the use of ascii tiles for both the movable sprites, and the world tiles:
I've noticed that visitors have started to enjoy the improved mouse-only controls, making it trivial for casual users to explore the world and interact with it (left, ctrl-left clicking to attack things; right click to move; shift-left to heal things, etc.). Casual visitors are actually encouraged to stick around enough to test drive the world, which is very encouraging.
However, every minute of player time is costing me ungodly amounts of development and design time; more than ever, its driven home every night I spend working on this thing till 3am, that creating a living online world is not for the faint hearted. This is truly a labor of love, and I honestly don't know why I do it; there is something addictive about creating a world of your own making.
Anyways, what I've discovered in the process of creating the new sprites, is that its now possible for the look of the sprites to change as a result of attributes. Stronger characters for instance could be made to look more bulky and bigger; more intelligent characters could be made to look thinner and taller, etc.. Also it opens up the avenue to player customization of their character. I think that this will ultimately help with player attraction and retention, because you end up caring a little more about the tiny guy who is your avatar in the world.
Probably whats next at this point is more wearable/usable items, such as shirt, pants, hats, helms, greaves, etc.. of various sizes. I am also thinking of adding more non-human entities such as wolves, dogs, snakes, etc. just to give a little variety to the bestiary. Comment here if you have a preference of what you want to see first (if anybody is watching this journal).
But maybe it might be time to introduce attributes and levelling to the game. I have a prototype of it, where strength matters for example. I may just implement that first, as it might encourage players to register and have persistent accounts.
Its been an interesting 3 days of alpha testing the game. What I've discovered is that the amount of time people spend in the game literally exploded from 15 seconds a visit to 10-15 minutes a visit when I made slight tweaks to the graphics engine (to be less ascii-like). Also it appears that most casual drop-ins were most disturbed by:
the very low density of simultaneous users (eg. it was usually one visitor at a time, plus me)
wasd controls which did not work like typical wasd movement controls -- you keep moving until you press the same direction twice, which users found confusing
in one instance the top down, fixed center world rendering made him feel illIts been very instructive, especially since I am trying to figure out what to do at this point. I believe that my best bet is to improve the controls, adding perhaps mouse control over movement, and attacks (though no one asked for this specifically); and also to make wasd movement more natural.
One of the interesting technological things I implemented was the notion of dynamically generated tiles: they are rendered via polygons and ascii characters, on to a single in-memory tile, which I then cache for the remainder of the rendering cycle. Previously, I was computing the polygons every since rendering -- which tended to bog down the client of course. I'm trying to avoid the use of real pre-rendered tiles, because its kind of time intensive and expensive.
Finally after 5 years of procrastination, I built out my mmorpg engine, Janthus (http://www.janthus.com) to the point where it can actually be played by more than 3 people (I think). Not really sure that 3 people make it a massively multiplayer online game, but at the very least, it doesn't seem to tank when my brothers and I log in and duke it out in party mode against the hordes of bad dudes roaming the world.
There were many false starts, most notably the one I opensourced (and abandoned due to the arrival of my son), http://sourceforge.n...ojects/janthus. That engine had some fundamental flaws in its inherent design, particularly the overly multithreaded architecture, and premature support for sharding, all of which contributed massively to bloat and unnecessary complexity.
The new design is consciously single threaded, with a single execution loop iterating through very short lived events, effectively timeslicing the CPU over the various tasks that power the world. This has worked out to be much more performant ... of course, I have yet to see any kind of traffic on the engine, so only time will tell if this approach beats out the earlier design (though I am pretty sure it will).
Now that I have a reasonably well fleshed out proof of concept -- fully playable -- I'm at an interesting crossroads: where to invest my incredibly scare free time? I could go many directions:
build out a story line
improve the graphics (but still keep the retro look)
focus on player dynamics (more party support, guilds, etc.)
more npcs and AIIf the engine can stay stable with say, 50 or more simultaneous users (please log in and play!), I could safely spend the next year or so on any one or two of the above. I won't bother if the engine can't support that many players, however; it just means I have to spend more time on the core engine, which I hope I don't have to do, having already spent months rewriting the original.
I'll try to keep this journal going, as a testament to my ultimate goal of creating a playable online community!