AHH.. oh well, it was late.

Okay, I want to explain about the icon thing.

image files are stored in bytes, number values between 0 and 255, giving an integer range of 256. these are further coded into hexadecimal, 0-9, A-F with two digit numbers, 0 being 0 and F being 15, then the two symbols are multiplied together, so if the value is 255, it will become (15*15), or FF
that is a not-quite true, but simple explanation of how information is stored on windows. All files share this format.

now, image files with 256 colors have 256 values, of three or four bytes tacked together.

these bytes are combined in a way that they make like one of 4 billion some odd numbers.
these four numbers are: alpha, red, green, and blue...

the format for all you coders is:
int color = alpha<<24 | red << 16 | green << 8 | blue

note: in some image files it only uses three bytes, red, green, and blue: I'll continue with this kind.

256 color pngs use this format:

FF FF FF this is one occurrence of a color value, there are 256 of these in the header of the file.

now comes the fun part, making the image, let's say it's a 3x3 image using 2 colors, this is the file:

FF FF FF 6C 6C 6C 00 01 00 01 00 01 00 01 00

This is the image header:
FF FF FF 6C 6C 6C this makes two colors, one white, one gray.

this is the image:
00 01 00
01 00 01
00 01 00

I broke it up so that it is easier to see. in actuality, the image looks a bit like this:
<font color = #FFFFFF>.</font><font color = #6C6C6C>.</font><font color = #FFFFFF>.</font>
<font color = #6C6C6C>.</font><font color = #FFFFFF>.</font><font color = #6C6C6C>.</font>
<font color = #FFFFFF>.</font><font color = #6C6C6C>.</font><font color = #FFFFFF>.</font>

now, when you make it a 24-bit image, which is what you are suggesting, it becomes infinitely more complex...

this is what the same image looks like:
FF FF FF FF FF 6C 6C 6C FF FF FF FF
FF 6C 6C 6C FF FF FF FF FF 6C 6C 6C
FF FF FF FF FF 6C 6C 6C FF FF FF FF

no header this time, just right into the image. that's it, you have successfully tripled the time it takes to create the same image, of course you can use more colors... but I see this as less effective...

The .dmi file format is different, because it supports states, directions, and animations, but I know one thing for certain, if you have a file of one-image icons, and you add a 4 directional animation, the file jumps in size, because I THINK the file acts as though all the icons are four directional... even if they aren't...

A lot of this has been simplified to show example, and some of it (the .dmi stuff) is guesswork, but I think most of this is basically true.

I jsut think it is not wise to make BYOND 24-bit, most games, believe it or not, are done in 256 colors. with the right mix of colors they can look just as good.

Iqloo wrote:

1)The ability to go isometric

I'm skeptical about this one. I, like many other people, am making isometric games, but if BYOND implemented a hard-coded system for isometric worlds, it would defeat a whole lot of the thrill in the effort.

[edit] One of the advantages of isometric is the fact that it acts as a simulation of 3D, allowing terrain to have elevation. When it all boils down to it, it would be just as hard to implement altitude in a hard-coded system (i.e. integrated into BYOND) as it would be to implement it in a soft-coded system (i.e. made in DM code).

2)A easier to understand bluebook/F1

The Blue Book is the easiest-to-understand computer-related book I've ever read. And I mean that.

As for F1, that's just a reference; reading a reference doesn't teach you how to use BYOND.

If you have anything that needs to be clarified, just make a topic about it in Newbie Central and we can clear it up in different words.

3)Some way to make games that have missile in them not lag like a white man on king richard's sterio sytem* after a few goes.

What does the asterisk point to? =P

4)The ability to customize the window that your game is in(Verb bars, chat screen)

This is supposedly coming in version 4.0.

5)Higher color count minimum. (just think, when you can store all of the graphics your game needs in one .dmi! makes me get tingles all over just thinking about it)

While true-colour DMIs would be nice to have -- despite massively-greater file transfer loads -- your statement in the parentheses is a very bad thing to try. It is very poor programming style to use the same icon for everything. That's like only using the base /obj type and then editing its variables and adding procs and verbs for every single object you could use in the game.

6)When you get a page the entire window flashes, not just the Pager tab (sorta like MSN Messanger or AIM)

The pager is being separated out of Dream Seeker, and supposedly sports this feature.

7)A few GREAT Games that will sorta set the standards of other games, so we dont have as many "Tossed together" just for the heck of having a game games.

The real problem with this is the investment of time and resources. Coordinating a large group of developers is extremely hard if you don't have verbal communication with the people you're working with, and working with a small group of developers takes too long.

It's a lose-lose situation. Insofar as I can tell, the current freelance scheme that BYOND has going has worked well so far -- look at the gems like Lode Wars or Incursion.

Looking at it this way might help, too: making a few great games won't change the simple "RPG"s that less skilled developers are making.

8)When you delete a Area, Turf, ect from your .dm it auto deletes itself from the .dmp

The problem there is... if I replace a type named /turf/dirt with a new type named /turf/soil, how would Dream Maker know that I want to replace /turf/dirt with /turf/soil and don't want to delete /turf/dirt altogether from the map?

It's a good idea, but I can't think of a way it would work.

So what your saying is "not every game uses icons, so why include them at all". Or not every game uses locate(), so dont include it? Just remember, anything that comes in(like the locate() proc) will run a lot faster the an a user made one. Text on screen could be done a lot better if it was a built in proc, rather than a User made. Also, the map maker could allow you to put text on it much like art does, so you can label things simply.

I wouldn't like to see a built-in isometric mode in BYOND, then all the games would use that and look the same still. Though they'd look a bit nicer, it wouldn't add much variety. However, I'd like to see improvements that would help make your own isometric system in BYOND.

This could help with isometric games, and it would help with other games as well; I'd still like to see them add pixel offsets for a player's view.

Yeah, those are a definite must for everything ranging from space games to pixel-based RPGs (imagine if it could better animate scrolling between two adjacent maps! *drool*). My earlier suggestion about animate_offsets would really help isometric views too. =)

Note that if you happen to move very slowly in a game, setting client.pixel_step_size to a tiny number like 2 can look pretty good.

If you break it down isometric is a biased result of math and computer knowledge. If you can find a simple demo on mathematics (which just happens to be my worst subject) you should be able to get to the OFD level. Although an isometric feature like that would be nice, there are still faults about this.
It would take away the effort of creating such a system, the only effort would simply come from the users customization ideas. Also, the blue book is very self-explanatory. Take time to read the code snippets in detail and also look at the denotes at the bottom of the page.
The f1 help command is simply for reference on a certain topic. ie: path operators.
A few great games, this is hard to come by lately, and as to seeing that there really is no solution from keeping the "un-great" games from entering the hub, this is a problem that sadly will stay. Although there were a few good points that I would have to agree with on you.
Overall I'm just awaiting the arival of BYOND version 4.0 (335?). I'm not expecting much yet I'm not doubting it.

-IW

What I'm saying is that BYOND already handles these easily, and it may be a thing for the future, but I see no reason for dantom to program in the glitz before they get the basic systems of BYOND working better. I think more client-side type of a system would work better than what we currently have.

Also, I would like to see it so that maps are an array, as they currently are, but they are interpreted by each individual user, making images appear on the screen player-by-player. Here's how my diagram works: (I've done this in java before, it's not that hard...)

(SERVER)

the server stores all the combined locations, and object inferences on it's machine. All actions are updated to here.

(CLIENT)

for every user that logs in, a client child window is created. The client systems basically do all the excess calculations, etc., and then send the result of all the users' actions to the server.

so here is how it works:

The user presses the right button. This means he wants to move east. The calculation is called, and due to the most-recently updated map, the client figures out if there is a dense object there. The Client then moves the user, and sends the result to the server.

The server has recieved the message that the user has moved, and then updates it's map accordingly. The server determines who saw this move, and then sends the updated map to all users in sight of this.


That's pretty simple, basically the server's only purpose is to create and manage the client windows. The clients actually do all of the acting, but cannot act on their own, they require the server to do much of anything...

It may, or may not be a bad idea, but this is how I see it as working.

It may, or may not be a bad idea, but this is how I see it as working.

Well this would pretty much be peer-peer networking only with a middleman involved. Which leads to two big problems security and the game will run at the rate of the slowest computer/connection.

Since calculations are handled client side the players could easily cheat with memory resident programs to send the server false information. If you have the server verify the information then you might as well just handle the calculations on the server. The only type of thing that should happin client side are special effects which are mostly icon stuff like color swaping, rotation, ect. The player could "cheat" by having them do something different but it wouldn't effect the game much except for thier personal display.

The second problem comes from the fact that you need to keep everyone synced up or else everyone will have their own different map. So every computer has to wait for the slowest computer to catch up or the other machines will get ahead of themselves. Which means if anyone joins with a 14.4k modem the game drops to a crawl for everyone not to mention you also have to send the state of the world when someone joins.

You also start running into major issues with this type of stuff when you try to get more than 8 or so players(even on a lan) so I don't think this would be the best way to handle things :P.

Crispy wrote:

who really cares about the version number anyway? =)

That exactly the attitude that got us into that whole Y2K situation... There will be chaos in the streets if BYOND v4.0 doesn't use an integer version value! CHAOS OF BIBLICAL PROPORTIONS!