Forums

OverviewV-Play 1 Support › Positioning entities at center versus topleft (and dragging onto moved levels)

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #7392

    Arend

    Hi there,

    I’ve been trying to create a level editor for my game and while I’ve been succeeding largely so far :), I’ve also run into some issues that I’d hope to get some second thoughts on…

     

    The main issue I’ve been having is one of positioning. All entities have a position, and from what I understand the position coordinate is actually the center point of the entity, which is nicely demonstrated by the sprite image being anchored to the center of the entity. Unfortunately, this is giving problems for me as soon as I want to create entities of varying sizes. Let’s say I have a grid size of 16×16, which is also the size most entities use. But then if I want to add a bigger entity, say 32×32, the problem I have is the center of the 32×32 entity is aligned on the 16×16 grid and because of that the entity “sticks out” by 8 pixels ( (32-16) / 2 ) on each side and thus gets misaligned with the 16×16 entities. So I’ve tried to solve this by aligning my entities at the topleft corner instead. This works mainly, but gives me two small annoyances:

    • The “notAllowedRectangle” item appears hard-coded to assume the entities are center-aligned and as such gets misaligned during drag operations. I’ve tried to overwrite this behavior by adding my own “notAllowedRectangle” item in my custom entity base (which inherits EntityBaseDraggable), but rather than overwriting the item from the base, I got two rectangles instead :) For this reason I would appreciate it if there was some ability to customize the behavior of the “notAllowedRectangle” item. (Or is there already some way to customize V-Play’s core QML items without compromising portability?)
    • For some reason it appears the coordinate (0, 0) is considered “out of bounds” by the collision detection algorithm, as well as any coordinate along the 0 X- or Y-axis. This is not a big problem as I could just move the background to offset the grid, but it feels a bit unnatural. It seems this also stems from the assumption that entities are always positioned by their center point, so I guess it boils down to the same question: Is there some easy way to customize this? Or otherwise the ability to customize it would be desired.

    Of course the fundamental question I might need to ask myself is, is it the right way to go to try and position entities by their topleft corner? Or is there some reason I’m overlooking for why center-positioning would still be preferred?

     

    Some unrelated issue I’m facing has to do with dragging entities into my level using a BuildEntityButton. I’m trying to create rather big levels (bigger than the scene), so I’ve implemented the ability to move the level around using the arrow keys. Unfortunately, when I try to drag ‘n drop an entity from the BuildEntityButton to the level while the level has been moved from its original position, the position of the entity is always wrong by exactly the opposite offset by which the level has been moved. For the actual drop action, this is easily corrected in the BuildEntityButton like this:

     

    onEntityWasBuilt: {
    var newEntity = entityManager.getEntityById(builtEntityId);
    // correct for the level position
    newEntity.x -= level.x;
    newEntity.y -= level.y;
    }

    But there is still the problem of collission detection during dragging which is wrong by the same offset as well, and I’ve not been able to easily correct this. Fortunately, once the entity is dropped into the level and dragged from there, there is no problem, but the initial placement remains problematic.

    Now, I suspect this might have something to do with how I set up my EntityManager:

     

    EntityManager {
    id: entityManager
    entityContainer: level || scene

    // …
    }

    The awkward “level || scene” is there because if I left it with just “level”, the BuildEntityButton wouldn’t work at all, presumably because it would’ve created instances to build at some moment the level was not available yet, as the level is loaded dynamically through the LevelLoader. Therefore I suspect the entity has the wrong offset because it’s still parented to the scene rather than the level, which would explain why the problem disappears after the entity has been added to the level. However, I’m unsure how I can test this hypothesis, or how to correct the situation if it is true.

     

    If someone could offer some insight into how I can improve this situation it would be greatly appreciated :)

     

    Thanks!

    Arend jr.

     

    #7398

    Alex
    V-Play Team

    Hi Arend,

    I will try to cover all your questions one by one :)

    — the not allowed rectangle:
    You can simply hide the default rectangle with the showRectangleWhenBuildingNotAllowed property set to false.

    — building on 0-coordinates:

    You are right, the algorithm considers 0 as out of bounds. However you can outmaneuver this behavior by overriding the “internal” property of the EntityBaseDraggable:

    __towerSizeInGridsHalf: colliderSize/(2*gridSize)-1 // the -1 is added to the original calculation

    I ran some tests with it and it seems to work flawless.

    — offsets:

    Since the entities should be created in the level, the entityContainer of the EntityManager must be the level. Also the PhysicsWorld must be inside the level or the colliders will not move accordingly when the level is moved.

    — entity origin:

    As long as you are not rotating the entity, using the top-left corner is just fine in my opinion.

     

    If you are still facing issues, could you create a small demo project that contains the errors and post the code here or send them to support@v-play.net? I can then try to debug them further.

    Cheers,
    Alex

     

    • This reply was modified 4 years, 7 months ago by  Alex.
    #7400

    Arend

    Hi Alex,

    Thanks for your swift and thorough reply!

     

    I’ve taken your advice on the “not allowed rectangle” and 0-coordinates, but implemented them in a bit of a non-conventional way :) I’ve taken the full source of BaseEntityDraggable and merged it into my own base class, stripped it down to the essentials relevant to my use-cases and modified it to my requirements. So rather than inheriting from BaseEntityDraggable, I used it as a template for my own base class now. It took a bit of effort to take everything apart, but I learned quite a bit from it and it now behaves exactly the way I want it to :)

     

    Regarding the offsets, I moved the PhysicsWorld from the Scene into the Level, but that did not result in any visible difference for me. But indeed the problem was the entityContainer was still defaulting to the scene rather than the level for the BuildEntityButtons. I’ve reverted the “level || scene” statement back to “level”, but now indeed the BuildEntityButtons again didn’t work anymore, they kept failing with the message:

    file::/qml/VPlay/level/BuildEntityButton.qml:372: TypeError: Result of expression 'createdEntity' [undefined] is not an object.

    However, I did manage to work around it now by putting the Item hosting the BuildEntityButtons into a Component and loading it with a Loader item *after* the level had finished loading. Now it worked again, and indeed the offsets were correct from the start now.

     

    Thanks & cheers!

    Arend.

    • This reply was modified 4 years, 7 months ago by  arendjr.
Viewing 3 posts - 1 through 3 (of 3 total)

RSS feed for this thread

You must be logged in to reply to this topic.

Voted #1 for:

  • Easiest to learn
  • Most time saving
  • Best support

Develop Cross-Platform Apps and Games 50% Faster!

  • Voted the best supported, most time-saving and easiest to learn cross-platform development tool
  • Based on the Qt framework, with native performance and appearance on all platforms including iOS and Android
  • Offers a variety of plugins to monetize, analyze and engage users
FREE!
create apps
create games
cross platform
native performance
3rd party services
game network
multiplayer
level editor
easiest to learn
biggest time saving
best support