ID:136174
 
Two things that I would like to see implemented in the near future: (The first one is a must.)

  • Text mode maps must be aligned center, with Terminal as a font.
  • Maps, perhaps an option to have the map loop? ex: When you approach the southern edge, instead of seeing black, you see the northern edge of the map. (It loops.) This could cause some conflicts with code... but it shouldn't be too big of a problem...


Any comments are welcome.
-Nova
Nova2000 wrote:
Text mode maps must be aligned center, with Terminal as a font.

I would hope that this is already in the top-secret pre-alpha build of BYOND 4.0, and it has already been requested. =) But yes, it is a simple fix which needs to be implemented.

Maps, perhaps an option to have the map loop? ex: When you approach the southern edge, instead of seeing black, you see the northern edge of the map. (It loops.) This could cause some conflicts with code... but it shouldn't be too big of a problem...

Interesting idea. I can't see it being implemented any time soon, though. I imagine you could fake this by not letting the player within sight of the black of the edge of the map (if they try, they loop), and using some turf images or dummy objects to make the map seem to loop. This could be problematic when you try to interact with an atom over the dividing line between map loops, though.

Might make good fodder for a BYONDscape library! (I most definitely don't volunteer; sounds like a nightmare job, heh) =)
In response to Crispy
Interesting idea. I can't see it being implemented any time soon, though. I imagine you could fake this by not letting the player within sight of the black of the edge of the map (if they try, they loop), and using some turf images or dummy objects to make the map seem to loop. This could be problematic when you try to interact with an atom over the dividing line between map loops, though.




I think Lexy's little side scroller had this and didn't have any problems with the other atoms, though I'm not quite sure how she did it.
Nova2000 wrote:
  • Maps, perhaps an option to have the map loop? ex: When you approach the southern edge, instead of seeing black, you see the northern edge of the map. (It loops.) This could cause some conflicts with code... but it shouldn't be too big of a problem...



I definately would love to see this. I've been working on trying to do it, but I've had no luck.

~>Volte
In response to Crispy
Making a looping map would be simple:

1. First, a custom map is made, with a buffer of 10 tiles (max value for world.view).
2. All atom/movables have a "var/atom/movable/loopobject" variable. This will create a new object of the same type. Objects created will have their ref variable (below) set to src, and their loopobject var will be null.
4. As atom/movables move around, it will check to see if they are within 21 tiles of the map boundry. At 1-10, it will loop you to the other side of the map. At 11-21, it will move your loopobject to the appropriate position.
5. All atom/movables have a "var/atom/movable/ref" variable. All verbs/procs called on src are immediately passed to ref, unless if it is null / src.

Yes, I know there is no 3. I had the mafia remove him. He was starting to talk.
In response to Garthor
What about the map corners :)?

This is a bit harder than you make it sound.
In response to Garthor
But in EVERY atom/movable proc (you'd have to override built-in ones too), you'd have to have a line like:

<code>if (ref) return ref:procname(arg1,arg1,etc)</code>

(You'd have to use the colon there unless it was really an atom/movable proc as opposed to a mob proc or obj proc or whatever, because ref isn't neccessarily the same type as src.)

And what about vars? Huh? Huh? =P

You'd have to make procs to access and change all atom/movable vars, and use them all over the place. You'd also have to pass in the var names as strings (so they can be accessed with vars[]), which would eliminate the compiler's ability to check that you hadn't misspelt var names.

Not to mention synchronizing icons, icon states, directions, overlays, images, areas, and turfs.

'Tis a bigger job than you seem to think, Garthor. =)
In response to Crispy
It really depends on how well you design your world. You could get away with only overriding the verbs instead of procs. All direct calls to built-in procs (like step()) should be handled by another proc (Take_Step()) so that it can be passed on to the correct mob, and the change are applied to the dummy as well. It would just require you not to slip up and use the direct proc instead of a proc that handles all the changes for you.
In response to Garthor
You'd need to design your entire game around the concept. If you've already started programming, a lot of annoying "translation" work would need to be done so it uses those procs. It's doable, but I wouldn't call it easy. It's certainly very, very inelegant. =\
In response to Crispy
Elegancy is over-rated Mr.Crispy.
In response to Jotdaniel
Really? Have you read the source code to Scream of the Stickster (from BYONDscape)? =P

If not, I'll post a brief snippet here to demonstrate.

var{list{L;P=V;G}turf{o/U;w/w}obj{o;l/l}mob{p/M;s/ S}A;B;C;s=41;p;v}world{O(){A=w(9);L=A:k;N=L[1];v=L[2];hub=L[ 7];Y(50)S()}

And that's only defining global vars and world info. There's a single line, nearly 4000 characters long, which is all like that.

Admittedly this is taking things to extremes, but that doesn't make my point any less valid. =)
In response to Crispy
I have that source, yes. But I would like to apologize, elegancy isnt a word, it was 4 am when I wrote that. I realized it after I went to bed. It came to me like "damn, did I really write elegancy on there?"
In response to Jotdaniel
If you're gonna be picky over which words are real, BYOND (strictly speaking) isn't a word (I know it's an acronym), and most of the game names aren't in the english dictionary.
In response to Hazman
Acronyms are words. Hence "nym". =)

The game names are just that, names. You won't find proper nouns in many dictionaries.
In response to Crispy
I would *love* to see basic joystick support! If that made it into BYOND, I would personally travel to Dantom's house(s), grovel at their feet, and give them money.
In response to digitalmouse
Problem is, they'd need to implement DirectX for that, which would kill platform independency. Unless they could find some sort of non-restrictive game library that allowed them a hardware abstraction layer, was free, and didn't require them to follow some asinine set of rules like the GPL. And if they could, I'd thank them to send it my way, too. ;-)
In response to digitalmouse
digitalmouse wrote:
I would *love* to see basic joystick support! If that made it into BYOND, I would personally travel to Dantom's house(s), grovel at their feet, and give them money.

Would this work :)?

http://hp.vector.co.jp/authors/VA016823/joytokey/ english.html
In response to Spuzzum
Spuzzum wrote:
Unless they could find some sort of non-restrictive game library that allowed them a hardware abstraction layer, was free, and didn't require them to follow some asinine set of rules like the GPL. And if they could, I'd thank them to send it my way, too. ;-)

http://www.libsdl.org/
In response to Theodis
Theodis wrote:
digitalmouse wrote:
I would *love* to see basic joystick support! If that made it into BYOND, I would personally travel to Dantom's house(s), grovel at their feet, and give them money.

Would this work :)?

http://hp.vector.co.jp/authors/VA016823/joytokey/ english.html


cool! will try it out right away! thanks!
In response to Spuzzum
Spuzzum wrote:
Problem is, they'd need to implement DirectX for that, which would kill platform independency.

We never needed directx for joysticks before, why would we need it now? just a simple dll that talks to the joystick port is all that is most likely needed. something that can be dropped in (just noticed Air Map's post on that).

And this would only affect Windows users anyway, until GUI support comes to Mac and *nix platforms.
Page: 1 2