Recondite Twenty-Eight: The Sixth Day

Recondite was an article that I used to write on The Dink Network to capture whatever random thoughts I had at the time. If my thoughts were butterflies, Recondite was an old man with a net and a penchant for entomological taxidermy. It eventually evolved into a pseudo-blog / status update for many things about The Dink Network that simply didn't fit into a forum message or a stand-alone news post.

It has been just over Ten Years since Recondite Twenty-Seven, and I can't quite comprehend that. Ten Years is a Long Time. That's twice as long as Bill Szczytko spent working on Quest for Dorinthia v2.5!

So read on, fellow Dinkers, and see what this edition entails.

Six Days Straight

Today is the sixth consecutive day that news has been posted on The Dink Network. This has not happened since... September 1998. I had updated redink1's Smallnet for 8 days in a row back then.

The Web

I am thrilled that Dink Smallwood HD and FreeDink are running successfully within web browsers. Not only does this lower the barrier of entry (you can start playing a D-Mod in two clicks), but I'm hopeful that this also means that Dink and D-Mods can be playable years from now.

Browser-based javascript/wasm games will almost assuredly continue to work for many many years, while I'm honestly not sure what operating system my computer or my phone will use five years from now. The Web handily won the platform wars, and now Dink is part of that.

From my view, the Web also trumps the gaming-specific platforms that some members of our community has been wishing Dink would be on (such as Steam or GOG). Now, playing Dink is a click away, and we just need to make it discoverable for those who might be interested.

Community D-Mod Jam

Sometime later this year, I am hoping to arrange a ludum-dare-ish game jam for a community D-Mod. The goal would be to schedule a 48 hour window to work on a D-Mod... but what if we all worked on the same D-Mod at the same time, and at the end we have a single D-Mod that everyone can play? We could coordinate through discord and twitch, and maybe use something like github to share the map and source code files.

Someone with no programming experience could suggest a joke in a discord chat room that we could include, players could beta test the in-work D-Mod on the fly in their browsers, three map designer could add decoration to map screens, and a programmer could add something crazy like a chess mini game.

This isn't exactly trivial. We'd need to come up with a few rules (for example, PG-13, no custom graphics, no custom hard.dat customizations, resolve how to handle conflicts, etc).

And, more importantly, we don't really have the right map editor to support something like this right now. Creating/merging script files is pretty easy with things like github, but I'm not sure how we'd merge changes to a map file. It'd be nice if we had a cross-platform solution, and it wasn't just a modified version of Windinkedit.

The D-Mod Improvement Project

Starting with Dink Smallwood v1.08, we've had various compatibility issues between the Dink engine and D-Mods. v1.08 added quite a lot of new features (yay), and unfortunately some of these features broke existing functionality (boo). FreeDink fixed quite a few things, and even supported a v1.07 compatibility mode. And Dink Smallwood HD has started fixing issues as well (after initially breaking a fair bit).

But, nobody has really played through most D-Mods most platforms to ensure that everything works as expected. I think this limits the appeal of playing D-Mods in general; do you use FreeDink? DinkHD? If you get stuck in a way that is simply not possible to get around, you probably don't want to play more D-Mods.
So, the idea of this hypothetical 'D-Mod Improvement Project' would be to select a well regarded D-Mod (like Lyna's Story or Malachi the Jerk), and encourage everyone in the community to play it and ensure that it works on as many platforms as possible.

If anyone reports any issues, community members (or, the original author, if they are still around) would make fixes to whatever would need to be fixed, whether that was Dink Smallwood HD, FreeDink, or the D-Mod itself. The goal would be to make the D-Mod work as it was intended (fixing gameplay dead-ends, crashes, hardness errors, and maybe even spelling and depth dot errors). We wouldn't be adding brand-new graphics, fixing plot holes, or making them 'better' (like Ted Shutes had done for a few D-Mods). We'd just be making it possible to complete them.

Then, when we finished one D-Mod, we'd move onto the next. And, in 40 years, we'd finally fix Goblin Castle.

The Future

I joined this community back in June of 1998, and I've been hearing that 'Dink Smallwood is dying' since around August 1998.

I'm not sure if either of the crazy ideas I mentioned above will become reality, or if they'll even be remotely successful. Regardless of any success or failure, this community will prevail because it has a good heart. We'll continue to recruit the odd duck here-and-there. They'll check out the chat room or browse through the forum and think "hey, this place is pretty weird, but nice".

Sometime later this year, I am hoping to arrange a ludum-dare-ish game jam for a community D-Mod. The goal would be to schedule a 48 hour window to work on a D-Mod... but what if we all worked on the same D-Mod at the same time, and at the end we have a single D-Mod that everyone can play? We could coordinate through discord and twitch, and maybe use something like github to share the map and source code files.

This is big stuff right here. Im thrilled about this whole post and all the ideas in it. While a community dmod jam would require not only a decent amount of members that would also be available any time in the span of those 48 hours, but it would also require a lot of coordonation. And while the first attempt at this (if we ever do it) would probably not give out the best results, it would have been a great learning experience for everyone involved and would offer the possibility for a better second attempt later. We could also document the whole progress and release it as an essay or a short documentary!

As for the dmod improvement project, Im willing to help as much as time and interest is going to let me.

But for both of those awesome ideas, especially the first one we would need a lot of people that are currently active in the dink community on a regular basis (not occasional returning lurkers) because I doubt that the number of daily active members even reaches 10. So IMO, we need to do what has been suggested by a lot of people over the years and that is, to make dink more popular. Now, Im not talking millions or thousands of people, of course. but we need a bigger number of people who join, say, per month. Because the truth is, if youve never heard about dink smallwood back in the day, chances are youll never hear about this community. Because most recent members (for example myself or bouncycles) thought about dink smallwood and decided to revisit it for nostalgia sake and stumbled across this community.

So long story short, in my humble opinion, we need to increase the number of new members before we could move on with any of those projects.

The web play function is amazing no doubt , i am going to post it around so that we can see how many people check it out but compared to steam/gog release , i think releasing the game on gog/steam could easily outmatch the numbers we see here everyday.

Just for a metric there is a wishlist feature on gog and more than 300 people have voted for dink smallwood https://www.gog.com/wishlist/games/dink_smallwood

My only reason for advocating a steam / gog release is that we can get new generations of people playing the game , creating dmods , sharing their dink experiences than just 5-10 of us thats here now.

I think tal suggested the prefect way dink can be released on those platforms without affecting anything here

The D-Mod jam is a good idea. As for mapping, I guess other people could do the map design on paper or images or such and post it in Discord, and one person could then map it all in WinDinkEdit as everything else goes along?

For those of you that do not know, the problem with binary files and version control systems (whether we use something as part of github or something else) has historically been conflict resolution.

With text files (such as DinkC text files) a lot of times things get added or changed in different places, so no conflict exists and merges are easy and can be done automatically. Even when two people make their changes in the same area with the same text file(*), resolving the conflicts visually is pretty easy too, if you get both authors to review the changes together.

Changes to different screens within the binary map file would be MUCH harder to identify, isolate and resolve. That being said, it would require an intimate knowledge of how the map file is constructed. However, if someone could develop a platform independent tool that could translate from the binary map file format into a human readable text format (and back again from text to binary), then we MIGHT be able to manage merging map file changes intelligently.

Anyone have any suggestions here? Do we have (or did we have in the past) any tools enough like the one mentioned above? Do we even have something a little bit like that which we could "build on" to get the tool that would be needed?

If not, then the only kind of merging and group work possible would be to have something "on paper or images or such" that would then require resolution and follow through by some agreed-upon-arbitrator-administrator that uses WinDinkEdit as needed. But this could be very awkward. Usually, I design screens in WinDinkEdit at the same time I code, adjusting each to each other on they fly. I suspect this is not uncommon for others as well. If there is no more robust solution for mapping, maybe the best idea would be to start with an existing map from our unfinished dmods section and assign sections of it for different people to work on. Merging would still be a bit clumsy and require an agreed-upon-arbitrator-administrator, but not quite as clumsy or error prone.

(*)Example: two different assignments to the same sound number in start.c, like (a)[load_sound("corkpop2.wav", 52);] and (b)[load_sound("ratdeath.wav", 52);].

You may just give the person the dmod for a specific day, and then they give it off to someone else the following day. You could also do a few days or a week. I wouldn't do anything more than a week though.

This method would ensure that everyone gets to add to it, and no conflict errors will pop up because only one person will be working on it at a specific time.

This method would ensure that everyone gets to add to it, and [fewer] conflict errors will pop up because only one person will be working on it at a specific time.

It would still be possible for conflict errors of various types to come about(*), but your approach would certainly reduce the chances for them.

(*) For example: Someone could assume a certain behavior for a certain sprite (call it sprite X) as a "&current_sprite" in it's script in a screen when Dink enters and another could override that behavior as a result of some changes that they make when assigning a new script to the screen as a whole or even through some incompletely tested changes to the original sprite X script.

It's pretty hard to mess with &current_sprite without realizing it. You could get script errors sure, but you shouldn't get any conflict errors. Conflict errors being that my version is different than yours. Conflict errors would make it so at least one person's work would have to be deleted, because you can only have one version.

@LeprochaUn:
Consider the use of functions like sp() to get the runtime sprite number of a sprite that is not the current sprite for that script, but rather the current sprite of another sprite on the same screen at the same time, making conversations between two sprites.

Example:
Dink enters a room to buy something from a shop. Upon entering, he freezes and starts conversing with the shop keeper. The shop keeper replies (because DmodDeveloper-A used int sp(int editor_sprite) to get the run time active_sprite value of the shop keeper). Then Dink is unfrozen, and is free to go up to the counter to try to buy something. This can all be done in the script assigned to that screen(*), [shopcsrn.c].

DmodDeveloper-B then gets control of the dmod and decides to use the main(void){} section of the script assigned to the shopkeeper [shopkeep.c] to freeze Dink when he enters the shop and creates an entirely different conversation for the two of them to have. Then Dink is unfrozen and can go up to the counter to try to buy something.

(*) I refer here to the script assigned in the properties of that screen via WinDinkEditPlus2.exe.

If DmodDevA works on a version and DmodDevB works on a version at the same time then you get conflict errors because now you have differences in the files. In this case only DmodDevA or DmodDevB's work can be kept(or you could spend a while resolving script issues).
If DmodDevA works on it and then DmodDevB works on it you won't get conflict errors because there is only that one version. DmodDevB will be able to start working on it (ideally) without issue. Any errors that pop up like for instance the use of functions like sp(), are not due to conflict errors, but because DmodDevA or DmodDevB did not write their scripts to avoid situations like this, or have/provide the information to prevent this. This is however still not a conflict error.

What would be better is making up a solid story first just a rough sketch , divide the parts into different people and then , release them to the community for feedback to see who gets the correct idea and then go in that direction.

(First, please accept thanks to both of you for your thoughts on the matter of how a "Community D-Mod Jam" would work).

If DmodDevA works on a version and DmodDevB works on a version at the same time then you get conflict errors because now you have differences in the files. In this case only DmodDevA's or DmodDevB's work can be kept(or you could spend a while resolving script issues).

Yes, there would be no conflict in the actual scripts. That is, since DmodDevA and DmodDevB each worked in different scripts (shopcsrn.c and shopkeep.c respectively), the version control system (assuming that we use one) would not detect the conflicts over two different conversations. Initially both shopcsrn.c and shopkeep.c would be "kept." And yes, in this simplified example, you could certainly "spend a while resolving script issues" once they were detected. Ideally, that resolution would require a dialogue between DmodDevA and DmodDevB. If we collect a few of these in the course of development, I'd say that it would make the "Community D-Mod Jam" process a bit tedious.

IF we go through with this "Community D-Mod Jam" idea, I agree that it makes sense to develop the "rough sketch" of a "solid story" first. As a next step different parts could be divided up into little teams. For Example, Team#1 could consist of DevModA fleshing out the story while Dink is in the town of SplatBang. If DmodDevB and DmodDevC agree with the storyline, then DmodDevB could do the mapping for the town. Finally DmodDevC could do the coding for various places in town. Then Team#2 could start on the DungeonOfDoom section of the story, mapping and coding, followed by Team#3 working on the same things for the ElysianFields section of the map.

One other factor here is something we have to be realistic about. Dmod development is (for most people) not the first and most important part of their lives, and there are dozens of unfinished dmods that testify the to reality that it takes time and commitment to develop a dmod, especially at this time in the history of Dinkdom. Many give up on the effort and therefore do not even end up uploading an incomplete dmod to be downloaded by Dink fans around the globe. Putting together a long list (well, it will seem like a long list for this small group of gaming fanatics) of people to work on a dmod practically guarantees (IMHO) that someone will stop producing or not produce fast enough to sustain the interest of all others involved.

@ yeoldetoast:
Well, I'd hardly call the failed creation of a dmod a disaster. The worst thing that could happen is that only a handful of gaming fanatics might get their feather's ruffled.

A tsunami is a global disaster. The descent of a nation into tyranny is a disaster for an entire people. An earthquake is a disaster wherever it strikes. The loss of a loved one is a personal disaster.

To quote a famous tome of wisdom known throughout the galaxy, "Don't Panic".

A failed dmod or a underappreciated dmod can certainly cause some people to take the hit very seriously and personally , we have seen it happen here a lot dont want to point out names there were lot of dmod makers who were very upset and sad when their dmods did not become a hit as much as they wanted(review score) or win that particular contests , we have to take everything into account seriously.

Just tried DinkHD on the web, awesome experience, no framerate issues whatsoever! The midi music sounds different than I remember, but it's been over 10 years since I've listened to a standalone midi file... Probably normal!

@ Skurn:
Oh, you meant the "Community D-Mod Jam". Well yes, I agree that it makes sense to create a sticky discussion about it, though first I'd say we still need to work out a few things about how it might work before we actually do it.

Would that community project be like one continuous large dmod, or a mashed-up jumble from several different authors where each section is self contained? You know, like Scheherazade's stories, where ending of each part will have something like:

Err... self-contained tiny bits would be fine. Every dmodder gets a few selected screens, and a number of variables he can use.

That sounds like a winning combination of simple rules to start with, except we may want to distinguish between global and local variables. Example: Each dmodder gets 15 local variables and 10 globals.

Also, would we allow dmodders to import graphics, sounds, animations, etc. at will or do you think it would be a good idea to limit each of those too? Or would it be better to state that only the original graphics, sounds, animations, etc. can be used?

If max number of global variables is ~ 200, if 4 people participate, each can get 50 globals. So, (available globals) / (number of participants).

Each global variable and each script name, must begin with our nicks, so if both of us make a script called bookshelf.c, your's would be slipDink_bookshelf.c, and mine toof_bookshelf.c. Again, same or similar for global vars, since someone will have to stitch it all together at the end. It would be a nice idea that every participant makes a list of his vars, and the initial values, so that the grand-master Stitcher Overseer can just copy them into main.c (scripts into story as well, but those would just be zipped).

Also, entry and exit points should be predefined for each section. If someone wants to change that, he can consult with the other dmodder if their sections have intersections (God, my english vocabulary sucks!!). I'd say, we start small, with four screens (box shaped), or 6 screens (rectangle), so if someone quits, we can easly rearrange them together (copy pasting screens with scripts).

@toof:
If max number of global variables is ~ 200, if 4 people participate, each can get 50 globals. So, (available globals) / (number of participants).

I think you might be confusing globals with locals here. I think I have a a somewhat better grasp of how variables are managed by DinkC. As I understand it...
{Globals always exist and always consume some of the limit of ~200. Locals come and go, according to how many scripts are active at a time. This includes what the main section of scripts for all armed "weapons" and magical spells declares and (potentially) a script for each item on the current screen, plus any that have simply been generated by a call to a currently active spawn() function that was started by other scripts, and those called by the external() function, etc.
}

So perhaps you could say, if then maximum number of variables is ~200, and 4 people participated, each participant would get 20 globals and 30 locals.

Each global variable and each script name, must begin with our nicks, so if both of us make a script called bookshelf.c, your's would be slipDink_bookshelf.c, and mine toof_bookshelf.c.

Okay. But keeping filenames under 8 character limits would be better. That would mean we could use slipbksf.c and toofbksf.c so that external and spawn still work.

Again, same or similar for global vars, since someone will have to stitch it all together at the end. It would be a nice idea that every participant makes a list of his vars, and the initial values, so that the grand-master Stitcher Overseer can just copy them into main.c (scripts into story as well, but those would just be zipped).

Actually, each participant could make their own main.c that contained only what they needed, such as slipmain.c, toofmain.c and each participant would need to update a special section of main.c like what I've shown below.

make_global_int("&dinklogo", 0);
// Add your own globals here. Remember, you only get about 200 of them
// total, so be sure you don't go overboard.
make_global_int("&story", 0);
external("skrnmain", "main");
external("slipmain", "main");
external("toofmain", "main");

Also, entry and exit points should be predefined for each section. If someone wants to change that, he can consult with the other dmodder if their sections have intersections

I'm not sure what you are proposing here by "entry and exit points for each section.", but I assume you are talking about conventions about how each screen (or block of 4 or 6 or 9 screens or ???) as designed by one participant can be entered from the screens developed by another participant. That sounds like a good idea. We would need to diagram it carefully or come up with general rules such as ... "All external southern and western edges must permit Dink's entrance without obstruction."

(God, my english vocabulary sucks!!). I'd say, we start small, with four screens (box shaped), or 6 screens (rectangle), so if someone quits, we can easily rearrange them together (copy pasting screens with scripts).

Actually, depending on how people use screens, moving them about could turn out to be a little troublesome. It is not uncommon to refer to the &player_map reserved variable and to assign it to certain values that represent particular screens.

As for importing graphics, I've no idea, I have never done that.

Oh. Well perhaps the rules for that should be that you can do it as long as you do not replace the standard graphics, unless you do so with the consent of all other participants. Not sure what I mean when I refer to replacing the standard graphics? Consider this example: Over the years some people have developed new "status screens" and (generally) those would be implemented by replacing the existing graphics used for that purpose. But if you were to add a new monster, or one from the development section of the DN, then the only rules would be that you could not re-use other graphics sprite sequence that is part of the standard graphics. Still I might use a sequence that another might want, so we would have to work out something with numeric ranges assigned to each participant, or (in your case) if you do not plan any new graphics, then you could just give your sequence range to another participant.

Fair enough. You obviously know about this stuff more than me. And, yes you understood me correctly about entry and exit points.

The simplest case would be that each dmodder has 1 screen, and Dink must be able to enter from right to left between y-coordinate values of say... 100~300, and exit to the left on the same y-coordinates, thus entering again from right to left on the next screen, on and on and on...

I'm also aware that var names should be kept short, so yeah... I agree on that too.

For main.c, I had no idea...

We should also then include that Dink must leave with same stats, gold, max-life, etc as he entered, unless the next dmodder has no problem with that.

@toof:
I'm also aware that var names should be kept short, so yeah... I agree on that too.

I assume you mean that we must limit DinkC .c filenames to 8 character strings and DinkC variable names to 18 characters.

The simplest case would be that each dmodder has 1 screen, and Dink must be able to enter from right to left between y-coordinate values of say... 100~300, and exit to the left on the same y-coordinates, thus entering again from right to left on the next screen, on and on and on...

If each dmodder has 1 screen each, then this (it seems to me) will be a short dmod as it looks like there are very few following this discussion beyond you, me and (perhaps?) Skurn. But I suppose that is ok. I'm spending a lot of time on my "Before..." dmod of late.

I think we have worked out about all of the basic rules here. Now, how can we get more dmodders to "sign up"?

I was giving 1 screen as an example. We can have as much as we want. As for recruiting others, thats up to them. They have this thread and all. I'm not sure for myself. Making a dmod is a huge task. It took me a while just for a small romp. Sure, It was my first, and I was still trying to grasp the basics (not that I'm an expert now), but still... Plus, I was free back then, now I'm working 10~12 hour shifts, so sitting at a computer isn't exactly my priority in the free time.

And I wasn't thinking about making another dmod. Golden Duck was a product of a long wish to contribute here, and a jumbled mish-mash of several thrown away ideas and trials. If you ask me what would be my next dmod about, I wouldn't have a clue.

#4 This link (DinkC Reference) is to a text file that serves as a good basic reference to DinkC, with some excellent commentary.

#5 This link (DinkC Reference (Windows Help File)) is to a later version of the DinkC documentation, with some valuable updates. This version of DinkC documentation (as the name clearly suggests) is in Windows help file format.

Finally, there are plenty of people here who should be willing to help you with any tough questions that come up after you review some of the above.

Since Skurn does this at a regular basis, I feel like I have the right to revive this thread. While I don't think I could significantly contribute to the D-Mod Jam, I'm interested in the D-Mod Improvement Project. I mean fixing game breaking bugs and updating the D-Mod to be more compatible with newer versions of Dink sounds great.