ID:154284
 
I've been working on a classic "dungeon crawl" type of RPG game for a while, largely using the new popup browser window functionality, and it's been going very nicely. Thus far, with the simple mock-ups I've got in place, I haven't seen any need to use statpanels for presenting stats, per se, and most commands are accessed via topic links (though I'm keeping the verbs accessible through command-line input).

However, I'm fast approaching a problem... the game is heavily text-oriented, mostly because I do not under any circumstances want to have to draw new graphics to add any new elements. Since the contents of a player's surroundings aren't represented graphically, I'm left with an unsavory choice... I can use slow-to-update popup windows to display the items and monsters in the same room as a player, I could use a statpanel just to display the player's room's contents, eating up space (and since I use the browser pane too, in lower resolutions players won't be able to see it and the statpanel at the same time), or I could just give up on having a realtime-updated contents listing. Movement is fairly slow-paced and finding new mobs or objs to interact with will generally create a prompt situation anyways, so this last option isn't quite so bad, but it does tend to drive me crazy in MUDs and the like when I have to constantly use the look command.

Any thoughts?
Everyone's used to the look command :oP Especially me, since I'm building one of those MUDs that drives you insane.
I was working on the exact same project as you, but it was my side project and it got further sidelined mentally when Tom said a history fix would probably be a long time coming, so I don't mind sharing what I've come up with.

First of all, I had separate windows (eventually to be arranged into frames) for the room's description, which was only updated when the room changed, the room's occupants (mobs), and the room's contents. I also had an "output" box, my version of the text console, since I intended the game's browser frameset to take up the whole screen. The occupants and contents were only updated when there was a change to those lists, and with a built in action delay (when you click an action, it announces that you begin that action, delay while the action is performed, completion of action is announced), this seemed to work pretty well.

I also made stylistic choices to minimize the number of updates needed... when you killed a monster, its contents went directly to you. I handled movement and combat by party rather than by mob. Everything as a whole was rather sedately paced. Rather than the old "it hits you you hit it it hits you you hit it" school of combat reporting, all sides involved made some basic tactical choices at the start of combat, and then the results of the initial fray were computed. If both sides were still standing, they could repeat.

In the end, players with slow connections are still going to be a step behind those with fast connections, but in an online game, I don't see how that can be avoided.
In response to Lesbian Assassin
Lesbian Assassin wrote:
I was working on the exact same project as you, but it was my side project and it got further sidelined mentally when Tom said a history fix would probably be a long time coming, so I don't mind sharing what I've come up with.

Check the release notes, Lexy :)
In response to Tom
Tom wrote:
Lesbian Assassin wrote:
I was working on the exact same project as you, but it was my side project and it got further sidelined mentally when Tom said a history fix would probably be a long time coming, so I don't mind sharing what I've come up with.

Check the release notes, Lexy :)

Yeah, it's there -- making the development of certainly heavily web-based apps a bit more of a pain for the developer to test!
In response to Tom
Yeah, I had already seen that... thanks for the quick response, but you ought to know by now it doesn't take much for me to lose interest in a project. :) Since it sounds like Leftley's got something similar in the pipeline, I'm still going to hold off.
In response to Deadron
Deadron wrote:
Tom wrote:
Lesbian Assassin wrote:
I was working on the exact same project as you, but it was my side project and it got further sidelined mentally when Tom said a history fix would probably be a long time coming, so I don't mind sharing what I've come up with.

Check the release notes, Lexy :)

Yeah, it's there -- making the development of certainly heavily web-based apps a bit more of a pain for the developer to test!

Do you want the "clear" feature ("clear=1" to clear the history) to be optional? I figured no one would care, so there was no sense complicating the syntax.
In response to Lesbian Assassin
Lesbian Assassin wrote:
Yeah, I had already seen that... thanks for the quick response, but you ought to know by now it doesn't take much for me to lose interest in a project. :) Since it sounds like Leftley's got something similar in the pipeline, I'm still going to hold off.

Well, I'm not sure if it's quite in the pipeline... more like heading in the pipeline's general direction. I'm getting sidetracked off of it myself. Making a first-person dungeon view didn't turn out to be abusive enough on the engine, so I'm working on a new way to break it.
In response to Leftley
Well, I'm not sure if it's quite in the pipeline... more like heading in the pipeline's general direction. I'm getting sidetracked off of it myself. Making a first-person dungeon view didn't turn out to be abusive enough on the engine, so I'm working on a new way to break it.

I demand that you turn Treasure Seeker into first person, then!
In response to Spuzzum
I demand that you turn Treasure Seeker into first person, then!

It's too far from its boardgame origins as it is!
Leftley wrote:
Any thoughts?

How about we bug Tom and Dan to make statpanels into little windows that are movable, resizable, openable and closable (and the text and browser window too!) and their existence controllable from a "windows" menu?

Whee!

Z
In response to Tom
Tom wrote:
Do you want the "clear" feature ("clear=1" to clear the history) to be optional? I figured no one would care, so there was no sense complicating the syntax.

It seems worth it...certain web-based utilities and games might want to allow people to backtrack, and it definitely makes a difference in my testing.
In response to Deadron
I agree... my request was intended to add functionality to the browser window, not change their function. If they can be used as both user-guided browsers and designer-controlled pop-ups, all the better.