So, I have been assigned to the task of adding a GUI to the MUD client I created. Would Gosu be a good choice to do this with? Can it support multiple windows? Can it support some of the same functionality as Ncurses (static objects, like a prompt line, but with the scrolling MUD text above, etc.)? And, lastly, do extra threads seems to screw with Gosu?

  Thanks in advance,
           Timothy. ^_^

Julian could give you a more definitive answer, but I think Gosu might not be what you are looking for for this particular project. It does not support multiple windows, and more importantly does not include a text buffer of *any* sort, let alone ncurses-like functionality. All text is rendered as open-gl textures. Which is not to say you could not implement your own scrolling text buffer... but I can't think off-hand how you'd do it. Gosu is much more intended for graphical, mostly 2D games with input usually being supplied single-key-a-time by keyboard/gamepad, or input via mouse.

As for a good alternative, that depends on what language you are looking at. Were you intending to write in Ruby, or C++? I assume it's one of the two if you were looking at Gosu.

Again, though, my word isn't final on this; Julian may pop up at any moment and point out some undocumented feature that makes Gosu just *perfect* for writing a MUD UI. Though, I doubt it, because his documentation is pretty good, honestly, so I doubt he'd leave something like that out.

Extra threads problably won't hurt as long as all drawing happens while Window#draw is executing, but multiple Windows are a no-go with Gosu (esp. since there is no way to specify the Z-order or positions between them). :(

I did manage to do a mud client in Gosu using eventmachine.

An entire 3d scene is rendered in the client using opengl in response to input being returned from the MUD server. The mud text renders to the screen and I have a small inputbox on the bottom that you can type into and hit enter to send the text to the server.

The only real problem I had was that I never implemented a scroll back of the buffer of incoming text. So, if there are players chatting and too much mud spam comes in, I can't scroll back as you would on a game such a Wow or using common mud clients.

....so, I'm sure this roadblock could be solved with clever programming, making a custom scroll system for the buffer,  but I never really cared to try and when I looked around, I didn't find anything supporting it on Gosu.

Now that I've come back again, there might be someone out there that has tackled this problem, and I may benefit from it.

Nice. For anything that involves scrolling, Window#clip_to usually solves some headaches :)

Got any samples of clip_to being used for a simulated window that can be scrolled?

Hmm, how should the result look like? :)

My usual approach to scrolling (in general) is to have a pair of screen_x/screen_y variables that are the position of the upper left corner of the screen on the map, then subtract those from all my drawing coordinates. If you only want to scroll things within a rectangular view, it'd be

clip_to(l, r, w, h) { @draw_things x - @screen_x, y - @screen_y, ... }


Thanks for the reply,
I'd love to see a sample of scrolling text up/down using clip_to.

Hi there!
I'm planning on working on a pretty text-heavy game right now and am learning Gosu as well.

I was perusing these forums and this particular post caught my eye. Since I'm trying to figure out this very problem, I decided to post an example of how I plan on implementing this.

Without further ado:

http://gist.github.com/107429

Now, this is a pretty rudimentary implementation, but you can see from the comments how it might be accomplished. I think it doesn't need saying, but you could easily implement a method like this and abstract it out into a class that provides methods of shifting the text up or down a line at a time or a specified arbitrary amount. That being said, I hope the comments explain the code well enough, but here's the gist.

Basically, the code clips an area of the screen that is 1/7th the height of the screen. I then use the word_wrap method to generate an arbitrary number of lines of text, and draw them to the screen. As each second passes, an offset is determined and applied to each lines Y position, which causes the text to either scroll up or down.

Hope this helps!