Fimbul's Forum Posts

  • In the long term we are thinking about where to take the editor in future, and how to solve this problem to make it really easy to add UI features - and how to allow third party addons to extend the UI usefully as well which helps take the pressure off us much like third party plugins already cover lots of niche/specific use/alternative features in the engine. This will be no small job though. I hope everyone can be patient, because to make a "dream" UI is going to take a lot of work... but it's in our sights!

    Why not kill 100000 birds with 1 stone? Ditch the C++ IDE and port the whole thing to CEF.

    • Linux/Mac/PC compatibility out-of-the-box
    • Mobile versions are simpler to make
    • Vastly fewer discrepancies between Edittime and Runtime (especially in regards to effects)
    • Component reuse across codebases
    • No need to switch between languages / Single standard library
    • IDE SDK becomes easy to make
    • Tons and tons of high-quality UI libraries
    • Possibility to make a "cloud" version
    • Easier collaboration (stuff is more abstracted than with C++)
    • Big community support
    • No need to make single-purpose C++ interfaces for plugins such as spriter - the developer would be responsible for integration

    I don't see any point to sticking to C++, especially since you said yourself that you wouldn't make native exporters and don't like "maintaining multiple codebases". Even if you were to add an editor SDK, if it was made with C++, I doubt a lot of people would use it, considering most here that can program tend to do so in javascript.

    It wasn't a viable option back when construct was still in alpha, but it has become an option now. Check out how easy it would be to make interfaces with something like jQWidgets and unsemantic! They'd be insanely better than what we currently have in the editor!

    I might post a topic with mockups.

    If the exporter was a commandline tool, I'd be tempted port the whole thing myself (well not really since I would be in a legal mess with Scirra in regards to IP Ownership but you get my point).

    We would be a long way behind where we are today if we had, because we would be having to maintain multiple codebases. Writing two codebases isn't twice as hard, it's more like squared (to the power two) as hard, because of all the extra effort to make sure both codebases are functionally identical in all circumstances, and that extra work never goes away if you keep adding features like we do.

    Need more arguments?

  • what I meant by that is that there should not be any difference for the user apart from a better experience

    Exactly. The developer doesn't have to change anything in order for things to "just work" on 64-bits chrome.

    However, it's important to realize that the benefits can be quite significant: 32-bits applications have a <4Gb memory ceiling (in practice <2Gb), which means having a ton of open tabs/windows will slow the browser to a crawl.

    Games love to consume memory, and browser-game-players love keeping multiple tabs (with multiple games) open, so this change will mean better performance in practice.

    I don't know whether this change affects Double's (the value type) precision, or if it will allow higher limits for graphics or AI processing, but it definitely makes 3D Web-GL in-browser games more viable than they were before.

    Well loss of an expected profit margin means nothing if people won't buy it at a higher price.

    ne of the big characteristics of good business acumen is being able to identify opportunity costs. Is the time spent writing javascript for a plugin more valuable than the time spent writing javascript for something else? In my opinion, not with a $5 per-dev license.

    You just need to add more value, more bling, and more shiny, to get more people interested... which is what I'm looking at.

    uite the contrary: spending more effort means raising the costs of production - if you can't pass on those costs to the market, you lose money. The best solution with a $5 ceiling would be to make tons of low-effort plugins (thus lowering the cost of production).

    A lot of what is being discussed here and feedback we've received does makes sense

    hank you.

    I really am sorry if this is a big disappointment so close to launch, but they are categories we do want to support in the future.

    'd love to see a "premium tutorials" type section as well, is that possible? It's functionally similar to the e-books section, but a bit shorter in scope and not limited to text (you could add video, exercises, step-by-step capx, commented source, powerpoint presentations, etc).

    Tom Make a list of rules of plugins, if they break one rule, then the plugin submission will be rejected. That's simple.

    don't think the issue here is with plugins breaking the rules. The problem is plugins adhering to the rules but breaking the spirit of the store, and making rules for those is a highly subjective process with tons of caveats and exceptions. Manual curation is already being done, I'd like to see manual pricing (by scirra staf, in case that's not obvious) as well.

    In fact all plugs up until recently have been free.

    ree and commercial content are produced for entirely different reasons. For instance, I have lots of ideas for cool plugins, but I don't make them because they take A LOT of time and time=money, which I need in order to survive.

    Also, commercial plugins require constant support (you can't just let them die) and documentation (which you can forgo if your plugin is free).

    But if you wish to continue the argument then lets look at something comparable, say for example Spriter.

    Its an editor, and a plug, and costs $24.99.

    Can you make something of that quality?

    priter can be sold mass-market, and plugin costs count as a feature for the software itself, which is the main product. That's not the case with a construct-exclusive plugin.

    Let me make an analogy: photoshop is sold to millions of people for a (arguably) low price, and is a very high quality product. The euphoria middleware, a much less complex product (though still pretty complicated), costs millions of dollars. How do they get away with it? Simple: euphoria is a niche product and thus can't be sold mass-market, just like c2 plugins, but on a much bigger scale.

    If you could provide a turnkey solution (a plugin bundle plus a game with source) for, say, a top-down MMO-game in construct 2 - which is quite possible and something I've considered briefly - I don't think charging upwards of $1500 would be a stretch, even if it ends up being less complex than Spriter. The possibility goes to hell instantly if you cap prices at $5.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • The way most people do is add a [request] in the topic title

    So your topic should be renamed

    [REQUEST] Select multiple sprites[/code:2as4idqt]
    
    Cheers!
  • It is intentional and was documented in the changelog a few versions ago.

    The wav files were never used for anything and were just taking up space, so Ashley removed them.

  • Arima you should just leave the spam. Tom is never going to do anything about it if you keep cleaning it up. If you leave it he will see the extent of the problem. I think it's now going beyond the work a volunteer should do for free on behalf of another company.

    But then tom will have to come up with a solution, which means less time dedicated to the scirra store.

  • Well I guess what I'm calling "not the complete path" and what you're calling "complete path" are the same thing.

    I'm going to generate the particle normally (to get starting conditions), then project the path forward (to get end coordinates) based on:

    • Starting x/y
    • Angle
    • Speed
    • Lifetime

    Then I'll either lerp it from end to start or shoot it backwards. I'll also lerp size, rotation and opacity based on what the user specified (taking into account that those values might hit their ceilings/floors before the trajectory ends).

  • Since the particle path is random and non-deterministic, the only way I can think to do this is to simulate a complete forwards path, then start at the end and play it backwards. That's not exactly a trivial change. I think perhaps it could be made in to a separate plugin.

    Yup, that's exactly what I wanted to do, though I don't intend to simulate the complete path.

    Also I know it's not a trivial change, it's not like you can just set particle speed to negative

    Can I go ahead and modify the plugin to make my own "reverse edition" then?

  • This seems like it could be very useful - I'd modify it myself but since this is frowned upon, I'm making a feature request instead:

    The particle object emits particles in a cone, with many settings such as growth over time, fade-out and so on. These are all deterministic, so why not allow it to emit particles in reverse?

    That is, it would create particles in front of it and "suck" them in. There are many cool effects that could be achieved with it, as well as some interesting optimizations. I don't see any technical problems with it either.

    Now, as I said in the beginning, I'm fully capable of implementing this. Question is, should I do it or wait for Ashley?

  • I've never had any issues visiting the scirra forums on my android phone either (besides that annoying bug where you don't stay logged in).

    However, I've had plenty of issues where the "request desktop site" version doesn't work, the site refuses to serve content, instead redirecting me to a "mobile-friendly" home page, or where the "responsive" mobile theme lacked most, if not all, power-user features.

    I say forget about optimizing the forums and keep everything as-is. "Mobile versions" are a blight in the web industry.

  • Oh god I hate "mobile-optimized" anything. One of two things inevitably ends happening:

    Either the "mobile version" is crippled and we don't have access to all the features from the desktop version

    or this:

    What's wrong with zooming and reading in landscape mode?

  • Force = ForceFactorVariable * sin( 180 * hill.width * 0.5 / distance(ball.x, ball.y, hill.x, hill.y) )

    You're in the right track, but there are a few caveats:

    • This presumes the force gets stronger, linearly, the closer the ball is. What a weird hill! This is also likely to send the ball into the stratosphere if it crosses the middle (which would be even weirder if the hill had a tapered top).
    • You need to take into account the steepness of the hill.

    Personally, I'd just spread a bunch of invisible "force-applying" objects on the screen, creating a sort of "force map".

  • It appears you have two questions:

    • Should I use WebRTC or WebSockets?
    • How do I modify default plugins?

    For the first question, we need to know what kind of game you're making. If it's a bullet-hell, use WebRTC. If it's a puzzle, use WebSockets. If it's a card game, use simple ajax.

    For the second question, let's go point by point:

    Multiplayer plugin seems to only support peer-to-peer, even though WebRTC is capable of following a authoritative server approach. Upside I gain UDP support, downside I lose the entire IE audience.

    Peer-to-peer can be coerced into "authoritative server" by simply adding special logic that treats some predefined peer as an authoritative server. It's really quite simple, and you get the benefit of also connecting to peers, so you can send them non-authoritative data for a latency boost (and a lower bandwidth fee on your server).

    Websocket plugin only allows you to send strings which would be a bit inefficient. I'd like to modify it to add ability to send custom datatypes.

    Regardless of the datatype you send, it will get converted to strings anyways. Besides, construct doesn't support types other than string/number/bool natively.

    Notice that you don't have to modify the plugins in either case.

  • I can't offer any advice for a gtx 750 ti, as I've never owned one.

    In any case, you should be set if your card is even modestly young. Heck, I've had success with intel's crappy h55 (admittedly Intel has come a long way since the horrible integrated chipsets of old).

    The most important thing I consider nowadays is triple-monitor support. Make sure the card can actually support 3 monitors, though - just because it has three ports doesn't mean it can run three monitors!

    As for the setup, you're pretty much right, just go BIOS and select PEG (this is your card, it stands for PCI EXPRESS GRAPHICS). Remember to disable intel's card completely (in the bios) and plug your monitors to the right slot (again, your card, not your mobo). Then download the latest drivers and you should be set.

    Considering the other system requirements, here are a few things to note:

    • Dual monitors are better than single monitors, especially for construct (since you can code in one monitor and preview in the other). Once you go dual, you can never go single again. However, triple monitors are even better since it gives you a central point for your vision. When working with construct, I usually have construct on the left, brackets (a javascript editor) in the middle (since I sometimes create plugins, you don't have to do this), and chrome/firefox on the right
    • An SSD is very nice, especially to cut boot times, but if your main use is construct, I don't know if I'd bother. They're pretty expensive, and only make a difference with i/o heavy applications (such as photoshop, AfterEffects, AudaCity). If you're going to use the PC for gaming, SSDs cut loading times by a lot, but they don't do much else.
    • If you're like me, you'll want to have a load of programs/tabs open at once, so you might want 8Gb of ram instead of 4Gb. Ram sticks are pretty cheap. If you have a choice, go with the biggest sticks you can grab (to give you room to upgrade), but get at least two sticks (so that you can dual-channel). I.e.: 2x4Gb is better than 1x8Gb as well as better than 4x2Gb.