Jayjay's Forum Posts

  • > Consider the exact equivalent in native: graphics driver bugs cause your game to crash on startup on *all* Intel HD 4000 series cards. (All graphics vendors have issues, don't think just AMD or Intel are affected.) After having to buy a new PC and build it with the given graphics card so we can test it, we waste days guessing what the problem might be and come up with nothing. Somebody says "I don't care if it's the graphics driver that is broken, I paid Scirra for a tool they say will work". Despite the frustration being understandable, it is a completely hopeless situation and there is nothing we can do, and it's still not our fault. As I described this is by no means theoretical, and already happened with the Construct 2 editor.

    >

    Sure, desktop will never be perfect since there's too many combinations, but having something that either works perfectly or doesn't work at all is actually better than something that works seemingly-randomly. I'd rather see customers leaving angry reviews like "I couldn't start the game!" than "I fell through floors and teleported all over the map and etc...".

    However, your response also ignores that there are some platforms which have exactly the same hardware across their entire install base including consoles, and Apple devices.

    As long as the exporters are geared towards working perfectly on the latest generation of Xbox, Sony, Nintendo, iPhones, Macbooks, and iPod Touches then a developer is guaranteed a large install base for the games they make with Construct 2, and can better expect their game to work the same on all devices.

    Perhaps then expand to the latest Google Nexus and Samsung Android devices, maybe even the latest Windows phone, then it's okay for the export to get buggy with other devices.

    For anything else or web games, that's where C2's HTML5 could be a fallback option.

    However, I do not believe that this debate should continue. We each have their own view on this. Nothing changes with C3 or C4 or C5. Scirra Ltd can do what they wants. It is their right as a company. I just tried to say what we really needed on C2. By my own opinion.

    True, but I think part of the reason for these debates occurring is because the customers care about the product and Scirra. If they didn't they would silently move onto another tool or leave a single topic saying their goodbyes, but with C3 still in development they feel there is hope for the final steps of improvement needed for Construct to be a viable tool for commercial indie game developers.

  • Regarding that C2 is a "product which is supposed to do what it says on the box" I must disagree a bit. Software is not a bike. You can say that about an easy accountant software which needs just one update a year to adjust new tax rules, but not about an engine which is made to make other software. Thinking this ways you should have the version of C2 which you downloaded as first, and use only wrappers and everything around with the version which was available the time you downloaded that first C2. Then it would be what was on the box (at that time).

    Perhaps some more background to why I feel C2 doesn't live up to its promise would help.

    As a Construct Classic user, I had been fine with the issues of the native engine crashing and editor bugs, because I had understood it was a project made open source by students in their spare time. It still produced amazing Windows games in both 2D and 2.5D that worked excellently (rarely crashing during runtime) on then-average (today low-end and ancient) DirectX 9 hardware, and even 3D ones if you knew the math.

    When Construct 2 was in early development there was a great deal of excitement: Scirra was going to make a serious go of it/a professional game dev tool and an improvement to CC starting all over from scratch.

    Around this time we were also told "desktop export would be a given", which many assumed to mean native export, and other ideas were being put out by Scirra (like having multiple exporter options rather than just the HTML5+Wrappers option. That's why the html5 engine is inside a folder called "exporters" eg: C:\Program Files\Construct 2\exporters\html5). Information about that is all here on the Scirra forums (possibly also on the old forums which should still be online right now) somewhere but you'll have to search to find the posts sadly as they've been buried over time.

    Then over time Scirra dropped down to just pure HTML5, promising that the technology would catch up and work out better for all. They pushed out reports of near-native performance tests (when what they really meant is that the code is more optimized than CC, but if those same optimizations were applied to a native exporter it would obviously perform better in most situations), and many other reasons why this is the best choice for us, the developers of games using their tool.

    It's 2016, 5 years after development started of C2, and I still find CC exported games to perform smoother on my Windows computers.

    I switched to CC from Clickteam KnP/TGF/MMF, so the "graphical coding" was not novel, just better. The editor in Construct tools is also way better to me too, but again the complaint isn't about the editor but the actual games, the products I get from this tool.

    In a way, C2 is exactly like "an easy accountant software", it's not an end product or a source of entertainment in itself, it's what I do with it that matters because it's a tool. I'm not even mad at the price because I agree it's relatively inexpensive (even considering that Unity and other big engines are now free for general use or low monthly fees for commercial titles), and Scirra should charge business customers more if they put native export into it.

    I'm mad because I believed in Construct 2, worked together with a friend to make over 50% of a game, which was then funded on Kickstarter with the dreams of "Win, Mac, Linux + WiiU" that hence became an expectation from the backers (read: customers), and had to turn up with the same excuse Ashley gives us: "We're sorry, issues with a third party (C2 -> Node Webkit -> Chrome -> HTML5 + WebGL) prevented this from working on anything but high-end Windows desktops".

    We were lucky enough to release to Steam, but there's still plenty of devices that should have no problems with the game suffering from frame skipping, missed collision detections, and etc. Especially in screencapture/let's play footage. And ultimately we can't port without totally re-writing the game.

    Even a method to quickly export games into something easier imported into other engines would make Construct 2 100% more useful for developers who want to make more than lightweight or mobile games.

    Quicksand

    There's less layers (points of failure) in native export:

    The driver issues Ashley mentioned were almost always AMD related, which is hilarious because WebGL still has issues on AMD devices too, and the solution changes from "wait for AMD to fix it" to "wait for NodeJS to update chrome, but if that doesn't fix it then wait for Chrome to make sure it's not their fault, then if it isn't hopefully Google will push AMD to fix it".

    And why is WebGL worse on AMD? Because it's already bad at OpenGL anyway, which WebGL is pretty much based on:

    https://www.gamingonlinux.com/articles/ ... hmark.3806

    For these next two links Vendor A is NVIDIA, B is AMD, and C is Intel.

    http://richg42.blogspot.ca/2014/05/the- ... ality.html

    http://www.extremetech.com/gaming/18234 ... -of-opengl

    Also a relevant link for how CC and C2 compared at the time when C2 started claiming to be "as fast as native": is-webgl-slow-on-some-machines_t75194

  • Newest update/dev log on the game is up! http://www.causalbitgames.com/2016/02/b ... nd-a-logo/

    Some sneak preview images of the new winter stage damainman has been working on:

  • Construct 3 is what we need to have hope for in future terms.

    ...

    Is C2 gonna change into the engine that you envision? Probably not, because Scirra is now more focused on C3 and perhaps that will be the engine that you envision.

    ...

    I think that Construct 3 is what will move Scirra forward.

    and we are very anxiously awaiting C3.

    You both know that C3 is planning on using the exact same HTML5 export/runtime as C2 right?

    BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.

    Source: will-the-top-level-design-be-removed-in-c3_p980758?#p980758

    The only thing you can actually anticipate for is devices, browsers, and NodeJS to all catch up to the "standard" of HTML5...which is also the same dragon C2 users have been chasing since the first betas came out in 2011.

    Granted, it's getting better slowly but surely. However, if you're making and releasing games *now* you would hope that your game works the same across all of your customers devices right? And it doesn't, it's all over the map with desktop export, mobile, and even web browsers still have major differences between them (Chrome goes through cycles of breaking-changes and patches, etc).

    Don't forget that you are a customer of Construct 2 meaning you are also buying a product which is supposed to do what it says on the box, so when it tells you that you can export to "Windows, Mac, and Linux" using a Node-Webkit wrapper ( https://www.scirra.com/construct2#multi ) and then your game fails to run on the "Mac and Linux" parts, it is not acceptable! and telling us to "just wait for it to improve/get fixed" is also not a valid response!

    I don't care if it's Node-Webkit that is broken, I paid Scirra for a tool that they say will work on Mac and Linux, and it doesn't for my (commercial) game. It barely even runs the same/without glitches across my Steam customers' computers too, and they have hardware that might be way better than mine or the exact same specs, it's random and *my* customers do not accept "Please wait for approximately 2 years for NodeJS to improve the export by using the latest Chrome...which will also disable Steam Achievements until Greenworks is updated, and introduce random new bugs because Chrome was updated".

    Ashley has done wonders with CC and C2, and has made an awesome tool for "learning game development" and "making small games for mobile and web" with a great editor and really cool way of visually coding games, but for Construct to really move forward into the status that the "more professional" game development tools have it needs a stronger export option. I don't care if that means exporting to a format that can be imported by other engines, but the native export to console and desktop is looking like the absolute minimum export options that commercial game devs need to grow. (And no, WiiU doesn't count, because it doesn't support WebGL).

  • I originally hoped to remake/continue the alpha of my CC game "I Had Hope" ( http://ihadhope.blogspot.ca/p/media.html ) in C2, but what started as waiting for early C2 betas to get features turned into waiting for better HTML5 performance / native export. Not sure I'll use C2 anymore if I ever get back to remaking IHH, but I'll wait and see if C3 plus Vulkan rendering delivers better performance.

  • Now that you mention it. That's a great idea for Construct 2, I hope that feature will be added. Html 5 is becoming more amazing the longer it gets.

    Yeah, the desktop has HTML5 going pretty well (as in, the Chrome and Firefox browsers are pretty good), but native wrappers/console browsers/mobiles still have some catch-up to do I think. Hopefully soon!

  • Hmm, sounds like what is effectively a JSON storage format if it's all one big string, I think in that case you might find the HashTable or Binary object even faster for saving and loading it all at once (Binary object saves to encrypted file too which should make cheating harder!).

    I've not tried them for this though, but the process shouldn't be too large of a code difference from your current system (HashTable might be the most event-friendly approach).

    HashTable usage: example-tips-hashtable-object_t69861

    Edit: Also this works for me for getting the most recently created object UID after it's created by name then applying some code to it in the next tick: https://dl.dropboxusercontent.com/u/471 ... DCheck.cap

    Getting that to work with the loop you have might be a matter of doing sub-events to check what the object being created is though, so depending on all the types of objects that might be a lot of code.

  • Export again and try this in the Win32 version:

    Rename "package.nw" to "package.nw.zip" and extract it to a folder called "Package.NW"

    Rename the game exe to "nw.exe"

    Are you using Greenworks plugins at all?

    Also, try putting all the plugins and behaviors you use into the New Project for testing (one at a time to see when the crash happens).

    Hope that helps!

  • This is a rough hack on top of my old CustomLOS example, but here is a Visible Beam that runs fairly quick <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> https://dl.dropboxusercontent.com/u/471 ... eBeam.capx

    The red LOSCheck object is much wider than the visible beam, so maybe decrease the height of the LOSCheck for the visible beam to look more accurate!

    For more optimizing you could also do this:

    Instead of checking every X milliseconds maybe do a function or sub-event that runs when the map has changed/moved that has each BadGuy object spawn a single check bullet.

    However, the spawning of more bullets does help though if you want to increase the speed bullets travel at, since sometimes they will miss a collision in their movement. Increasing bullet size helps combat the missed collisions. I don't remember but I thought the C2 Rain demo had a laser that simulates instant-hit as well, or maybe I'm again remembering a CC example.

  • I found these resources really helpful:

    http://www.gamefromscratch.com/page/Gam ... cipes.aspx

    2D math: https://www.siggraph.org/education/mate ... ran/2d.htm

    3D math: https://www.siggraph.org/education/mate ... ran/3d.htm

    Mostly I just look up what I need the first time I need it, then save the C2/C#/etc code version of it for later in a text file.

    For most game development learning how to use already existing code/math where you need it is probably enough to do well <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • My "I Had Hope" game loaded all the levels from simple INI format files, but I didn't write a level editor/layout to INI saver for it (might have an example of that in my Examples Kit download in the signature too though).

    Source code to IHH alpha is up at http://ihadhope.blogspot.ca/p/download.html

  • Unfortunately the "on any key pressed/released" are triggers, meaning they only happen once when first "triggered", so inverse of that is something that never happens at all.

    It looks like you might have to check "is down" for each and every control to check for no keys down sadly

  • mikewalton206 I think it's still up in my dropbox at the same link Can you access it from the other page in this topic?

    If not I will re-upload it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • — Yeah! I'm actually really surprised by how smooth it is in the example games both 3D and 2D compared to some of my other experiences with Construct 2 + NodeWebkit, and that it even runs pretty nicely (meaning the editor has some bugs but the runtime is good and highly playable) on my Xbox One!

    Also love that the editor is made in HTML5 as well, so no installation for collaborators is needed. Code editing is live like a Google Docs file and map editing changes are instantly shown on others' computers as well. Pretty neat and again, amazingly it's open source/free software

    Definitely some features there I'd love to see in Construct 3, especially the live collaboration support and maybe even switching to Electron instead of NodeWebkit.