jbadams's Forum Posts

  • 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">

  • Making games is hard. It's a lot less hard with Construct 2, but you still have to put in the work if you want a good game.

    A lot of California's suggestions are actually things that the "best practices", "performance tips" and "mobile performance tips" tutorials recommended -- the tutorials you said you'd already followed earlier in the topic.

    No offence intended, but surely now you can see that it wouldn't be fair for Scirra to have to refund your money; your problem aren't because the software isn't capable but because you're too lazy to actually do the work necessary to optimise your game.

    If you want to fix your game we're here to help, but you will have to do the work. Ask us about any of the specific suggestions you don't understand and we can help you with more detailed information.

    Do you want to fix your game, or do you just want to give up?

  • Another option for those without a Mac is to use a service like MacInCloud. <img src="smileys/smiley1.gif" border="0" align="middle">

  • I specifically suggested that you not share your actual game because you were concerned about that.

    Produce a new, similar but simpler capx -- one that uses the same types of objects and events, but not assembled into your actual game play -- that demonstrates the same problem, and share that.

    If what you've said about still experiencing the problem when you remove objects or even your entire event sheet is true this should be pretty easy to do, and then people will actually be able to offer you some suggestions; you might even discover the problem for yourself during the process.

    How are you testing your game? Are you actually running on your iPhone, and have you been testing using the iPhone during the whole process as suggested?

    Do you have pixel rounding turned on?

    Do you have WebGL turned on?

    Do you have sampling set to "point"?

    Do you have clear background set to "no"?

    Do you use a lot of loops in your events?

    Are your sprites overly large? Do you rotate or resize them often during game play?

    Do you have a lot of animations and/or lengthy animations? What speed are they set to play at?

    Are your sprites semi-transparent, and do you use any effects on them?

    Do you use particles?

  • cesarzevil

    No offence intended, but you're just not coming across as reasonable -- if the product genuinely doesn't offer the capabilities it advertises then you would definitely be in the right to ask for your money back -- but that simply isn't the case.

    Why don't you try getting some help to see if you can fix your problem? Other people have achieved some great results with Construct 2, so it's very obviously possible to do so, and if you're getting unacceptable performance with only 4 objects it's likely there's something amiss that could be fixed to improve your results.

    Honestly, it's coming across as if you aren't interested in getting help and don't actually want to try to fix your game.

    Are you using CocoonJS? Ashley asked earlier in the topic, and you haven't answered.

    How are you testing your game? Are you actually running it on the device in question? Have you been doing so from the beginning of your project as advised in the "performance tips" manual entry? Again, you were asked about this earlier in the topic but haven't responded to it.

    I understand that you don't want to share what you're hoping will be your game with everyone -- you want to be able to sell it! However, if you're having the problem even with a reduced number of objects in the scene or without your events then something is obviously wrong -- how about producing a new, simple capx that's similar to your game and sharing that so that people can help you.

    The simple fact is that Construct 2 is capable of better performance than you're describing, and it wouldn't be fair to Scirra to have to give you a refund because you're doing something wrong and refusing to try to fix it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • A few thoughts, in no particular order:

    1. 30 FPS is often an acceptable frame-rate for titles on mobile platforms. Whilst a higher FPS value is obviously preferable, there are realistically only a few types of games that require it, and the main examples of those -- namely, racing games and shooters which require very fast and accurate "twitch" style input -- aren't the sorts of things you would be developing with Construct 2 anyway. If your game has been properly created to be frame-rate independent it really should be playable at 30FPS, and even many professionally created titles made with lower-level technologies are perfectly happy with this sort of performance.

    2. 30 FPS with 9 objects does not necessarily translate to lower performance with more than 9 objects. Often beginners increase the complexity of their games to some certain level, notice that the frame-rate is beginning to drop and assume that anything more complex will be out of the question, but in reality that depends on a number of factors, and unless you've actually tested to be sure it's entirely possible that you could conceivably add quite a few more objects without (or with only minimal) further drop in performance.

    ...and as noted above, for a huge variety of games ~30FPS should be good enough for a playable game.

    3. Other people have successfully created games with Construct 2 that perform acceptably well on the platforms in question. There are limitations to every system, Construct 2 being no exception, but the fact that other people have succeeded shows that it can be done if you have sensible goals and do things correctly.

    4. "Go try something else" is a terrible response. Construct 2 is Ashley and Tom's livelihood, and unless they are able to make a living with it they won't be able to continue their fantastic efforts of constantly adding features and improving things. It really doesn't help them to suggest that someone who complains should just go elsewhere.

    It's frustrating when things don't work the way you want, but rather than screaming "scam" it's pretty likely you can actually solve your problem. Making (good) games is hard, no matter how you do it, and whilst an editor like Construct 2 makes the process a lot easier you still have a lot of work to do yourself if you want to create a good game that performs well -- especially if you're targeting a mobile platform with limited capabilities.

    Follow the recommended best practices, try the performance tips, and if you're still having trouble ask for community input.

  • Any official response? Ashley?

  • The (relatively) new path-finding behaviour is great, but I had one small request:

    Ashley : Would it be possible to add offset values for the positioning of the grid relative to the top and left of the layout?

    In a game I'm working on my map is made up of a grid of fairly large square objects -- this means that I could set the cell size of the path-finding behaviour to the same size as those objects and get very accurate path-finding with good performance... except that thanks to the game's UI elements a grid set to the exact size of the objects doesn't match up with the position of said objects -- this could be fixed if I could specify that the grid should be offset from the top and left sides of the layout to compensate for the UI elements.

    As a side-note the same thing would be useful for the "layout grid"'s "snap to grid" option.

  • The Construct 2 manual can be found HERE -- it's accessible from the top navigation bar of the website.

    There's a download link in the left-hand sidebar on that page, or you can directly access it HERE.

    Reading the manual is an excellent idea, but be sure to actually try out the software as well -- you'll learn much faster by actually doing things with the editor than by simply reading about it.

    <img src="smileys/smiley1.gif" border="0" align="middle">

  • You need to be a registered Apple developer to distribute through the app store, which costs US$99 per year.

    You can build as many "public apps" as you want for free, but if you want to build more than a single "private app" you'll also need a paid plan with PhoneGap Build, which starts from US$9.99 per month. Public apps must have their sourcecode hosted in a publicly accessible GitHub repository, which probably isn't what you want if you're trying to distribute a commercial app.

    Does that help?