Tk is not very beautiful, but it's part of default install on many perl setups, which is a big advantage. Gtk needs a whopping lot of libraries to run (especially on windows I guess) though is better looking. I'd keep it simple and go with Tk.
Another interesting option is http://www.tkzinc.org which is beautiful, graphically very complete and waaaaay faster than Tk (it even supports OpenGl...) Oooops, I'm afraid the choice gets even harder now, sorry :) | [reply] |
Thanks. A quick look at tkzinc looks interesting, I'll do a little reading on it and see if it'll do what I want.
| [reply] |
I have looked at Gtk2, Image::Magick, GD, Tk,
and havn't been able to decide which of them
these are not on the same leve, Gtk2 & Tk are GUI toolkits, while Image::Magick, GD are graphics packages. Without any idea about the games, I'd say Tk plus GD can do what you want, probably add POE, which supports event loops for TK and network programming. | [reply] |
I know. I guess I'm hoping for a GUI toolkit, with the canvas options of Image::Magick. (the image transformation tools aren't all that important).
I'll re-look at POE, although I remember dis-liking it for some reason (although this was a year or so ago, it's probably improved, and I may be able to grasp how to work it finally)
| [reply] |
I always use tk. In fact, I'm rewriting a drawing program using the canvas widget. | [reply] |
I would also say use Tk or Tk::Zinc. Zinc will allow you to
do easy "resize and rotations" on "defined groups", which is tough to do on a plain Tk Canvas. But a plain Canvas would probably be easier to get going. As far as Tk "not looking good"...it looks as good as the amount of "detailing" you want to put into it. Gtk2 is coming on strong, but unless you are "expert" at objects, signals, and gui design, it will be harder to work with than Tk, plus Tk is definitely better tested on Windows, and easier to install ( it comes with ActiveStatePerl.) Getting back to your design, I will tell you right away, you will have to work out some sort of "data transmission protocol" to keep your player's screens in "sync". What I mean is, you will not be able to "send objects thru tcp", you will be able to send hashes(or whatever) of positional(and gui details) data
to your clients, then they will have to "update" their screens with that data.
For learning about it, I wrote a multiplayer "scrabble clone", which uses Tk Canvas, and Net::Easy::TCP. Its at ztk-babel client server game with chat. Feel free to look at it, and use it's code if you can figure it out. Right now, I'm playing with a poker game, using the same code, but I've turned it into an "object-oriented" design, which you may want to do. Why. It will get extremely complex trying to keep track of all the player's data, and if you make each player a blessed object,
with internal methods, you will be able to simplify things.
As you can see in ztk-babel, I use hash tables to send data,
and I've reached the "breaking point of complexity". If I were to redo it, I would use a more OO design. Another pointer, is that Net::EasyTCP makes it easy to exchange "hashes of data", plus it has built in encryption and "port protection" , which will be important if you try to play your game on the "open internet", where you will get "port scanned and hacked" within minutes.
I'm not really a human, but I play one on earth.
flash japh
| [reply] |