To add to R0J0hound's suggestion, perhaps Pinning them with offset will be more straightforward to control?

Oh man, that's a lot to process.

I have a bunch of question but i will get them all together after re reading what you wrote, but the one that is bothering me right now is this:

A global object exists through all the layouts, but it has to be created initially, what happens when you return to the layout of creation? does it duplicate? and if so how can you avoid duplication?

Metathronos, yeah if you return to that layout and the event fires (due to the condition) it will duplicate. You have various ways of dealing with that, like checking against a particular object/instance and say if it exists or has a certain instance count, then don't create.

Or you could use a different layout and event sheet to gather your assets, both Global and not, and never go back to that layout.

When you move out of the layout, you will lose everything except those that are Global objects. Usually Sprites are not Global by default; you need to turn them on. It depends on the nature of the pickups or how many Sprites you want to remain for you to manage.

In regards to persistent pickups: I would like to suggest working with a 'database' of objects that you expect to be in a layout. This 'database' is actually a Dictionary, which are Global, so they persist. They are saved when you 'Save Game', so that's bonus.

The Dictionary contains information about the item, for example. its default location, and its state/status (eg 'default', 'pickedup', etc) and whatever seems relevant to you. This Dictionary defines how the item will be displayed, if it were to be displayed at all.

So for example, I have a Dictionary object called 'ItemsDict'. ItemsDict has an instance variable called `owner`. `owner` refers to the House that will refer to this dict. When I have ItemsDict.owner=House_A, this means that the items that will be contained in this dict are items from House_A.

Then imagine we instantiate another ItemsDict and assign `owner` to House_B. So now we have 2 dicts.

Now when we enter a layout, we pick the appropriate ItemsDict using the owner name. You may use the layout's name, or some other mechanism. Once you pick the correct ItemsDict, you cycle through all the keys, and instantiating new Sprites that correspond with the data inside ItemsDict.

When the player has interacted (eg picked up) with an Item, you have make sure that ItemsDicts is updated first by removing the item/key or changing the values, or whatever is appropriate. Perhaps your update mechanism (ie the one that controls the visibility/presence of Sprites) should always derive its state from ItemsDict so that you only have to change ItemsDict and let your updating mechanism handle the visual updating of the scene.

If you exit the layout the Sprites will be destroyed, but ItemsDict will remain. Then go into House_B layout, the same process applies; Sprites are recreated using ItemDict.owner=House_B. But when you go back to House_A layout, the Sprites are recreated, but the objects you've taken will no longer be in the dict and thus won't be created. And that's how you may approach persistence.

Re portals: the player character, whether it is encapsulated as a single Sprite or multiple Sprites, I recommend to be Global because it's usually efficient as the player is the most consistent element from layout to layout.

First, I suggest creating an instance variable in the player called something like `portal`. This makes you avoid the use of global variables.

The concept is having an 'outbound' portal and an 'inbound' landing area. These are two different Sprites. The 'outbound' portal has 2 instance variables called `layout` and `landing`, which is the name of the layout and landing id, respectively, that this portal is going to deliver the player. The 'inbound' landing Sprite has only one instance variable called `name`, which is its identifier.

For example, inside a House_A, there's a portal with `layout=FirstAvenueLayout` and `landing=House_A_entrance`. In the layout FirstAvenueLayout, there is an 'inbound' landing Sprite with the `name=House_A_entrance`.

When the player goes over the 'outbound' portal (ie is overlapping object), the player acquires the `landing` variable value and puts that value into its own `portal` instance variable. This tells the player that whatever layout he ends up in, he will always be placed on the 'landing' Sprite with the same name. In this case it's 'House_A_entrance'.

The System, on the other hand, will acquire the `layout` variable of the portal, which tells the System to move to that layout. When the layout is loaded (ie On Layout start), the player looks at its`portal` variable and finds the 'landing' Sprite and positions itself there.

It is important here to make sure that when you 'land' at a place that it is not in the same place as an 'outbound' portal, or else you'll keep on bouncing back and forth. You may place other event conditions that prevent this, of course.

Hope that made sense.

Tokenize your string by the newline character (in the image above I use \n); iterate through to tokenization to concat it back up with &newline at the end of each iteration.

but then there is a profile error dialog showing up when I try to run the exported game

Delete your profile for the game:

%localappdata%\<your_game_name>[/code:1das61kz]

TheRealDannyyy, many thanks for your info. Helpful as always.

I was wondering if any one is having a similar problem I'm having with NWJS v0.29.0 in which Effects are no longer working and using the fallback. NWJS v0.28.0 works fine though. Running C2 r250. (Could that be it?)

EDIT: Just to add some images illustrating the problem.

This is the base image.

There's a green background (TiledBackground) that goes over this with an Effect: Multiply. In v0.28.0 Chromium 64, it works as expected, and this is how it looks:

In v0.28.0 Chromium 65 it looks like this:

Also other effects don't seem to work as well. They simply don't show up.

I'm not knowledgeable enough to know if this is related to Chromium itself -- I tried looking for instances of rendering errors using WebGL effects, etc but couldn't find anything relevant -- so I'm not sure where the 'bug' lies. Any hints? Thanks!

[EDIT]

I've upgraded to C2 r255, but no, that doesn't seem to change anything.

Alon, sorry but I can't open up your C3 project (I'm not a subscriber and the free trial is a version lower than your c3p). I just use C2.

I'll just quickly run through my setup, which is very basic.

The first thing is that I use a circle sprite as a 'mover'.

I squeeze this vertically so that it conforms to the 'perspective' of the rest of the artwork. As you can see above, the collision polygons simply follow the shape.

The properties for the pathfinder is this:

The Cell Size and Cell Border would highly depend on your own graphics and how 'tight' your moveable area is.

Note that Obstacles is set to Solids.

The next idea is that I use blocks and circles as collision and I layer them up. The best way to describe them is this picture:

The some of the highlighted blue objects represent square sprites with collision polygons shaped likewise. If you can spot also there are these flattened pink circles (with a 'C' written on it) that are circle collisions. These Sprites have the Solids behaviour attached to them, and the Pathfinder uses these to navigate around. I use a combination of these collision Sprites to make up the moveable area. (In other progs like AGS, you define the walkable area, but in C2 I define the area that should be blocked).

Here's another picture of the other scene in the demo. The pink circles are more visible here. I use a lot of them here.

My event sheet for movement is super-simple. It looks like this:

You can ignore most of it because it's mostly related to specifics of the game. As you can see it's nothing special. However, there is a 'special' workaround here that you will see in event line 35. Sometimes the player mover can get stuck because it gets too close and overlaps a collision. When it does this, Pathfinding usually fails to get a path. So what I do every time there is an attempt to walk, I check if the player mover if overlapping any of the collision Sprites (CollisionFamily). If it is overlapping, I disable Solids for the picked CollisionFamily Sprite and then regenerate the obstacle map. Then when the Pathfinding path is found, I enable the Solid again.

Hopefully that helps. I can't share the project, unfortunately, and to be honest, it is burdened with many gameplay things anyway. The pathfinding is a very simple aspect of it.

Any other suggestions instead of the built-in pathfinding behaviour since it's very slow calculating and not reacting right away? please share your ideas / suggestions / examples will be great since I'm still a newbie user.

Alon, I've used pathfinding on a point-and-click type prototype before and there is no real lag for me unless I keep on regenerating my obstacles, which would not be commonly done so much in that type of game.

I think you can use pathfinding. If you have lag issues with a certain pathfinding setup, then the best way is to show others how you've set it up by uploading the capx so we can determine if there's some thing that can be optimised/improved.

ivall, I'm not getting any buggy behaviour.

When I click on 'nagrajgre' it switches to 'jakagra' and 'nagrajgre' disappears (destroyed) because it has moved to another layout. In 'jakagra' I click Team Fortress, and I go back to 'gra'. 'nagrajgre' appears again because it's loaded back to layout.

FYI, I'm using Build 250.

Thanks for this. Useful to have it in mind.