Manipulating Layouts that aren't the 'active' Layout

Hey all,

TL;DR - Can I make stuff happen on a layout that's not the "current" layout. IE - set variables and read from them on an "inactive" layout.

I was wondering if anyone knew anything about changing things on a layout that isn't the current displayed layout?

What I have currently, is a layout that is the "game world" and a second layout I'm using as a map. I want to be able to have events happen on the map while that layout isn't being "run" at the time.

It would still need to be able to read/write global and instance variables and (maybe) a dictionary object specific to the layout, but no collisions or anything like that (though they would be a bonus)... would setting the layout to GLOBAL simply be enough to do what I want? I'm hesitant to go through the process of changing the way a bunch of event sheets interact just to test it - unless nobody else knows the easy answer - I've kind of set myself up in a dumb way with event sheet inclusions that would take a bit of work to de-spaghettify. xD

If by chance this ends up being not possible... I have an idea on how to save and load the relevant data between layouts, but I'm having nightmares already thinking about how complex it would end up being in the near future when things get more complicated in my game. Hoping not to have to go that way.

~Sol

I tried to accomplish something similar before on a test project. I didn't really get to finish any working prototype with it, but some things i tried out was was using a regular layer as the Map, and setting the layer to be global (But hidden)except when in the map layout. I remember a bit, but It was about 2 years ago or so, so I don't remember really how far i got on it, but I was getting close. I also tried saving the game to store the positions on the global layer, and loading the game again to restore it to the save state. Unfortunately I don't have any capx of that prototype left as it was on my old computer that broke down. Maybe something like that could work.

Ahhh crapola.

I kind of felt like that was going to be the answer... thanks tunepunk I will make the changes soon to head in that direction. I knew I should have just made the map in the same layout, I was just worried about performance due to the number of tiles to be drawn on the map and the potential loops running to calculate stuff.

I don't know of a better way than to have shared timers on each layout that are set from a global clock... then to quickly compute "time jumps" between the layouts being open using hard drive committed data (using a dictionary or an array).

FARK D:

I'm hating myself right about now, but I'm up for the challenge...

~Sol

https://dl.dropboxusercontent.com/u/205 ... tsave.capx

Pont and click to move the blue dot

This seemed to work. Saving positions to localstorage. Maybe you can use for each on the layer, to save all the things, then for each load as well.

/

Thanks tunepunk

I'm using NWjs with a nested dictionary save system, in JSON.

I know how I can do what I need to do now since there's no "easy way" but it's going to be a little hellish, mostly due to the way my map tiles are generating. I think I may need a better over-all approach to how I'm doing the map, or come up with some "creative" way around my issue.

I will need to be able to track the positions of (potentially several) objects as well as monitor "random events" that happen on the map - then interpolate them from the clock based calculations made on the "main" layout where most of the game takes place. It's almost like I need to have two separate things running at the same time and talking to each other... but without all of the draw calls and loops mashed into a single room.

I do have a "creative" method in mind for working around the issue and possibly establishing a (maybe fun/maybe boring) mechanic in to the game - whereby the player actually discovers the map manually using some sort of "magnifying glass" and then visits any discovered locations that are already "discovered" - rather than being able to send out a rally point to unexplored (not-yet-generated) areas and having it generate on the fly.

I'm starting to wonder if I make any sense anymore? xD

~Sol

Sounds complicated. Seems like the global layer seems to be the approach though. Then just update on layout switch. I can't really think of any other way to have an inactive layout being modified, unless it's all happening in an array by numbers, and somehow transfer the whole array from one layout to another.

Sounds complicated. Seems like the global layer seems to be the approach though. Then just update on layout switch. I can't really think of any other way to have an inactive layout being modified, unless it's all happening in an array by numbers, and somehow transfer the whole array from one layout to another.

That's essentially what I'm doing now using nested dictionaries (then saving a JSON file with NWjs)... transferring data between each layout... but it's about to get a whoooole lot more complicated xD

I think I'm going to have to make some "ghost objects" on my main layout that will dummy as data-clones to my second layout. This way I will have a few invisible objects that I can store the same instance variables and positioning data in, then save and load that onto the map; almost like a reverse mini-map.

I'm still not sure how to handle tile based "random events" though if the tile data isn't directly accessible without changing layouts. I'm not sure that I could really go with using a "map layer" and just turning it on and off, because of the sheer amount of objects between my main "game layout" and the map - it would implode something I think. ARGH!

*EDIT*

Bugger it, I'm going to try and merge the layouts using a global layer and just if if catches on fire or not - there's only one way to find out right?

~Sol

Absolutely, you won't know until you tried. Let me know how it works out.

I've half converted everything over to be on the main layout using a global layer from the map layout - but now I have to re-work how I was saving and loading data since there is no layout changes anymore (so the layout isn't "clearing" itself automatically between data calls).

So far so good, but the real test will be when there is a lot of action going on AND I open the map up... I have a feeling this is going to impact performance quite a bit once things are in high gear.

I can't really see any other real way around it though, since I need such fine control over the map at all times - because that will be I guess "really" where the game takes place. The side-view screen where the characters are is really only a small part of it all. Oh well, I spent a few hours yesterday (while thinking about how to approach this issue) doing some more optimisations on the event sheets and found quite a bit of wasted CPU time, which I have now (mostly) fixed.

~Sol

I have no encountered one annoying problem now...

My map layout is set to "unbounded scrolling" but using the layer as global in my main layout still uses the bounded scrolling attribute from the main layout.

Any ideas how I can get around that? :/ I guess I need to make the main layout unbounded as well - then add some artificial camera bounds somehow unless the map is open?

*EDIT*

Nevermind, I answered my own question here...

Anyway it seems pretty good so far - I have a map that has generated about 5000 tiles (which isn't many compared to the possibilities but it's still a good test I think) and about 80 marionette/characters with a stable 60fps still - when I open the map however with that many characters there's noticeable fps drop so I will have to see what I can do about that, but at least I can have full control over things now.

~Sol

I think the FPS drop might be because back to front rendering. While the map is open, can you set other layers behind (that you don't really see anyway) to invisible, maybe that would help, and turn them back on when the map is closed?

Yep that's the last thing I haven't done yet is to hide those layers... I think it will work because when the map is "closed" it's simply those layers hidden... and it doesn't affect performance. I will make it switch the other 10 or so layers that's used for the rest of the game to invisible and it should be good to go.

I still wish there was a way to make other layouts do stuff without being the active layout... I honestly think this will be possibly one of the heaviest single layout games ever made in C2 when it's finished... It's already pretty massive in what it can do, but it will really start to show the potential when i build my "location maker" and start saving some layout data for various places the player can visit.

Thanks for the input and help tunepunk

~Sol

No problem. Looking forward to see a demo later. Sounds like a cool project.

Demo is always live on my domain... you can go to my project thread and check it out.

The web build doesn't handle saving and loading though, because it's NWjs - but I have a link on the web build to the standalone version with some instructions to set up the name lists and stuff (it's all manually done for now). The standalone version is a bit out-dated though compared to the web build - but the web build is good enough for a bit of a tech demo.

~Sol