+1. This would be really useful to a lot of users.

The work-around of targeting a secondary object is very usable, but for many games that's a lot of additional objects that shouldn't really be necessary to get proper functionality.

Alternatively Construct 2 can also be purchased through Steam, which may allow some additional payment options based on where you're located.

It's not that complicated a suggestion guys... the suggestion is that pressing tab would indent an event, thereby making it a sub-event of the one above and that shift + tab would do the reverse (un-indent, making a sub-event it's own event at the next level up).

I'm pretty indifferent to this one: I guess it could lead to a faster workflow once I got used to it, but I don't find this to be a major slow-down in my process anyway.

cesarzevil

Perhaps you could give the latest beta release of Construct 2 (r129) a go -- it includes experimental support for using the native version of Box2d (the physics engine Construct uses under the hood) for CocoonJS exports and can potentially offer 3-4X increases in performance; note however that it is currently still experimental and had a couple of small known issues which are noted on the update page. Based on past experience we can probably expect Scirra to have these (and any other issues) fixed pretty quickly.

While pixel perfick's response is commonly accepted practice amongst many hobbyists and would probably be good enough to keep you out of trouble, it's not strictly correct.

If your work is based on an existing piece -- even if you create the new piece completely from scratch; drawing your own version of Mario for example -- it is considered to be a derivative work, and you risk running afoul of copyright infringement. This covers your numbers 2, 3 and 4 situations, and technically there is no amount of changes you can make to the work that makes it legally ok -- the only way you can safely use someone else's copyrighted work is to get permission*. In practice of course, if you make enough changes the work won't be recognisable as something based on the original and you wouldn't be taken to court.

Your current situation (listed as #1 in your post) however is not a derivative work; you created your character completely independently and without intention of copying existing work, and only later realised it is similar to the existing character. Technically you're in the right and aren't violating copyright. Unfortunately however this still doesn't guarantee you're safe from legal action...

You can be sued for any (vaguely rational) reason at all, and even if you're 100% in the right you could still be taken to court. If you're really in the right hopefully the judge would decide in your favour, but the process of going through the court case may still be quite expensive, especially if you're fighting a large company.

If a company thinks you're using their work, or a derivative there-of they will usually send you a cease & desist letter asking you to stop; they can however simply choose to skip this step and go straight to legal action, in which case they would file a case against you. It's then up to the judge who hears the case to decide whether or not you are actually infringing and if you are to award damages you would have to pay. If you're just a fan with good intentions and you haven't made much (or any) money from your game, you would be forced to cease your project, but probably wouldn't have to pay a lot in damages. However, if you've done as Pixel perfick suggests above and given credit to the original creator it may be decided that your infringement was "willful infringement", which can potentially result in much higher damages being awarded.

It's up to you to decide what's an acceptable level of risk to take, and if you'd like to be more certain you should speak to a lawyer experienced in video games and entertainment -- you can find a list HERE. Is your character similar enough that an employee of the company is question is likely to genuinely think you've ripped off their work, and are you using it in a way that they would be likely to object to? You could spend forever trying to play it completely safe, but there will always be some minimal level of risk -- it sounds like you genuinely didn't copy anything in this particular case, so unless your character is bears a striking resemblance it's probably a pretty low risk to take.

Hope that's helpful! <img src="smileys/smiley1.gif" border="0" align="middle">

* Technically there is another way you can safely copy a copyrighted work without permission; Fair Use. Unfortunately however this is not a protection you can reliably depend on without legal advice, as only a judge is able to rule whether or not your particular usage qualifies, so you would have to be taken to court before finding out if Fair Use applies.

If you'd like an understanding of how vectors work, try Math for Game Developers: Intro To Vectors and Math for Game Developers: Advanced Vectors, or alternatively Vectors and Matrices: A Primer. These obviously aren't specific to Construct, but I think it's the underlying theory you want explained.

Hope that's helpful! <img src="smileys/smiley1.gif" border="0" align="middle">

I think the suggestion is to include buttons in the UI rather than just keyboard shortcuts. I'm pretty indifferent to the idea personally, but I can see how it might aid discoverability for beginners.

Did you only try once, or have you tried to re-download the file? It could have been some intermittent problem that may not occur if you try again.

To get an actual answer rather than just guesses, you'll either need to show us the code so we can figure it out or ask the original developer you got it from, although 7Soul's guess sounds probable.

Fantastic suggestion. Obviously it may be non-trivial to implement, but it would make a fantastic addition if it can be done eventually.

Not to beat a dead horse if it's already been seen and either rejected or added to the to-do list, but I just wanted to re-mention that I think it would also be really helpful and applicable in a wide variety of cases to be able to specify an offset for the path finding grid so that we could use a cell size that exactly matches game play elements if they're imprecisely aligned thanks to UI.

Obviously I'll be repeating a lot of suggestions from the above linked "programming best (and worst) practices" discussion, but as you're after individual habits and reasoning I'll list some of the things that are most important to me personally here, and try to briefly explain the reasoning behind them. <img src="smileys/smiley1.gif" border="0" align="middle">

1. Always be consistent. Always.

A lot of things in programming -- and using an event sheet is essentially programming -- are subjective and come down to personal preference. It's important that you choose a preference and stick to it within any given project; you should never have to wonder if a variable name is in camelCase, ALL_CAPS_WITH_UNDERSCORES, or some other style, because you should be following your own consistent set of rules for these things.

If you assign some meaning to particular styles (ALL_CAPS for constants for example) it will even help by providing additional hints when reading your code.

2. Use sensible, meaningful variable and object names.

Don't be tempted to save typing by using one character or very short abbreviated names unless there is already an established convention to do so for a particular usage.

It may be clear what you mean now, but it might be less clear if you have to read the same code again after not touching it for a year or if you find you need to hand it over to someone else to be updated.

Using proper names is also a good step towards making your code/events "self documenting", rather than having to explain what it means by adding comments -- see the next point.

3. Use comments to describe why things are a certain way or to explain unusual code, not to describe what your events are doing.

Your events already explain what they're doing, and should be quite clear if you've chosen sensible names. Comments should be used to explain why you're doing it, which may be less readily apparent at a glance.

For example, you might have an event that sets a boolean instance variable to true if a particular sprite is colliding with another. You don't need to write a comment saying that, as the event already describes it perfectly; instead, explain why you're doing so.

4. Use the functions and expressions that most clearly express your intent.

Something there will be multiple functions or expressions which produce the same result. Consider for example the system expressions floor() and int(): when applied to a number such as 4.6 both will produce a result of 4, but these functions have different purposes, and you should use the one which matches what you're actually trying to do. Again, this will help to make your code "self documenting" and easier to understand.

Hope that's the sort of thing you're after. <img src="smileys/smiley1.gif" border="0" align="middle">