Wastrel's Forum Posts

  • Utternoob, I started out using Construct 2 and have never used Construct Classic. The biggest obstacle I have encountered is when developers in the Construct 2 forums reference some feature that is available in CC, and talk about their issue, or whatever, in that context. It just sometimes takes me a little longer to figure out what they are talking about.

    Other than that, starting with C2 has been a really good experience. I can tell that all of Ashley's and Tom's experience with CC has made C2 a really good product from the start, and it will only get better.

    You should consider that C2 is still in beta, so it may be missing some standard features and/or contain bugs. On the other hand, though, it's kind of exciting to be involved in something new and still in the development stages, which gives you the opportunity to help direct its future by requesting features and pointing out improvements and bugs.

    You should also consider your goals in game development. I am a pure hobbyist. I don't really care if I ever make money with a game or not. I just do it because I love it. Thus, I am not worried so much about C2's current state or when it will have certain features.

    If your goal is to make some money as a developer (which is a reasonable goal) then you may want to look at CC instead, since it is much more mature and has a larger base of support.

    These are just my opinions, based on my experiences so far, so take them for what they are. I'm sure some of the more experienced developers will have more relevant opinions.

    Good luck!

  • —: I don't believe there is. I haven't found it either, if it exists. I have been making my own grid and putting it in its own layer so I can turn it on and off.

  • I'm not sure if this is the right place, but I'd like to make a request for a feature in the IDE.

    Would it be possible to save the snap-to-grid settings with the project or in some other fashion?

    I realize this isn't a critical request, but I just thought I would put it out there.

    Thanks!

  • I fixed a few issues from before. Here is the latest capx:

    http://dl.dropbox.com/u/38038537/TestPathfinding-01.capx

    Fixed issues include:

    • Precision of the movement to the final destination coordinates was fixed by adding an event that replaces the final coordinates in the path list with the original mouse-click x,y coordinates.
    • Added a check for the initial movement in the path to see if the distance between the player sprite at the second path coordinate was less than the distance between the first and second coordinates. This fixed an issue where if the first set of coordinates were in the wrong direction (i.e. farther from the second set of coordinates than the player sprite), the sprite would turn and move to the first set, then move to the second set. If this situation occurs, the first set is just skipped.
    • Worked around the obstacle issue (where is would only recognize the last obstacle set in the events) by only creating one obstacle sprite, then creating an obstacle layer, and setting it to invisible. This way, the obstacle matrix can be designed on one layer, and the environment objects can be designed on a different layer, using the obstacle layer as a reference. I tried using one sprite with animation, but I failed, and this solution seems cleaner.

    There still seems to be an issue when a path is generated using cut-corner, the player sprite will still bleed over into to environment (i.e. the walls).

    I also added a check to the mouse-click events to make sure the player can't click on an obstacle grid square. If they do, the player sprite will ignore the obstacle and move into the square. If you disable the condition in the Controls group, and them click on a wall, you can see the issue.

    Thanks!

  • This is because the pathfinding is made as a grid like in the example with S and D. When you drop the Destination icon wherever on a cell, it is automaticly repositionned to its center. That's because the center of the cell IS the target, its X and Y position, its center.

    The pathfinder will locate the X and Y of the target object and will check in what cell this position actually is (so if your target object is put in between 4 cells at the same time, having bits of it being present in 4 cells, only the cell which contains the actual X and Y coordinates of the object will be set as destination of the pathfinder.)

    Same principle goes for the Source object. It's X and Y defines the starting cell.

    I may be unclear, I'll document it more in the next version of the pathfinder.

    No, that makes perfect sense. I will work on modifying the events so that the correct coordinates get assigned. I think that will take care of things being slightly off.

    A workaround that could work for now would be to have a single object "Wall", set as obstacle.

    Its animation would contain different frames, holding the several textures (WallHorz, WallVert and WallColumn).

    On startup you assign the right frame to the object (you might "mark" the instances with an instance variable and display the correct frame for the setted value on start of layout).

    I will give this a try.

    Also be sure to keep consistency in the size of the objects. Your player is 80 pixel of height, be sure that your obstacles are also 80X80px.

    For the obstacle, it's not taking only the X,Y position into account, but the bounding box.

    Meaning that on the path calculation, if any bit of the bounding box of the obstacle is colliding/overlapsing a cell, the cell will be marked as unwalkable. I'll document on that too.

    I will re-size the sprites. I thought earlier that this might cause an issue, but then forgot to go back and change them.

    If you don't mind, I'll use this example of yours (and work on it for tests and improvements) for the future releases of the behavior.

    Thanks for the working on the behavior.

    Of course I don't mind. Thank YOU for working on the path-finding!

  • ScottP: thanks for the example

    I was finally able to find time to work on the mouse-click movement using Kyatric's path-finding plug-in.

    Here is the example capx:

    http://dl.dropbox.com/u/38038537/TestPathfinding-00.capx

    There are still some issues I need to resolve:

    • I need to refine the setting of the player sprite angle towards the target.
    • I need to refine the final movements of the player sprite to the target. The final position of the sprite always seem to be a bit off of the actual target coordinates.
    • It appears that when setting the path-finding obstacle, it only recognizes the final obstacle set in the event sheet. I think I may not be setting the obstacle list correctly. In the example, you can see that the only obstacle recognized is the horizontal wall. The player sprite will walk right through the vertical wall and the column obstacles.

    Overall, it seems to work pretty well. I am open to any suggestions for making it more elegant or precise.

    Also, I am still getting up to speed on JavaScript and the SDK, but I am wondering if this type of movement using a path list would translate well to a plug-in, or if it is better handled through events.

    Thanks!

  • Rez, that is really cool. I haven't played with it yet, so this may be obvious, but can the LightCell be any shape and color, or does it need to be a black square.

    Also, please develop a game using DrunkGuy. I would play that game! :D

    Seeing all of these new behaviors is really giving me the itch to start making my own plug-ins. I do know some JavaScript, although it's mostly been for one-off admin tasks at work. Did you find it easy to figure out?

  • alexh: do you have an example capx we can see?

  • ScottP: The link isn't working for me.

  • Thank you both for your insight and the links. I think it's actually starting to sink in.

  • There are certain points in the processing of an event sheet for which I need some clarification.

    I found this from deadeye in the CC forums:

    "For Each" is a loop. Think of your events like so:

    1. Top of event sheet

    2. Do some stuff

    3a. Loop fifty times                  <--- this is your For Each

        3b. Do stuff fifty times

        3c. Go back to 3a fifty times

    4. Do some more stuff

    5. Go back to Top of event sheet

    The event sheet is read from top to bottom, and then starts over again. Since the whole event sheet itself is a loop, then the For Each is basically a loop within a loop.

    From what I understand, the whole event sheet is processed every tick, and there are 60 ticks per second, which (obviously) means the event sheet is processed 60 times per second.

    If I have a For loop embedded in the event sheet, does the processing of the rest of the sheet stop while the For loop is processed, then the processing continues on with the next event after the For loop? If so, what happens if the processing of the For loop takes a "long" time, say 2-3 seconds? Doesn't that throw off the 60 ticks per second processing of the even sheet?

    If someone could clarify how this works, I would greatly appreciate it. I like the concept of the event sheet, but as I get deeper into it, I am realizing just how ignorant I am.

    Thanks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I will check out the capx when I get home.

    I totally agree that the path finding and movement should be completely separate behaviors. I'm trying to come up with a movement pseudo-behavior (i.e. all event driven) that will accept an array of positions, but I think I have a basic mis-undertstanding about how the event sheet is processed.

  • It seems to me that you would want to keep the path-finding and movement behaviors separate. You would use the path-finding behavior to generate a path list, then use a movement behavior to execute the path list.

    Looking at the bullet behavior, for instance, behind the scenes, it is generating its own linear path, then following that path every tick.

    What we would need is a modified movement behavior which could accept a path list as a parameter. That path list could be from any source, whether it be from the path-finding behavior, or a more linear function.

    I am working on building something using events, and i will post the capx once I have something working. Iam still trying to wrap my head around the JavaScript SDK and building plug-ins, so I will have to do it the hard way for now.

  • I am trying to use the pathfinding behavior, and am having problems trying to get the player sprite animation working. I think it is fairly simple, I'm just ignorant of how to get it to work.

    Here is the capx I've been working on: dl.dropbox.com/u/38038537/TestPathfinding.capx

    Here are the steps I think should happen:

    1. Initialize pathfinding

    2. Generate pathfinding based on a mouse click

    3. Move player sprite to target location along path

    If you have reference to a demo I've missed, or can just tell me what I am doing wrong, I would greatly appreciate it.

    Please let me know if you need any more information.

    Thanks!