Ashley's Forum Posts

  • Javascript errors are bugs, you should make a post with a .capx in the Bugs forum.

  • I'm relatively open to the idea of inline scripts like Classic had, but using Javascript rather than Python. The main reason it's been held off is firstly time (as always), but it's also easy to accidentally use platform or browser specific features that break your game's portability (especially with non-browser engines like CocoonJS), or use new javascript features that aren't supported everywhere yet, or just write code that accidentally creates tonnes of garbage and ruins the game's performance. So there's really a lot to go wrong there (and it's partly why I held of for a pretty long time before even just adding execution of javascript strings via the Browser object). The fact C2's engine is well-optimised, low-garbage, and well-tested on a broad range of platforms are nice features IMO, and custom scripting lets you break that (as do third party plugins, actually). But I guess the fact a tool could be used wrong is not a reason to prevent anyone using the tool, especially if it can be used educationally.

    FWIW, all the "built-in" plugins and behaviors except the System object are written in the same Javascript SDK that third party devs use. So it's really capable of everything.

  • HTML6 is probably years away. But if it introduces anything useful for games, we'll probably support it. I've heard talk of "HTML 5.1" which seems to be the next standardisation project.

  • If you import images with 16 colors in to Construct 2, does it manage to export them at the same reduced size? (The exporter does run all PNG-8s through PNGOut).

    I'm not sure about the implementation of an optimal quality palette reduction, so it might be better to do this in external tools then import them with their colors reduced.

  • I would say "Self.X + Self.speed * dt" is not programming, it is only an expression. It's closer to maths than programming. I don't think the fact it contains the word 'Self' changes that, because it's just a way to tell C2 where to get the variable, so I think that keeps it in the realm of maths. We could disallow anyone from typing in syntax like that, or use a patronising block system where you first have to drag in a multiply block, then the dt block, then the Self.speed block, and so on and on. I think both options are clearly inferior. Anyone with a basic grasp of math should be fine using the typed expressions. There are lots of advanced expression features, but you don't have to use them - if you like you can just use things like Sprite.X + 1.

    I would agree that "no programming required" is not strictly true, since the event system allows things like recursive functions, local variables, and loops. However I do think it's the most succinct way to describe it to new users. A more accurate line would be "no traditional programming required", but simply from a marketing point of view we think it gets the point across more clearly saying "no programming required".

    The point of Construct 2 is it makes game development accessible. Drop a sprite in to a game, give it the 8 direction behavior, and run it in a browser. To code just that by hand, you need a good knowledge of the javascript programming language, including its syntax, performance issues, quirks and gotchas; you need to know a bit of HTML and CSS; setting up the WebGL renderer and asset loading in a memory-efficient way requires technical knowledge of how GPUs work; how to make an identically-drawing canavs2D renderer to fall back to when WebGL is unavailable; you need to know how game loops work, how to accurately measure delta-time, how to receive user input; how to do everything so far while dealing with cross-browser quirks and differing feature support; probably how to use a simple code editor and the Chrome dev tools debugger, how to configure a local HTTP server for testing, and probably a few other things I forgot. Construct 2 lowers this barrier enormously, and the example I just gave truly does not involve programming. Construct 2 makes it deceptively easy - you might see the object moving around with arrow key controls and think "what's so hard about that?". Potentially, there's a lot hard with that, if you're coding!

    • Post link icon

    You should never edit the source of the official plugins, you will cause really annoying compatibility problems for yourself. Isn't it possible to read the data on the server-side and convert it to JSON even with that MIME type?

  • You do not have permission to view this post

  • There are lots of tools out there to help programmers - just look up a list of how many HTML5 game engines or SDKs people have made. My impression was that if you wanted to code, you could just do it yourself in Chrome with notepad or the like. However I guess I'm underestimating the utility of the WebGL renderer, animations system, layout view and so on. Those are great, but also easy to code around (although much more time consuming). Basically, we're a small team and we wanted to make a different tool that helps ordinary people get in to game development, rather than yet-another-programmer-IDE.

  • Or use the Array object?

  • If display glitches are involved, I would put money on it being a graphics card driver bug. Your best bet would be to report it to AMD.

  • Yup, it's already on the todo list, been asked for a lot!

  • For a very rough ballpark, Javascript is generally slower than C, but is amongst the very fastest of dynamic languages. Very few languages have had the same amount of immense engineering input into optimisation as Javascript, with entire teams of coders at Google, Mozilla and Microsoft all competing to make the fastest engine.

  • Disabling image deduplication wouldn't fix sprite font. Sprite Font should be working in the next build anyway.

  • irina - can you post a new bug report for that?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • We don't intend the UI to be completely logically consistent under all circumstances. Rather we aim for it to do what you want it to, or expect it to, even if that's not logically consistent with other actions. For example the usual action of double-clicking is to do the most common action, not just to edit. Editing is the most common action for actions and conditions, but expanding/collapsing is the most common action for groups. That's why that one example is that way around. I'll take a look at the other things you mention next week.