cyanide-devel Mailing List for Cyanide
Status: Beta
Brought to you by:
kcnkcn
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(4) |
Oct
(1) |
Nov
(2) |
Dec
|
---|
From: <chr...@re...> - 2002-11-12 13:20:30
|
Hello! We have just released the new version of the Cyanide client: reality-python 1.1.2 Download it from the sf page (http://www.sf.net/projects/cyanide/). There are not many changes, but the client will run more stable. Take a look at the news on the sf page. Regards, Christian |
From: Timtohy <tr...@si...> - 2002-11-12 00:58:21
|
On Mon, 11 Nov 2002 16:54:25 -0800 cya...@li... wrote: > Cyanide-devel -- confirmation of subscription -- request 355503 > > We have received a request from 204.210.207.97 for subscription of > your email address, <tr...@si...>, to the > cya...@li... mailing list. To confirm the > request, please send a message to > cya...@li..., and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 355503 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to > cya...@li.... |
From: <chr...@re...> - 2002-10-02 17:11:15
|
Hello! Cyanide needs a server. Mine went offline on monday, and I do not why or if it will ever come up again, for I have no physical access to it. If it comes up again, a second server would also help a lot, because we could use the second server as a development server. Requirements are: Python (>=2.0) Good would be: webspace free ircnet connection (for the astral chamber) multiprocessor Regards, Chrstian |
From: <chr...@re...> - 2002-09-26 19:54:33
|
Hello! Once, there was much activity for cyanide, but now I'm not very happy about the discussions going on (actually there are no discussions going on as you perhaps have noticed...). The forum I created was something near to useless. Is something not working or am I just too optimistic about the motivation of loosely arranged free software developers? Ah, and tell me if you have a sourceforge username and want to join the project! Perhaps I'll inform you about what is going on at the moment: XML protocol: The communication protocol between server and client is changed to XML, we could need some design workers here, although it is pretty far. Animations and Sounds: Animations and Sounds are enabled in the client. Design is mostly done and implementation is not hard. We could need some artists here. Sprite size: The sprites are expanded, Jesus said he was experimenting there. How far are you, Jesus? Client interface: The client interface is made more "graphical" (like in Diablo). Jesus? Roleplaying: Fights: Fights are implemented in the server. We could need both design and implementation workers. It will be half-realtime, that means that the character keeps on attacking the enemy/enemies until interrupted. Two models: 1. Everything is a matter of speed, so every character + weapon results in different speeds of drawing a weapon, attacking, putting the weapon/shield into defense. While that happens, the enemy acts, too in realtime. When the defender is not in defense state while the attacker attacks, the parade failed. The damage depends on armour, weapon type, perhaps time taken to strike out, ... 2. Everything is a matter of skill points and chance. So you have a certain probability to fail an attack, to fail a parade and the damage is computed similarly. All those probabilities surely depend on other things like weapon type and of course, training. In the second alternative there are clear fighting rounds, one attack per round. The first alternative allows completely free attacks, but I think a weak character has no chance to attack at all against a strong character. Ok, that was much, perhaps too much... On we go: Quests: Nothing yet, I do not even have a clue about any quest... Though money already exists... -> Design + Implementation It would be very kind of you, if you could "subscribe" to one of the tasks ;-). I would like to give more information about everything, the server internals, my ideas etc. But I think this is not a good idea to post on the main mailing list. We could use the forum or create other mailing lists. Regards, Christian |
From: Sean <pa...@fr...> - 2002-09-23 00:15:54
|
Hey all, I'm in the beta test, but sadly, still have not been able to play Cyanide, try as I might, windows will not play it, also the 1.1.1 release is pretty broken, no data etc. For a world, I think something like UO would be best, medieval style, with the class system, trades/fighting skills, everyone loves UO, and everyone loves medieval stuff, or at least, a lot do, if the hundred thousand plus UO players don't show that already. Sure it's unoriginal, but done right, will be good :) -Thikanu |
From: <chr...@re...> - 2002-09-22 21:25:47
|
Hi folks! Hey, I'm back again, but unfortunately, I see that the activity of cyanide has dropped to 40 per cent. I think we need animations and fighting as soon as possible or nobody will use/play cyanide. I've posted an article to the forum, but nobody has answered it yet. Some things I've got to work while I was on that seminar, I will merge the changes into the CVS in the next days. Ah and how are the beta tests going on? Hmm, and perhaps someone has a neat story to build a world around? Regards, Christian |
From: <je...@ya...> - 2002-09-08 17:49:17
|
----- Forwarded message from darkfusion ----- Date: Fri, 6 Sep 2002 15:42:17 +0200 To: cya...@li... Subject: reality-python_1.1.1 out Hello Friends! I am happy to anounce that reality-python version 1.1.1 is out. How about a release party, this evening at my house ;-) The purpose of this release is mainly to get all the fresh new features I implemented in the last weeks out before the client will get a mess. We will change a lot of things, perhaps the communication protocol and in any case the graphics system, and I wanted to have a stable version for the non-developers. reality-python 1.1.1 is mainly out developer version at http://secretstar.de/stuff/reality-python_1.1.0-dev.tar.gz Ok, anything else to say? I guess not. Regards, Christian _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es |
From: <chr...@re...> - 2002-08-26 20:26:53
|
Hello all! I made a forum post for cyanide concerning abolishing cell based graphics. This should be interesting for developers and graphicians. Greetings, Christian PS: If you have problems accessing the forum, please drop me a line. |
From: <chr...@re...> - 2002-08-25 19:33:14
|
Hello! I have activated the forums (and other features) at sourceforge and created some forums. (http://www.sf.net/projects/cyanide) BTW: How wants to be added as a project developer, please mail me your SourceForge username. On Sun, Aug 25, 2002 at 07:36:42PM +0200, Jesus Lopez wrote: > Hello all, > > here I send some comments over the different topics. > __________________________________________________________ > __________________________________________________________ > > Graphics: > > [...] > > For this first assignments (potato, plants, salesman, > etc), lets distribute them. To begin with, I send to > you a tentative money bag and a potato. Hey, they are really great :-) But it would be good if all the pictures were exactly 32x48 pixels (up to now, depends on if we change that or not) with a transparent background and both png and gif. Here pops up a very difficult issue: One year ago, I wrote a client in Java and at the moment I want to leave it compatible with current servers. Now if we change the resolution of the images, this cannot be done. But generaly, I think that compatibility is not that big an issue, because no-one really uses that client... What do you (all) think? > There is another point regarding graphics that I would > like to talk about, and its the tiny size of the > terrain cells. There are > good reasons for it, sure, but I really think that we > should look for increasing the size of them. That > would allow for more detailed > objects, characters and terrain. The current size > implies that, either we create a huge number of tiles > to create patterns larger than > a cell, or we stick to heavy tiled look of the game. It is not a good thing to create moving objects bigger than one cell, so I would say that we should enlargen the cells, now that we have our own graphics (or will get). I think that abolishing cells at all would not be a good idea, because we need collision detection and so on. Another solution would be to only enlargen the maximum inventory image size. > A mixed solution to avoid increasing the size of the > cells, is to put background, fixed images and over > them, put the cells, that would > be usually include some transparency (or be completely > tranparent!). I do not know if this is possible > (Christian?). Yes, that's possible. I have also already thought of that. We can put a (big) image of a meadow in the background and then put the cells above it, for example the walls of a house and the players. Transparency is used already. When we do that, flexibility is damaged a bit, because no-one can create his/her own rooms without drawing his/her own background image. But it is preserved as far as small changes in the room are concerned, for example burned grass can be simulated by simply drawing a cell with burned grass on top of the background image. > --- Design: --- > > For battles, I have thought over a possible non > realtime solution, not either a turn based one. The > idea is to make combat automatic. > When attacking or being attacked, combat mode > automatically switches on, and all involved characters > engage into combat with the weapons > they were wielding. This could be sophisticated with > rough- scripted behaviour ala Baldurs Gate (equip best > weapon, heal self when points under x%, etc), > but the key point is that there is no need for player > input during combat, apart from "Break from combat", > or "Flee!", well, something like that. > > This idea could be improved with player input over the > combat. Things that require 1-2 seconds, like changing > the weapon, using an inventory item, etc, should be > possible, even > if there is a big lag since the player clicked. During > that 1-2 seconds, a message like "Changing weapon..." > could appear as the battle goes on, and the player > would not detect the lag, as it is masked by the > requires time to change the weapon, etc. That is a good idea, but the problem is, that when we have a big lag, the message will appear a bit after the user clicks the mouse button, and not at once. Greetings, Christian |
From: <je...@ya...> - 2002-08-25 17:36:45
|
Hello all, here I send some comments over the different topics. __________________________________________________________ __________________________________________________________ Graphics: As there is quite a lot of work to be done, I think it is a good idea to distribute the work according to an specific area. That means that somebody should work on the full screen illustrations, another one on the object images, another one or two on the terrain, etc. I would suggest that each of us states her/his preferences and competence. With a bit of luck we won´t overlap too much and all the areas will be covered :-). On first thought, these are the areas: - Still large images (illustrations). Loading screen, exit screen, portraits, etc. - Game interface - Logos, banners, buttons, etc for web purposes (not needed right now) - Terrain tiles (BIG WORK here) - Objects (in-game and inventory) - In-game characters (some animation here) My preferences are, well, all of them. I feel more or less confortable in any of the listed areas, although I really like illustration. Objects also are fine, or terrain, mmmm, not very restrictive, or? For this first assignments (potato, plants, salesman, etc), lets distribute them. To begin with, I send to you a tentative money bag and a potato. There is another point regarding graphics that I would like to talk about, and its the tiny size of the terrain cells. There are good reasons for it, sure, but I really think that we should look for increasing the size of them. That would allow for more detailed objects, characters and terrain. The current size implies that, either we create a huge number of tiles to create patterns larger than a cell, or we stick to heavy tiled look of the game. A mixed solution to avoid increasing the size of the cells, is to put background, fixed images and over them, put the cells, that would be usually include some transparency (or be completely tranparent!). I do not know if this is possible (Christian?). --- Design: --- For battles, I have thought over a possible non realtime solution, not either a turn based one. The idea is to make combat automatic. When attacking or being attacked, combat mode automatically switches on, and all involved characters engage into combat with the weapons they were wielding. This could be sophisticated with rough- scripted behaviour ala Baldurs Gate (equip best weapon, heal self when points under x%, etc), but the key point is that there is no need for player input during combat, apart from "Break from combat", or "Flee!", well, something like that. This idea could be improved with player input over the combat. Things that require 1-2 seconds, like changing the weapon, using an inventory item, etc, should be possible, even if there is a big lag since the player clicked. During that 1-2 seconds, a message like "Changing weapon..." could appear as the battle goes on, and the player would not detect the lag, as it is masked by the requires time to change the weapon, etc. Ok, this is a big mess, and nobody is understanding anything, so please, any question? About overall design: We should find out as soon as possible the type of RPG we want. That is, theme (fantasy, sci-fi, modern, cyberpunk), style (dark, humourous, ironic, parody), background (History, races, politics, economics) Do not be scared, this should be just guidelines, but the would help us defining a consistent world, and not end up with a mix-mix thing nobody cares about. I am currently working on some ideas, that will be posted as soon as they become more defined. ________________________________ ________________________________ That´s it. I also find good to create a board instead of a mailing list. Let's keep the list for news, announcements, and so, and discuss details over the different topics in the board. Cheers, Jesus. _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es |
From: Avel'ien K. <av...@ka...> - 2002-08-24 16:55:35
|
Hello all! I think that creating a forum is indeed a good idea, mainly for excellent thread and topic separation, offered by these tools. On the other hand - at least for me - mailing lists tend to get clogged and hard-to read, as messages from several topics put in a single folder, messed up. One might argue, that using a threaded mail reader should solve these problems and I would agree to such statement. Hovewer, I consider using theaded mail readers a kludge only, since these programs only hide the problem from the user, via additional features, that tend to change from one program to another. On the other hand, mailing lists are excellent in propagating of rare but important announcements, like bug reports or new version notifications.From this point of view, IMHO, the best solution would be setting up a forum for day-to-day, less important discussion while the list should be kept to spread important messages that everyone should be informed of. If setting up the board would pose any concerns of disk space, bandwidth or anything else of hardware/money type, I'll be more than happy to host it on my server .. for which such problems are rather nonexistant. Avel'ien Kadere, The one and only Admingryph, with VERBOSITY set to 'TOO MUCH'. |
From: Sean <pa...@fr...> - 2002-08-24 13:45:09
|
Hey all, I dunno how useful this would be, but I think we really need a forum for = this beta test, since there are a few of us, and email is slow and = annoying to coordinate it with, since it's rather slow to email many = people at once, since timezones differ, and not everyone will get it at = the same time, also, your email box starts to get clogged after a while = :P -Paradox |
From: <chr...@re...> - 2002-08-23 22:22:50
|
Hello again! Here are some other things that I think are good for cyanide: Some title image (big resolution) for the homepage and when connecting to the server. I have thought about a bit of ocean, teleporting portal, a wizard, hilly meadows, a village and some paths. And another task: Paths and rivers. They are very difficult with the current server design (cells), either they look angular or they need lots of images. Perhaps someone of you can build some images where it does not look angular. I chose that cell design to make it easy to build new rooms. When you only have one big terrain image file, it is very difficult to build a new room and impossible to make changes in that file. When there are cells, you can easily change the path of a river while the server is running and no-one has to download anything. See what you can do and thanks, Christian |
From: - 2002-08-23 15:06:51
|
On Fri, Aug 23, 2002 at 04:29:56PM +0200, Jesus Lopez wrote: > Hello all! > > Seems that we are already a few of us, so let´s > coordinate in some way. This is a good place to do it, > anyway. > > The first thing is to ask you how can I get the client > running. I could only download the source code, and > since I cannot compile it (by the moment)...Is there > any executable version in sourceforge? Sorry, I think I only said that in the betatesting information. http://secretstar.de/stuff/reality-python_1.1.0_dev.tar.gz is the current CVS-version including binaries and the basic image data. > Second, we should define the different > tasks/requirements (at least for the graphical part, > as far as I am concerned), that is, inventory, > interface, tiles, etc. Right, that's something I forgot. I would like to have some better user interface, with not so simple graphics. CU, Christian |
From: <chr...@re...> - 2002-08-23 14:48:08
|
Hello! As some people are on the mailing list, now, we can start some work. We are not only betatesters, but also graphicians, designer and programmers. Some betatesters are new, so I'll attach the betatesting information I sent to others, too. If you have any questions, ideas, suggestions or if I missed to explain something here, please do not hesitate to write to the list. First let us talk about beta-testing, next will be graphics, design, music and a bit about programming, perhaps. If you want to download the current version of the client and get some help installing it, you can find that in the betatesting information attached to this mail. BTW, I have uploaded a newer version of the client, there are some bugs fixed. --- Beta-Testing: --- I hope all the information is in the attached file. But let me speek a bit about reporting bugs: Please think about a good name of the bug and mail the bug report to this list with the subject: "BUG: bug name" In the body of the mail, please give a good description in which circumstances the bug appeared, if you think it is a server bug or a client bug and send all the information that was given to you by the client. And perhaps try to repeat the bug, if it is not repeatable, there are very little chances for the bug to be fixed. Some tips for getting more information from the client: Almost always, the stack trace and error report is bigger than the message window, so it will fade away before it can be read. If you start the client in a dos box (or xterm under linux), the errors will also be printed out there, so you can copy them from there. I think the dos box will be opened in any case. I have no windows at hand here, ATM, so please tell me if it does not work. But normally, the client should be running fullscreen, so that dos box (or "console") will not be visible. Press F2 for switching to windowed mode and the console will hopefully be visible. OK, I think that should be all. Next is --- Graphics: --- 3 to 4 graphicians are subscribed to the list, some of them already gave me some samples of their work and they were absolutely great. But all are waiting for jobs, so I will post some of my ideas here. Perhaps you should talk a bit about it and then arrange on who will do the work. At the moment, I'm working on the Potato Village. It is already playable, but some good graphics are missing. I'll explain a bit about it: The Potato Village is a room where you can buy land and potato seeds. You sow the potatoes, watch them grow and reproduce and their qualities being inherited and mutated. You throw the bad potato plants away, dig out the good potato plants and implant them near each other and wait to get super-plants. You can harvest the potatoes and sell them, buy new land and so on. OK, now I have thought about a registrar, where you can create a character, get your moneybag for trading (you can also exchange potatoes with other players) and perhaps buy a small hut. Then there is a salesman where you can buy potato seeds, land, sell potatoes and so on. Both of them need a nice house, a nice name and a nice image. Furhtermore, I have no good potato images, I use some plants with blue fruits... We would need images of potato plants in different states of growth. And surely also an image of a potato. Next, some character images would be good, then you could also change your appearance at the registrar. Damn, I have to implement that registrar as soon as possible... But the salesman is already there in the great hall and you can also already grow potatoes without buying land. They are only not protected from thiefs then. OK, needed images: moneybag potato plants (different growth states) potato salesman (with house) registrar (with house) perhaps fence Then some words about the images: All images in cyanide are 32x48 pixels, gif or png with transparency or alpha layers. Every object normally has two images: One if it is in the inventory (called the object image) and one if it is "in game" (called image). The perspective is isometric. The rooms are divided in cells. Perhaps you should look at http://secretstar.de/cyanide/imgs/cursors/cursor_1.gif http://secretstar.de/cyanide/imgs/cursors/cursor_10.gif http://secretstar.de/cyanide/imgs/ufo/terrain/forest_1.gif to get the idea. The first shows the right and left back walls of a cell, the second shows the two front walls of the cell and the third is the floor of a cell (it's the standard terrain image). The floor and the walls of an image should always be as in those images (concerning the pixel coordinates). Though the floor can be higher if we have a hill or a slope. If you have some problems with that exaplanation, please tell me. It is not quite easy to understand, especially without good images. Object images can be anywhere in the complete 32x48 area. I think there is nothing to be said about it. --- Design: --- Unfortunately, I have no real story at the moment. There is only the Potato Village and perhaps the Astral Chamber (IRC link). Fell free to post your ideas here. Please read about the potato village in the graphics section above. A very urgent problem is also battle. Many players need that to have fun in a RPG... ;-) But I fear that the server is too slow for real-time battle. What are the pros and cons for real-time battle and strategic round-based battle? What character attributes are needed for battle? There is much to talk about. --- Music: --- From the beginning of the game, I have thought about at least background music in the game. Adding support for other (one-time) sounds should also be not difficult, but my problem is always the creation of the sounds (same prob as with the graphics...). If someone has some good songs or can create them, I will add them to the game. It should also not be a problem to provide a player with some item that can be used as a jukebox, where he/she can select the background sound. --- Programming: --- It would be great if someone could help me a bit with the programming work. I try to explain the very basics of the structure of the server: The server is programmed in python, but I do not want to give an introduction for python here. If you do not know python, learn it, it's great fun ;-) The source is devided in two directories: the base directory and the objects directory. In the base directory are the startup files and the server core (managing IO, events, object database, ...). All the objects are in the object subdirectory, every object in its own file. They are all subclasses of the generic object (objects.generic.GenericObject). The base attributes are: id (object id as key in the object hash) name description image (image for the object "in game") obj_image (image for the object in the inventory) verbs (verbs, i.e. methods, that can be called from the client) The objects are stored pickeled (python module "pickle") in objects.dat. (This is not quite correct, the selector is also stored there.) Ok, so let's talk a bit about the server core: In all those modules (manager, selector, player_spawner...) there is one class defined and upon server startup, an instance is created with the same name as the module in the module's global namespace. So the manager instance is manager.manager and the selector instance is selector.selector. The manager manages the objects (it holds the object hash in manager.manager.objects) and their creation (manager.manager.create_object()). The selector managers IO and timeouts: selector.selector.reg_timeout(), selector.selector.listen() (listens on a file descriptor) and so on. The player_spawner handles the player login, listens for connections, looks for the character object and calls a function of that object handing over the socket. Perhaps I should also speak some words about the client interface: Every object has some callable verbs. A verb is callable by the client when it has the "caller" keyword argument. For example: def move(self, direction, caller = None): ... def destroy(self): ... move is callable by the client, because there is a caller keyword argument, destroy is not callable by the client, python would generate an exception because there is no keyword argument called "caller" That argument is assigned the player's character. In the move method, caller is None when it is called from any method inside the server, where there is no real caller. Then there is that base object attribute "verbs", those are the verbs that are callable by the client and are visible by the client (the attribute can change, for example a potato plant is not always harvestable). The structure is as follows: objects/terrainer.py, class ObjectImage: verbs = [('put in cell', 'c', 'destination cell'), ('put in cells multi', 'cc', 'first corner', 'second corner'), # this here is old transformer crap... ('put on transformer', 'o', 'transformer'), ('put on trans mult', 'oo', 'first corner', 'second corner'), ('put in cells mult old', 'oo', 'first corner', 'second corner') ] + objects.generic.GenericObject.verbs The list contains tuples, every tuple represents a verb. The first element of the tuple is the verb's name (the method's name is generated from this name by replacing special characters (like space) with an '_'. I know that this is a bad idea, perhaps it will change in future). The second is a string that contains the types of arguments. Every character is one argument. c means coordinate, o object, t short text, T long text. Then follow the descriptions of the arguments, they are shown in the verb window in the client. Here, the verbs of the generic object are appended, take and drop. Hmm, I could write 1000 more lines about all that, but time is short, as always. If you have any questions, feel free to ask, and perhaps take a look at the code. OK, that was it, I'm awaiting comments :-) Greetings, Christian |
From: <je...@ya...> - 2002-08-23 14:29:57
|
Hello all! Seems that we are already a few of us, so let´s coordinate in some way. This is a good place to do it, anyway. The first thing is to ask you how can I get the client running. I could only download the source code, and since I cannot compile it (by the moment)...Is there any executable version in sourceforge? Second, we should define the different tasks/requirements (at least for the graphical part, as far as I am concerned), that is, inventory, interface, tiles, etc. Cheers, Jesus _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es |
From: <chr...@re...> - 2002-08-13 12:35:17
|
Hello everyone! (actually you, because we are two in this list, ATM) Do you get the client to work? If not, please tell me your problems. If yes, do you get the usage, or do you think it's too complicated? What do you think of the server, the objects in the server and so on? Do you want an account? Thanks, Christian |