Davioware's Forum Posts

    If you're on Windows there's little reason to use or subscribe to C3 right now.

    C2 does more than C3 right now, due to third party additions that greatly expand the feature set. I wouldn't put off buying C2 just because C3 is out; it's still useful and very good software, and they'll support it for a while. You won't get new features anymore, but it doesn't need new features really, it's pretty complete as is. Buy C2, it's great. C3 is just a browser based version of C2 with no third party support right now, and it's still in infancy.

    What's really puzzling about this sub model is that they're releasing C3 with very little meaningful improvement over C2, no third party support (plugins have yet to be ported etc), and useful features way out on the horizon. When C2 first came out, it was CHEAPER because it was new and lacking features, hence the "early adopter" period. Once it got better, the price went up from there. With C3 you're an early adopter but you're paying full price right now unless you get that discount from owning C2. Will this mean the price to sub will go up even more once things like the new runtime come out? I don't think it will, but I sure hope not.

    You need to retain something from a subscription as well. It would make people feel invested in the program and make them feel like they own it. The problem with subscriptions is that people don't want to subscribe in the first place if they know they'll end up with nothing. It's not like a magazine subscription where you get something concrete. Subbing for 5 years means 500$. At the end of those 5 years, you've got nothing to show for it, and are locked out of editing your projects. It's a huge disincentive to using the software in the first place. Consider letting people keep the versions released during their sub period. You will get a lot more customers this way, including ones who will continue to subscribe year after year just as you want. The idea that they own something will make them happy, and you won't be losing anything. Many people are extremely opposed to renting software. In this way people pay for continued updates, instead of continued use.

    We'd rather come up with one system focused on browser usage that covers everything. The standalone versions are basically a bonus for Windows, Mac and Linux users only

    Ashley

    Game engines are a bit of a special case. People work on long term projects and absolutely do not want automatic updates to the editor or runtime. There's a reason Unity has every old release available for download, and even releases patches for old versions of the engine. Once you're on a release it can be a big headache to upgrade even one version ahead. You have to study patch notes like crazy and see if they apply to you. You have to re-test the entire game and hope nothing broke. Every little fix or change in a new version can heavily affect a big project. Will users be able to launch the release version of their choice when launching construct 3? If that's not an option on all platforms, that's a pretty big problem. You don't want someone on Chrome OS to always be running the latest version automatically. Users MUST be able to freeze their release version for stability reasons, including if there's no standalone versions. And users should be warned when saving an older version project to a new version.

    EDIT: Ok, it appears that you can launch old releases from the website at least.

  • Like newt said, without a load this measurement is pointless. You're just measuring the performance of an empty project which is pretty much meaningless. It's not taking into account how things like the scripting engine, graphics, or collision engine scale. Similar to algorithms, the performance of the engine subsystems are xn+c where n is the size of the input (how much code, collision, sprite rendering etc.), x is some factor, and c is a constant. Right now you're just looking at c.

    Obviously there will be bugs on the first days of release. The whole point of a beta is for bugs like this to surface and be dealt with.

  • Is this .c3p file supposed to show that when moving the circle back and forth, the black line doesn't always line up with the ground at the same place as when you started? (when pushing it back and forth against the wall, let's say, it becomes misaligned compared to the starting state.)

    If that's what you're trying to show, here's my response:

    Sampling delta time in an accumulator fashion like what you're doing in the .c3p will always show imperfect results. Why? Because delta time varies ever so slightly and you're summing a ton of floating point data over time. Floating point data does not represent an exact number (due to a finite number of bits used to store it), and is susceptible to rounding error/cutoff. The problem becomes exacerbated when you start summing up lots and lots of this approximated data, because you're losing some every time.

    Ashley

    Was implementing multiplayer really a waste of time though? Is your use data based only on your signaling server activity levels? If so, then it's quite obvious that the majority of users won't be using it much; it's a lot of work to make a multiplayer game and beyond the capabilities of beginners. But simply having multiplayer as a feature in C2 probably sold a lot of copies of the engine. Even if it goes unused. People buy things based on what they want, and not necessarily on what they will end up using. I'm sure a ton of hobbyist's first question on reading about C2 was "can it do multiplayer." And the answer is yes, so they bought it. It sounds cool to them and they like the idea. In reality, 99%+ won't ever make a multiplayer game, or even a single request? to the signaling server. But they bought C2 because they know the option exists. The poll on the forum clearly showed that there was a lot of interest in that option.

  • Dt will always have random variations, that's the entire point. The fix Ashley made is internal to the platform behavior code only, and has nothing to do with Dt or pixels per tick/second in general.

    I think technical issues aside, there has been a huge ideological shift from Construct Classic to Construct 3.

    I completely agree with this. I do think they are trying to make the best 2D HTML5 game engine possible still. However they seem to be excited about C3 running in a browser, without asking why people would want it running in a browser in the first place. Yes, it's very cool that complex software can run well in-browser, with hardware acceleration and multi threading. Kudos on the execution of this. I'm impressed at what you've accomplished. But why does professional level software need to be browser-based from an end user point-of-view? One big advantage is multi-platform support. But editing a game on a phone is not useful. Any for-PC game will not even work because there's no touch controls set up and/or the game is too demanding for the hardware. Nobody does work without a mouse and keyboard, it's just not practical. Even something like music creation software is a nightmare to use on mobile devices.

    It's understandable that they're trying to reach a larger market with the multi-platform editor, but at the end of the day people just wanted another big paradigm changing upgrade. The paradigm change this time has nothing to do with the engine itself, but the editor.

    Construct Classic was exciting because it had a great event based language, and the runtime was extremely performant, both in code speed and graphics, it was IMO the best 2D game engine at the time.

    Construct 2 was exciting because it broke new ground on the HTML5 front and made the editor bug free and stable, at the cost of code execution speed (since it moved to JS from c++)(I haven't done any benchmarks recently with chrome's JS engine but I believe it's still slower than Classic). C2 was very well supported and they did their best. HTML5 based games are great in theory and they're almost there, but they aren't quite perfect. Reliance is on wrappers and device support. I'm not surprised that the Wii U can't run a "for-desktop" HTML5 game.

    Construct 3 brings.. A better editor for all platforms (good for non-windows users I guess), and that's about it. I would even call the browser based editor a downgrade for windows users, simply because almost everything that they've added could have been done to Construct 2's editor. A browser based program will never be better than a native application. Easier to write, maybe. Better for the company for control/update purposes too.

    I would never use the chrome based editor for a serious project if I were to use C3 (which is unlikely). It would be static versioned, tested, wrapped windows versions. I can't afford a chrome update breaking the IDE somehow or causing problems. Or what if chrome drops support for feature x or y which construct uses since it's so cutting edge?

    The features in C3 are just quality of life improvements to the editor, or things which won't often be used. I've read all of them. Adding them together does make the experience better, but there's no "wow" features to the engine itself to be excited about, coming from C2. Especially considering the hefty subscription fee. Using C2 just makes more sense unless you want to support Scirra.

  • Decoupling a sprite from its frames is very useful. It makes the program a bit less beginner friendly unfortunately, which I don't think Ashley wants. The way it could work in Construct is that when you add a new sprite object, instead of being taken directly into the image editor to define the first frame, a popup box appears and you can assign an animation(s) from the project resources bar/some new UI window containing animations. This would mean animations are globally accessible to the project and not tied to sprites; sprites simply inherit them. This would require a change to the UI of course. Being able to decouple frame data from the image as suggested here would also be nice; you would be able to reuse frames when defining animations. I doubt these things will be added however as they require big changes to the way construct works. A workaround which might be possible and would be very useful is a runtime action on sprites to inherit animations from another sprite type and add it to its own animation list. It would come in handy for certain in-game UI cases where the same animations/images need to be displayed on different object types. (think of a level editor, where every graphic in the game needs to be accessible to a single sprite type, or a fighting game character selection screen that displays the character). Sprite types should inherit animations, and animations should be able to share and reuse segments of spritesheets. Construct's current way of setting up animations frame by frame is good for beginners though, if they don't work with sprite sheets.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • After trying out the demo projects and giving the program a quick test, I'm split. From an engineering standpoint this an amazing feat. Achieving all of this in a browser is very impressive. The editor runs smoothly, at least for the simple sample projects that were provided. It runs on iOS and Android now, as well as Mac and Linux. Great. But I don't care about that as a Windows developer. Running in a browser is more of a hindrance than anything. Running in a browser is better for Scirra, since they can easily port the editor to all platforms. But why would I want an additional point of failure/slowdown in my IDE? Answer: I wouldn't. It's cool to be able to edit a project on a phone or tablet (the main feature of being in a browser) but it's more of a novelty than a useful feature.

    It's basically just Construct 2.

    The "free edition" is essentially useless. 25 events, and for some reason even more strict restrictions on layers and effects, as if "25 events" wasn't enough. The free edition is for you to try the thing, and then subscribe. There is no useful free version like Unity has. I was thinking they would make the free version actually usable with Construct 3 since it costs so much more, but I guess I was wrong.

    I see this as being a very good program for education or schools, since it works on all platforms.

    But as developer on windows (as is everyone here) there's no point to using it over C2. Construct 2 does everything I need if I want to make a HTML5 game. The small amount of features it adds to 2 just aren't worth the cost. It's a marvel of engineering, but why bother using it when Construct 2 exists if you're on windows? If this was a new product and there was no Construct 2, it would be much better received by the community.

    Many people are upset with it because it really adds nothing new, yet costs so much more.

  • If you like C2's coding system, try using the Q3D plugin for C2.

    Unity is a very different engine to C2. It wasn't designed around a visual coding system like Construct, and you're better off just coding in C# for it.

  • Finding obscure bugs in CC can be annoying as hell, so I'll share what I can remember.

    Strange things which can crash the game:

    -Calling a function as an action, in the same event as an "is overlapping" condition. to fix, put the function in an empty sub event.

    -.WAV bit rate. Do not exceed 1411kbps for .wav sounds or crashing will occur. This one was fun to figure out..

  • Extremely inefficient. It would be much better to do this through a shader, or scrolling tiled textures.

  • That's a dumb way to do things for a fighting game. What you should be doing is spawning hitboxes as a different object which has frames/animations to choose a shape. This way you can make them move independently of the character, have them shoot out, etc. Not to mention it's a thousand times easier to tweak (which you will be doing nonstop making a fighting game) a position/offset in code, than to open up the image editor and drag points around.

    I can't think of a use case for your original idea either. Why would you want to change the collision mask of an object without changing it's image? It's just confusing to the player.

  • Even though, if I were to buy the plugin while you are away (cause I'm waiting for the pay-check...), would I receive it anyway or does it need to be validated by hand?

    You get it automatically.