Arima's Forum Posts

  • It's mostly a toy for hobbyists.

    No, it's not. Just because not many have managed to make a living with it yet, doesn't mean it's the fault of the tool.

    While HTML5's platform compatibility gives you the ability to export to any platform, it never really excels at any of the platforms it works on.

    It's a jack of all trades, master of none.

    Most games don't need more than c2 provides. Even CC, which is native, doesn't have that much more capability than c2. Also, don't underestimate the value of the ease of porting. I'd take that over using a framework that's a 'master' of one platform any day, since it doesn't give that much more capability anyway.

    While you can make Android/iOS games from the same HTML5 project, both their performance and functionality are very limited. You have to work with really large limitations, both performance-wise and in terms of what you can implement in your games.

    That's true for all mobile games in comparison to desktops. Even though JavaScript isn't as fast as native code, putting an extra performance hit for the game logic on top of mobile devices's reduced power, if you design with it in mind and optimize you can still make fine games.

    You can export a project to PC as an .exe file, but you have very little control of the file system, and you're never running "native" - it works through a bare-boned version of Chrome called Chromium. While it's compatible with any PC out there, Chrome/Chromium tends to give different results on different PCs. For example, after applying a coloring-effect, a cloud appears Green on my PC and Red on friend's.

    You can read, write, execute, append, move, list, rename and delete files to disk via node webkit, as well as create folders. Most games won't need more file access than this, and if you do anyway, the SDK can be used to ake a plugin for it via the SDK. There are still issues with some webgl effects, true, but they can be reported and a lot of people are working to get them fixed. Also keep in mind that even tools used by AAA game studios have bugs in them. Writing a cross platform game framework is quite difficult when it's expected to run on tons of different hardware configurations and software drivers.

    WiiU is something that is in the works of being implemented, but really, who has a WiiU anyway?

    Something like 4 million people who are starved for games on the system. It might not be enough to develop exclusively for, but it certainly wouldn't hurt with how easy it is to port to other platforms.

    Ouya - Look at android section.

    I read that cocoonjs has plans to support ouya.

    PS and XBOX have we no news or info about.

    Microsoft has stated win 8 apps should be able to run on Xbox one, so it's likely that will work with c2.

    All that said, it's still a hobbyist tool. I don't think i've heard of anyone earning more than a few hundred bucks a month with Construct 2 Games/Apps. And there's less than a handful of people doing that.

    There are people making a living using it. Also keep in mind games take a long time to make, even with a tool like c2 that does a lot of the work for you.

    Anyway, the point is that html5 is still pretty new, and is improving. There are a lot of people at a lot of different companies working hard to improve it. It may have some issues now, but they should be ironed out relatively soon.

  • You do not have permission to view this post

  • Yeah, and you can put a variable in an array in a hash table in another variable in a -

    (Resists temptation to post an inception 'we need to go deeper' image)

  • You can avoid the performance hit the canvas object causes with webgl by keeping it invisible, pasting to it at the start of layout, the having a sprite load its image.

    However, it's been around long enough and still not gained webgl support that I have to agree - it would be nice to have a webgl compatible canvas plugin.

  • You can accomplish this by finding the path to each instance, and for each path found cycle through the nodes, adding up the distance between them to find the total distance.

    Mind you, this is a bit tricky to do. But it can be done.

  • Link to .capx file (required!):

    amirai.net/bugs/turretaimingbug.zip

    This is a light modification of the predictive aiming example. All that was changed was upping the rotation speed of the predictive turret to 10,000,000 (trying to get instant rotation) and reducing the range, as well as automating the movement of the player sprite.

    Steps to reproduce:

    1. Run the capx.

    Observed result:

    When the player sprite enters the range of the predictive turret, the first shot always misses.

    Expected result:

    The first shot should aim correctly with the others.

    Browsers affected:

    Chrome: yes

    Firefox: yes

    Internet Explorer: yes

    Operating system & service pack:

    Vista

    Construct 2 version:

    140

  • I'm pretty busy but if it's not too much then sure.

  • As Ashley mentioned, families are treated the same way as other objects, so the for each tutorial should work fine for this if you read it and imagine I'm referring to a family rather than a sprite.

  • I've been debating this very thing in one of my prototypes. At first the button was a simple directional dash that the player could only control the initial direction of, but I found it to be a bit difficult to make the character move exactly as a wanted. I then modified it so that all it did was increase the speed and the player could change directions at any time and it controlled much better, but then there was no reason not to use it and it would have resulted in players always holding it down as you mentioned. Still not sure what to do about it. :/

  • I'm actually not 100% sure of how it works, but I think it's like this:

    At startup, all code and images are loaded into memory, but the images are left in a compressed state.

    At the start of a layout, necessary images are decompressed for rendering and unnecessary decompressed images are removed from memory, but their compressed versions remain.

    I could be wrong about that - best to get Ashley or ludei to comment.

  • The stuttering at the start is a result of chrome compiling the JavaScript in the background so it will run faster. It starts displaying the game before it's done so people can start using it quicker.

    We had the debate about a native exporter a while ago, but it doesn't seem like it would be worth bothering with (C2's code execution speed is plenty fast for most games, especially on desktop, and it actually renders faster than construct classic does, which was native dx9). I really doubt it would improve stability any - google's got an army of programmers to throw at chrome, and as such it's quite stable as it is.

    As for flash, it's still a capable technology, but it has a lot of problems (stability in particular, it crashes often on some people's systems/browsers), and both iOS and android don't support the flash player though AIR apps can still be made. It's steadily being replaced by html5 - even adobe seems to be basically admitting that html5 is going to take over by making tools to convert flash to html5 and discontinuing development of it for android.

  • Cocoonjs implemented webgl, which should improve the situation by using layout by layout loading. There are currently some fps issues with it on iOS right now though.

    I agree an option to wait on loading anything from disk until loading the layout that heeds it would be nice.

  • wizaerd - in one of scirra's blogs they tested c2 and got about 150,000 instances on screen, and they could have had more, but they were checking how many they could have on screen at 30 fps: https://www.scirra.com/blog/102/html5-games-faster-than-native

  • Please stick to English on the forums or provide a translation, thanks.

  • Use [tube].

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads