Arima's Forum Posts

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • github.com/brownhci/WebGazer

    Hey, neat! If I get a webcam I'll try that out. It seems to be a lot less accurate than the head tracker I've got, but it would still be useful for web browsing and such. Thanks for the link!

    Is it going to be ok man? Are your hands going to recover?

    Hopefully they'll recover at least somewhat, but since originally hurting them in 2005 they haven't ever healed past the point of being able to do a small fraction of what they used to be capable of each day. I've been to a bunch of doctors, including hand specialists, and their responses have been either to tell me they don't know, misdiagnose me saying they would just get better, and when I went back to one after they didn't, was accused of lying about how much pain it was causing me. So at this point, unless they invent some new treatment I'm not counting on it.

    Thanks Kyatric, it's nice to be back.

  • Hey, Alspal! Yeah, I needed a break from gamedev for a while but I'm having fun again. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    Sorry for what you are going through.

    But, can we get a video of how you use it? I am reading through how you use Construct (and a computer at that) and it sounds really intriguing. I'd love to see how it is all done.

    Hmm... I think it would be easiest if I just link to what I'm using rather than record a video myself.

    The head tracker: http://naturalpoint.com/smartnav/products/4-at/

    Here's a video of it in use. I don't like sticking a reflective dot on my forehead, so I use a hat instead. Once you get used to it and adjust the settings it's a lot faster than the speed they show as well. It also shows one of the keyboards I'm using for a moment at 28 seconds in:

    Subscribe to Construct videos now

    The keyboard in the video works great for inputting small numbers or words, but for anything longer like expressions and such I use dasher: http://www.inference.phy.cam.ac.uk/dasher/

    It works like this:

  • Ashley Tom and the rest of the scirra team

    I thought you guys might like to know that I've discovered that I can reasonably comfortably make games in C2 without using my hands.

    Because my hands are injured, I've been using a head tracker, dwell clicker and two different on screen keyboards. It definitely requires some patience as it's nowhere near as fast as using my hands, but it's a big step up from what little I was able to do before. There are obviously some tasks I need my hands for like making graphics, but for the vast majority of the work using C2 itself, it seems like I can use it pretty well!

    That said, there's one thing in particular that would really make it easier. On the event sheet, clicking below the scroll bar only scrolls down a small amount. In almost every other program I've used, like web browsers, clicking there scrolls almost a full screen down, leaving only a small amount of what was previously at the bottom of the screen then at the top. As it is, I have to keep clicking repeatedly, which requires a head turn each time, or switch to dragging mode with the dwell clicker and then back again, which requires extra head movements as well - not an issue when doing it a little, but scrolling around the event sheet happens a lot.

    Could it be changed to mimic the standard behavior of most programs? Or could it be made an option to set how far it scrolls? Then people could keep it the current way if they like it as is.

    Optimally, I'd like to be able to set the scrolling distance of the arrows at the top and bottom as well - currently clicking on them barely moves the event sheet at all. Being able to set those both independently would make it useful for when I don't want to scroll the whole screen.

    Another thing I think could be a good UI improvement, though less important, is to make use of the empty space to the right of the 'add action' links at the bottom of an event's actions. There's no link for adding anything else, and that seems like a good spot to use for it - the icons listed in the menu when right clicking an event would work perfectly there, so instead of 'Add action' it would read 'Add: (icons here for all the stuff in the right click menu, like condition - action - event above, event below, subevent, blank subevent, comment, group, variable, toggle disabled, etc). Mouseover could display what the icon does if people aren't sure.

    I know my situation is unusual, but I actually wanted it to work these ways anyway when I was able to use my hands, and I think it would be better for users in general if at least scrolling mimicked the behavior of most programs.

    I also understand you've got a lot to work on, so I understand if you can't implement features like these that would most benefit probably one user.

    I want to say how grateful I am for the work you're doing - I was really going out of my mind with such limited ways to express myself until I realized I could do this again, so thanks for making construct. It's helping me get my sanity back.