Great idea, I never knew about that! I'll add that action to my printToErrorText function and play around with it.

Sometimes the layout editor in C3 stops rendering the layout and instead just shows a sad face in the upper left corner (pic below). When this happens, none of the 10+ layouts in my game will render properly. The only solution I've found is to close the project, restart the browser (chrome), and reload the project. Any idea why this may be happening, and is there anything I can check to track down the underlying cause?

For the more experienced programmers in the community: what are some best practices for logging debug-type data in C3?

I use some simple logging in my code for debugging purposes. Basically I have the simple function below that prints to a text object, which is in a layer called 'debugLayer'. Every layout in my game has a 'debugLayer' layer, and pressing the 'd' key toggles visibility of that layer. I call printToErrorText throughout the code to log what I feel may be helpful or relevant for debugging, but other than calling it once at the beginning of every function (with the function name and parameter values as the str argument) I don't have any consistent rules on when to use it.

This method has been helpful, but I have to think there are better ways to tackle logging with C3. Would love to hear what's been working for the C3 veterans out there.

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