The Dink Network

I wish I could make a poll thing.

Should freescrolling be added? Yes? No? What's your opinion?

My vote is yes.

What's freescrolling merlin?

Wow, fastest responses ever! Freescrolling is where the game is not screen-by-screen. There are no sides.

yes

Ok, we've reached a stage where we're working out the graphics system for Windemere (the name for our new Dink engine). Now, we have a choice. Either we can stick with Dink's current scrolling system (isolated screens, Dink walks to the edge of each to move around the map) or a new system which I call freescrolling. Anyone who has played Diablo will be familiar with it: the environment scrolls around when the player moves. If you want us to, we'll implement it. We'll also implement what I like to call 'Classic mode', which is the current scrolling method that Dink uses. This will be available so as to allow backwards compatibility with current DMODs.

My vote is for optional freescrolling, with the ability to let DMODs decide whether they want to or not.

Yeah, optional free scrolling seems like the best bet, unless implementing free scrolling will cause Windemere to be delayed 7 years.

i vote yes

Yup. that'd kick-ass!

Yep, freescrolling sounds very nice as an option. But please make it screen-by-screen by default.

Definitely yes. Although I haven't looked at the source, it seems like this wouldn't be too hard to do from a programming standpoint. However, sometimes you just don't know until you try. :\

We'll have to make it off by default, because pre-Windemere DMODs won't be aware of it and so won't work with it turned on. Authors will be able to set the freescrolling mode in the editor.

I vote yes... And add something that can make various fields autoscroll, and others screen-by-screen. If you've played Zelda: A Link to the Past, you'll know what I mean.

Yeah, I agree with Redink. I'd like it in if it doesn't delay the release too much. But, I'm still wondering how you're going to make that compatible with existing move commands. How will coordinates relate to screens?

For example, say you have this on a screen :

move_stop(1, 6, 255, 1);

If you're working with freescrolling, x-coordinate 255 will no longer be the same, right? Unless of course you'll still be working with resetting coordinates whne Dink "enters" a new screen. But, if you're working with freescrolling, you'd need commands to scroll via scripting instead of always following around Dink. Else cutscenes will be impossible to do as many of them require Dink to be hidden.

My guess is move commands will have different syntax in free-scrolling D-Mods.

Hmmm, so you'll end up learning multiple commands for the same thing. Not very efficient :/

Well, at first it seems a cool thing, but ónly if old dmods will freescroll too.

Also, screenlocks should still be possible too.

If above can be done, I vote yes.

YES! It is what I hoped for all along I'm curious though, when will sprite scripts start to run? when Dink is in sight? Room scripts can be attached to sprites, Most vision uses can be done with sp_active within each sprite script.

Most vision uses can be done with sp_active within each sprite script.

And that sort of defeats the whole point of visions, the ability to have numerous sprites active (or inactive) simply and easily, regardless of what script they use. It would be a PITA to have to, say, create a new monster script just to make it not show up sometimes when Dink goes to a current screen to emulate visions.

won't maps still be divided up into quadrants, screens, whatever anyway? The way I've seen freescroller work is that you preload the surrounding adjacent screens, around the one the avatar is currently in.

One problem, though, just look at the following "image":

OO
I O

Eacht character is what previously was a screen.
O = outdoor; I = indoor.

You'll have to fix that the indoor screen doesn't get displayed when Dink, or whoever, walks from the lower right screen to the upper left.

Sorry I couldn't explain it more clearly.

It would be more like this:

(O = outdoor, I = indoor, X = empty screen)

(area 1)

O O
X O

(area 2)

X X
I X

I think Desplesda described it to me like this, anyway. Basically, the different free-scrolling areas would be in completely different 'areas' of the map, so that you'd select 'area 1' to edit area 1, and 'area 2' to edit area 2, instead of viewing all of the map screens at once like in WinDinkedit. It would almost be like multiple map files, but not really.

But... this would be a pain for lots of indoor screens, because you'd have to have a new 'area' for each. You guys should have the 'area' or similar abstract allow you to specify free-scrolling or screen-based. This would allow easy importation of earlier D-Mods, where each would just be a 32x24 screen-based area.

I don't know... couldn't we just do freescrolling within the individual cells? That way we'd have a lot more map. Each cell could have its own defined boundries at which the map stops scrolling. Of course, that might be kind of complicated, as it would require a new editor.

But in your suggestion... how would the empty screen be displayed? Are you seeing a black field in the corner of your screen?

A scrollblock would be nice, yeah, so it won't scroll in the black when you're at the edge of the map or an isolated area.

Right, here are the answers to all of your questions.

Please note that this is all ideas and subject to change, but this is about as polished as we have at the moment.

DMODs that are made before Windemere is released will run in 'classic mode', where freescrolling is turned off and it's essentially vanilla dink, but more uber.

DMODs that are made for Windemere can run in what might be called 'uber mode' or something (hell, I dunno). While current Dink maps are made by editing a huge 32 by 24 cluster of screens, the Windemere editor will use a very different approach.

Each map is divided into 'segments', which are equivalent to screens. Each segment is 'tied' to up to 8 other segments (north, south, east, west, ne, se, sw, nw). This means that there won't ever be any problem with accidentally being able to walk into an adjoining segment (ie walking straight from a desert into an ice segment) because if the two segments aren't linked, then you can't walk between them.

A new area is created by telling the editor "Ok, make me a new isolated segment". You then add whatever you want to that segment (sprites, land, tiles, etc) and create a 'cluster' (read: area) by creating more segments and linking them together. Think of clusters as islands of screens, floating in a big huge void and completely isolated from each other. So, for instance, you'd make a cluster and call it "Dink's home". You'd make it x segments big, and pretty it all up. Then, in other cluster, you'd make a door, and set its touch() to 'move dink to this segment', just like we do now.

Any comments, questions?

eh??

>^~~^<

Right.

Much big bunch of screens in cluster. Cluster big. Much big. Cluster make area. Building is cluster. Outside is cluster. Cluster no touch other cluster. Map maker say to editor, 'you make new cluster. You call it "Dink's House".'
Editor say, 'ok'.

Dink go from cluster to cluster through warps like doors. Savvy?

Haha.

Of course, that might be kind of complicated, as it would require a new editor.

Either way we do it is going to require a new editor.

i see. i understand. i am excited.

And what if you want segments and all that jazz, not no free-scrolling?

If you want vanilla dink, no free scrolling. The map format neither supports it nor has the capability to support it. And if it were supported, it wouldn't make sense to support an old version.

What is this vanilla Dink of which you speak?

Sucky dink.

We'd have to make a new editor anyway. 768 segments just isn't enough; our new editor will be able to handle an unlimited amount of segments.

<whispers>really?</whispers>

Has anyone seen RPG Maker 2000 or 2003? The map system in that game editor is quite excellent (when it comes to defining maps) It's a freescrolling game, and it has separate maps, of which you can link to using warp commands or a touch-like system.

If you want vanilla dink, no free scrolling. The map format neither supports it nor has the capability to support it. And if it were supported, it wouldn't make sense to support an old version.

I don't want vanilla dink, nor vanilla coke. I want one of the following:

1) The ability to use the new editor with segments, and still have a non-freescrolling game. Free scrolling should *not* be forced upon an author as a requirement just to take advantage of new features. New, dramatic features should be optional, even if I'm starting a new D-Mod.

2) The ability to peg certain segments as free-scrolling, and other segments as non-free scrolling. This would be the best-of-all-worlds option, really, and could be quite useful. In the countryside, the game could have free scrolling, but in dungeons it could have non-free scrolling for whatever reason.

Also a suggestion:

Segments should not be viewable on the same screen. They should act more like tabs or layers, so you click on a tab that says 'Countryside', and it shows the countryside segment.

That makes a lot of sense. Besides, the only way to make a map in the new engine will be with segments, freescrolling or no. And we'll take the tabbed segments view into consideration, thanks

I don't think 768 screens is not enough.
Just look what a huge world (and more than one) SimonK creates without even using all the map space!
And there are a lot of DMods that just waste the map (yes, I admit the sin too...).
I understand you could make a DMod that requires more space - and use it wizely, but as yet it is a DMod we have to wait for. The only one with a really huge map is LOT, a great DMod, but with all the empty (or almost empty) screens it might be one map instead of two, right?
I don't say more space won't be good, but I don't think 768 screens is not enough to make a good DMod.

Actually, we're craving for more map screens for LT! There just isn't enough space left for dungeons! Well, interesting dungeons that is.

I could do with a 1000, but with a new engine, why make a limit?

Er, I said that the engine would be capable of handling an unlimited number of segments. That means, y'know, no limit?

Heh, kind of like the global variable limit - none.

You all know if you want a request you can submit a feature request to the request tracker?

Well yeah, but we can *discuss* feature requests here

At some point in the process, it becomes an entirely new game. I don't see that as all bad. Some might.

Multi-player anyone?

No comment

Looks at his tiny little phone line.
*laughs*

Of couse it would have a built-in lag detector that'd cut you off if you have dial-up.