is the development still on-going? Arima

— I ran into some design issues that I was having difficulty working around, like how stuff offscreen is important to keep tabs on but how is the player supposed to do that if the stuff is offscreen? I put the project on hold while trying to figure it out and focused more on a novel I've been writing in the meantime, but I think I might have answers to the design problems and have been feeling like trying to work on it again lately.

I know I work at a glacial pace, and it's not by choice, but I still want to make Loot Pursuit in some sort of way, even if I have to scale back the scope some amount.

But yeah... it's going to be a while before I manage to get it to a presentable state.

— To get the 3D effect and collisions I use the three objects - the first is an invisible base that represents the ground location. I put it into a family with only itself, and all variables and behaviors given to the base have to be given through the family. That makes for easier picking when comparing one base vs another. It has the variables z and zmodifier, which controls the elevation and speed on the fake z axis. There is an action to subtract the same amount from zmodifier every tick that simulates gravity.

The second is the object itself. It's placed at base.x, base.y-base.z. Likewise, all variables and behaviors should be applied to this object through a family.

Third is a shadow sprite placed at base.BBoxLeft, base.y and the width is set to object.width. If you don't care about the shadow being accurate you can make the base be the shadow instead.

All the objects have the UIDs of the objects they're paired with stored as variables (base.objectUID, object.baseUID, etc). This is necessary for the collision check.

To check for collisions in 3D space, check if base is overlapping basefamily. If so, then as a subevent, for each base check again for collisions with basefamily. That will pick the specific bases that are colliding. Then pick the objects the bases are paired to via the stored UIDs and check if they are overlapping each other. If they are, that's a collision in faked 3D space.

The method isn't perfect alone because it's faking 3D. For example, if I have a laser beam that's one long sprite aiming from high to low elevation, but visually is shooting up or down, it'll register a hit in places where the laser should have missed. To rectify that problem, all that's required is breaking up the object into multiple smaller pieces to check collisions with.

I hope that's clear -- it is some complex picking and collisions, but it works great.

Paradox Thanks. They aren't particles, I used a bunch of normal sprites so I could have more control over how they behaved.

Paradox

Thanks! I'm going to make the proof of concept demo public. It's quite playable already, but the main issue is a lack of content - it doesn't give a good idea how anything past a single battle would play, and the game is supposed to be much more than that. Still, it might be a good idea to get incremental feedback so I might change my mind, but at bare minimum I need enough of a basic level to have a tutorial explaining how to play.

As for the floor, I did add the checkerboard texture in the most recent gifs on page 2, I'm not sure if you saw them. In retrospect, I should have added it before making those first gifs.

There is going to be lots more stuff in the levels, but I've actually already got holes in the floor implemented:

Hitting an enemy into a pit instantly defeats them, but enemies can hit player characters into them too, and if I can figure out how to code it, the more intelligent ones will try to do so intentionally. This gif also shows how aim is important, or you can blast an enemy straight over the pit entirely.

Player characters and some bosses have warp crystals to protect against threats like these. Warp crystals can be used once and automatically teleport the unit back to the spot they last executed a command, make them invincible for short time and might restore a little HP and SP, as shown here with a new enemy: the wizard slime, which shoots magic bolts and explosion spells.

Some enemies can't be hit into pits, mainly the ones that fly.

As for party size, most of the game is designed for two characters with an occasional third joining in. The reason for that is because of how all the action happens simultaneously - it would just be too much to keep track of at once with any more.

I was wondering about this. The 'is downloading update' and ‘on update ready' conditions were useful, why don't they work for the new method? I don't want the user to have to open the browser console to find out that information.

The closest you can get is by running C2 on a PC then use remote desktop software on the iPad. I've used splashtop before and it worked a lot better than I expected.

Lol, yeah, I think there are other badges doing this too. Paging Tom

Enemy collisions

Nw.js dropped support for both vista and XP. I'm stuck on C2 r230 because of it.

As for long export times because of other platforms, you can browse to program files/NWjsForC2 and delete all the folders aside from win32 and win64 which are the only required ones.

I doubt there's a good way to implement that. One problem with the method you describe is that it would require constant switching between C2 and the debugger to check which event is which. A much simpler solution is for you to just code something into the event you want to watch with that never happens anywhere else in the event sheet. I generally rotate a part of the UI.

This method is also better because then you can tailor the visual feedback to what works best for you. For example, I sometimes create debugSprites (a basic yellow square) at the locations of specific instances which reveals which objects the event was using.