It does, but I'm afraid I don't know the answers.

I've found C2 is quite good on the accessibility front already, so much so that with the help of a head tracker and a couple virtual keyboards, I can use everything in C2 without using my hands at all.

I don't know what you mean by alt on img or button? I don't understand what you mean by your second question either. Access them how?

There is, I just haven't gotten around to it yet.

Most recent update September 29:

Loot Pursuit is a lighthearted, humorous simultaneous turn-based RPG with a battle system sort of similar to Grandia where you can mess with your opponent's actions and has an environment inspired by Zelda and Mario that has a strong influence in the battles.

It's a little difficult to explain, so I've got some gifs! The game is still very early in development so I haven't nailed down all the mechanics yet, but this is some of what I've got so far:

One click to attack

Dash attack to hit the enemy harder and further

Hit enemies against walls for extra damage

Instead of only having stats determine the outcome of an incoming attack...

...players have multiple options, such as hitting the enemy first...

...dodging to put the enemy in a position where it can be hit against a wall...

...or one character can protect the other.

Spin attack to hit multiple enemies

Not so good against singular opponents...

...unless...

Traps can hit enemies too! Use them to your advantage!

The design philosophy is this: I love turn-based battle systems, but think there's a lot of untapped potential. Strategy RPGs add unit location and attack range to the mix, but I don't think they go far enough. It seems like all the innovations developers make aren't what I want in such a system... so I'm making it myself.

I'm trying to make the abilities have multiple uses and strategic benefits in different situations. Using a spin attack next to a wall is just the beginning.

It's designed to be a small game so I don't get in over my head with more than I can manage. It's got plenty of potential for sequels or using the battle engine in another game with different characters if I want to do more with it.

I actually got a previous version of this game about 90% complete a while ago, but it was very different and was the first game I ever tried to make, so I made two main mistakes with it - the first is it was too complex for a first game and my code became utterly unmanageable so eventually everything I fixed broke something else. The second was that there wasn't enough variety to the gameplay. When I attempted to make Shards as a video game I tried to fix both those problems, but I went too far in the other direction while designing it, and the gameplay turned out to be too technical to be fun.

With Loot Pursuit version 2, I'm solving that problem by this time not trying to make such an accurate simulation of battle, and instead am building upon tried and true game mechanics.

One of the big factors in my decision to redesign Loot Pursuit rather than use a different setting is that I already have most of the character sprites needed for it, which means a lot less hand usage will be required for the graphics (my hands are injured, so having most of the character animations already made helps a lot).

Injured hands? How am I making this then? Aside from the graphics, about 99.9% of the work has been done with a head tracker. It's too clumsy to draw with, but I can use C2!

The primary target platform is PC and it's intended to be played with a mouse (or head tracker like mine), but I hope to be able to put it on mobile and maybe Xbox one if I can figure out how to get it to play well with a controller instead of a mouse or touchscreen (the interface in the screenshot is an early version of the mobile design, I haven't decided the best way for the PC UI to work yet). I'd like to put it on mac and linux, but they depend on the state of nw.js which will hopefully have its kinks ironed out by then.

Something I've also learned is that even if something seems like it would be fun to play in your head, it can be different than imagined when made real. Because of that, I am currently committing only to a prototype to find out how it plays. If it's fun, then I'll keep working on it.

Yeah, I've got that bug too. I guess I'll keep searching the web for answers.

Hmm... if that's the case it's not obvious. I suspected something like that might be happening, but I didn't think it was by design.

Ashley if you're not going to change the way it's coded, perhaps a note should be put on the set speed action of the bullet behavior's manual page? If this has been posted about multiple times before that would make it clearer.

Problem Description

The angle of motion of the bullet behavior is affected by setting its speed to 0.

Attach a Capx

http://www.amirai.net/bugs/bulletdirectionbug.zip

Description of Capx

It has three events. Preview three times with only one of the events enabled at a time.

Event 1 works properly. The white sprites move in the opposite direction of the grey one.

In event 2, by setting the bullet speed to 0 before setting the angle, the white sprites move either left or right.

In event 3, moving the angle action after the second action to set the speed overrides the bug and it works properly.

Steps to Reproduce Bug

Open the capx, it should have events 1 and 3 disabled, and 2 enabled. Preview.

Observed Result

The white sprites move either left or right.

Expected Result

The white sprites should move in the opposite direction of the grey sprite.

Affected Browsers

I know the list of browsers I can test is sub-optimal, but it's the best my computer can manage and I'm confident it's not a browser bug.

• Chrome (out of date, the newest versions don't support my computer anymore): (YES)
• FireFox: (Can't test it, Firefox doesn't work on my computer for reasons I don't understand)
• Internet Explorer 8: (YES)
• Nw.js v0.15.0 (v0.16.0 doesn't work on my computer): (YES)

Operating System and Service Pack

Vista SP2

Construct 2 Version ID

231

I've got the newest C2 beta, r231, and it required me to upgrade nw.js. Even previewing a blank capx, I get this error when it starts up:

• --------------------------

nw.exe - Entry Point Not Found

---------------------------

The procedure entry point PowerCreateRequest could not be located in the dynamic link library KERNEL32.dll.

---------------------------

OK

---------------------------

I wanted to check if anyone else is having the problem before posting a bug report. I'm on 32 bit vista SP2.

Oh right, yes, that was a limitation. But then in theory your filtering has already reduced the list of candidates that need to be tested for collisions. Or are you picking large numbers of instances first? That could effectively disable the optimisation, but if it's really bad it should be possible to rearrange events to do the collision-cell enabled check first.

Possible, yes, but it can be messy and runs backwards to all the other logic as I mentioned before. The point really is just that any cpu cycles that can be saved frees them up for other use elsewhere, and if it wouldn't be that much work - and I acknowledge that I have no idea of how much work it would actually be - why not?

Not really, like asm.js it's setup in a way that can be more directly translated to machine language by the javascript engine. So that's where the native performance statement comes from. Who knows, it may allow for more efficient machine language to be generated. But I don't imagine significant speed improvements in most cases, because generating machine code is nothing new for a javascript engine.

I guess we'll just have to wait to find out.

Is it a separate exporter that requires rewriting plugs?

Would it require any third party wrappers?

What platforms would be available?

As I understand it, it's an addition to the web spec so exporting wouldn't change. If I recall correctly, I think it is backwards compatible even with browsers that don't support it yet by using javascript instead.

What exactly about the event system is slow if it were compared to what webAssembly would do? Or is it just everything in general?

I think most things written in it would just be faster, as it's inherently faster than javascript.

Actually, it's very similar to asm.js and probably has similar performance characteristics. The main draw over asm.js is the code will be more compact in size, but I'd have to see an example to see by what margin.

That's a bit frustrating and feels somewhat misleading of them to call it native performance if that's true, but regardless getting the event system up to asm.js levels of speed would still be fantastic, even if it's not truly native speed.

Mainly I was comparing it to a major limitation of asm.js, where by default you get a fixed amount of memory, and that's it.

Wow, that's... a bit odd. Glad to hear webAssembly fixes that.

[quote:cyszn4yy]Collision cells are an automatic internal engine feature and it doesn't need you to do anything different, so what exactly is difficult/infeasible/complicated about that?

I thought they required collision checks to happen before any instance filtering occurred in the event sheet? Most of the times I need to check collisions it's after filtering has occurred. Doing it the other way around is basically backwards from my entire code tree because I keep needing to check collisions in different ways and different times due to the complex behaviors I'm trying to make. I do my best to limit the number of checks via the filtering, but when doing enough loops or such, it always helps to have more speed that can free up the cpu for tasks elsewhere.

Also, after seeing your tweet about a quarter million sprites at 30 fps on a GTX 1070, any concerns I had about draw calls have been alleviated. XD

Still, even if it is just the event system, I could definitely make use of it.

Let's keep this thread about webAssembly itself - the native export discussion is another topic that's been discussed elsewhere.

What is webAssembly?

An oversimplified explanation is it's a new technology for the web that loads faster and claims it'll run at native speed.

In addition, unlike other such attempts in the past, this one is being worked on by Apple, Google, Microsoft and Mozilla so everyone's actually going to support it.

Though there's still a lot of work to be done, it's not all that far away, either - experimental support is already beginning to appear in browsers.

Ashley has expressed interest in possibly rewriting the event system to use it if we want it.

Ashley - I'm very happy to hear that you're open to the idea of rewriting at least parts of the engine in webAssembly - I had been considering making a thread to ask about it earlier until you mentioned it in your blog. I do a lot of intensive stuff with events, so if construct 3 has that it will make me very interested to upgrade.

I suspect the reason more people haven't expressed interest in it yet is because it's so new they don't know about it since the implementation hasn't even been completed yet.

I have a few questions about it, though:

• You said it brings improvements to memory management - does that mean we as users would get more control of loading and unloading things like textures from memory?
• When you talked about the possibility of rewriting the event system in it, how far would that extend? Would that cover behaviors as well? Would people be able to make third-party extensions using it as long as they had the tools?
• In particular I'm interested in collisions - I have a lot of scenarios where using collision cells is either difficult, unfeasible or complicates my code, so any speedup there would be helpful.
• Rendering - I acknowledge my ignorance on the subject, but since webGL is written in javascript, it seems plausible that it could help with the performance impact of the draw calls or other such elements of preparing the scene for rendering, even if it wouldn't speed up rendering itself?
• Physics - because webAssembly needs to be compiled to from another language like C similarly to asm.js, would it be a comparatively simple task to compile the physics for webAssembly to get the 20-30% speed boost (if, of course, it's really that much faster)?

Who else wants native speed events?

Arima Welcome back. I just want to tell you that I'm really amazed by your determination. I hope your hands will get better soon and I wish you good luck with your projects.

Arima Hope you get well mate!

Thanks!

Any event sheet improvement ideas I've made in the past have been ignored/unresponded, I hope that won't be the case for you too, but maybe they're wanting to just wait and fix the editor for Construct 3 instead?

Maybe. I'm hoping my request is simple enough that it won't have to be put off that long, if they choose to implement it.