Jaycephus's Forum Posts

  • Thanks. I'll check this out later today.

    Yes, that was one thing I was wondering about, if families should be used. No manual update on families yet.

  • I have a beginning project built for an RTS. It is a scrollable, zoomable background with main and GUI layers, and includes a clickable mini-map.

    So just consider that this project will be a simple form of tower defense. The scroll and zoom aren't really required at this point.

    Consider player objects are fixed. These would initially just be a tower-type of object. (A GUI for placing those, and additional variety can come later and is not really in the scope of this example, at least not yet.) For now, let's just do whatever is easiest, such as pre-create those programmatically. Need to spawn enemies as well, which move toward target (center of map). Assume that enemies are 'fliers', so they move without need for complex path-finding for now. Player base is at center of map. A consideration is that enemies would be created in waves, but I'm not sure that is really a big factor in the structure of tracking and handling them, only in the initial spawning of them. So that might be out of the scope of this example too.

    I would like to be able to easily increase and extend the types of player and enemy objects as development continues.

    I figure this is a fairly simple learning project, but useful for the style of game I am trying to create.

    (I'd also like to put the whole experience of this learning project into a tutorial series, since I would like to encourage others to come up with some good RTS games.)

    Thanks

  • Certainly. :)

    It's not so much the counts involved, but the structure you would use to handle more than a handful of objects.

    Thank you

  • Is there a good example of a game that has a lot of onscreen enemies, and other objects such as bullets and/or missiles fired from these enemies, player objects, and checking or tracking of missiles to targets, bullet-collision, etc?

    I want to see how to structure such a game within C2.

    Thanks

  • Thanks very much for the reply. Appreciate it!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Right now, I'm using a plain sprite rectangle to indicate the viewport on the minimap, resizing depending on zoom level.

    But I'm also curious about whether 'drawing' a lot of enemies, bullets, missiles, etc, is better than using pixel sprites instead.

  • In C2, what is the best way to display a resizable rectangle? With this plugin?

    Or just make a square sprite and change its dimensions?

    Or is it about the same in terms of memory/speed for a 1-50 instances?

    One thing I want to do is make a view-port rectangle in a minimap.

    (A one-pixel un-filled rectangle would work. Or I could draw a rectangular sprite, resized on the fly, to represent the same thing.)

    Thanks

  • There are actually two issues described above:

    Yes, when Unbounded Scrolling is set to YES, the event handling on my side I JUST now discovered, is at fault. (rookie Construct mistake, I know: missing the Else-ness in my logic.)

    However, the behavior when Unbounded Scrolling is set to NO is seemingly completely messed up when zoomed in at about scaling less than .5 in my app. (Try the newly edited capx with Unbounded Scrolling set to YES, then set it to NO and scroll 'down'/zoom in to observe this.) So even though the current code never sets ScrollX & ScrollY out-of-bounds while dragging due to the above bounds checking, the auto-bounds setting seems to be erroneously forcing the viewport well out-of-bounds when zoomed all the way in (scaling of 0.1).

    http://dl.dropbox.com/u/67882392/MyRTS%20zoom-pan.capx

  • I'm pretty sure the exact same behavior was present in r81, especially the auto-bounds when zoomed in problem. But testing today was on r82. I tried this on Vista 64 and Win7 64, both times in a Chrome browser, both with r82. I believe that the Win7 system has the latest 32-bit Java for running Processing.js in Chrome.

  • In the capx, it works as intended as saved. un-comment the commented section in the scrolling group to see the problem. Also, set Unbounded scrolling to NO to see the problem with auto-bounding when zoomed in.

    Due to the current layout.y size bug, I couldn't make it as big as I wanted, but it should be fine to demonstrate the problem.

    Also, since I currently have a working version, is the multi-layer x,y,& z parallax effect a good subject for a tutorial? If it hasn't been covered, I'll do one.

    Thanks,

  • r81, r82: problem checking if viewport in-bounds on right and lower edges:

    I don't know if this is a bug or my inexperience with this system, but...

    The intention of my capx is to create an in-browser RTS game with left-mouse click-drag for panning, and scroll-wheel zooming, and it is currently a working background with pan and zoom.

    I have working zoom and pan, and with only the need to 'stay in bounds' of the layout being the problem, so when drag-panning, the view-port size/position must be compared to the bounds of the layout, and also while zooming out, the same checks must occur. For reasons explained below, this manual check for bounds must be done. (All is much clearer in the attached capx.)

    RTS pan-zoom test

    Zoom out code works: Since while zooming out, scrollX & scrollY are presumably in-bounds at the beginning, but as the view-port 'grows' actual scrollX (mid-point of the view-port) ends up closer to the edge of the layout, and it can be possible to see the edge of the layout at full zoom-out, so each mouse-wheel-up event checks scrollX and scrollY, and forces the view-port back in-bounds if necessary. Works.

    Scrolling:

    During the scrolling, the mouse is dragging the layout left, or actually the view-port to the right. Here, I started out trying to compare the value that is 'about' to be applied to see if it is in-bounds, and then only apply values to scrollX & scrollY that are in-bounds. Works on the left and upper bounds, but not the lower and right bounds. The only workaround is to just go ahead an apply the value regardless, THEN do the checks in the same way as the zoom-out code does, comparing the actual scrollX & scrollY values to see if they have gotten out of bounds, and THEN forcing them back in again.

    Finally, all attempts to use both zooming and the Unbounded scrolling : OFF feature were a failure. EVEN with the workaround in place where the code appears to keep the view-port in-bounds at all times, if Unbounded scrolling is set to NO, very weird interactions occur when zoomed out (about 0.3 to 0.1 scaling). When zoomed at 1.0 or near to it, the auto-bounds is fine.

    So to recap:

    With the initial method, the view-port can be dragged infinitely to the right or down, but the upper and left bounds work fine. If out of bounds to the right or bottom, the moment the zoom-out code is triggered, it is forced back in-bounds, as checking against scrollX works fine.