Fimbul's Forum Posts

  • This is all speculation, but from what Ashley has said in the past, I'm pretty confident that construct 3 will be an HTML5 editor, won't be browser based, won't be "in the cloud", won't be subscription based, and will remain a desktop app, with technology behind the editor probably being HTML5.

    This has several advantages:

    • Linux/Mac/Windows support out of the box
    • Fewer discrepancies between editor and runtime (such as shader bugs)
    • Code reuse (since everything will be javascript)
    • Better and more extensive API for plugin developers
    • More editor features (since we won't be limited by a third party GUI API like the one in construct 2)

    What will likely happen, and what makes the most sense, is that c3 will be a javascript app compiled in NWK (or similar) to turn it into an executable, with a decoupled "compiler" that spits out your games.

  • really tired of repeating it all

    I believe a stickied post or a blog post would help here?

    I mean it's obvious for you, and for forum regulars like me and others here, but many new users have never read the other posts, or at least they pretend not to. A sticky could alleviate that, I think.

  • I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

    Yes, but at the cost of development speed. Also I think "control over his own program" is a bit of a dubious statement. By giving up on code provided by browser vendors to work around limitations, bugs and incompatibilities between different configurations/hardware setups, you're absorbing responsibility for overcoming those problems yourself, polluting your codebase with patches. The way I see it, you lose even more control over your own codebase, since you keep having to put dirty hacks to make it work with another set of "third parties".

    Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

    The future (for now) is javascript, that much is pretty clear - the discussion is whether things are moving at an acceptable pace (you say they're not, I say they are). Unless something changed and I didn't notice it, tech such as NaCl and PNaCl aren't moving forward. Even if you think HTML is a bad choice, what other option do we have? Haxe is a pile of garbage documentation-wise, just look at their tutorials and try to follow along - it looks like a graveyard of broken changes - nothing ever works like the docs say they should, and even the standard library is unstable, not to mention the libraries/packages (which are third parties, btw). So what about a native exporter for Android? Well there's no such thing: android apps run on top of a virtual machine, and even before that mobile games used to run on j2me which is now extinct. I pity the ones who developed an exporter for it. Oh wait...

    Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase

    That's the whole point. Everyone wants that. Your choices are:

    • Haxe - broken spec, outdated/wrong docs, small community, not production-ready
    • Java - they haven't delivered on their promise of "write once - run everywhere" yet, why should they start?
    • Air/Silverlight/whatever - so, like, wrappers? Also, as you can see, they're all dead by now
    • HTML5 - big performance leaps every year, growing capabilities, multi-billion dollar investments, humongous community, and we already have dedicated HTML5 devices

    I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.

    The runtime already does nearly everything I want it to do, it's the editor that gets in the way. Developer time is much more valuable than machine time! When I making/use external tools to simplify development I feel like it's a huge waste of time, that I'm fighting the IDE more than being aided by it, especially considering there's no easy way to integrate tools to the IDE (without going through ashley, a la spriter) so you're forced to close the editor before using them (since they modify the XML directly). The interface is the biggest hindrance for gamemaking for the kinds of games I like to make.

    Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys

    Pictured: a modern mobile device compared to a modern desktop computer

    Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects, and hand-painted full-hd rotating backgrounds. Native isn't going to get you there, and even if you were a programmer god and could create and engine entirely in handwritten ASM, I doubt it would do it either.

    If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.

  • [quote:17azthjc]We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.

    I disagree with that statement completely. Reliance on third parties is only bad if you suffer from vendor lock-in (which we don't, by the way, the closest we get is over-reliance on chromium, which isn't even that bad since chromium is FOSS). What you're calling "third parties" actually means "abstraction layers" in this context, and those are the holy grail of computing, and has been that way since its inception.

    It is obvious that the more layers of abstraction you have between you and the metal, the slower things are, but the more layers you remove, the more you start finding that writing software borders on the impossible, culminating in "real programmers use a magnetized needle and a steady hand". For example, buggy and bloated as graphics drivers may be, no one would dream of ditching them and pushing raw instructions directly to the GPU, even if those ended up being a thousand times faster than going through the drivers.

    Same goes for the myriad of third-party-reliant technologies used by Scirra to provide fast turnaround, easy gamemaking capabilities and seamless portability. To implement those by hand would require titanic efforts that a solo programmer just can't cope with, regardless of his "rockstar" status. Ashley has stated multiple times: bringing feature parity to a native exporter amounts to writing a browser engine from scratch; and lest anyone thinks this is easy, remember that Opera is basically a wrapper nowadays, even their multi-man team and 2~3% market penetration (which is huge when you consider the numbers we're talking about here) wasn't enough to convince them to stay (nevermind "switching to") in-house.

    If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.

  • - Set "myKey" to "myValue" (only writes to cache)

    - Write "myKey" (writes for real and is asynchronous)

    I agree with rex here - the only difference is I would drop the "write" action entirely. This proposed schema looks like many of the modern key-value storage schemas, which don't truly commit the data to disk until some time later, hence the term "eventually consistent". This shows that the proposed flow is a pattern (as opposed to an anti-pattern).

    The system as it is implemented now is close to the way it works in javascript, and I'm used to the async nature of js, but I believe it is very hard for beginners to grasp: remember some people have difficulty with arrays and some think variables are too hard. I'm not saying constuct should be designed solely for those people (lest we become like some other game-making software out there *cough*), but it should at least cater to them if it doesn't get in the way.

    The benefits of a "fake write" with posterior flush are reduced complexity for the dev (which is one of the strong suits of C2) and performance (since you don't have to wait to read values you just set). The only (slight) complication for you Ashley would be to ensure that writes issued in order get committed in order as well, and if there's a conflict, last write wins.

    It would be worth it to investigate how writes commit if the application crashes before receiving acknowledgement (different engines may do this differently). If it commits even without acks and "last write wins", as I suspect it happens, then there is no problem at all.

  • Nesteris Yep, actually they said 200 releases when the site went live too, same goes for 2 M download, they were not yet at 2 M...

    I guess marketing and rounding up can go together, even if I think it is kind of cheating..

    to be fair, that site wasn't publicized anywhere and construct 3 doesn't exist either, so the way I see it they get a pass. Does anyone have any doubt that we'll see r200 before construct 3, considering we're on r199? I mean unless ashley gets run over by a bus or something, r200 is pretty much inevitable

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • mind mapping?

    You don't know mind mapping? Oh boy it's your lucky day!

    Mind mapping is a technique to help you sort out your ideas, and can be used for project planning, todo lists, project management, brainstorming and all sorts of things (I've even seen it used for bugtracking/bugfixing). You just make a big diagram to categorize your ideas/tasks/whatever in a hierarchical form, thus creating a "mind map" of your thoughts and their connections. It's sincerely fantastic for everything (including game design and programming), and vastly superior to todo lists.

    Check out freemind for a FOSS alternative

    There's also simplemind as a good commercial option. Also available for Android and Apple, and it's really worth the price.

  • I understand your opinion but as a designer I disagree with it. If you suggest make the editor support CSS instead of make the editor skinnable your not giving the real problem to Ashley solve, your are giving only one limiting solution. The end user needs a skinnable editor, if it's better to do it through CSS or other method is up to Ashley to decide based on all the other decisions he will need to do for the engine. If in the design path chosen by Ashley CSS ends up not being an option, then by your suggestion we will not have a skinnable editor, even though maybe there's other ways it could be implemented inside those restrictions.

    So in my view there's no harm in asking requests that are not strictly architectural. Ashley can analyze what's needed to make that particular feature feasible and decide what is needed to change in the Construct architecture to make it happen. If Ashley is willing to make architectural changes...

    Hm. Yeah you're absolutely right, requesting "CSS support" is no different than asking for "C# exporters", it's focusing too much on the means instead of the ends. Ashley should be the one dictating the technologies. 100% agreed.

    I think megatronx gave a good idea in that sense, just start a topic where users can vent about their current frustrations with the current IDE and other users could propose solutions to them.

    But you can see what I'm trying to say here, right? Just don't allow C3 to become a bag full of special cases, exceptions and niche features (C2 is becoming more and more like that recently)

  • So right now. The list would support all your posted ideas. Though it does come down to. how flexible the current system is, how much needs to be redone, and what Ashley's values of the suggestions.

    Oh, I know, I just wanted to make it clear for everyone that this is not a place to request trivial things. As it stands, people will eventually jump in this thread asking for things that can already be implemented (i.e. "there should be a plugin for adbizz" or "make a physics plugin using PunyPhysixz"), or features that are too niche and would be better expanded as an architectural change (i.e. "make a plugin for damage types" - this could be made much easier if we had a better way to fold away or abstract object variables, or using your "generic object" idea).

    Some (imho bad) ideas already requested:

    • Make the editor skinnable (a.k.a. "make a dark theme") sounds like a nice idea, until you realize you can just say make the editor support CSS and get something much more versatile, while still getting everything you want
    • Support for multilanguage also sounds nice, but you can instead ask for make the editor support third-party javascript libraries and get access to tons and tons of free, open-source translating libraries already available as well as other nifty stuff for drawing, maths and lots of other things
    • we need a menu editor is desperately needed, but nowhere near as flexible as make the runtime support sub-layouts

    Some grandiose ideas are better here (some great ones already in this thread and the document!), such as increased versatility for the layout editor , allowing you to customize it in such a way that in addition to supporting top-down and sidescrolling views (which is what we have currently) it will also be able to handle isometric, 2.5D and 3D. This should be done preferentially via plugins or config options, avoiding hardcoding as much as possible.

    [quote:hxkchvw4]I also think each one of us should write down what is annoying bout current IDE workflow.

    Want to start another topic? I'd post there.

  • Nah. I think Ashley is talking about "backwards compatibility for c2 plugins".

    I don't think it is possible or even wanted. The editor will change so much that the edittime side of current plugins will probably be unusable, unless there's some sort of converter (I personally think this is a waste of time - throw C2 plugins out the window if you have to).

    As for your case, it's probably OK to keep going with your project using C2, you have a long time before C3 arrives, and a long time after that before C3 reaches feature parity with C2 (I wouldn't dare guess how long, though).

  • People, keep in mind that this thread is for architectural features in C3.

    I'm going to give a list of suggestions that ARE NOT APPROPRIATE for this thread:

    • Path Movement (I'm not talking about pathfinding, but a simple "follow the nodes" movement): If we can have plugins and behaviors drawing on the canvas, this will already be possible with the SDK, so this is a shitty suggestion for this thread, even if it is immensely useful for development. Same goes for bezier curves, for instance.
    • Instead of asking for pin behavior should take size into account, why not ask for expressions during edittime? this way we could set the X position of an object to something like "parent.X*parent.size+self.variable", turning the pin behavior almost obsolete (don't take the pin behavior out, though, beginners can still use it before they wrap their heads around variables)
    • AI Editor or similar. Ask instead for "plugins should be able to define and spawn their own editing windows, just like the sprite animation editor", this way we'd be able to create finite state machines, 3D map editors and all sorts of things
    • Instead of asking for multiple collision masks, why not ask for collision masks to be decoupled from the animation? This way different objects can share the same collision mask. Even better, why not ask for "collision mask" to be something you can store in a variable? Heck, it doesn't even have to be a "collision mask", it can be just a "mask", that we can crop, apply effects to, etc. Also who said masks have to be edited? Maybe I can just choose on a list from a few presets, such as a circular mask, or a square mask, or an editable mask. Maybe I can have a little "mask editor" where I can do operations such as "fit inner" or "fit outer"

    There's no point asking for features piecemeal, it's about asking for architectural changes that will enable us to create the most things using the least stuff. It's about making the engine versatile instead of a bag full of special cases (i.e. the tilemap and spriter extensions)

    Also, for people talking about exporters, this is crazy talk. Don't ask for "native XYZ exporter", ask instead for "an exporter SDK"! I may or may not agree with you, but at least it's an architecture request.

  • No, there's no plan to do it - the whole point of Construct 2 is that there isn't any programming like that.

    That's not entirely true.

    You can use the SDK if, like me, you really like coding. There's nothing stopping you from doing everything but the highest-level coding in raw javascript.

    If you're really patient, you can bypass the event system entirely, though I don't recommend you do it. check it out!

    With C3 it seems we'll be getting an editor SDK, so you'll get even more bang for your buck.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post