megatronx

Hehe, you live and you learn, that's how it goes!

I keep trying and testing to get features to work exactly as I want, even if its unorthodox or "hackish".. I only care about the end result.

Also, there is plenty of other weird quirks. Right now I have object that uses rotate plugin, and it is suppose to shoot every x seconds and when is in between angles. It does shoot, however the projectile with bullet behavior only moves at 180 degrees instead, even thought of having the angle of motion set to spawning objects angle. What to do? Sorry to say, but this is irrational.

Use set angle on your projectile rather than set angle of motion. There's a few things like that which once you figure it out, it's understandable why.

Let me take a screen from my own example, I hope it makes sense:

https://halfgeekstudios.files.wordpress ... /09/00.jpg

It's a shotgun, 8 round blast in a cone from the gun.

> JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine

>

Most modern Javascript engines use just-in-time (JIT) compilation to machine code. They use a flow something like script -> bytecode -> profiling -> machine code generation. This means well-written Javascript gets "truly" compiled and can reach pretty impressive levels of performance.

I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

Nitro-JIT engine.

I notice it performs very close to Chrome on PC, ie, similar cpu usage for my test games, which is rather insane when you think about how powerful an Intel i5 or i7 is compared to what's on an iPad Mini 2.

Why do you think its higher quality if you add a bigger image but then downscale it in-game?

An sprite of 128 x 128 looks good with an image that's 128 x 128, as good as an image that's 256 x 256. It may even look better due to down-sampling losing some details (blurry).

> I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

>

The engine already does this automatically on a layout-by-layout basis. The problem with adding more control over this is you create the opportunity for mistakes in memory handling to actually make things worse and use even more memory, or you rely too much on mid-gameplay texture loading which can cause serious jank, which is something everyone wants to avoid.

[quote:3rdo5u6u]The biggest limitation I see currently is single-thread logic.

See Why do events only run on one core? The blog post goes on to detail many features which modern browsers (and our own engine) run multithreaded.

I know the engine already does this per layout, but the option to do it manually for a sprite that we want when we want it is what allows more flexibility. Sure, people can mess up if they don't know how to use it, but that's a poor excuse to not have that level of control at all.

I'll give you a basic example of the jank that people notice in C2 games. When a layout is changed, everything prior is flushed to gc, a new layout is started, sprites are spawned etc, but they are spawned fresh when called in the first time in that layout, so creating a big sprite or one with many frames cause a visible stutter. Why? Because it has to be loaded from HDD and as its not present in vram.

If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

Multi-thread is difficult to get it to work well, big engines have it and little engines don't.

It's up to you guys for C3 if you want to be part of the big boys or not, its bluntly put but that's reality, I see it all the time when devs talk about game engines and compare them on forums and reddit. I regularly defend C2 on r/gamedev! Single-threaded on JS which incurs extra overhead is a limiting factor. Most C2 users wont ever hit that ceiling but it's lower than other engines and much lower than big engines that support multi-core CPUs well. So it's a question of how grand do you want your engine to be capable of?

You can do the bar to any variable, global or instance.

If instance, you have 2 instance variables for your player sprite.

1. Health

2. HealthMax

Set the bar width to ((Player.Health / Player.HealthMax) * 100)

If you use C2 for mobiles, its vital to start testing performance on mobiles from the start. Use the cpuutilisation to check on your target device, this way you know when you add some new features and it drops performance (cpu usage jumps up), you know that's to be avoided.

Some behavior or effects hurt performance a lot on mobiles. I posted awhile ago with a short list of things to avoid.

The logic and collision still functions for invisible objects.

It's how I often do AoE explosion damage, by spawning an invisible sprite to test for collision.

For mobiles or PC?

If for PC you don't need to worry about those things in general until you have a very massive game. Ashley is keen to tell people not to waste time optimizing, its true for most cases.

For mobiles, always test it and see which runs faster. Debug, profile view, look at CPU usage and compare for yourself.

caad8user

In your specific case, you need two variables. Player_HP and Player_HPMax. Both starts at 100.

Set HP bar sprite width to ((Player_HP / Player_HPMax) * 100).

When you upgrade, raise the Player_HPMax to 300. So if the player health is 100/300, the bar width is 1/3 of 100 pixels only. Until you raise the Player_HP.

You can also apply that to enemies or npcs too if you want to scale their health but keep the bar the same width max.

Hope that helps you.

megatronx

Your desire for better pathfinding or smarter pathfinding is in fact seeking the holygrail of RTS AI. Many many big-time RTS still struggle with smart pathfinding. What they achieve, it's all logic from "hacks and work-arounds", thinking outside the box.

I doubt we will ever get a smart pathfind AI out of the box. It's gonna require a lot of logic.

I don't mind work arounds or hacks to get things to work, but I do mind some major technical limitations.

I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

The biggest limitation I see currently is single-thread logic. JS/HTML5 has higher CPU overhead and we're limited to 1 thread when modern CPUs have 4-8 is quite backwards. Yes, multi-thread programming is very difficult. But other game engines have MT functional, even Unity these days are moving to DX12 and multi-thread native.