Glad to see such a project
Michal M
I landed on your sorrows-mudlib project page by chance while searching
some python related stuff. I was glad to see that someone develops a
project that resembles my own. I develop mud-roguelike in Python (not
stackless) as a hobbyist project. I even use miniboa too. Is your
project ready? Are you going to continue it?
Regards
Michal
Richard Tew
Hi Michal,
My project is more of a technical experiment than something ready for
use. I tend to find it easier to implement new systems than to design
a game to play. I would like to take a step back, design a game that
can be played and then create a new code base that picks useful pieces
of code out of the existing code base to make a simpler code base.
Cheers,
Richard.
mich.m...@gmail.com
I see. I am experimenting as well although I wish my game would be playable some day.
I just noticed your code is a lot better than mine so I hope you would not mind if I checked some solutions from your code.
W dniu Richard Tew <richar...@gmail.com> napisał(a):
>
> You received this message because you are subscribed to the Google Groups "sorrows-mudlib-discuss" group.
>
> To post to this group, send email to sorrows-mud...@googlegroups.com.
>
> To unsubscribe from this group, send email to sorrows-mudlib-di...@googlegroups.com.
>
> For more options, visit this group at http://groups.google.com/group/sorrows-mudlib-discuss?hl=en.
>
>
>
>
Richard Tew
> I see. I am experimenting as well although I wish my game would be playable
> some day.
> I just noticed your code is a lot better than mine so I hope you would not
> mind if I checked some solutions from your code.
Do you have your code checked in somewhere?
If you did and I could see you check in your progress, it would be
healthy competition for me to develop mine more.
Yes, check what you wish. It is open source.
Cheers,
Richard.
Michal Mierzwa
Cheers,
Richard.
Richard Tew
> I work on it by myself only so I did not bother to create repository. If you
> would like to take a look though here is the zip file with
> code. http://dl.dropbox.com/u/21455945/pymud.zip
You should put it in a repository. No-one uses my code but me, but
you never know who like yourself might stumble over it and have an
interest in talking about it.
> First I created it but soon started worrying about performance (e.g. I
> wanted to implement A* pathfinding algorithm to be useful for npc's). So I
> decided it will be fun to have one central server and as many clients as
> needed. So Central is taking care of connections with users, databases and
> Clients, whereas every Client runs one or more areas. Of course it is pretty
> much transparent for the gamer who can move between areas no mater whether
> they are on the same client, on client run as another process, or even
> client on another machine. There is also www comet solution that works like
> telnet but switched off by the moment. Oh, game is designed to be
> multilingual but at the moment only polish and English exists. English is
> not completely translated.
> I am during translation to client-server architecture and it barely works.
> And I am really bad coder. :(
> So I doubt you find anything interesting in my code but If you would like to
> see it - you are welcomed.
I don't really have any advice, it is hard to understand someone
else's framework without using it or experimenting with it. The code
looked fine to me, it looked like you had made progress in a wide
variety of areas. Lots where I am not making progress myself..
especially game-wise.
The presence of a GIL in Python is guaranteed, so the locking in your
web server is pointless I think.
I recommend mudbytes.net as a forum for mud discussion. It is the
most popular place for mud developers.
Cheers,
Richard.
Michal Mierzwa
On Fri, Sep 23, 2011 at 2:56 AM, Michal Mierzwa <mich.m...@gmail.com> wrote:You should put it in a repository. No-one uses my code but me, but
> I work on it by myself only so I did not bother to create repository. If you
> would like to take a look though here is the zip file with
> code. http://dl.dropbox.com/u/21455945/pymud.zip
you never know who like yourself might stumble over it and have an
interest in talking about it.
I don't really have any advice, it is hard to understand someone
> First I created it but soon started worrying about performance (e.g. I
> wanted to implement A* pathfinding algorithm to be useful for npc's). So I
> decided it will be fun to have one central server and as many clients as
> needed. So Central is taking care of connections with users, databases and
> Clients, whereas every Client runs one or more areas. Of course it is pretty
> much transparent for the gamer who can move between areas no mater whether
> they are on the same client, on client run as another process, or even
> client on another machine. There is also www comet solution that works like
> telnet but switched off by the moment. Oh, game is designed to be
> multilingual but at the moment only polish and English exists. English is
> not completely translated.
> I am during translation to client-server architecture and it barely works.
> And I am really bad coder. :(
> So I doubt you find anything interesting in my code but If you would like to
> see it - you are welcomed.
else's framework without using it or experimenting with it. The code
looked fine to me, it looked like you had made progress in a wide
variety of areas. Lots where I am not making progress myself..
especially game-wise.
The presence of a GIL in Python is guaranteed, so the locking in your
web server is pointless I think.
I recommend mudbytes.net as a forum for mud discussion. It is the
most popular place for mud developers.
Richard Tew
> It's hard to find such an enthusiast like me these days. Would you take into
> account possibility to merge our projects (providing it is possible) and
> work over it together?
I'd definitely consider it, but I don't think it is possible. We do
not have the exact same ideal feature sets or games in mind, and this
would get in the way of developing code. The best we could probably
do is to work together to create some libraries of specific shared
functionality.
Not sure what offhand though.
Cheers,
Richard.
Michal Mierzwa
Richard Tew
> 2011/9/24 Richard Tew <richar...@gmail.com>
>> would get in the way of developing code. The best we could probably
>> do is to work together to create some libraries of specific shared
>> functionality.
>>
>> Not sure what offhand though.
>
> You are probably right. One of the features I will need is scripting system.
> How it looks like in yours?
It depends what you mean by scripting system, if you mean a way for
people to code and build while logged on rather than doing it in the
same codebase as the game engine itself.. then I have none :-) That
would be done locally by developers with a copy of the codebase and
then submitted as a patch or something.
I'm finding it difficult to find ideas that aren't dependent on my own
game design ideas :-)
Cheers,
Richard.
mich.m...@gmail.com
Cheers
Michal
Richard Tew
> Ok, I see. In case you would like I am always open to discussion. :)
I've been thinking about some project ideas. They're pretty general
so would help out any Python MUD.
1) Web-hook-up mini-project that any developer can hook their MUD up to.
This should have as few dependencies as possible, use as much
non-custom only standard Python library support code as possible and
provide:
- Flexible web page to web server transport layer (web sockets,
otherwise flash, otherwise comet, otherwise ajax).
- Web-based support for text game, perhaps a terminal-like interface
with colours, links, etc. This could also be left out, maybe there is
a better option.
- Python server-side interface that is easy to use.
To me for the first point, socket.io seems like the best option.
Maybe you already have some code which we could use to be the start of
this, if you were interested in working on it together, since you
mentioned some disabled comet support.
2) Text-based graphics library.
Roguelike tiles:
Unicode, ascii, characters. Generating an array of "tiles"/characters
to display. Now, the way I envision it, there are going to be layers.
There's going to be the world which is rendered based on the viewed
contents of each given tile in the view window of the players. There
is going to be a user interface over this, perhaps with menus and
perhaps with speech bubbles and other gameplay enhancing elements.
It should be possible to only render selected layers, so that if there
were speech bubbles and overlaying game enhancing elements like that,
they would be rendered as tiles over the world view tiles. But if
the client was web based, then the opportunity would be there to use
javascript and floating divs or whatever to render something that
takes better advantage of the medium.
MUD text:
The library should be designed in such a way that for the viewable
area of the player, the API allows generation of "graphics" in the
form of a text description. This would be secondary and would just
generate the most straightforward representation in order not to
distract from the main focus of roguelike. It would also encourage
routing information in abstract ways, like where speech bubbles would
be used for heard dialogue in the roguelike, in the text-based MUD it
would appear as a normal "say" or "tell".
3) Internationalisation.
I know nothing about this and I think you homebrewed your own
solution. But if I were to do it, I'd want to research the current
game development state of the art and hopefully find some generic
Python library (or C/C++ library which might have Python bindings).
Or generify your solution if that were the best option and it was some
way towards that ideal solution already. Thoughts?
We might have a library which would wrap this and would provide a way
of registering known internationalised strings, and a fixed
straightforward format for messages which are to be processed. And
some way of making available game data in a standard way for it to use
to populate messages.
4) Telnet support library.
miniboa is all well and good, but I think I found it lacking. Maybe
look at these codes and see what we should do to provide something
better:
- https://github.com/Twisol/anachronism
- http://www.mudbytes.net/file-2811
5) MUD architecture
Something to be discussed is MUD architecture. So there is a
web-based interface. So there is a telnet interface with support for
colors, unicode and protocols. So there is internationalisation.
What is the MUD made up of? What functionalities are needed? How do
these things link together?
Anyway, just some ideas, Any thoughts / interest?
Cheers,
Richard.
Michal Mierzwa
2011/9/26 <mich.m...@gmail.com>:
> Ok, I see. In case you would like I am always open to discussion. :)I've been thinking about some project ideas. They're pretty general
so would help out any Python MUD.
1) Web-hook-up mini-project that any developer can hook their MUD up to.
This should have as few dependencies as possible, use as much
non-custom only standard Python library support code as possible and
provide:
- Flexible web page to web server transport layer (web sockets,
otherwise flash, otherwise comet, otherwise ajax).
- Web-based support for text game, perhaps a terminal-like interface
with colours, links, etc. This could also be left out, maybe there is
a better option.
- Python server-side interface that is easy to use.
To me for the first point, socket.io seems like the best option.
Maybe you already have some code which we could use to be the start of
this, if you were interested in working on it together, since you
mentioned some disabled comet support.
A lot of work in this area is done. When I started there were no web sockets so I developed my own comet solution.
Well, it worked. So if you like we could start with it. It provided telnet like terminal in a floating window. I have seen ready made solution too.
http://decafmud.kicks-ass.net/
The reasons I am tend to not to use it and improve my solution is that:
1. I have it, it works, I know it
2. Maybe I will improve it to include graphic map for instance and so on, knowing my code from server and client side it will be much easier.
2) Text-based graphics library.
Roguelike tiles:
Unicode, ascii, characters. Generating an array of "tiles"/characters
to display. Now, the way I envision it, there are going to be layers.
There's going to be the world which is rendered based on the viewed
contents of each given tile in the view window of the players. There
is going to be a user interface over this, perhaps with menus and
perhaps with speech bubbles and other gameplay enhancing elements.
It should be possible to only render selected layers, so that if there
were speech bubbles and overlaying game enhancing elements like that,
they would be rendered as tiles over the world view tiles. But if
the client was web based, then the opportunity would be there to use
javascript and floating divs or whatever to render something that
takes better advantage of the medium.
MUD text:
The library should be designed in such a way that for the viewable
area of the player, the API allows generation of "graphics" in the
form of a text description. This would be secondary and would just
generate the most straightforward representation in order not to
distract from the main focus of roguelike. It would also encourage
routing information in abstract ways, like where speech bubbles would
be used for heard dialogue in the roguelike, in the text-based MUD it
would appear as a normal "say" or "tell".
In my current solution there is map about 15x15 displayed with player character in the center.
There is also heights taken into account (displayed in colors). Displaying map line of sight is taken into account (obstacles can hide other elements).
Text and all information is displayed under the map. I did not consider to improve it to be an ascii-graphics because these days everyone can use
web browser and there I can use true graphics for that.
So I would rather like to work over graphic display output in a browser window leaving telnet side as I have it now.
3) Internationalisation.
I know nothing about this and I think you homebrewed your own
solution. But if I were to do it, I'd want to research the current
game development state of the art and hopefully find some generic
Python library (or C/C++ library which might have Python bindings).
Or generify your solution if that were the best option and it was some
way towards that ideal solution already. Thoughts?
We might have a library which would wrap this and would provide a way
of registering known internationalised strings, and a fixed
straightforward format for messages which are to be processed. And
some way of making available game data in a standard way for it to use
to populate messages.
I agree. I doubt there is possible uniwersal grammar library. My solution works with polish and english.
There is no problem to widen it to use other languages too. It can use also native diacritical characters in different
encoding systems.
If we could find ready made solution - I am open to adapt it. If you like, we can take what I have and work over it.
4) Telnet support library.
miniboa is all well and good, but I think I found it lacking. Maybe
look at these codes and see what we should do to provide something
better:
- https://github.com/Twisol/anachronism
- http://www.mudbytes.net/file-2811
I do not know what more we need. The miniboa author works on improved solution that can work in character mode instead on
line mode. (but I think I do not need it). Generally subject to discussion.
5) MUD architecture
Something to be discussed is MUD architecture. So there is a
web-based interface. So there is a telnet interface with support for
colors, unicode and protocols. So there is internationalisation.
What is the MUD made up of? What functionalities are needed? How do
these things link together?
If you would like I could present few of my solutions that I think my be interesting.
Anyway, just some ideas, Any thoughts / interest?
Cheers,
Richard.
Michal Mierzwa
Cheers,
Richard.
Richard Tew
> Oh, one more subject. I was thinking I could provide full 3d client made in
> unity3d (also working in browser) and in a result end up with a MMO instead
> of MUD/Roguelike. But it would be too much even for us 2 and involves
> graphics work. So maybe in the future... :)
I like the idea of a procedurally generated world in 3D.. but as a
programmer I want to stick with text as a medium for display. It
allows me to focus on programming, without getting distracted by
graphics programming. Unless the graphics programming was old-school
retro style lines and flat shading demo style :)
Cheers,
Richard.
Michal M
On Sep 25, 3:05 pm, Richard Tew <richard.m....@gmail.com> wrote:
> On Sun, Sep 25, 2011 at 1:47 AM, Michal Mierzwa <mich.mier...@gmail.com> wrote:
> > 2011/9/24 Richard Tew <richard.m....@gmail.com>
> >> do is to work together to create some libraries of specific shared
> >> functionality.
>
> >> Not sure what offhand though.
>
> > You are probably right. One of the features I will need is scripting system.
> > How it looks like in yours?
>
> It depends what you mean by scripting system, if you mean a way for
> people to code and build while logged on rather than doing it in the
> same codebase as the game engine itself.. then I have none :-) That
> would be done locally by developers with a copy of the codebase and
> then submitted as a patch or something.
possible bugs, mean behaviors, mess and so on. So I would rather
separate game code from in-game scripting.
It could be done using some hooks and plugins. Base code should be
protected in case of script failure and every script should be easy to
remove/disable.
One of possible solutions I can think of is to spawn separate thread
only for scripts. Script could be executed in such a thread, while
execution main program should wait but be able to stop executed script
on timeout. Scrip execution environment must be prepared carefully to
have access only to what we want allow.
Richard Tew
> On Sep 25, 3:05 pm, Richard Tew <richard.m....@gmail.com> wrote:
>> same codebase as the game engine itself.. then I have none :-) That
>> would be done locally by developers with a copy of the codebase and
>> then submitted as a patch or something.
>
> I gave it some thoughts and it seems it is not good idea. Because of
> possible bugs, mean behaviors, mess and so on. So I would rather
> separate game code from in-game scripting.
> It could be done using some hooks and plugins. Base code should be
> protected in case of script failure and every script should be easy to
> remove/disable.
I think that the only way to safely do scripting, is to embed another
language that supports sandboxing like lua. Or to move to PyPy as a
Python environment.
Cheers,
Richard.