R0J0hound's Forum Posts

  • Yeah, any kind of variable should work. Global or instance for example.

  • If you’re moving manually I suppose that means you aren’t using a behavior and can’t use their angle of motion expression.

    If you manually move an object by changing its velocity you could calculate the angle of motion with:

    angle(0,0,velocityX,velocityY)

    If instead you move an object by changing an object’s position you can calculate it by saving the position to some variables, manually moving the sprite, then calculating the angle.

    1. Set oldx to sprite.x, set oldy to sprite.y

    2. Manually move sprite

    3. Set angle to angle(oldx,oldy,sprite.x,sprite.y)

    That’s useful for calculating an angle of motion no matter what you use.

    You could calculate a 3d orientation instead but I say it’s simpler to just fake it with 2d angles till you can’t.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It’s not the full three.js library, it’s a half sized subset that appears to mostly include math and model loading portions. The rendering stuff isn’t in it. So my guess is they are experimenting with utilizing it to load gltf files instead of implementing a loader themselves.

    Anyways, all that hints at is Ashley may be investigating and/or experimenting with some more 3d stuff. Best case we’ll get some new 3d features in a near future release.

    Traditionally we only get to see what they are working on once it works and is part of a release. So I guess just wait and see.

  • You could also keep using the double loop, make them invisible after creation, then add a wait before making it visible again.

    Wait (loopindex(“x”)-1)*24+loopindex(“y”)

    Or

    Wait (loopindex(“y”)-1)*40+loopindex(“x”)

    Depending on the order you want them to appear

  • You do not have permission to view this post

  • You can probably get familiar with manipulating the 3d camera by looking at existing examples and just copying what they do.

    Flying could be as simple as just moving the player with an 8direction behavior and increasing the zelevation when a button is down, otherwise move it down.

    One possible following camera could be to consider the angle the player is moving, and position the camera some distance behind it and higher.

    Maybe use look at action

    Camera position: (player.x-200*cos(player.8direction.angleOfMotion), player.y-200*sin(player.8direction.angleOfMotion), player.zelevation+50)

    Look at: (player.x, player.y, player.zelevation)

    Up vector: (0,0,1)

    All that is vector math if you want to know what to google to expand your knowledge. You could make it smoother with some easing as well, which would simulate the camera man‘s delayed reaction of what the player does.

    It may also be useful to try similar ideas in just 2d to get the concepts down. 2d is way easier and construct provides a lot for you. Construct provides very little to assist with 3d stuff so you’ll end up needing to use a lot more math.

  • So it’s not centering horizontally? Wouldn’t that mean it’s not correct? It could just relate to where the origin of your sprites are.

    I find it useful to re derive formulas when the result isn’t what I’m after. If the box origin is at the top left, then you can center a 3xN grid of boxes with the following. 

    Repeat count times
— create box at center.x+(loopindex%3)*box.width-3*box.width/2, center.y+int(loopindex/3)*box.height-int((count-1)/3)*box.height/2

    What if the box origins are centered? Then the positions will be off by half the size of the box. Based on your image the origin may be right-center, so just add box.width to the x position to center everything.

  • Minimally being able to do at least the following would be useful:

    * Move/zoom/rotate view in 3d

    * Be able to select objects from any view angle.

    * Move/scale/rotate objects freely in 3d.

    It would also be a good opportunity to modify some existing limitations.

    * Rotation for all objects are currently limited to only on the xy plane. At least 3dshapes and mesh distorted objects could be able to be rotated freely in 3d.

    * with mesh distorts there currently is the limitation where a point’s zelevation can only be greater than zero. Changing that to allow negative zelevations would add more flexibility.

    Runtime raycasts, collision detection and physics, like fedca said, could be made as a third party addon if not done officially right away. We just need read/write access to any object’s position/rotation, and at least read only access to object’s size/geometry, and the camera’s view and perspective matrices (for mouse raycasts). C3 already provides access to most but not all of that with the js api, however I haven’t investigated in a bit.

  • I can't reproduce that. Tween always stops at an exact value in my tests.

  • I mean doing:

    Every tick

    — set layer 0 scroll to scrollx+16, scrolly

    Seems to do the trick. But it still is subject to bounded scrolling along the edges of the layout unless you select unbounded scrolling on the layout properties.

  • Probably the set layer scroll action.

  • Maybe try a different algorithm to generate the maze? Or you’ll have to explain how the algorithm you’re using should work. Maybe your logic is flawed, or maybe you made a typo somewhere.

  • I should clarify that I don’t make or sell templates. I can appreciate the desire to take on a coder to implement the game mechanics but I’m not your guy since I’m not available for such a time commitment.

    With my limited time I like answering posts with ideas or concepts on how to do things. But rarely am I able to provide complete solutions that don’t have to be adapted to your project.

    Anyways. There’s already a few examples to try here in this topic. Dops example can be made in c2 no problem. It’s not using any new c3 features. Isn’t it possible to just recreate a c2 project in the same way as the c3 one?

  • I’d rather help convey ideas and suggestions that you can implement instead of making the game for you or taking your money.

    What specifically are you having trouble with? I’m sure showing what you have and listing what’s not working can allow more people to maybe help.

    If there’s ever something you can’t figure out how to do, there also is some simpler variation you can do to build your skills.

    For example: have you tried your hand at doing all that logic with just squares instead of with an isometric grid? That would be one approach to work out the logic easier and you’d just make it isometric afterwards.

    Or you could forget all the math and do it a different way.

    1. Add a sprite for an isometric square and call it “square”. Draw it as an isometric square and put the image origin at the bottom corner.

    2. Place a bunch of them down in the editor to make your iso grid just like the image of a grid you posted. To assist, you can turn on the editor’s grid and make the grid width to half the square’s width, and the height to half the square’s height.

    3. Add another sprite for the isometric objects you want to move around. For example a “cube.” Draw an isometric cube and set the origin at the bottom corner. You can customize the collision polygon so it matches the image better if you like. Place one or more of those on the layout on top of the squares.

    4. Next let’s get it ready for events. Add the drag drop behavior to the cube, and add an instance variable number to the square sprite and call it “occupied.”

    5. Ok now events. The logic we are going for is to lock the cube objects to the nearest squares when not dragging. And we set the square’s occupied variable to true when there’s a cube on it so we can tell if a square is free or not.

    Then events would look like: 

    Start of layout
— square: set occupied to 0

Start of layout
For each cube
Square: occupied=0
Square: pick closest to cube
— cube: set position to square
— square: set occupied to 1

Cube: on drag start
Square: pick closest to cube
— square: set occupied to 0

Cube: on drop
Square: occupied=0
Square: pick closest to cube
— cube: set position to square
— square: set occupied to 1

For each cube ordered by cube.y ascending
— cube: move to front

    And viola! Basically no math to snap objects to empty spaces on an isometric grid. And ripe to be heavily tweaked to any more complex behavior you like.

  • Snapping can be done by converting the xy positions to isometric, snapping that and converting it back to xy.

    Xy to iso:

    ix=y+x/2

    iy=y-x/2

    ISO to xy:

    X=ix-iy

    Y=(ix+iy)/2

    You can modify those slightly to align the grid from somewhere different than (0,0) to say (cx,cy):

    Xy to iso:

    ix=y-cy+(x-cx)/2

    iy=y-cy-(x-cx)/2

    ISO to xy:

    X=ix-iy+cx

    Y=(ix+iy)/2+cy

    And finally the snapping formula:

    Int(X/grid)*grid

    Combined snapping to an isometric grid would look like this: 

    set x to sprite.x-corner.x
Set y to sprite.y-corner.y
Set ix to int((y+x/2)/grid)*grid
Set iy to int((y-x/2)/grid)*grid
Set x to ix-iy+corner.x
Set y to (ix+iy)/2+corner.y

    After snapping you only need to check grid positions to see if an object is there. Whether that be picking objects at an xy or the closest to an xy that’s a small distance away. You could also check if an object is overlapping a point if you setup the collision polygon to only overlap the base of the object. You could also use an array to store the object’s snapped isometric coordinates *grid. But you’d need to select a corner so that those values aren’t negative.

    The simplest is probably just setting the object’s collision polygon to just cover the base, then put all your isometric objects in a family. Then you’d know if a space was occupied with a condition like:

    System: family overlaps point x,y