The sign of a true released product -- a player bug report!
Not really a bug though -- a misunderstanding about how the + piece works. Apparently it's not clear that the snot will always flow straight through the piece, and that the point of it is that you can use both directions.
So we'll get that added to the instructions.
ID:194485
 Jan 27 2001, 8:20 pm
|
|
On 1/28/01 11:02 am Zilal wrote:
On 1/27/01 11:20 pm Deadron wrote: Email, which totally surprised me, cause my email address is way at the bottom of the web page in tiny little type. | |
On 1/27/01 11:20 pm Deadron wrote:
The sign of a true released product -- a player bug report! Hey, glad to help out. Nothing makes me happier than a fun game that works right. I was checking out your game (and a few others as well) to get a feel for what BYOND can do. Mr. Sanity | |
On 1/28/01 10:13 pm Mr. Sanity wrote:
I was checking out your game (and a few others as well) to get a feel for what BYOND can do. An interesting question...because BYOND can do an amazing variety of games, but people often stumble on a couple of factors... With this system you can create server-based persistent worlds, you can create standalone games to run on a person's local system, you can create web-based games, and you can use the integrated browser to provide rich information interfaces along with the graphical game content. Even better, you can create a single game that uses all of these. In fact, DragonSnot is an example of such a game. The clincher is that BYOND provides a tile-based graphic system using 32x32 icons. It's quite flexible within that constraint, supporting icon states, overlays and underlays, transparency, and object layers. But when people envision the game they want to create, they usually see a free-form graphic model where things can be an arbitrary size and move around in an unrestricted fashion. So to my mind that's the big question...if you want to create a game that can work within the BYOND graphic model, then you can do a pretty amazing job with this system. | |
Yep, BYOND seems to have quite a lot of flexibility under the hood, with its main limitation being the tile-based engine. BUT compared to most of the RPG-type tools out there, BYOND looks to be the most effective and most complete.
Being a skilled OO programmer, BYOND's language strikes me as being very interesting and useful. I'm trying to get used to some of the conventions of the language that are un (or under) documented, but mostly I'm having fun with the system. Once I get more familiar with BYOND, I'll probably be asking around for answers to the questions I haven't answered for myself. [edit] Oh, one question does immediately spring to mind: I know that individual tiles are limited to 8 bit color. BUT, it is not specifically stated if the entire screen needs to share the same 8 bit palette or not. It also doesn't state weather or not overlays/underlays need to share the same 8 bit palette as the tile they ahre space with. What's the lowdown? Is it 8 bits screenwide? Or 16/24 overall, with the 8 bit limitation simply being for individual tiles? Mr. Sanity | |
On 1/29/01 9:35 am Mr. Sanity wrote:
Being a skilled OO programmer, BYOND's language strikes me as being very interesting and useful. I'm trying to get used to some of the conventions of the language that are un (or under) documented, but mostly I'm having fun with the system. Very interesting...you are starting in exactly the same place I did. My personal feeling about the language, having used C++, Objective-C and Java previously, is that it's just right for this problem space. In particular, it avoids all the nastiness I found in other languages, so there is no extensive operator overloading, no multiple inheritence, no need for templates or 'friend' classes or any of the other things that take months to learn and unduly complicate implementations. What is does provide is simple power. For example, as you've probably noticed, you can add or override functionality for any class, whether built in or not. Dynamic binding is used and objects are true introspective objects, so lists can be heterogeneous and object types do not need to be known at compile-time. The challenges I found in my first days with the language had to do with declaring variables. There is some subtlety there, and I kept accidentally creating variables in the global namespace instead of in the scope of the object. For example (not realistic code!): obj/door proc Open() /var/already_open = OpenCheck() In this case, the already_open variable is actually in the global namespace, because the declaration starts with a '/' in the path. This means the variable declaration is using an "absolute path", and / is the global namespace. The correct way is: obj/door proc Open() var/already_open = OpenCheck() Now there is no '/' at the beginning of the declaration, so the variable is created on a relative path, which means it belongs to the current object. Thankfully, once you get this convention down, you don't need to spend time thinking about variable declarations as paths. One feature that many RPG code bases use which BYOND does not currently support is loadable code modules. So you can't add a new mob to a running game on the fly by dropping the object code for the mob into a directory. There are some workaround approaches, though. Oh, one question does immediately spring to mind: I know that individual tiles are limited to 8 bit color. BUT, it is not specifically stated if the entire screen needs to share the same 8 bit palette or not. Nope. The palette is per-icon file. An individual icon file can have any number of icon states and animations, and all of those share one palette. It also doesn't state weather or not overlays/underlays need to share the same 8 bit palette as the tile they ahre space with. What's the lowdown? They do not need to use the same palette. If the overlay is stored in the same icon file as the tile, then they will use the same palette. But if the overlay is in another icon file, they don't need to. (Hmm, Tom this might be good stuff to add to the icon tutorial...) Anyway, good luck Mr. Sanity. I hope you'll find the system to your liking and the community will be happy to help when the inevitable questions pop up. | |
On 1/29/01 9:35 am Mr. Sanity wrote:
Being a skilled OO programmer, BYOND's language strikes me as being very interesting and useful. I'm trying to get used to some of the conventions of the language that are un (or under) documented... Do post about what you find to be under-documented! I dunno about Tom and Dan, but I'm always eager to hear what newcomers to my creations are stickng on. And a more complete reference would benefit everyone. Mrs. Insanity | |
On 1/29/01 11:56 am Zilal wrote:
On 1/29/01 9:35 am Mr. Sanity wrote: Also, while all the information should be available somewhere between the F1 help in DreamMaker, the online guide and reference and the tutorials, there is the definitive documentation for the entire language, available in the printed book: Designer's Guide to World's BYOND | |
Thanks for the info, and I'm aware of the book, and planning on getting a copy in the very near future. :)
Oh, one more palette-related question: if I import a whole .bmp image, does the image get broken up and THEN palette reduction applied, or does palette reduction get applied and THEN it is broken up? [edit] Or, is palette reduction even done? (Programming is easy... Content planning and management are the hard parts. hehehe) | |
On 1/30/01 10:38 am Mr. Sanity wrote:
Oh, one more palette-related question: if I import a whole .bmp image, does the image get broken up and THEN palette reduction applied, or does palette reduction get applied and THEN it is broken up? I can't say definitively -- hopefully Tom will answer... My guess would be that any palette operations occur before it is broken up, and if you want different behavior you would need to take the more manual approach of breaking it up yourself. | |
On 1/30/01 10:38 am Mr. Sanity wrote:
Oh, one more palette-related question: if I import a whole .bmp image, does the image get broken up and THEN palette reduction applied, or does palette reduction get applied and THEN it is broken up? Palette reduction is applied on the entire image, before it is tiled. In this way the entire image shares a single palette (just as it would for a standard icon with multiple icon-states). I'm pretty pleased with the reduction algorithm; I did tests on a number of hi-color jpegs and they turned out quite nicely. Eventually we can do away with the need for reduction altogether, but right now it is necesary due to the specifics of the internal DMI format (which uses some old-school 8-bit compression). Sorry for the shoddy documentation on all of this. As far as I know, this is only mentioned in the release notes somewhere. At some point one of us (or one of you :) should go through those notes and write up a DM feature update. | |
Sorry for the shoddy documentation on all of this. As far as I know, this is only mentioned in the release notes somewhere. At some point one of us (or one of you :) should go through those notes and write up a DM feature update. I volunteered a ways back to sift through the old forums and provide the converted 1.0 -> 2.0 code for any little problems to compile a big directory. But I never got the tarball from you. Can I have it (assuming you still have it... =P)? (Speaking of which, where's my user-based InfoCentre? You'd better spell it the Canadian way, too! =) | |
On 1/30/01 4:28 pm Tom H. wrote:
Palette reduction is applied on the entire image, before it is tiled. In this way the entire image shares a single palette (just as it would for a standard icon with multiple icon-states). I'm pretty pleased with the reduction algorithm; I did tests on a number of hi-color jpegs and they turned out quite nicely. Eventually we can do away with the need for reduction altogether, but right now it is necesary due to the specifics of the internal DMI format (which uses some old-school 8-bit compression). Thanks for the information. It's good to know this though. Now I can be confident that if I render out a scene to be used as a location, I don't have to worry about strange color mismatches at the tile seams. :) As for "shoddy documentation," I can understand the predicament. When you have a continual work in progress, it can be realy hard to keep the documentation in close synch with the program's true functionality. I'm sure that it will come along once the development cycle has cooled down. Oh, and speaking of documentation, how up-to-date is the printed book? Mr. Sanity | |
On 1/31/01 10:22 am Mr. Sanity wrote:
Oh, and speaking of documentation, how up-to-date is the printed book? A few features have been added since its release (such as object layers to control order of drawing) but overall the book is very up to date. It would be quite helpful, though, to maintain some kind of readme on the site that lists any features added after the book came out. Maybe that can be added to the FAQ, which I haven't gotten to dealing with yet... | |
Oooh... how did you get the report?
Z