Sorry if this is messy its just my thought process. I cannot check your CAPX because Im still on an older C2 version for now.

Here's a quick example of moving on Y axis with DT to give it a smooth transition (attached).

200 * dt = 200 pixels over 1 second, but it moves per frame so its smooth.

You can have your enemies trigger to move up or down using that and some variables/booleans. Here's how I would do it if not using Pathfinding.

For example, your ground combat area has 4 Y-axis Level (1,2,3,4) you want enemies to travel to corresponding to 500, 550, 600, 650 on the Y axis.

You do a check, Player.Y < 500 (Trigger Once) = Set global variable Level 1. And same for setting Level 2, Player.Y < 550 & > 500 etc.

Add a trigger for your enemies. Level = 1 & Enemy.Y > 500 = set Enemy.Y to Self.Y - (200 * dt)

Your enemy will move up gradually until he is on Y-axis 500 then stop going further up.

If your player moves down, it will trigger the global variable Level to be 2. Then you have another movement trigger for Enemy, Level = 2 and sub-events Enemy.Y > 550 as well as another sub-event Enemy.Y < 550 (above and below 550/player Y) to move enemy up or down to match the player Y axis.

If you combine it with Bullet Behaviour for X axis movement (angle of motion 0 or 180), the delta time Y axis will cover their Y axis movement for you.

I hope that makes sense, it should work.

Edit: Oh and for your 2nd point, you want enemies in close combat range to always maintain constant Y with player, just do a distance check.

Compare two variables, distance(Player.X, Player.Y, Enemy.X, Enemy.Y) < 100 = set enemy instance variable (melee) to 1/true and set enemy.Y to player.Y

Then filter out other far away enemies so they move up and down as above, by adding in a condition that check for Enemy.Melee = false etc before triggering the movement up or down.

Messy thought process, apologies.

Edit2: Actually if you just want enemies to spawn on their own Y axis and ONLY move toward the player in close combat to fight on the same Y axis, its even easier, just only use the distance check, set enemy instance variable Melee to true, and when its true, set Enemy.Y to move to Player.Y using dt.

It's best if you divide your path to 4-5 different Y levels you want enemies to be on. Then just do a trigger checking for player Y, if less or greater than a certain level Y, trigger a boolean on enemies to move them up or down to another Y level, the movement can be smoothed out as per tick add delta time pixel Y.

Or another approach is to do a pathfind behaviour, not to the player, but to another temporary sprite that you generate behind the player and call the update every few seconds to simulate enemies adapting to your player movement, but with a delay. I have a similar setup for my enemies in my Ninja fighting game (attached image), the black lines are pathfind boundary.

Pigs spawn on the right and if its at the 2nd upper path, they scale their size according to their Y over time so as they run down they get bigger. They run towards a spot behind the player. You can easily change where enemies move if you get to them pathfind towards a sprite which you control the spawning based on player X/Y. Obviously if they are on the left of screen, they mirror and flip the art to travel back etc.

I don't understand, if you want enemies to move up or down to the Player Y axis before moving forward, the player will just move up and down to prevent enemies from moving to attack him, no?

Otherwise you can do a set Enemy.Y to Player.Y every tick so they run up or down as well as towards the player (via X movement) and will match the player's Y axis... but then every enemy will be on the same plane. You'll have to filter it with some variables.

Hopefully some one else can chime in.

Integrated graphics from Intel (HD4000 etc) or AMD use system ram for vram so its actually not an issue as most of those come with at least 4GB of system ram for awhile now.

What you can make with C2 (as long as its 2D and not an MMO), is nearly always limited by your own talent.

1gb vram is on most discrete video cards, with many now 2 to 4gb. iGPU from Intel such as HD4000 uses system ram as vram so its not an issue.

There's already a few great C2 games on Steam via Greenlight. Mortar Melon for desktop also did very well.

Making games is fine and good, making a hit game is part talent, good marketing and a lot of luck.

OlivierC You won't have any issues with memory management with Intel XDK, its amazing actually, the only lacking feature atm is AdMob and IAPs which are coming soon (hopefully very soon!)

And Ashley is working with Ejecta to give it proper memory management, so soon we'll have both iOS and Android exporters that can handle bigger games great.

OlivierC

jayderyu

Excellent work and example there. I also agree with you guys, definitely for PC development, C2 is only limited by your talent.

Can only offer my own experience and results:

Big RPG physics shooter, heaps of stages, enemies, animations and big art:

https://play.google.com/store/apps/deta ... gacy&hl=en

Big RTS space sandbox:

You can do a lot with C2 on mobiles, just optimize it.

Also that blog is wrong. I use a lot of particles in my games, runs amazing even on dual core 512mb ram devices from 2010.

The killer to mobile performance from C2 is not animated large sprites, particles or big layouts. It's WebGL shader effects that come default in C2. They are all poorly optimized for mobiles (works great on desktop) and crushes even a Samsung S4.

Really good effort, keep at it! Soon we'll have both iOS and Android exporters that don't suck for larger games. Exciting times!

XDK doesn't scale graphics as nice to different resolutions, its slightly less sharp, but its not something that bother me since the difference is tiny. Also, XDK scales the actual resolution perfectly whereas CJS has issues with bars and such on lots of devices.