Hi! I've been doing a bit of planning and game design before getting back to the editor, and I'm hesitating between to different ways of structuring my game. Since the narrative relies a lot on flashback and reusing the same maps with a few differences, I was wondering, for any given place where the player will return several times, if I should use a single map where scripts control the many different changes that may occur with the passing of time, or if I should make several different maps based on the same one.

Let's say, for example, that the player comes back to the same map five times during the game, but that one year is supposed to pass between each visit. Should I use a single map and script every change, knowing the player will move to other maps before coming back, or should I make five different versions of my map?

At he moment I'm more inclined to make different versions of the map, since I won't have to come up with a complicated set of scripts to track everything (not to mention I'm not sure all the functions I'd need are implemented yet). But on the other hand, if for some reason I want to change something "permanent" in my map, like a room or an architectural feature, I'll also have to change it manually in all five versions, and that sounds equally (if not more) tedious.

So, what would be the smartest approach? I didn't really try scripting yet except for basic stuff like opening and closing door, which worked pretty fine, but in its current state, is scripting ok to change lighting, camera height, add or remove characters and objects, swap dialogues, stuff like that? I mean, I'm sure it will in future releases, but can it already be used for this kind of "persistent map"? Or should I go with map versions, or wait a bit for more advanced scripting?

Hello! I think either approach that you describe would have its pros and cons, but the biggest thing that stands out to me is one that you mentioned - if there are permanent changes you decide to make then you'd have to make them across all of the maps. Unless there are huge changes between each version (which it doesn't that sound way), I would recommend just having one map and using scripting to make adjustments.

So, I actually think this might be a good situation in which to start building out the scripting system some more. :) It would be great to just go ahead and start implementing those events that you'd need since it would help give me direction of what scripts are useful and you could avoid the need for multiple versions of the map.

Feel free to create a list of scripting functions that you'd like to have available (for example, swapping dialogue), and I will try to start working them in. And if you could sort the list in order of priority, that would be even better. :)

Excellent! I already have a little list, so I'll update it and set priorities. I've poked around a bit in the script editor and it seems I should be able to do a good part of what I want with the existing functions, but it also depends on the "user friendliness" you're aiming for. I mean, while I'm definitely not a programmer, I'm used to simple programming logic and game development tricks, so while I can combine some of the existing functions to suit my needs, maybe you'll want more specific logic blocks for beginners. Or maybe you could create templates with a bunch of pre-linked functions...

But I digress, time to update this list :)

Oh, and one question while I'm at it, how does the new "pending" path work?

Sounds great, thanks! I very much welcome any feedback on the Script Editor as I definitely want it to be as user-friendly as possible. One scenario I could see having a template or pre-defined logic block for would be "toggling" of states, for example a door opening and closing, since that is a common scenario. We can work together to determine what makes the most sense. :)

The "pending" path is something I am experimenting with and probably doesn't have much use at the moment. Basically, it makes a connection between two tiles, but doesn't allow any interaction or navigation initially - kind of like a "placeholder" connection. The intent is for it to become convenient for automating certain navigation based on the state of an object.

This path type will become much more useful once I add the functionality that will allow you to attach a script to a particular animation for an object. For example, you could create generic scripts for a door and attach them to the "open" animation and "close" animations. When "open" is triggered, the script could say update the path type between the tile that this door is on and the tile to the west of it to be "Walk and Interact", and when "close" is triggered, the script could say update the path type between the tile that this door is on and the tile to the west of it to now be "Pending". This would eliminate some of the need for giving unique IDs to tiles since you would have those pending paths and will be able to reference relative tiles (e.g. tile to the north, south, etc. instead of unique tile IDs to keep track of for each door). Hopefully I explained that well enough! Here is what it would look like visually:

It's still a work in progress at this point, so it may evolve or change to make it less confusing. :)

This also reminded me of a feature I wanted to add that should be useful with what you are wanting to do. The idea is an "on load" script you could specify per map that would be executed any time the map is loaded. You could check for a global property when the map is loaded to trigger any changes to the map, like when you have moved onto a new time period.

I agree an "on load" script would be very useful! And this pending path sure would come handy, especially given the number of doors I have on that map.

I've almost finished the list, it's taking me more time than I thought since everything is indeed kind of interconnected. But it's an interesting thing to work on, in fact quite similar to my daily job :)

Okay, here's a first draft: https://wri.tt/43mbmsj9xj1eh7po

I guess some functions would require much more work than others, and most of them could be merged or divided depending on where you want to put the global specific/generic slider. Some of them are also possibly just plain dumb :) Overall it's a lot of cinematic stuff I don't really need for the game logic, but since my game is supposed to be rather atmospheric / contemplative, it's still important. I could add a few more features and ideas, but this is probably long enough for now :)

Let me know if you prefer using Workflowy or a forum post, since this isn't an editable/commentable document (yet, because it's a planned feature).

At the moment, I have designed a second map (very different and simple compared to the one you know), and my goal is to set up the beginning of the game, which implies to go back and forth between these two maps, one being the present and the other being the past. So I'll be able to test quickly all these enties and properties changes I mentionned earlier. And it's quite exciting!

Keep up the great work and cheers!

This is great, thanks for the details and organization! I'll admit that reading through it was a bit intimidating at first, but as long as I focus on one at a time I don't think it should be too bad. :) I'd say the most challenging ones will be those related to the camera, but it will be a good opportunity to improve my knowledge of vector math!

For now, if you don't mind, go ahead and create a new post on the general section of the forum and include the link to document, then we can use that thread to answer questions, discuss, etc. as I work through each one. Looking forward to getting started on these and seeing them in action! :)

Awesome! I also thought the camera stuff would be the most complicated, and at first I tried to come up with more simple parameters, but in the end, given RPG in a Box's huge potential for doing first person games quite easily, it's probably a good thing to make it more versatile from start. Anyway, it's great to be able to contribute a bit, thanks a lot :)

Totally out of topic, but I've just noticed I've left a typo in the description of the game for the RPG in a Box website: "a first-person adventure game about the death of a utopia" should probably be "about the death of an utopia".

No problem! I agree, it will be good to get things like this implemented earlier on, and it helps having actual game projects to get feedback from about what will be useful.

In regards to the description, I think I may have actually changed that myself when entering it onto the website. Since utopia is pronounced "you-topia" and you go by the starting sound as opposed to the letter, it ends up being "a" instead of "an". One of the many weird things about the English language. Or I may be totally wrong... :)

Right, I didn't think about that :) For some reason I thought it was only valid for words starting with a H, but yes, that makes sense.