Non-Named (More debugging)

[puggsoy]

From my experience with Stencyl, it's not a very efficient engine. Admittedly, I have only used it once and that was for a game jam, so I can't say too much; but it did start lagging once I had too many things on screen and since we hadn't implemented death by the end, the way you lost was "once the screen contains enough enemies to lag the game to an unplayable speed"

Mind you, I'm not saying you should use something else, Stencyl is still pretty good. But that might just be a contributing factor to the memory usage. Other things such as forgetting to remove/destroy objects that you don't need anymore might also be something you can look into.

[Filler]

The biggest cause I found that lags the game is collision, overuse of layers, and failure to recycle actors (Actors are recycled in modern versions of the engine by default).

It's best to optimize the game the best you can for the engine, such as reducing as much if/otherwise statements a possible, and removing continuous collision. It's best to enable the debug FPS monitor to see how much memory is actually being used on where. Scripts that don't need to be used anymore should just flat out be stopped. It's tiny things like that which make the engine run better.

The Stencyl engine itself always loads all the graphics and sound on launch, this does reduce loading time, but kills a chunk of ram. That's why atlas use (think of it like bank swapping) is important. As it cuts down the memory and CPU use massively.

It's also best to avoid using the flash compiler for the engine, as it's nothing but a bloat hog (like flash is).

[iyenal]

If you use HTML5 export, JavaScript garbage have to be managed.

[Filler]

The HTML compiler is a pain to get working.

Anyways, just unloading the GUI menus with atlases saved 20 MB of ram. So I'm pretty sure that's the next step on working on stuff just so that it runs a tad better.

[Filler]

Memory usage has been cut by almost half with atlas use, but the CPU usage didn't lower that much.

At least I know it's possible to lower it by quite a bit.

[iyenal]

The CPU usage is caused principally by physics and collision. Maybe simplify collision polygons.

[Silversea]

For my games with extensive object use I ran a script that disabled scripts and objects outside the viewing area. Consequently I then needed a second script to enable anything outside the area that /did/ need to still run, but it cut my memory use by nearly 2/3.

[Filler]

Never preferred that method, as it makes things seem less natural. As you know the world only exists when you're in the screen.

I'd rather prefer a bunch of smaller zones with objects that are always active. The only way I'd do the script disable when off screen method is if there's a room with a point of no return.

Anyways, got the game's introduction written up, as I wanted to keep it simple.

Quick edit, my next update to the codebase will be killing off the massive amount of "If/otherwise" scripts that bog down CPU usage.

[Silversea]

Another thing you can do is change the timing of if/check statements. For instance, depending on how you do it you might find many scripts are running every single frame when they could be running every 5 or even 10 frames with no ill effect.

[Filler]

That's true.

Most of it can be massively cut down, though.

For example, instead of having a massive hierarchy of if/otherwise statements for player movement. I could do a single, simple if statement that checks if any of the movement keys were pressed, and applies X/Y speed based off variables. Below the script could be 2 if/otherwise if statements that change the X/Y speed off what keys were held down. It's far more shorter in terms of code than the method I have right now, and less checks are involved.

For example, my original movement code was 700-something lines long (Judge me for being a bad coder, please). While this new one is far smaller.

/* ======================== When Updating ========================= */
addWhenUpdatedListener(null, function(elapsedTime:Float, list:Array<Dynamic>):Void
{
if(wrapper.enabled)
{
if((isKeyDown("right") || (isKeyDown("left") || (isKeyDown("down") || isKeyDown("up")))))
{
if(isKeyDown("up"))
{
_Yspeed = asNumber(-10);
propertyChanged("_Yspeed", _Yspeed);
}
else if(isKeyDown("down"))
{
_Yspeed = asNumber(10);
propertyChanged("_Yspeed", _Yspeed);
}
if(isKeyDown("right"))
{
_Xspeed = asNumber(10);
propertyChanged("_Xspeed", _Xspeed);
}
else if(isKeyDown("left"))
{
_Xspeed = asNumber(-10);
propertyChanged("_Xspeed", _Xspeed);
}
actor.setXVelocity(_Xspeed);
actor.setXVelocity(_Yspeed);
}
else
{
actor.setXVelocity(0);
actor.setXVelocity(0);
}
}
});

}

override public function forwardMessage(msg:String)
{

}
}

It's neat, and clean. And if you're wondering what it looks like in visual code mode, it's just as clean.



EDIT: This script could be even further optimized by running it so that it detects only when keys are pressed, instead of using an always updating script.



While it looks longer, it'll use less memory as it doesn't check every frame. This doesn't support cornered movement, yet.

[Filler]

Since most of the updates are going to be about writing, which I assume most don't care of, I'll talk about the game's struggle of early development.

Development of the game started early 2016, and most of that was development hell in concepts. I had the writing and concept art done, but I didn't like how it went due to me having some harsh standards myself. Almost all the concept art was scrapped, as I decided to reuse what I thought would work. Here's a small sample of the original game's concepts when it was very overblown and filled with issues.

Here's a room. This one got far enough to have the basic layout made in-game.





The abandoned prison was going to serve a major plot point for a NPC, it was cut 100%. It was going to contain you looking around various rooms to find switches to open vairous doors. You also had to explore the dark basement with little light. It was cut for having no real relevance to the game's plot other than filler to move things onwards.



Bottom floor of a house.



One of the rooms in that house shown above. This room got far enough into development before the restart to have it's own room fleshed out.





Early town.



Earlier sprites were more rough, with flat colours and a more MS Paint quality to them. (I still use MS Paint to make these sprites funny enough. But they're far less rough)

[Silversea]

Having external anti-aliasing is interesting, I don't think I've ever tried that before (except for sprites that are strictly on only one background colour).

[Filler]

It's interesting, but not really effective.

You don't have to do it with the grey pixels like how I did, but pixels that are transparent work, too. Personally, I'd avoid doing it unless it's apart of the artstyle.

[Filler]

Usually when making map concept art, I tend to do really rough layouts. These are placed in the writing document of the game itself so I get a feeling of what should go where.



This is suppose to be a camping area that a NPC couple reside in. There's a small cutscene of them chatting involved here.

Afterwards when It's time to polish things up, I do them in the more professional hand-drawn style I did above.

[Filler]

I haven't been in the mood to make game stuff lately since I've been in a negative slump.

I'll probably resume in like a week or so to chill out.