ID:136174
Apr 17 2003, 6:12 pm
|
|
Two things that I would like to see implemented in the near future: (The first one is a must.)
Any comments are welcome. -Nova | |
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:
I definately would love to see this. I've been working on trying to do it, but I've had no luck. ~>Volte | |
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. | |
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. =) | |
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.
| |
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. =\
| |
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. =) | |
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?"
| |
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.
| |
Acronyms are words. Hence "nym". =)
The game names are just that, names. You won't find proper nouns in many dictionaries. | |
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.
| |
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. ;-)
| |
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 | |
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/ | |
Theodis wrote:
digitalmouse wrote: cool! will try it out right away! thanks! | |
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. | |
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.
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) =)