I have about 10 layouts in my game. I can debug most layouts just fine, but there are a couple that "crash" the debugger. When I select "Debug layout" for those I get what's in the screenshot below. No controls work, and eventually I get the warning window from Chrome. This is happening on simple layouts: the main title layout and the level select layout. Both of these layouts work fine when playing the game, and I can't think of any objects these layouts contain that are not in the layouts that work with the debugger. My capx is too large to share, any suggestions on what to check?

Layers and event groups are not reset to their default state. If you deactivated a group, it will stay deactivated after the layout restart.

All objects are re-created, except global and the ones with Persist behavior.

Hey Dop thanks for the response. Re: your comment on groups, just want to make sure I'm not misunderstanding something. Per the docs:

Restart layout:

Restart the current layout. Note that unlike Go to layout, this action resets all event groups to their initial activation state. Global variables keep their current value - they are not reset. To reset them use the system action Reset global variables.

?

Thanks everyone, this is very helpful. The 2 articles mentioned provide great detail and I have a strategy now to deal with this. Luckily I'll be able to break up the sprite into a number of smaller ones, and I only need a few per layout. I'll also work to reduce the overall image size and crop the dead-space around the images.

I'm trying to understand what "system->restart layout" actually resets...

For example, in the layout editor I set one of the layers to be initially invisible. During the game it's set to visible at one point, but when I call "system->restart layout" it doesn't reset that layer to invisible.

Does "system->restart layout" ignore the layout properties set in the layout editor? If so, which ones? And what's the best way to truly reset the layout - store all properties in global variables?

In my game, there are a large set of high-res animations for each player/enemy combination. To provide come context, I expect the total size of the animations for my game (after C3 processes them) to be upwards of 1gb.

I currently have all the animations in a single "player_combat" sprite, that I place when and where a combat occurs. I only have one instance of player_combat that I make invisible when not in use.

This is convenient because I have all the animations in one place, and can easily copy animations, image points, and collision polygons between different "enemy" folders in the object's animation page. However, C3 is taking a long time (several seconds) to instantiate the object at the beginning of the game, and I believe it's because of the number and size of the animations it contains. My C3 editor is running slower these days as well, especially when opening the animations dialog for any sprite object, and I'm wondering if the size of player_combat and its large animation count is contributing.

I'm thinking it may be more efficient to separate the "player_combat" sprite into multiple "enemy_combat" sprites, each of which only contain the animations for that enemy. Seems logical that these sprites would take less memory, and even if I have 1 of each instantiated all at the same time, the combined performance hit would be no more than a single player_combat sprite.

I want to run this by the community before I go down this route, because if it turns out to be a bad idea, going back to a single player_combat sprite would be a lot of work (I'd have to recreate all the collision polygons for each animation since there's no way to transfer those from one sprite to another).

So my question is: is separating the "player_combat" sprite into multiple "enemy_combat" sprites a good idea for this situation? And are there any other best practices I should keep in mind with large numbers of high-res animations?

Thanks

Before

Since posting this I realized I can use Event Groups for this, and enable/disable groups based on the situation. E.g., I can have a Player Attack group with all the keyboard events I use for attacks, and disable this when interacting with a menu. This is a lot cleaner than the individual conditionals I've been using for every keyboard event. I'm looking forward to seeing how this will work.

Any other 'best practices' folks have been using?

In my game, the 'z' keyboard key serves many functions. Depending on the situation, it can be used to kick, shoot, reload, talk to an NPC, continue a conversation, end a conversation, or select items in a menu.

I've been using a combinations of conditions to determine what code should be executed when 'z' is pressed. They check for player 'state' (instance variable) values, object visibility, overlap with other objects, layer visibility, or a combination of these. It works but is getting messy, and when I add new features or make changes to the game, my logic is prone to break. It's basically spaghetti logic. I'm pretty early in my game so I have to think there's a better way to implement this, and that this is a common challenge with some proven solutions.

Is there a 'best practice' on how to implement and manage overloaded key events? Maybe use of a data structure or dictionary opens up some cleaner options?

"Add Sprite.pickedcount to killCount" -- That's good stuff right there!

My understanding of picked logic was: iterate through every step in the action block X times, where X = picked count

But it sounds like you're saying: iterate through every step THAT REFERECES THE PICKED OBJECT(s) in the action block X times, where X = picked count. For all other steps, execute those once

Is my new understanding correct?

Thanks

Agreed. I have thousands of values (my array is 500+ rows and 140+ columns) and I do a select all (ctrl+a) and copy (ctrl+c) in excel, then paste that into the top left cell in the C3 array editor. Works great.

My game is similar to KiwiStory, where I'm creating multiple platform levels in a single layout (pic below). In my game, the enemies move towards the player based on Line of Sight behavior (LOS). They start with a smaller LOS range, but once they "see" the player or are hit their range is increased to the Layout width, so they always have LOS to the player on that level.

The player can move to different levels in the layout, similar to how the doors work in KiwiStory. The problem is, once the player moves to another level, the enemies on the original level may still have LOS to the player, so they try to move towards the player. I want to keep them from 'seeing' the player unless they're on the same level.

I see a few ways of implementing this. E.g., a global currentLevel variable that's set when entering the doors, and only enemies with that value can see the player. Or I can compare an enemy's Y coordinate to the Player's Y to determine if they're on the same level. Or I can wrap each level in "obstacle" sprites which can block LOS. Each has its pros and cons, so I wanted to see if there are any strong recommendations for one, or if there's an even better one I'm not thinking of?

Thanks