Hi Flex, here's an example of how to do that, if you want them to always shoot even if the towers aren't onscreen you can just remove the on-screen condition: https://dl.dropboxusercontent.com/u/471 ... ooting.cap

Hope that helps <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> Also be sure to check out the examples from the link in my signature, you can grab the source code to my I Had Hope game on that blog too!

megatronx I remember someone was working on an XNA exporter a long long time ago, but I think along with the change from multi-export to HTML5 pure the options for third party exporters also went out the window (I was under the impression that at one point the plan was to have some sort of SDK/engine parts exposed to allow third party native exporters that were not HTML5/Javascript based).

Could be wrong about that though...

Edit: XNA runtime from 2011

Fimbul

Construct Classic, Craft Studio, Game Develop, GameMaker 6, Clickteam products (MMF, TGF, etc), Godot, and many other small-team-engines perform very well and generally use less layers of abstraction than Construct 2.

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.

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.

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 (eg: after they have been determined to have met a minimum of specs and updated their graphics drivers to the latest version and updated their DirectX and Windows Updates, after that point I should rarely ever see a complaint about bad performance)

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.

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 interesting question is: Why do so many people buy a HTML5 engine if they don't want one? The "we can export with wrappers!!!"-thing came as a bonus over time and is still just a bunch of hacks.

I have always wanted the sequel to Construct Classic to be something with native desktop export (even if just Windows), and that was one of the things that we were told would be "definitely" part of Construct 2 in the early stages of its development. In fact, C2 was supposed to support multiple exporters during its early plannings, rather than just HTML5, which is why all the plugins go inside "Construct 2/exporters/html5/plugins" rather than just "Construct 2/plugins".

There were many people who voiced this concern in the early days and we were basically told it was "a given" that proper desktop export was included.

After Scirra decided to focus on just the one exporter, were told that HTML5 would be better for portability and run better than Construct Classic ( https://www.scirra.com/blog/102/html5-g ... han-native ) , and it's true, I can now have a badly running game on a whole bunch of platforms, but the performance just isn't smooth, and eventually we are told that it's due to third parties.

Well, if we aren't using a native engine because it depends on "too many third parties" I don't see how this makes sense:

A funny comparison would be to how (and why) Apple ditched Flash: https://www.apple.com/hotnews/thoughts-on-flash/

If you replace Flash with Construct 2/HTML5 in our case (because for them, HTML5 is something they directly code the native browser for) the words become

[quote:ivecik6v]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. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Construct 2 is a cross platform development tool. It is not Scirra’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Scirra has been painfully slow to adopt enhancements to Apple’s platforms.

Toddler

Sorry, but my game is 256x192 base resolution upscaled to fit the desktop (as I can't force a desktop resolution, so it stays as-is eg: 1600x900 on my desktop or 1366x768 on laptops), and some of the examples you gave are older games that run very well on modern hardware which somehow still stutters with a simple C2 2D retro game like mine.

There is something going on that is not quite as easy as blaming it on the developer for "demanding too much from the hardware", especially when I get better performance than someone running my game on a better PC.

Colludium

Yeah, there's beginners throwing every shader on and getting the game barely pushing 1fps and complaining, but there's also people stripping every feature they can find to try and determine the source of the slow fps when their game is a small retro inspired title that in theory could run on a NeoGeo.

Considering how high-level C2 is, it actually does make sense for the engine to pre-bake any data we feed into it and do the heavy optimization only once at export, so that runtime can be incredibly fast. Therefore, aside of real-time things like shaders, I don't see why the engine doesn't automatically know to break a 2048x2048 or larger sprite down into smaller chunks internally and apply the mathematics necessary to change the game logic for this break-down of objects.

An easy game development tool can still run well, as I've experienced with Construct Classic, Multimedia Fusion, and Unity.

But if i want it to fire not only after "On Space pressed"? Let's say i have multiple events with Get Item?

That's where the "on all complete" trigger Ashley was talking about would come into play, but maybe the Then feature can be turned on and off in the same way that you can right-click an event and select "OR" mode.

No problem Flex, here's some more description:

The yellow powerup objects are just images that the player touches to trigger collection of an item from the array, so instead of "On collision between Player and PowerupObj" you can just trigger the event when a chest is opened/touched.

The global variable (In the project tab on the right) is how many different values there can be.

The first event under Start Of Layout just fills the array with "Powerup" and a number, eg: "Powerup1", "Powerup2", and so on.

You could just store a cash number in each of the slots instead, and then when the player reaches in to a chest it will return one of the cash values that was not already picked up before.

I think a lot of what/how people feel, and the things discussed over many past forum threads including this one, can be described in your own words Ashley. (https://dl.dropboxusercontent.com/u/4714446/AshTweets.PNG)

I don't want to feel like a guinea pig, but I will try to do some profiling and debugging (if it doesn't crash / can even run at full speed), but sometimes I get a sense that even if you just played the finished game in various conditions (different software open, screen capture tools, average/mid level PCs, etc) you could really discover the issues we're seeing or hearing about.

Here is a way of randomized rewards that will never be collected more than once per reward: https://dl.dropboxusercontent.com/u/471 ... werups.cap

Hope that helps!

Perhaps it should automatically appear and conjoin to an event that uses asynch so that the user can't get confused/realizes it's part of the command.

Naji Try to do the angle comparisons in the first task with only 3 if/else statements and 2 variables but good luck! and cool looking forward to that too then

10% sounds like a great boost, if it's the difference between even 59fps and 60fps it may be all that's needed to remove the strangeness that occurs in platform behaviour.